• T
    Remove lockfile from mainUtils · 8190ed40
    Tyler Ramer 提交于
    [Lockfile](https://pypi.org/project/lockfile/) has not been maintained
    since around 2015. Further, the functionality it provided seems poor - a
    review of the code indicated that it used the presence of the PID file
    itself as the lock - in Unix, using a file's existence followed by a
    creation is not atomic, so a lock could be prone to race conditions.
    
    The lockfile package also did not clean up after itself - a process
    which was destroyed unexpectedly would not clear the created locks, so
    some faulty logic was added to mainUtils.py, which checked to see if a
    process with the same PID as the lockfile's creator was running. This
    is obviously failure prone, as a new process might be assigned the same
    PID as the old lockfile's owner, without actually being the same process.
    
    (Of note, the SIG_DFL argument to os.kill() is not a signal at all, but
    rather of type signal.handler. It appears that the python cast this
    handler to the int 0, which, according to man 2 kill, leads to no signal
    being sent, but existance and permission checks are still performed. So
    it is a happy accident that this code worked at all)
    
    This commit removes lockfile from the codebase entirely.
    
    It also adds a "PIDLockFile" class which provides an atomic-guarenteed
    lock via the mkdir and rmdir commands on Unix - thus, it is not safely
    portable to Windows, but this should not be an issue as only Unix-based
    utilities use the "simple_main()" function.
    
    PIDLockFile provides API compatible classes to replace most of the
    functionality from lockfile.PidLockFile, but does remove any timeout
    logic as it was not used in any meaningful sense - a hard-coded timeout
    of 1 second was used, but an immediate result of if the lock is held is
    sufficient.
    
    PIDLockFile also includes appropriate __enter__, __exit__, and __del__
    attributes, so that, should we extend this class in the future, with
    syntax is functional, and __del__ calls release, so a process reaped
    unexpectedly should still clean its own locks as part of the garbage
    collection process.
    Authored-by: NTyler Ramer <tramer@pivotal.io>
    8190ed40