[Haskell-cafe] fcntl locks, executeFile and threaded runtime

[diego souza]

Hi Donn,

Thanks for your response. Here is more info, first what I'm trying to
accomplish.

The program I'm writing is a kind of supervisor (like daemontools),
something to daemonize a process then report the state on zookeeper
which is why I need the threaded runtime.

That said, I'm aware of the limitations. But for this particular case
I believe it is going to work. I was using the posix locks only to
test whether or not the program I'm supervising is still alive, as
they have the nice feature of returning the pid that actually holds
the lock.

Before writing to haskell-cafe@ I've been "stracing" this program
trying to make some sense of it, with no luck. I'm could attach the
results, but there is nothing there that could explain this
behavior. Well, at least I could not figure it out.

The reason that makes me believe that executeFile is the culpirt is
that without that line it works. If you take that out and use
'threadDelay' for instance, the problem is gone.

Ah, and for the mean time I'm using flock. This has no problems, which
makes sense as the locks is per file handle not per process as the
posix ones.

~dsouza

At Fri, 25 Oct 2013 08:52:38 -0700 (PDT),
Donn Cave wrote:
> 
> diego souza <dsouza at c0d3.xxx>,
> 
> > I'm having problems with executeFile as it seems to clear the advisory
> > locks using the threaded runtime.
> 
> I'm stumped, and unfortunately can't duplicate it here (no surprise as
> I have a different platform and GHC version.)  But in case it helps ...
> your fcntl(2) file lock will be lost if your process closes any fd open
> on that file.  So if the threaded runtime for some reason were to dup
> random fds and then close them, around a fork, that would do it.  You
> might be able to pick that up in an strace (or whatever your platform
> utility for system call tracing.) But I don't see how executeFile could
> make any difference, in that scenario.
> 
> 	Donn
> 
> 
> > Consider the following snippet (a simplification of what I'm doing):
> > 
> >     import System.IO
> >     import Control.Monad
> >     import System.Posix.IO
> >     import Control.Concurrent
> >     import System.Posix.Files
> >     import System.Posix.Process
> >      
> >     main = do
> >       let lock = (WriteLock, AbsoluteSeek, 0, 0)
> >       fd  <- openFd "/tmp/foobar" ReadWrite (Just stdFileMode) defaultFileFlags {trunc=True}
> >       pid <- forkProcess $ do
> >         setLock fd lock >> putStrLn "child: ok"
> >         executeFile "/usr/bin/sleep" False ["5"] Nothing
> >       threadDelay $ 1 * 1000 * 1000
> >       setLock fd lock >> putStrLn "parent: fail!"
> >       void $ getProcessStatus True False pid
> > 
> > Then I consistentlty get these results:
> > 
> > $ ghc -threaded --make test.hs; ./test
> > child: ok
> > parent: fail!
> > 
> > $ ghc -rtsopts --make test.hs; ./test
> > child: ok
> > test: setLock: resource exhausted (Resource temporarily unavailable)
> > 
> > Any pointers? At first I though it might be an issue with the unix
> > package but that doesn't seem to be the case.
> > 
> > $ ghc-pkg list | grep unix
> >     unix-2.6.0.1
> > 
> > $ ./test +RTS --info
> >  [("GHC RTS", "YES")
> >  ,("GHC version", "7.6.3")
> >  ,("RTS way", "rts_thr")
> >  ,("Build platform", "x86_64-unknown-linux")
> >  ,("Build architecture", "x86_64")
> >  ,("Build OS", "linux")
> >  ,("Build vendor", "unknown")
> >  ,("Host platform", "x86_64-unknown-linux")
> >  ,("Host architecture", "x86_64")
> >  ,("Host OS", "linux")
> >  ,("Host vendor", "unknown")
> >  ,("Target platform", "x86_64-unknown-linux")
> >  ,("Target architecture", "x86_64")
> >  ,("Target OS", "linux")
> >  ,("Target vendor", "unknown")
> >  ,("Word size", "64")
> >  ,("Compiler unregisterised", "NO")
> >  ,("Tables next to code", "YES")
> >  ]
> > 
> > Thanks!
> > ~dsouza
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > 
> > 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe