Hey fellow portophiles. A lot of ports install rc scripts that are used to start some service[s] during the system boot process. Programs launched from within the rc script are expected to daemonize to let the boot sequence continue. Daemonization can be performed either
- by the application itself using whatever means it has - or by the porter/rc script writer which usually employs daemon(8) to do the job Programs that know how to daemonize themselves often provide a way to disable this feature, which brings porter to a choice - use an in-house daemonization functionality or resort to wrapping the program invocation into daemon(8). I believe it'd be nice to have a paragraph talking about this topic in Porter Handbook? The initial problem that led me to this question is how dbus-daemon performs daemonization. It first creates a "pollable set" object (which is an abstraction over Linux epoll() or POSIX poll()) and then calls simply fork(). When trying to write a kqueue-based implementation for the pollable set I found that kqueue fd's are not inherited by the child process unless rfork() is used. Luckily, dbus-daemon has the --no-fork option, which made me think that using it together with daemon(8) would be a better option. Some other reasons for preferring daemon(8) over in-house daemonization IMHO are: - daemon can restart the program in case of crashes or other failures - daemon can route program's output into syslog - daemon handles creation of pidfile's - daemon can change the user under which the program will run the right way (tm) - it uses setusercontext() that takes login.conf into account. On the other hand I understand that for some programs running in the foreground is not an intended way to be used. An application may enable debugging output or features when asked to not daemonize, so a discretion would still be required when choosing the daemonization method. Please share your thoughts on this topic.
