You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
alt-src does not manage its lockfile correctly with respect to cleaning up an incomplete working directory.
See for example this log:
2020-02-04 18:37:55,304 [INFO] Lock acquired
2020-02-04 18:37:55,305 [WARNING] Incomplete staging dir /mnt/redhat/altsrc/staging/stage/c8-stream-rhel8/rpms/c/conmon/conmon-2.0.6-1.module+el8.1.1+5259+bcdd613a (state=None), will overwrite.
2020-02-04 18:37:55,318 [ERROR] Staging failed
Traceback (most recent call last):
File "/usr/bin/alt-src", line 2065, in main
task.run()
File "/usr/bin/alt-src", line 646, in run
if self.make_workdir() in ['STAGED', 'PUSHED']:
File "/usr/bin/alt-src", line 691, in make_workdir
koji.util.rmtree(dirname)
File "/usr/lib/python2.4/site-packages/koji/util.py", line 297, in rmtree
os.rmdir(path)
OSError: [Errno 39] Directory not empty: '/mnt/redhat/altsrc/staging/stage/c8-stream-rhel8/rpms/c/conmon/conmon-2.0.6-1.module+el8.1.1+5259+bcdd613a'
alt-src acquires a lock on a file to ensure no other run on the same package is in progress.
alt-src determines that the working directory is incomplete and decides to remove it before continuing.
Problem: the lock file is contained within the directory we're deleting.
I'm not certain, but what happens next might depend on the filesystem in use. In the above example, where NFS is used, we can see that it causes the rmtree operation to fail. In other cases, perhaps it wouldn't cause a failure, but would still be wrong as it would cause the lock to become ineffective (as nothing would prevent another process from creating another lock file at the target path).
This needs to be fixed so that alt-src does not attempt to delete its own lock file when cleaning an incomplete working directory.
The text was updated successfully, but these errors were encountered:
alt-src does not manage its lockfile correctly with respect to cleaning up an incomplete working directory.
See for example this log:
Problem: the lock file is contained within the directory we're deleting.
I'm not certain, but what happens next might depend on the filesystem in use. In the above example, where NFS is used, we can see that it causes the rmtree operation to fail. In other cases, perhaps it wouldn't cause a failure, but would still be wrong as it would cause the lock to become ineffective (as nothing would prevent another process from creating another lock file at the target path).
This needs to be fixed so that alt-src does not attempt to delete its own lock file when cleaning an incomplete working directory.
The text was updated successfully, but these errors were encountered: