Date: Sat, 04 Jun 2016 14:01:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 210020] newsyslog sleeps for 10 seconds even when -s & -R specified Message-ID: <bug-210020-8-RPtpr9odrg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-210020-8@https.bugs.freebsd.org/bugzilla/> References: <bug-210020-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210020 david_a_bright@dell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People --- Comment #1 from david_a_bright@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-210020-8-RPtpr9odrg>