On 5 March 2011 21:43, Donn Cave wrote:

Quoth Bas van Dijk , ...

...

I understand why it's problematic to fork a process which is in the middle of running multiple simultaneous threads. However, in the case of a daemon the fork happens in the beginning of the program. So if I can manage to create a program that first daemonizes my process then starts the Haskell program, all is good.

type ProcessID = CInt type Fd = CInt

foreign import ccall "fork" c_fork :: IO CInt foreign import ccall "_exit" _exit :: CInt -> IO ()

fork :: IO Int -> IO ProcessID fork fn = do        pid <- c_fork        if pid == 0                then do                        fn >>= _exit . fromIntegral                        return 0 -- unused, I reckon                else if pid > 0                        then return pid                        else throwErrno "fork"

System.PosixProcess (exitImmediately) is supposed to be "_exit".

I would not care to hazard a guess as to whether this will work reliably for you.

Thanks, I thought about this too, however I consider myself too unfamiliar with the RTS to know if this is safe. Bas

On 5 March 2011 21:51, Vincent Hanquez wrote:

On Sat, Mar 05, 2011 at 08:51:59PM +0100, Bas van Dijk wrote:

...

Hello,

I like to turn my Haskell program into a unix daemon. One of the steps in "daemonizing" a process is to fork it then exit the parent and continue with the child. All this is nicely abstracted in hdaemonize[1] which internally calls forkProcess[2].

I would also like to use multiple simultaneous threads in my program. Unfortunately forkProcess is not supported when running with +RTS -N so I can't use hdaemonize.

I understand why it's problematic to fork a process which is in the middle of running multiple simultaneous threads. However, in the case of a daemon the fork happens in the beginning of the program. So if I can manage to create a program that first daemonizes my process then starts the Haskell program, all is good.

My current plan is to have a custom Haskell main function which is exported using the FFI:

Hi,

Did you alternatively though about daemonizing in your haskell program normally without using +RTS -N, and exec'ing yourself (using executeFile) with the extra cmdline +RTS -N options, and also --no-daemon option to avoid re-daemon/exec'ing ?

I think that would be simpler than your current approch.

What a nice idea! I actually looked for a unix command line tool that could do this but did not think further about doing it myself. Thanks, Bas P.S. So is there a tool that daemonizes another program? Sounds like a job for a neat little Haskell program...

On Sat, Mar 5, 2011 at 11:59 PM, Bas van Dijk wrote:

So is there a tool that daemonizes another program? Sounds like a job for a neat little Haskell program...

There are a few I'm aware of: * http://software.clapper.org/daemonize/ * http://cr.yp.to/daemontools.html (warning, DJ Bernstein code :) ) G -- Gregory Collins

On Mon, Mar 7, 2011 at 12:39 AM, Bas van Dijk wrote:

Sterling, Gregory, Brandon and David thanks for your suggestions.

On 6 March 2011 05:38, David Anderson wrote:

...

I humbly recommend doing such daemonizations from outside your program. Programs that daemonize on startup make it very difficult to monitor them by direct means, instead forcing you to rely on PID files and other mechanisms which may not always be available or fresh.

Agreed, I already noticed that debugging is a bit harder since I have no stdout and stderr anymore.

...

For reference, Upstart, the new PID 1 on Ubuntu and friends, has a horrible hack[1] built in specifically to keep track of processes that "helpfully" daemonize themselves, so that it can offer additional services like restarting crashed services or notifying the owner of a problem. As has been pointed out elsewhere on thread, there are plenty of standalone programs that implement daemonization if you end up not using service management software to do it for you.

I plan to run the daemon on a Ubuntu server. Do you know if Upstart is able to daemonize a process?

It's perfectly simple. In fact, it's the default assumption of Upstart that your program doesn't daemonize, and that Upstart should help it. You have to specify if your program violates that assumption. Here's a sample file. It specifies a service that; should run whenever the main runlevels are entered (i.e. basic system init like mounting filesystems is done, but no other guarantee); stops when the system leaves those runlevels; runs a binary that does not fork or daemonize; respawns the service if the process should die for any reason; can be manually stopped and restarted by the admin if he feels like it. $ cat /etc/init/demo.conf description "Demo service that doesn't daemonize by itself" start on runlevel [2345] stop on runlevel [!2345] respawn exec /path/to/binary $ sudo start demo demo start/running, process 27469 $ sudo stop demo demo stop/waiting $ sudo status demo demo stop/waiting $ Hope this helps. The upstart configuration format is a little sparsely documented, when I wrote scripts for it, I used the existing files in /etc/init as a rough guide. - Dave

Regards,

Bas