Proposal for a new syscall

[cos]

pitchfork() - daemon fork

Much like fork(), except that the new child automatically also setsid()'s and:
- Has a umask of 0 and working directory "/"
- SIGHUP set to ignore
- Gets new stdin, stdout, stderr handles, all tied to /dev/null

[ Apologizes to non-unix-geek readers. Maybe you'll like my next post. ]

Comments

[sandhawke.livejournal.com]

+1

I had to look up setsid and came across this interesting bit: http://stackoverflow.com/questions/2613104/why-fork-before-setsid

[en-ki.livejournal.com]

Love it.

In all seriousness, of course it shouldn't be a new syscall, but it would make a lot of sense to write a little thing called libdaemon that did this sort of thing right, maybe ship it with libc? While I'm dreaming, it could be packaged with gflags and a few other things to encourage people to write their C tools in a standard non-insane way.

[gwillen.livejournal.com]

I think the concept of 'daemonforking' like this actually seems to be on the way out. It's harder to monitor the health of a process that's daemonized itself in this way. I know that djb's daemontools wants monitored processes not to do this, and I get the impression that Poettering's systemd also prefers it (since I've seen reports that it captures stdout and stderr from daemons.)

[xthread.livejournal.com]

No, no, working directory set to /dev
Just to make your next syscall() easier..

[safetybitch.livejournal.com]

*wince*