On 5/23/2015 8:00 PM, Carlos A. Carnero Delgado wrote:

El sáb., may. 23, 2015 10:37 PM, Kirk Bocek t004@kbocek.com escribió:

...

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

boot...

Did you run

systemctl enable ntp.service

after installing it?

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)

On 5/23/2015 11:22 PM, Luigi Rosa wrote:

Kirk Bocek wrote on 24/05/2015 04:37:

...

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:

In CentOS 7 is bettere to use chrony, here's an howto

http://linoxide.com/linux-command/chrony-time-sync/

So reviewing Red Hat's documentation on the subject:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...

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!

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.

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.

On May 24, 2015 4:46:18 PM PDT, Jonathan Billings billings@negate.org wrote:

...

On May 24, 2015, at 18:24, Kirk Bocek t004@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.

On May 25, 2015, at 01:10, Kirk Bocek t004@kbocek.com wrote:

I'll reinstall chrony. But there *are* places I've needed to use nodeps. Mostly to manage inter-repo package incompatibilities.

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.

-- Jonathan Billings

On 05/25/2015 07:48 AM, Kirk Bocek wrote:

On 5/25/2015 4:40 AM, Jonathan Billings wrote:

...

...

On May 25, 2015, at 01:10, Kirk Bocek t004@kbocek.com wrote:

I'll reinstall chrony. But there *are* places I've needed to use nodeps. Mostly to manage inter-repo package incompatibilities.

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.

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.

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

remove old-package install new-package ts run exit

-Thomas

On 5/25/2015 12:12 PM, Jonathan Billings wrote:

On May 25, 2015, at 10:48 AM, Kirk Bocek t004@kbocek.com 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.

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.

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:

http://packages.atrpms.net/dist/

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:

http://scrpms.net/pub/

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.

On Mon, May 25, 2015 12:10 am, Kirk Bocek wrote:

On May 24, 2015 4:46:18 PM PDT, Jonathan Billings billings@negate.org wrote:

...

...

On May 24, 2015, at 18:24, Kirk Bocek t004@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.

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 ++++++++++++++++++++++++++++++++++++++++