On 5/24/2015 12:22 PM, Gordon Messmer wrote:> On 05/24/2015 11:41 AM, Kirk Bocek wrote: >> to activate your selected daemon. I just used the new systemd commands, >> thinking that would be enough. So I tried that and rebooted. Nope, same >> problem: > > chronyd and ntpd both use UDP port 123, so each will terminate the > other when it starts. If both are enabled, chronyd's unit file > indicates that it should start after ntpd, so it will always "win." > > You probably have both enabled, so the system boots, starts ntpd, then > starts chronyd which terminates ntpd. > > Disable chronyd. >Yes, indeedy. $systemctl status chronyd chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: inactive (dead) since Sun 2015-05-24 11:39:21 PDT; 3h 31min ago Process: 845 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=0/SUCCESS) Process: 808 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 814 (code=exited, status=0/SUCCESS) CGroup: /system.slice/chronyd.service May 24 11:35:53 cobalt chronyd[814]: NTP packet received from unauthorised host 10.0.0.1 port 123 ... So: $rpm -e --nodeps chrony chrony has dependencies with anaconda and initial-setup. Reboot, and: $systemctl status ntpd ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: active (running) since Sun 2015-05-24 15:15:42 PDT; 3min 1s ago Process: 847 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 868 (ntpd) CGroup: /system.slice/ntpd.service ??868 /usr/sbin/ntpd -u ntp:ntp -g May 24 15:15:42 cobalt ntpd[868]: Failed to join 224.0.1.1 socket to multicast group 224.0.1.1 May 24 15:15:42 cobalt ntpd[868]: 0.0.0.0 c016 06 restart May 24 15:15:42 cobalt ntpd[868]: 0.0.0.0 c012 02 freq_set kernel 17.232 PPM May 24 15:15:43 cobalt ntpd[868]: 0.0.0.0 c515 05 clock_sync May 24 15:15:49 cobalt ntpd[868]: Listen normally on 5 enp4s0f0 fe80::ec4:7aff:fe34:1dcc UDP 123 May 24 15:15:49 cobalt ntpd[868]: new interface(s) found: waking up resolver May 24 15:15:51 cobalt ntpd[868]: Listen normally on 6 enp4s0f0 10.0.0.160 UDP 123 May 24 15:15:51 cobalt ntpd[868]: io_setbclient: Opened broadcast client on interface #6 enp4s0f0 May 24 15:15:51 cobalt ntpd[868]: new interface(s) found: waking up resolver May 24 15:16:47 cobalt ntpd[868]: 0.0.0.0 0613 03 spike_detect +0.416806 s Multicast error, but no big deal. ntpq -p is reporting correctly on the broadcast servers on my network. Also, I suppose I could have just disabled chrony instead of removing it. I had no idea about chrony and no idea it was installed *and activated* by default. So much new stuff to learn in 7. Thank you Frank and Gordon.
On Sun, May 24, 2015 at 03:24:59PM -0700, Kirk Bocek wrote:> > > On 5/24/2015 12:22 PM, Gordon Messmer wrote: > >On 05/24/2015 11:41 AM, Kirk Bocek wrote: > >>to activate your selected daemon. I just used the new systemd commands, > >>thinking that would be enough. So I tried that and rebooted. Nope, same > >>problem: > > > >chronyd and ntpd both use UDP port 123, so each will terminate the > >other when it starts. If both are enabled, chronyd's unit file > >indicates that it should start after ntpd, so it will always > >"win." > > > >You probably have both enabled, so the system boots, starts ntpd, > >then starts chronyd which terminates ntpd. > > > >Disable chronyd. > > > > Yes, indeedy. > > $systemctl status chronyd<big snip>> Multicast error, but no big deal. ntpq -p is reporting correctly on > the broadcast servers on my network. Also, I suppose I could have > just disabled chrony instead of removing it. > > I had no idea about chrony and no idea it was installed *and > activated* by default. So much new stuff to learn in 7. > > Thank you Frank and Gordon.Chrony is actually a useful tool... years and years ago, when Chrony was young and being maintained by the original author, I ran it here at home, because I had dialup only. Ran it on a (even then) obsolete Pentium 90 box that also ran the GPL version of Smoothwall. Configured PPP to autodial when someone wanted to access the internet, and we're off to the races. Chrony kept the smoothwall box fairly accurate, and all the system on the LAN then synced with the smoothwall system. Chrony is actually designed to be able to work properly on such systems/ networks, where internet connectivity is intermittent, and to do a good job of keeping the time within a reasonably near facsimile of actual time. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ---------------------------- Do you not know? Have you not heard? The LORD is the everlasting God, the Creator of the ends of the earth. He will not grow tired or weary, and his understanding no one can fathom. ----------------------------- Isaiah 40:28 (niv) -----------------------------
> On May 24, 2015, at 18:24, Kirk Bocek <t004 at kbocek.com> wrote: > > So: > > $rpm -e --nodeps chronyNo. Bad. Just disable the service. Breaking your rpm database will just lead to pain down the road. Disabling the service will maintain the integrity of the package dependencies, and most likely a later yum update will reinstall chrony, possibly enabled. -- Jonathan Billings
On 05/24/2015 03:24 PM, Kirk Bocek wrote:>> Disable chronyd. > > So: > > $rpm -e --nodeps chrony > > chrony has dependencies with anaconda and initial-setup.No, not that I can tell... # rpm -q --whatrequires chrony Either way, don't use --nodeps. Just don't. If you break dependencies, you're going to have trouble updating later. Or something unexpected will stop working. In this case it's not a big deal, since nothing actually requires chrony, but in general it's a really bad practice.
On May 24, 2015 4:46:18 PM PDT, Jonathan Billings <billings at negate.org> wrote:>> On May 24, 2015, at 18:24, Kirk Bocek <t004 at kbocek.com> wrote: >> >> So: >> >> $rpm -e --nodeps chrony > >No. Bad. >Okay, okay! I'll go on the paper. I'll reinstall chrony. But there *are* places I've needed to use nodeps. Mostly to manage inter-repo package incompatibilities. Fortunately this isn't yet a production host but more a chance to learn all the changes like this, systemd, grub2, xfs, whatever the new firewall is called. The list keeps growing.