daemon(8): Add option to write pidfile w/o supervising it

[mail_fbsd2.e4m.org]

Summary

I needed to get the pid of a process started by daemon(8) but without using its supervising functionality of --child-pidfile (and therefore without the need of having daemon(8) hang around as another process). This comes handy when you want to switch the user but can't use su(1) (e.g. because the user has a negative listing in /etc/login.access).

This patch adds an option "-x file" to accomplish this (see also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280487)

It also fixes an internal comment regarding which options enable Supervision mode.

(Note: This is my first time using reviews.freebsd.org so please be lenient towards me :-))

[otis]

When I think of it more closely, couldn't it be modified to do something like --no-supervise or --execute-only and use -p to get the command's pid file in child-pidfile? I'm just trying to avoid duplicate functionality.

[mail_fbsd2.e4m.org]

Hmm, what will happen if one uses --no-supervise (with or even w/o -p) but has given other
options which need supervising? Should we silently ignore --no-supervise? Or spit out a
warning or even an error?
Not thinking about the code which has to honour --no-supervise when finished parsing all
options and then has to decide what to do...

[mail_fbsd2.e4m.org]

So how shall we proceed with this? While I am not happy with the --no-supervise idea (because of
the confusion it might produce) I could make a patch which

1. Adds --no-supervise (or whatever we want to call it)
2. decides what to do with it when option processing has finished

In this case: How shall we call it? Do we want a short option for it?

[kevans]

Please upload diffs with full context (-U999999) or use git-arc from devel/freebsd-git-devtools going forward- it helps to be able to expand files a little bit.

The manpage also needs to note that the pidfile isn't locked like it is with -p -- the lock gets dropped after we exec the child. This also has implications for preventing concurrent instances: daemon(8) relies on the pidfle(3) API and the pidfile(3) API relies on advisory locks -- if the file existed but was not locked, we'll just truncate it rather than trying to investigate if the pid was valid for another instance of the same daemon (since that's hard or impossible to do reliably). This is all a good reason for the current pidfile option forcing supervisor mode, since the value drops down to whatever rc provides as a wrapper around pidfiles if we don't hold it locked.

usr.sbin/daemon/daemon.8

170

New sentence should start on new line

173

Ditto

[mail_fbsd2.e4m.org]

Thanks for the input. I've changed the manpage -- hopefully addressing all issues correctly.
But just to be sure I understood things properly: I should upload a diff with 1260 lines
containing just 30 lines of changes?

[kevans]

In D46313#1190917, @mail_fbsd2.e4m.org wrote:

Thanks for the input. I've changed the manpage -- hopefully addressing all issues correctly.
But just to be sure I understood things properly: I should upload a diff with 1260 lines
containing just 30 lines of changes?

Correct- Phab will hide all of the unchanged lines, but it gives us the opportunity to unhide those bits if we need to for review purposes.

[mail_fbsd2.e4m.org]

Updated version, hopefully adressing kevans input.

[michaelo]

Can you move the unrelated doc changes to a separate review, @ziaee and me can easily review and merge them?

[michaelo]

This somewhat reminds of of systemd's oneshot type. I agree with other committers against introducing another PID file, we should have an option doing the oneshot, execute-onl, etc. and the manpage shall say which options are ignored in such a case.

[ziaee]

In D46313#1264717, @michaelo wrote:

Can you move the unrelated doc changes to a separate review,

Negative, negative! One logical change includes doc, we want to do everything we can to try and include people to 1. write doc 2. include it with code changes.

@ziaee and me can easily review and merge them?

Thanks for tagging me! Happy to help with manuals anytime :)

usr.sbin/daemon/daemon.8

38

Any reason not to insert these moving towards roughly alphabetical ordering? It really helps people find things.

[michaelo]

In D46313#1264734, @ziaee wrote:

In D46313#1264717, @michaelo wrote:

Can you move the unrelated doc changes to a separate review,

Negative, negative! One logical change includes doc, we want to do everything we can to try and include people to 1. write doc 2. include it with code changes.

@ziaee and me can easily review and merge them?

Thanks for tagging me! Happy to help with manuals anytime :)

I was referring solely to this comment:

It also fixes an internal comment regarding which options enable Supervision mode.

This, I believe, can be done separately, no?

[ziaee]

In D46313#1264737, @michaelo wrote:

It also fixes an internal comment regarding which options enable Supervision mode.

This, I believe, can be done separately, no?

Oh, sorry, ETOOSLEEPY. Yes, and that's much better because then even if the features don't get backported, we can backport the documentation fix!