DevHeads.net

Systemd

So I've built my first CentOS 7 host and am learning all the new ways of
doing things. I setup and enabled ntpd but after a reboot I get:

$ systemctl status ntpd
ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
Active: inactive (dead)

After issuing:

$ systemctl start ntpd

Ntpd runs just fine. But why isn't it loading at boot time?

Comments

Re: Systemd

By Luigi Rosa at 05/24/2015 - 01:22

Kirk Bocek wrote on 24/05/2015 04:37:
In CentOS 7 is bettere to use chrony, here's an howto

<a href="http://linoxide.com/linux-command/chrony-time-sync/" title="http://linoxide.com/linux-command/chrony-time-sync/">http://linoxide.com/linux-command/chrony-time-sync/</a>

Re: Systemd

By Kirk Bocek at 05/24/2015 - 13:41

On 5/23/2015 11:22 PM, Luigi Rosa wrote:
So reviewing Red Hat's documentation on the subject:

<a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Configuring_the_Date_and_Time.html#sect-Configuring_the_Date_and_Time-timedatectl-NTP" title="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Configuring_the_Date_and_Time.html#sect-Configuring_the_Date_and_Time-timedatectl-NTP">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7...</a>

I see both chrony and ntpd mentioned but no preference given. Seeing
that I've used ntpd for a decade and am more comfortable an familiar
with it, I think I just stick with ntpd.

However, we have yet *another* new control system. We are supposed to issue:

$timedatectl set-ntp yes

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:

$systemctl status ntpd
ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
Active: inactive (dead)

I have also tried:

$systemctl reenable ntpd

To get the symbolic links rewritten. No help.

To be clear, if I manually issue:

$systemctl start ntpd

ntpd runs fine:

$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 11:39:21 PDT; 8s ago
Process: 2935 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS
(code=exited, status=0/SUCCESS)
Main PID: 2936 (ntpd)
CGroup: /system.slice/ntpd.service
ââ2936 /usr/sbin/ntpd -u ntp:ntp -g

May 24 11:39:21 cobalt ntpd[2936]: Listen normally on 3 enp4s0f0
10.0.0.160 UDP 123
May 24 11:39:21 cobalt ntpd[2936]: Listen normally on 4 lo ::1 UDP 123
May 24 11:39:21 cobalt ntpd[2936]: Listen normally on 5 enp4s0f0
fe80::ec4:7aff:fe34:1dcc UDP 123
May 24 11:39:21 cobalt ntpd[2936]: Listening on routing socket on fd #22
for interface updates
May 24 11:39:21 cobalt ntpd[2936]: io_setbclient: Opened broadcast
client on interface #3 enp4s0f0
May 24 11:39:21 cobalt ntpd[2936]: Listen normally on 6 multicast
224.0.1.1 UDP 123
May 24 11:39:21 cobalt ntpd[2936]: Joined 224.0.1.1 socket to multicast
group 224.0.1.1
May 24 11:39:21 cobalt ntpd[2936]: 0.0.0.0 c016 06 restart
May 24 11:39:21 cobalt ntpd[2936]: 0.0.0.0 c012 02 freq_set kernel
17.232 PPM
May 24 11:39:22 cobalt ntpd[2936]: 0.0.0.0 c515 05 clock_sync

It's just not running at boot time. Come on, I can't be the only one
here to setup time services!

Re: Systemd

By Frank Cox at 05/24/2015 - 13:53

On Sun, 24 May 2015 11:41:43 -0700

Every Centos 7 installation that I've done so far installs and activates chrony by default, without any particular action required on my part at all.

Re: Systemd

By Gordon Messmer at 05/24/2015 - 14:22

On 05/24/2015 11:41 AM, Kirk Bocek wrote:
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.

Re: Systemd

By Kirk Bocek at 05/24/2015 - 17:24

On 5/24/2015 12:22 PM, Gordon Messmer wrote:
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.

Re: Systemd

By Jonathan Billings at 05/24/2015 - 18:46

No. 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.

Re: Systemd

By Kirk Bocek at 05/25/2015 - 00:10

On May 24, 2015 4:46:18 PM PDT, Jonathan Billings < ... at negate dot org> wrote:
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.

Re: Systemd

By Valeri Galtsev at 05/25/2015 - 11:12

On Mon, May 25, 2015 12:10 am, Kirk Bocek wrote:
The need to use --nodeps undermines the idea of rpm based (or more
generally package based) system maintained in harmony by system vendor
(and extra repository vendors). Basically, you become individual system
vendor for yourself, which is a lot of work. If it comes to that, then you
will be in much better shape (from the point of view of how much time you
spend on keeping your box in harmony with all components working) if you
switch from package management based system to source build based system.
Examples of the last just off the top of my head would be: gentoo linux,
FreeBSD, NetBSD... The last two are sort of "port based systems" as far
as extra software is concerned. (Of course, BSD boxes in addition to ports
have package management, so in their case you can maintain system either
way: as prebuilt packages, or as building ports yourself, the last gives
you ability to change configuration options of what you build to your
specific needs).

