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 to fork()) 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 rc system 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, then exec() 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:
# cd /etc/rc.d
# cat grafana
# $OpenBSD: grafana.rc,v 1.2 2018/01/11 19:27:10 rpe Exp $
daemon_flags="-homepath /usr/local/share/grafana -config /etc/grafana/config.ini"
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#ENVIRONMENT
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.
And one more thing from the man page of dd(1)
Sending a USR1 signal to a running 'dd' process makes it print I/O statistics to standard error and then resume copying.
In FreeBSD we have SIGINFO which is triggered by C-t and many applications support it (it’s one thing that I really miss when I am in Linux). For example, when doing a cp just hit C-t to see stats on the progress.
oooo, that’s a neat tidbit to find out. Thanks!
From what I can see, a significant chunk of problems in the unix command lines is due to the fact that arbitrary filenames are allowed. I wonder if we should look at restricting the file names to include only specific sets of characters (or at least exclude specific ASCII characters that make life difficult in the shell world) on the filesystem level.
Another way to get around the issue described in the section on -- is to always use something like ./* instead of * for globs.
Omitted from the description of the first point (“Use -- to separate options and arguments”): this happens “for free” if you just use getopt(3).