[Bug 210020] newsyslog sleeps for 10 seconds even when -s & -R specified

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Jun 4 14:01:49 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210020

david_a_bright at dell.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Affects Only Me             |Affects Some People

--- Comment #1 from david_a_bright at dell.com ---
>From the man page description of the -R flag:

                                                     When a daemon does exe-
             cute newsyslog with the -R option, it should make sure all of the
             log files are closed before calling newsyslog, and then it should
             re-open the files after newsyslog returns.  Usually the calling
             process will also want to specify the -s option, so newsyslog
             will not send a signal to the very process which called it to
             force the rotate.  Skipping the signal step will also mean that
             newsyslog will return faster, since newsyslog normally waits a
             few seconds after any signal that is sent.

After going through the signal work list, during which do_sigwork() is called
and essentially does nothing because -s and -R were specified on the command
line, newsyslog will sleep for 10 seconds as the (verbose) code says: "Pause 10
seconds to allow daemon(s) to close log file(s)".

However, the man page verbiage for -R (and -s) seems quite clear that this
sleep() is unnecessary because the daemon was expected to have already closed
the log file before calling newsyslog. I submit that the sleep should be
eliminated in at least the case where -R and -s have been specified and
possibly also in the case where only -s was specified (if there were no signal
sent, how is the daemon supposed to know to close (and reopen) the log file?).

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list