Services Status -NTPD- Reversed

Nachtfalke

I am using:
2.0-RC1 (i386) built on Wed Mar 2 03:30:11 EST 2011

If I enable OpenNTPD on LAN interface, this line comes up in Systemlog "system".

php: /pkg_edit.php: The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 4781: No such process'

If I disable OpenNTPD on LAN interface, this line comes up in Systemlog "system".

php: /pkg_edit.php: The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 7464: No such process'

Cino

I have the same results. Disabling NTPD under Services shows it being started under Status:Services. I don't see anything in my system log tho. Running 2.0-RC1 (i386) built on Sun Mar 6 03:05:44 EST 2011

AhnHEL

I'm hoping this is just another side effect of the yandex em driver that was committed recently

jimp

Not likely. It happens on my ALIX as well and this isn't anywhere near the network drivers.

podilarius

If I go in an kill all the ntpdate processes and then go and re-enable ntp .. the service shows as started.

Podilarius

LostInIgnorance

Is anyone else still having problems with this? It's showing still reversed on my full i386 machine.

AhnHEL

This was fixed in the most recent snapshots. Please note that saving a OpenVPN config though will shut it down and will not allow it to start back up again until a reboot is performed, or you kill all ntp processes and restart ntpd

LostInIgnorance

Just updated to 2.0-RC1 (i386) built on Mon Apr 11 15:52:08 EDT 2011 and it is still showing the status reversed. When it is running it shows stopped, when I stop it, it shows running.

jimp

It should show running all the time. It being enabled/disabled only changes whether it listens for client access. When you have the enable box unticked, it is still used to keep the clock in sync.

On my test VMs, it shows enabled all the time now on current snapshots.

Anyone who still sees it show on/off incorrectly, I need to see the output of "ps uxawww | grep ntp"

LostInIgnorance

root   12897  0.0  0.2  3656   872  ??  IN   10:32PM   0:00.02 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
root   17460  0.0  0.2  3504  1084  ??  IN   10:32PM   0:00.24 ntpdate -s -t 5 0.pfsense.pool.ntp.org
root   22432  0.0  0.2  3524   996  u0  S+   11:31AM   0:00.01 grep ntp

jimp

How far off from the current clock is that 10:32? It's odd that ntpdate would be stuck there but I ahve seen it do that before. It's supposed to stop itself after 5 seconds, but sometimes doesn't.

Anything in the system log from ntpdate?

I'm going to be replacing ntpdate with just running ntpd with -s instead. Might clear everything up but will take a little work to pull off.

iFloris

Jimp, I've been seeing the same (not running / inverted status).

The output of "ps uxawww | grep ntp" on my machine is:

$ ps uxawww | grep ntp
root    48849  0.0  0.6  3656  1416  ??  S     6:55PM   0:00.00 sh -c ps uxawww | grep ntp
root    49007  0.0  0.5  3524  1252  ??  S     6:55PM   0:00.00 grep ntp
root    54158  0.0  0.6  3656  1364  ??  IN   10:34AM   0:00.01 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
root    56211  0.0  0.6  3504  1356  ??  SN   10:34AM   0:00.20 ntpdate 193.79.237.14 193.79.237.30 1.nl.pool.ntp.org 0.nl.pool.ntp.org 0.pfsense.pool.ntp.org0
root    25863  0.0  0.6  3656  1404  u0- S    10:34AM   0:05.94 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh

As for the time 10:34AM, it's 19:00 (7PM) right now.

LostInIgnorance

the 10:32PM is way off, the 11:31A is pretty much exact.

jimp

ok, so it's been stuck for quite a while.

LostInIgnorance

yeah, been stuck since i updated the firewall last night. whats weird is if I uncheck the box, it shows running under services and gives me this as an output for that command

root   55531  1.0  0.2  3316  1052  ??  Ss   12:14PM   0:00.00 ntpd: [priv] (ntpd)
root   12897  0.0  0.2  3656   808  ??  IN   10:32PM   0:00.02 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
root   17460  0.0  0.2  3504   828  ??  IN   10:32PM   0:00.26 ntpdate -s -t 5 0.pfsense.pool.ntp.org
_ntp   55364  0.0  0.2  3316  1060  ??  S    12:14PM   0:00.01 ntpd: ntp engine (ntpd)
root   34601  0.0  0.1  1848   536  u0  R+   12:15PM   0:00.00 grep ntp

the 12:15 is dead on!

jimp

Yes, when ntpdate_sync_once.sh runs it kills ntpd, syncs the time, and then restarts ntpd. If it gets stuck in the sync part, then it never restarts ntpd.

This is going to change here shortly, though. Don't bother investigating any more just yet.

LostInIgnorance

Sweet, thanks pfSense team.

jimp

Try to apply this change (or wait for a new snap dated after this post):

https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/cd11a1426d3c140918a74cb7e3efc500644e220c

LostInIgnorance

Reboot after making changes?

jimp

That would be an ideal test, yes. At least kill all ntp and ntpdate processes and then edit/save the OpenNTPD settings.

Though a reboot would be the most accurate test.