https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230561
Kubilay Kocak <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|Closed |Open Resolution|Not A Bug |--- Assignee|[email protected] |[email protected] 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 <[email protected]> --- 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 on the CC list for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
