I no longer believe that daemons should fork into the background. Most Unix systems now have better service control and it makes the code easier to deal with if it doesn’t call fork(). This makes it easier to test (no longer do you have to provide an option not to fork() or an option tofork()) and less code is always better.
This is not so much about the forking per se, but rather the other behaviour that generally goes with it: closing any file descriptors that might be connected to a controlling terminal.
It’s not that hard to write a program to do the daemonization (call umask(), setsid(), chdir(), set up any redirection of stdin, stdout and stderr, then exec() the non-forking daemon.
I’m not sure this is accurate, at least on -current. There are several go “deamons” that as far as I understand don’t support fork(2). These can still be managed by OpenBSD’s rc system:
For those that don’t know, daemontools is a nice service system that explicitly wants programs to not try to daemonize themselves. For services I build and run I try to use that.
I no longer believe that daemons should fork into the background. Most Unix systems now have better service control and it makes the code easier to deal with if it doesn’t call
fork(). This makes it easier to test (no longer do you have to provide an option not tofork()or an option tofork()) and less code is always better.Not forking also allows logging to be an external concern and the process should just write to stdout and stderr as normal.
This is not so much about the forking per se, but rather the other behaviour that generally goes with it: closing any file descriptors that might be connected to a controlling terminal.
OpenBSD’s
rcsystem seems to expect that processes fork. I don’t see an obvious workaround for processes that don’t fork.It’s not that hard to write a program to do the daemonization (call
umask(),setsid(),chdir(), set up any redirection of stdin, stdout and stderr, thenexec()the non-forking daemon.It’s even simpler when you have daemon(3): http://man7.org/linux/man-pages/man3/daemon.3.html
Which you do on OpenBSD, actually.
Note that daemon(3) is a non-standard extension so it should be avoided for portable code. The implementation is simple enough, though.
I’m not sure this is accurate, at least on -current. There are several go “deamons” that as far as I understand don’t support
fork(2). These can still be managed by OpenBSD’s rc system:I’m not sure if there’s more to it that I don’t understand, I don’t write many deamons!
Well, it turns out, I can’t read! The key to this is
rc_bg, see https://man.openbsd.org/rc.subr#ENVIRONMENTFor those that don’t know, daemontools is a nice service system that explicitly wants programs to not try to daemonize themselves. For services I build and run I try to use that.