The dataskq did not previously handle the SIGTERM signal as it was not a daemon. However, there are cases when it might exit prematurely (Eg: server reboot) where a SIGTERM is sent to it. The issue was that any lock files created were not being cleaned up. Fix - added a lock file tracker (added to list when lock is created, removed from list when unlocked). - signal handler for SIGTERM in the dataskq to call a cleanup of any leftover items in this list. Cleanup calls also added to directadmin processes, in case they've missed their unlock state (not aware of issues there, but backup check is low cost to add). Should any cleanup happen, you'll see this in your system.log and (error.log or errortaskq.log): sys::remove_tracked_temporary_files: removed temporary file '%s' where %s is replaced with the file that was removed. The tracker also know which uid/gid the locks were created as, thus they'll be removed with the same access level.