Changed to a custom user process kill, during User removal

Version 1.53

Bugfix
Finished

UPDATE: September 1, 2018: Bug found, fixed for DA 1.53.5: https://www.directadmin.com/features.php?id=2177 ============== Only reported on CloudLinux boxes. Not sure if it's caused by a recent CL update. May undo this change if it's found that it has no effect. the userdel call is going defunct, and DA is left waiting for it's return, which never comes. Suspect wast this recent change to killall: https://www.directadmin.com/features.php?id=1898 but some strange behaviors started to pop up where it would end up killing bits of the directadmin process, even after the killall had returned. It's possible killall (possibly just in CloudLinux, not sure) where it sticks around after the fact to make sure all processes are dead (just a theory) Changed to instead delete the User first, and then go through all processes that were running at that old UID number (noted before User removal) Each of those UID based processes are removed while running at that UID, to reduce the chance of issues (the list is obtained while running as root.. we don't want to commit suicide) Then this is all done one more time, in case a master process had spawned an other child after it's SIGTERM (unlikely, but good to be sure) User suspension will still use the killall method (no reports of issues, as userdel isn't run during suspension) ------- after testing, this change was found to have no effect at all. May undo it. More info will determine the course of action.

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