Date: Fri, 05 Oct 2018 09:47:41 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230561] ntpd error: only one pidfile option allowed Message-ID: <bug-230561-227-5HWCawrOw2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230561-227@https.bugs.freebsd.org/bugzilla/> References: <bug-230561-227@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=230561 Kubilay Kocak <koobs@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koobs@FreeBSD.org Status|Closed |Open Resolution|Not A Bug |--- Assignee|bugs@FreeBSD.org |ian@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1135 | |52, | |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=2315 | |92 --- Comment #4 from Kubilay Kocak <koobs@FreeBSD.org> --- Hi Ian, I'm commenting here as I've only just realised my CURRENT system's ntpd was not running (for a while it seems!), discovering the reported error when trying to start the service manually. I'm not sure why/how I didn't pick the issue up earlier, perhaps it was missed in daily periodic logs. I'm a fairly seasoned FreeBSD user and I worry about the user experience of this issue for those less experienced. There is a section (can_run_root() function) in the startup script which checks for user-supplied arguments (including pidfile), which when set, causes the scripts default behaviour (to use user:ntp and its own arguments/locations) to not be used, *but* apparently (?) only for the driftfile argument # Otherwise, figure out what to do about the driftfile option. If set # by the admin, we don't add the option. <snip> driftopt="" # admin set the option, we don't need to add it. Why can't the same, if not specific, then general behaviour, apply to !driftfile arguments as well? Why is pidfile a/the special case? If its a permission issue, why isn't that a problem for driftfile, keyfile, etc? Isn't the actual and only issue that the only argument the script explicitly sets is "-p ${pidfile}" causing the conflict/error reported here, but not for any other arguments? If the pidfile argument absolutely and positively cannot be supported in any capacity, differently from other path/file-value arguments, pidfile should be stripped from arguments, given the *only* outcome of the user supplying it is this error. In addition, and note I am not advocating that rc scripts should support any or all *particular values* for command arguments (see bug 231592), but not supporting overriding arguments via foo_flags via rc.conf is a pola violation and inconsistent (I believe) with; the expectations of our users generally, and almost all other rc scripts we ship (in base and ports). @with bugmeister hat, assign to Ian as previous issue closer and committer of base r336547 -- 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-230561-227-5HWCawrOw2>