darcs repository web UI and hosting app. This is the main darcsden trunk, which also runs hub.darcs.net. (https://hub.darcs.net)
#46if user kills a push, the lock file is not removed, preventing subsequent pushes
push can be slow, and can be killed, and darcsden (or darcs, it's not clear whose bug this is) should immediately remove the lock file in this case. Also in similar cases such as a lost connection during push.
Currently a cron script cleans up the stale lock files, but it's pretty dumb and can't identify stale locks less than a day old. This could be improved, but better to fix the bug.
I'll offer a bounty of $10 on this.. anyone else ?
- added tag bounty:$10
saneRepo path darcsTransferMode >> clearLock $ saneUser ...
clearLock :: FilePath -> IO () clearLock fn = removeFile fn
catchhandleExists where handleExists e | isDoesNotExistError e = return () | otherwise = throwIO eAlso.. The lock file is always left there (if the user kills the connection/process)... so maybe run clearLock on connection close. Makes more sense.
Or better for the code for clearLock = when fileExists $ removeFile -- :)
^ Problem with removing the lockfile like this is... You'd have to check that the user isn't already doing something or the lock file is rendered useless. :|
The ssh server was not successfully terminating darcs subprocesses (and cleaning up their locks) on interruption. A fix has been deployed that seems to solve the problem (close the subprocess's stdin as well as sending the termination signal - http://hub.darcs.net/simon/ssh/browse/src/SSH/Channel.hs#178).
There is another failure mode known to be possible though not probable: if darcs push of a large patch causes darcsden to use up available memory and be killed by the Linux OOM killer, the lock file will not be cleaned up. I have an hourly check for lock files which should let me know if this happens.
So far so good, closing this. The bounty is claimed by me and Heffalump, and donated towards project hosting expenses.
- status set to closed
OOM kills turn out to be quite possible indeed, taking this up at #51.
