Various forms of logging in rc.d scripts

[dizzy67]

Hi,

I do not know where the right place to bring this up is and I hope that someone picks it up. Something that I have been noticing for a while now is that port maintainers implement different ways of logging, when the software doesn't take care of logging itself. This sometimes causes issues regarding file creation (and permissions), overwriting old logs, skipping logs, etc.

This seems to be the case in software that was created with systemd, supervisord, etc. in mind, so software that doesn't fork on its own and logs to stdout/stderr. A common way here would be to use daemon(8), which can take care of all of that. However, I mostly came across ports that does not use daemon to use logging, but tries to redirect output by piping into a file, which often fails.

Now, while I don't mean to point fingers, I want to give examples. net-mgmt/alertmanager and net-mgmt/blackbox_exporter for example at the time of writing this post have this problem.

For that reason maybe it would make sense to give examples of using logging -o parameter of daemon(8) in the porters handbook. Also given that very similar setups of daemon(8) for Go (and some Java, Python, etc.) software is in use, I wonder if it would make sense to add some scripting that can be used to have some standard "daemon not forking into background, logging to stdout/stderr" behavior. That might help to unify how ported software behaves on FreeBSD. The Porter's Handbook might be a good start though.


EDIT: Whoops, I think this should probably go into the Porting New Software Forum. I am sorry.

 

[ralphbsz]

To begin with, if you have a specific problem with certain packages, you should probably start by pinging the maintainers for those packages.

The more pervasive problem is this: daemonizing a program is actually surprisingly difficult. And one thing that's missing in particular (even when using the daemon(8) program) is this: log output should not get appended to a file, it should usually go through syslog. I once spent a few days writing a daemonizing library for python, and I'm not at all sure my version is 100% correct. And it doesn't generalize to Go or Java, because the output redirection (to syslog) uses Python-specific facilities, and requires discipline from the program itself (like: don't call C modules). So I agree that you should point out in the Porting forum that daemon(8) is a step in the right direction. But properly daemonizing something can be considerably harder.

This is by the way the single biggest advantage of systemd: it makes writing daemons easier and more reliable, because it takes the IO and daemonizing handling and centralizes it. Lacking that, people who write daemons just have to be very well organized and careful.