You are not logged in.
(This is a related to https://bbs.archlinux.org/viewtopic.php?id=150415, but different, so I'll post this separately.)
I have systemd, ntp and NetworkManager and networkmanager-dispatcher-ntpd installed. Since this is a laptop, I do not want NTP to start until after I've established a network connection. This is in essence what the dispatcher package is for.
However, I noticed that the ntpd.service is "enabled" in systemd, which means that it starts well before a Wifi connection is established, and, of course, making the dispatcher script useless, since it's already started.
I thought I could simply fix this with "systemctl disable ntpd.service", but that doesn't really work. After a reboot the ntpd.service is re-enabled again. I *think* this is because the ntpd.service file contains the following section:
[Install]
WantedBy=multi-user.target
And the following command shows ntpd.service listed as well:
systemctl show -p "Wants" multi-user.target
Since I'm not that familiar with systemd (yet), my question is: is this what is happening? Does the ntpd.service get re-enabled because it has that "WantedBy" clause in its service file?
Now, if that is truly the case, is this a bug in the ntp package, or should I simply hack the ntpd.service file and remove the WantedBy clause? Or is that not recommended? I looked at the upstream code and the ntpd.service file appears to be Arch-specific, since it's not in the tarball.
Offline
I do not use network manager, so I am not really sure about this issue. But I think you could use systemd-analyze plot to see what is actually going on. I have a feeling that ntpd is just being pulled in as a dependency of the dispatcher-whodingy that you use.
Offline
As far as I know the [Install] section just decides where the symlink gets put WHEN you enable, it does not automatically enable the unit. After a fresh boot, try searching for ntpd.service in /etc/systemd/system/multi-user.target.wants, which is the list which actually is enabled by you the user. /lib/systemd/system/multi-user.target.wants/ contains the list which is by default enabled (in my case, dbus.service, getty.target, systemd-ask-passwordwall.path, systemd-logind.service, and systemd-user-sessions.service)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Good info, I did not know about systemd-analyze! Unfortunately, that made it even more mysterious.
Here is my output: http://imgur.com/ePWrb
I read this graph as if ntpd.service seems to be started by the network.target. But where is that defined so I can change this?
Offline
After a fresh boot, try searching for ntpd.service in /etc/systemd/system/multi-user.target.wants, which is the list which actually is enabled by you the user.
Ah! I think I found the culprit. Here's the rundown. I call "systemctl disable ntpd.service" and my /etc/systemd/multi-user.target.wants folder no longer has a link to ntpd.service, as you describe.
I reboot and have no network cable connected, nor any "auto starting" wifi connections. After the reboot, still no entry for ntpd.service in multi-user.target.wants.
Then, I make a wifi connection, which triggers the call to the networkmanager-dispatcher-ntpd script.
Voila: a link now appears in multi-user.target and "systemctl status ntpd.service reports that it is enabled. Therefore, the networkmanager-dispatcher-ntpd script (or, I guess this could be the case, NetworkManager itself?) is re-enabling ntpd.service...
The dispatch script essentially makes this call when a connection is established:
gdbus call \
--system \
--object-path /org/freedesktop/timedate1 \
--dest org.freedesktop.timedate1 \
--method org.freedesktop.timedate1.SetNTP true false
I'm not familiar with "gdbus" - could this be re-enabling the systemd service? Or would it be NetworkManager itself that's re-enabling ntpd.service upon establishing a connection?
Offline
Very possible, Gnome is trying very hard to work through systemd. You should go to their bug tracker and file a bug about network manager enabling ntpd.service, since it seems odd that the behaviour would be to 'enable' rather than merely 'start'.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
So it is doing its job once, and enabling? Or is it simply not doing its job of starting but instead just enabling ntpd?
This is curious for sure.
Offline
Yes, I looked into the code for the org.freedesktop.timedate1 object and the call to SetNTP and the following snippet looks wrong to me. I think it is ALWAYS enabling and then starting the ntpd.service. I think this is a bug. It should only start the service?
...
} else if (dbus_message_is_method_call(message, "org.freedesktop.timedate1", "SetNTP")) {
...
r = enable_ntp(connection, &error);
if (r < 0)
return bus_send_error_reply(connection, message, &error, r);
r = start_ntp(connection, &error);
if (r < 0)
return bus_send_error_reply(connection, message, &error, r);
..
Offline
I submitted this to the freedesktop Bugzilla:
Offline
I submitted this to the freedesktop Bugzilla:
Thanks, would be good once that's settled to come back here and post the results (just for thread completeness). Really seems to be a bug there, enabling and starting rather than just starting.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
I wonder why ntpd is that quick on my installation, it is the fastest service ever seen .
4ms ntpd.service
On twelveeighty's bootchart it takes around 3000 ms .
As there is no dispatcher package here, this is another evidence for the bug.
Offline
I wonder why ntpd is that quick on my installation, it is the fastest service ever seen .
4ms ntpd.service
On twelveeighty's bootchart it takes around 3000 ms .
As there is no dispatcher package here, this is another evidence for the bug.
No, it is not, your symptom is totally unrelated. Or does every software only have one BUG now rather than (possibly) multiple bugs. In this case the bug being discussed isn't even a problem with ntpd.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
I haven't heard anything yet on the bug report I filed. But, in the mean time, for those Googling this, here is my (temporary?) modified NetworkManager dispatcher script to start ntpd after a connection has been made:
/etc/NetworkManager/dispatcher.d/10-ntpd (modified from the networkmanager-dispatcher-ntpd package)
#!/bin/bash
timedate1() {
gdbus call \
--system \
--object-path /org/freedesktop/timedate1 \
--dest org.freedesktop.timedate1 \
--method org.freedesktop.timedate1.SetNTP "$@"
}
if [ -e /sys/fs/cgroup/systemd ]; then
case "$2" in
up)
# HACK for bug in timedate1.SetNTP that re-enables ntpd.service
# timedate1 true false
systemctl start ntpd.service
;;
down)
# HACK for bug in timedate1.SetNTP that re-enables ntpd.service
# timedate1 false false
systemctl stop ntpd.service
;;
esac
else
if [ -e "/etc/rc.d/ntpd" ]; then
case "$2" in
up)
rc.d start ntpd
;;
down)
rc.d stop ntpd
;;
esac
fi
fi
Offline
Another update on this.
The folks at freedesktop.org have closed the bug saying that this is not the proper usage of the SetNTP function (see comments in the bug). This now throws it back to the Arch package for networkmanager-dispatcher-ntpd. I've opened a bug on the Arch Linux Bug Tracker: https://bugs.archlinux.org/task/32049
Since this is now all on the Arch side, please "Watch" the bug for updates, by selecting that option in the Bug Tracker.
Offline