[Bug 230561] ntpd error: only one pidfile option allowed

[bugzilla-noreply at freebsd.org]

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

Kubilay Kocak <koobs at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |koobs at FreeBSD.org
             Status|Closed                      |Open
         Resolution|Not A Bug                   |---
           Assignee|bugs at FreeBSD.org            |ian at 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 at 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.