
This is nice to know.... otopi is ready: commit d756b789d60934f935718ff25f8208f563b0f123 Author: Alon Bar-Lev <alonbl@redhat.com> Date: Wed Jan 23 02:27:51 2013 +0200 system: clock: support chrony as ntpd Change-Id: I2917bdd8248eb0b123f6b2cca875820f2cac664c Signed-off-by: Alon Bar-Lev <alonbl@redhat.com> http://gerrit.ovirt.org/#/c/11288/ ----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: "Adam Litke" <agl@us.ibm.com>, "Alon Bar-Lev" <alonbl@redhat.com>, "users" <users@ovirt.org> Sent: Wednesday, January 23, 2013 1:50:59 AM Subject: Re: [Users] host deploy and after reboot not responsive
On Tue, Jan 22, 2013 at 9:02 PM, Dan Kenigsberg wrote:
That's great, as it reduces the question to: why doesn't ntpd start on your machine after boot. Do you have any guess? and ntpd logs to share? Any peculiar ntp.conf setting?
Hum... I think in Fedora 18 itself and/or due to oVirt setup there is some conflict regarding network synchronization services....
In fact together with standard ntp there is chrony that I didn't know until today...
My suspect is this one:
- At install time Fedora 18 by default installs now chrony and doesn't install instead ntpd
In fact my anaconda log in /root [root@f18ovn03 ~]# ll /root/anaconda-tb-38wvGO -rw-r--r--. 1 root root 1493714 Dec 18 14:27 /root/anaconda-tb-38wvGO contains:
14:19:00,759 DEBUG packaging: select package chrony
and no entry for ntp
At this moment chronyd was still enabled as per default at install time: [root@f18ovn03 ~]# systemctl status chronyd.service chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: inactive (dead) since Tue, 2013-01-22 14:15:42 CET; 9h ago Main PID: 1348 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/chronyd.service
Jan 22 14:15:40 f18ovn03.ceda.polimi.it chronyd[1348]: chronyd version 1.27-git1ca844 starting Jan 22 14:15:40 f18ovn03.ceda.polimi.it chronyd[1348]: Linux kernel major=3 minor=6 patch=11 Jan 22 14:15:40 f18ovn03.ceda.polimi.it chronyd[1348]: hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000...ll=2 Jan 22 14:15:41 f18ovn03.ceda.polimi.it systemd[1]: Started NTP client/server. Jan 22 14:15:42 f18ovn03.ceda.polimi.it systemd[1]: Stopping NTP client/server... Jan 22 14:15:42 f18ovn03.ceda.polimi.it systemd[1]: Stopped NTP client/server.
- When I ran install of ovirt-engine it pulled in ntp as one of its dependencies, enabling it In yum.log in fact I find:
Jan 15 06:05:53 Installed: libvirt-0.10.2.2-3.fc18.x86_64 Jan 15 06:05:53 Installed: mom-0.3.0-1.fc18.noarch Jan 15 06:05:54 Installed: fence-agents-3.1.10-1.fc18.x86_64 Jan 15 06:05:54 Installed: usbredir-0.6-1.fc18.x86_64 Jan 15 06:05:54 Installed: ipxe-roms-qemu-20120328-2.gitaac9718.fc18.noarch Jan 15 06:05:55 Installed: 2:qemu-system-x86-1.2.2-1.fc18.x86_64 Jan 15 06:05:55 Installed: 2:qemu-kvm-1.2.2-1.fc18.x86_64 Jan 15 06:05:56 Installed: autogen-libopts-5.12-2.fc17.x86_64 ---> Jan 15 06:05:56 Installed: ntp-4.2.6p5-8.fc18.x86_64 <------ Jan 15 06:06:02 Installed: vdsm-4.10.3-0.78.gitb005b54.fc18.x86_64 Jan 15 06:06:04 Installed: tuned-2.1.2-1.fc18.noarch Jan 15 06:06:04 Installed: vdsm-cli-4.10.3-0.78.gitb005b54.fc18.noarch Jan 15 06:06:04 Installed: 2:qemu-kvm-tools-1.2.2-1.fc18.x86_64
Probably chronyd runs before ntpd and creates conflict.....
So I have tested disabling chrony # systemctl disable chronyd
and re-enabling ntp as a dependency for vdsmd to see if something changes: Changed /usr/lib/systemd/system/vdsmd.service matching: Requires=multipathd.service libvirtd.service ntpd.service
Bingo!
After reboot [root@f18ovn03 ~]# systemctl status ntpd.service ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: active (running) since Wed, 2013-01-23 00:31:00 CET; 1min 47s ago Main PID: 1424 (ntpd) CGroup: name=systemd:/system/ntpd.service └ 1424 /usr/sbin/ntpd -u ntp:ntp -g
Jan 23 00:31:07 f18ovn03 ntpd[1424]: Listen normally on 8 em3 fe80::21c:c4ff:feab:3add UDP 123 Jan 23 00:31:07 f18ovn03. ntpd[1424]: Listen normally on 9 em2 fe80::21e:bff:fe21:b8c6 UDP 123 Jan 23 00:31:07 f18ovn03 ntpd[1424]: Listen normally on 10 em1 fe80::21e:bff:fe21:b8c4 UDP 123 Jan 23 00:31:07 f18ovn03 ntpd[1424]: peers refreshed ...
[root@f18ovn03 ~]# systemctl status vdsmd.service vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: active (running) since Wed, 2013-01-23 00:31:10 CET; 2min 25s ago Process: 1434 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=0/SUCCESS) Main PID: 2778 (respawn) CGroup: name=systemd:/system/vdsmd.service ├ 2778 /bin/bash -e /usr/share/vdsm/respawn --minlifetime 10 --daemon --masterpid /var/run/vdsm/r... ├ 2781 /usr/bin/python /usr/share/vdsm/vdsm ├ 2801 /usr/bin/sudo -n /usr/bin/python /usr/share/vdsm/supervdsmServer.py 95a1f3e1-8c0d-4efe-a65... ├ 2802 /usr/bin/python /usr/share/vdsm/supervdsmServer.py 95a1f3e1-8c0d-4efe-a65a-c5af1c7f4d61 27... ├ 3035 rpc.statd --no-notify ├ 3041 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 31 30 ├ 3214 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 44 43 ├ 3216 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 49 46 └ 3229 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 37 34
Jan 23 00:31:38 f18ovn03 rpc.statd[3035]: Version 1.2.7 starting Jan 23 00:31:38 f18ovn03 rpc.statd[3035]: Flags: TI-RPC ...
I also modified ntp.conf commenting out #server 0.fedora.pool.ntp.org iburst #server 1.fedora.pool.ntp.org iburst #server 2.fedora.pool.ntp.org iburst #server 3.fedora.pool.ntp.org iburst
and putting a "server xxx.yyy.www.zzz" line to an internal ntp server but I don't think this was influencing my problems To be sure anyway I reverted to old ntp.conf config with server 0.fedora.pool.ntp.org iburst server 1.fedora.pool.ntp.org iburst server 2.fedora.pool.ntp.org iburst server 3.fedora.pool.ntp.org iburst # server xxx.yyy.www.zzz
And both ntpd and vdsmd started again and host up and SPM in webadmin.
Probably another thing to take care of for Fedora 18 configured as an oVirt node.
Gianluca