Ensure that all lock fds are close-on-exec, fixing various problems with them being inherited by child processes such as git commands.

(With the exception of daemon pid locking.)

This fixes at part of #758630. I reproduced the assistant locking eg, a
removable drive's annex journal lock file and forking a long-running
git-cat-file process that inherited that lock.

This did not affect Windows.

Considered doing a portable Utility.LockFile layer, but git-annex uses
posix locks in several special ways that have no direct Windows equivilant,
and it seems like it would mostly be a complication.

This commit was sponsored by Protonet.
This commit is contained in:
Joey Hess 2014-08-20 11:25:07 -04:00
parent dfec2ffb22
commit 092041fab0
8 changed files with 23 additions and 3 deletions

View file

@ -37,6 +37,7 @@ lockFileShared file = go =<< fromLockPool file
mode <- annexFileMode
lockhandle <- liftIO $ noUmask mode $
openFd file ReadOnly (Just mode) defaultFileFlags
setFdOption lockhandle CloseOnExec True
liftIO $ waitToSetLock lockhandle (ReadLock, AbsoluteSeek, 0, 0)
#else
lockhandle <- liftIO $ waitToLock $ lockShared file
@ -70,13 +71,19 @@ changeLockPool a = do
withExclusiveLock :: (Git.Repo -> FilePath) -> Annex a -> Annex a
withExclusiveLock getlockfile a = do
lockfile <- fromRepo getlockfile
liftIO $ hPutStrLn stderr (show ("locking", lockfile))
liftIO $ hFlush stderr
createAnnexDirectory $ takeDirectory lockfile
mode <- annexFileMode
bracketIO (lock lockfile mode) unlock (const a)
r <- bracketIO (lock lockfile mode) unlock (const a)
liftIO $ hPutStrLn stderr (show ("unlocked", lockfile))
liftIO $ hFlush stderr
return r
where
#ifndef mingw32_HOST_OS
lock lockfile mode = do
l <- noUmask mode $ createFile lockfile mode
setFdOption l CloseOnExec True
waitToSetLock l (WriteLock, AbsoluteSeek, 0, 0)
return l
unlock = closeFd