Summary: | [patch] daemon(8): Add option to redirect stdout and stderr to a file | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Christian Schwarz <me> | ||||
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Closed Overcome By Events | ||||||
Severity: | Affects Many People | CC: | dch, markj, me | ||||
Priority: | Normal | Keywords: | feature, needs-qa, patch | ||||
Version: | CURRENT | Flags: | koobs:
mfc-stable10?
|
||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Christian Schwarz
2016-02-16 14:22:18 UTC
Super idea! I've come across a couple of daemons just this week that fall into this category. Both are golang ports "designed" to run in docker/systemd land where stdio is handled by some parent container, e.g. security/vault being one of them. I can't tell if this is already the case, but it would be ideal for the redirected io to go into a file owned by whatever `-u $USER` was passed into daemon, instead of root, good for managing disk quotas and smaller systems where out of control log files have caused systems to stop due to disk full issues. I can't test until 110.0 has landed but I'd also want to know if log rotation plays nicely with this or not. worth mentioning https://svnweb.freebsd.org/base?view=revision&revision=307769 now in 12.0-CURRENT which looks like it provides the same functionality. Maybe this can be closed? specifically `-o /var/log/thing.log -m 3` -o output_file Append output from the daemonized process to output_file. If the file does not exist, it is created with permissions 0600. -m output_mask Redirect output from the child process stdout (1), stderr (2), or both (3). This value specifies what is sent to syslog and the log file. The default is 3. from https://www.freebsd.org/cgi/man.cgi?query=daemon&apropos=0&sektion=0&manpath=FreeBSD+12-current&arch=default&format=html Indeed, daemon(8) can now redirect output to a file. This is not quite the same as the proposed functionality but is hopefully sufficient. Please re-open if not. |