Issue: Use of ntpd_flags in /etc/rc.conf results in completely broken behaviour when ntpd starts. The most common issue is that there is no longer a pidfile associated with ntpd, as well as other problems. This is caused by a design/logic problem in etc/rc.d/ntpd which I have not yet worked out. I am certain it must be easy/simple, and hoping someone in the FreeBSD team can figure it out easier than I can. Reproducing: rc.conf contains following settings: ntpd_enable="yes" ntpd_config="/conf/ME/ntp.conf" ntpd_sync_on_start="yes" Process starts as: /usr/sbin/ntpd -g -c /conf/ME/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift Add the following line to rc.conf: ntpd_flags="-4" Process starts as: /usr/sbin/ntpd -g -c /conf/ME/ntp.conf -4 Note missing -p and -f. This causes lots of problems (like service/rc scripts saying "ntpd: no such pid", etc.). This is on a stable/9 system (9.3-STABLE, which is not a choice in the Bugzilla pulldown for some reason). No idea if stable/10 has this fixed (haven't looked, but if it has, it should be MFC'd). Footnote: this may or may not somehow be related to Bug 106927.
Just wanna mention that I just stumbled across this and it's still present in FreeBSD 11.0-RELEASE-p10.
Created attachment 185920 [details] Use command_args not rc_flags to avoid rc.conf messing up configuration I've come across this bug too, but only realised after seeing this one :) On my machine the pidfile doesn't appear because I've overridden ntpd_flags in rc.conf. The correct use is to have command_args for non-configurable stuff, not (ab)use ${name}_flags and hope no-one changes them! Please would someone approve me to commit this? Cheers! Chris
I have incorporated the command_args fix suggested in comment 2 and the attached patch into a larger set of changes, see https://reviews.freebsd.org/D16050
*** Bug 177089 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: ian Date: Fri Jul 20 13:59:30 UTC 2018 New revision: 336547 URL: https://svnweb.freebsd.org/changeset/base/336547 Log: Automatically run ntpd as non-root when possible. Ntpd needs only a subset of full root privileges to do its job. Specifically it needs the ability to manipulate system time, and to re-bind to a privileged UDP port after interface changes. The mac_ntpd(4) policy module (see r336525) can grant these privs. These changes detect the availability of mac_ntpd(4). If enabled, and if the ntpd configuration is fairly vanilla, it automatically runs ntpd as the non-root user 'ntpd' (uid 123). "Vanilla" means the config doesn't include command line or ntp.conf options changing the location of files or using any files/dirs likely to be inaccessible to user ntpd. Ntpd can still run as non-root when using such options, but the admin must ensure all required files and dirs are accessible, and then set ntpd_user=ntpd in rc.conf. Note that these changes also address PR 199127 by using the command_args technique suggested in the patch. They also tangentially address PR 113552, which is primarily about inconsistent filenames in documentation, but some of the inconsistancy was caused by old code in rc.d/ntpd which is leftover from the intial import from netbsd. There was code to do chroot setup which required the use of the netbsd clockctl(4) device; that code never had any effect on freebsd, because we lack that device and don't build ntpd with the options that would allow using it. PR: 113552 199127 Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16050 Changes: head/etc/defaults/rc.conf head/etc/rc.d/ntpd
Ian, is r336547 potentially MFC-able to stable/11, or a portion of it, re: c#2?
(In reply to Jeremy Chadwick from comment #6) I would like to mfc the entire set of run-nonpriv changes, but adding the ntpd user was very disruptive for 12-current users, and I'm afraid it's likely to be just as disruptive if not moreso for 11-stable users (especially anyone running openntpd, which also adds a uid 123). I definitely plan to revisit the issue and see what can be done to smooth the transition, but it needs some coordination with re@ and the ports team (and I'm very busy with $work right now), so it might be best to wait until after 12.0-RELEASE is done.
With a heavy heart, return this PR to rc@ with bugmeister hat. To Jeremy: is this aging PR still relevant?
You asked Jeremy I know, but I can confirm that the issue was fixed. I think it was effectively in the old "patched" state, but now 11 is gone this can indeed close. Thanks.
For additional confirmation: what Chris said is correct. I've verified on a test 13.2-RELEASE VM that ntpd_flags="-4" works fine (instead of having to say ntpd_flags="-4 ${ntpd_flags}" on older FreeBSD versions). Thanks.