Race condition during account deletion

Version 1.533

Feature
Finished

Lets say we have 2 User accounts and they're both going to be deleted. User A fairly large, and is deleted first, this will take a while. In a 2nd call, before the deletion of A is done, another call is made to remove the smaller user B. The 2nd call finished before the 1st call. Both Users are gone, but User A is still in the list. Why? We have a race condition, where DA reads the users.list file at the start of the deletion, removes the user from the list, and only after the account is gone is the users.list rewritten. Because the start/end of the 2nd deletion of B happened after the read, and before the write of A, either: - User B would still be in the list, since A had the final say, and wasn't aware of the deletion - DA noticed a change in the users.list, but due to deletion, it decided this process should win, so overwrite the users.list with the removed A, thus leaving B in the list again. Code has been changed so that anytime an account is removed from any of: users.list reseller.list admin.list At that moment (after the account data is actually gone) it will: - lock the file - re-read the file, in case there were other changes - remove the line from the container (in memory) - write the file - unlock the file This "point of time" method is better, avoid race conditions and should prevent stray Users from the users.list during removal of larger accounts.

Interested to try DirectAdmin? Get a 30-day Free Trial!