Not intending to criticize what you are doing, just giving you an idea
what it looks like for external observer.

Just my $0.02

Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

Re: Systemd

By Jonathan Billings at 05/25/2015 - 06:40

You should look into the yum priorities option to ensure packages from different repos don't step on each other, however I'd consider any yum repository that requires you break your rpm database to be one to avoid.

Re: Systemd

By Kirk Bocek at 05/25/2015 - 09:48

On 5/25/2015 4:40 AM, Jonathan Billings wrote:
It usually happens when I've wanted to change versions of the same
software between repos and that software has been compiled differently.
Usually audio-visual software. Yum install triggers a conflict and yum
uninstall on the older package cascades a bunch of undesirable
uninstalls. The only solution is rpm -e -nodeps followed by installing
the newer package.

If you have a better solution, let me know.

Re: Systemd

By Jonathan Billings at 05/25/2015 - 14:12

On May 25, 2015, at 10:48 AM, Kirk Bocek < ... at kbocek dot com> wrote:
Stop using those repos. Whatever you’re doing, you’re not using a repo or software packaged for the version of CentOS you are using. Could you give some examples? It would help to see these dependency mismatches in person.

If you want to use the software, find the source RPMs and rebuild them for the version of CentOS you’re using.

Re: Systemd

By Kirk Bocek at 05/25/2015 - 14:50

On 5/25/2015 12:12 PM, Jonathan Billings wrote:
I am an avid user of MythTV and prefer to install from RPM. There are
*very* few sources of those RPMS. ATRpms used to be my main source:

<a href="http://packages.atrpms.net/dist/" title="http://packages.atrpms.net/dist/">http://packages.atrpms.net/dist/</a>

But Axel Thimm seems to have drifted off to better things and he stopped
building the latest versions of Myth. SCRpms provided by Stephen Collier
has picked up the torch:

<a href="http://scrpms.net/pub/" title="http://scrpms.net/pub/">http://scrpms.net/pub/</a>

Now the problem has been less these repos than the host of supporting
audio-visual packages needed to get MythTV up and running: things like
FFMpeg, the latest proprietary Nvidia driver, lirc. Often I have to go
to third party repos to get things working.

One example of the conflicts involved here are the QT packages. It looks
like CentOS 7 ships with QT 4.8 which is what MythTV currently requires.
But CentOS 6 shipped with QT 4.6. Stephen Collier did a really good job
compiling his 4.8 packages for CentOS 6 so they could install in
parallel. *Except* for the qt-x11 package. That one cannot be installed
in parallel. If you have anything depending on qt-x11, you'll have to
rpm -e --nodeps the 4.6 package before installing the 4.8 package. The
regular yum upgrade process somehow doesn't work. As I recall it wants
to pull in a bunch of other stuff and conflicts arise.

The bigger issue is a project like MythTV being targeted at the bleeding
edge like Fedora while I want to stay on the stable edge with CentOS.
I've had to deal with this for years. MythTV will eventually move on to
a library or a tool not supported by the base CentOS install and it will
be a battle to get it to work.

Re: Systemd

By A. Kirillov at 05/25/2015 - 15:04

docker or kvm?

Re: Systemd

By Thomas Eriksson at 05/25/2015 - 14:09

On 05/25/2015 07:48 AM, Kirk Bocek wrote:
If the new package fulfills all requirements as the old one, you can use
"yum shell" to do both transactions at the same time.

$> yum shell
-Thomas

Re: Systemd

By Peter Lawler at 05/25/2015 - 03:27

On 25/05/15 15:10, Kirk Bocek wrote:

Re: Systemd

By Gordon Messmer at 05/24/2015 - 19:58

On 05/24/2015 03:24 PM, Kirk Bocek wrote:
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.

Re: Systemd

By fred smith at 05/24/2015 - 18:22

On Sun, May 24, 2015 at 03:24:59PM -0700, Kirk Bocek wrote:
<big snip>

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.

Re: Systemd

By Carlos A. Carne... at 05/23/2015 - 22:00

El sáb., may. 23, 2015 10:37 PM, Kirk Bocek < ... at kbocek dot com> escribió:

...

Ntpd runs just fine. But why isn't it loading at

boot...

Did you run

systemctl enable ntp.service

after installing it?

HTH,
Carlos.

Re: Systemd

By Kirk Bocek at 05/23/2015 - 22:08

On 5/23/2015 8:00 PM, Carlos A. Carnero Delgado wrote:
Yup, take a look at the second line:

$ systemctl status ntpd
ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
Active: inactive (dead)