FS#30220 - [networkmanager-dispatcher-ntpd] systemd support (patch included)

Attached to Project: Community Packages
Opened by Swift Geek (swiftgeek) - Saturday, 09 June 2012, 17:03 GMT
Last edited by Jelle van der Waa (jelly) - Thursday, 06 September 2012, 09:07 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Jelle van der Waa (jelly)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Added support for systemd via use of `ps -p 1 ch -o cmd`
Works fine with e4rat ;)

http://pastebin.com/THUNkNC4
This task depends upon

Closed by  Jelle van der Waa (jelly)
Thursday, 06 September 2012, 09:07 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in -4
Comment by Swift Geek (swiftgeek) - Saturday, 09 June 2012, 17:50 GMT
Second possible solution is making use of [[ -e /sys/fs/cgroup/systemd ]]
http://pastebin.com/AdhnVgc9
Comment by Jelle van der Waa (jelly) - Monday, 11 June 2012, 06:50 GMT
Thanks for the script I will look into applying it
Comment by Swift Geek (swiftgeek) - Monday, 11 June 2012, 07:01 GMT
That second solution is much less complicated and cleaner. And upstart does also respond with "init" for `ps -p 1 ch -o cmd`, so there is probably no point in using that case switch.
Comment by Dave Reisner (falconindy) - Monday, 11 June 2012, 10:16 GMT
This is wrong, because it assumes the name of the ntp daemon. You should be starting systemd-timedated-ntpd.target instead.
Comment by Swift Geek (swiftgeek) - Friday, 15 June 2012, 03:29 GMT Comment by Swift Geek (swiftgeek) - Tuesday, 07 August 2012, 09:51 GMT
  • Field changed: Percent Complete (100% → 0%)
Doesn't work anymore with recent systemd
https://bbs.archlinux.org/viewtopic.php?id=145010
Comment by Vasil Yonkov (spirtbrat) - Tuesday, 28 August 2012, 07:33 GMT
Let's go back to assuming, please. There's nothing wrong with assuming.
And it works, also.
Comment by Swift Geek (swiftgeek) - Tuesday, 28 August 2012, 07:45 GMT
Then just copy this http://pastebin.com/AdhnVgc9 to /etc/NetworkManager/dispatcher.d/10-ntpd
Also add that to pacman.conf:
NoUpgrade = etc/NetworkManager/dispatcher.d/10-ntpd
Comment by Vasil Yonkov (spirtbrat) - Tuesday, 28 August 2012, 07:51 GMT
I know how to fix it for myself. But if everyone have to do that, what's the point of this package?
Comment by Swift Geek (swiftgeek) - Tuesday, 28 August 2012, 07:59 GMT
It's just not the right way to do it
SetNTP() http://www.freedesktop.org/wiki/Software/systemd/timedated

And i'm not good with dbus (especially from scripts)
Comment by Dave Reisner (falconindy) - Tuesday, 28 August 2012, 12:18 GMT
Something like this might work...

gdbus call --system --object-path /org/freedesktop/timedate1 --dest org.freedesktop.timedate1 --method org.freedesktop.timedate1.SetNTP true false

Anyone care to test? I don't use this stuff.
Comment by Swift Geek (swiftgeek) - Tuesday, 28 August 2012, 12:26 GMT
Seems to work
EDIT: works even without starting /usr/lib/systemd/system/systemd-timedated.service
EDIT2: updated script http://pastebin.com/AdhnVgc9
Comment by Vasil Yonkov (spirtbrat) - Tuesday, 28 August 2012, 12:40 GMT
What do you mean it works? What is this command supposed to do?
According to the limited information on the web, this thing should either:

- start the ntpd.service (or whatever configured)
OR
- start the ntpd.service just to set the time and then stop it and exit

It is not clear which one exactly.
And it doesn't seem to do either.
Here, timedated's NTP string is already set to true:

$ dbus-send --system --print-reply --dest=org.freedesktop.timedate1 /org/freedesktop/timedate1 org.freedesktop.DBus.Properties.GetAll string:org.freedesktop.timedate1
method return sender=:1.206 -> dest=:1.207 reply_serial=2
array [
dict entry(
string "Timezone"
variant string "Europe/Sofia"
)
dict entry(
string "LocalRTC"
variant boolean false
)
dict entry(
string "NTP"
variant boolean true
)
]
$

but ntpd.service is not engaged as supposed to when systemd-timedated.service is started.

Can you shine some light on the process, the expected and the achieved results, please.
Comment by Dave Reisner (falconindy) - Tuesday, 28 August 2012, 12:50 GMT
Right, so since the changes in 187, there's obviously two "conflicting" things here and this bug is no longer the same as it originally was reported as.

1) network-manager supports dispatcher hooks to start/stop things on network up/down. This is what this hook is being abused for.
2) systemd-timedated allows applets to control time and date setting including use of an NTP daemon, over Dbus.

Really, these things are orthogonal.

In my opinion, this should be documented on the wiki and left at that. There's really strange behavior here like start/stop ntpd on vpn connection state. If you bring your VPN connection down but still have an internet connection, why should your ntpd turn off? Of course, maybe that makes sense for some people...
Comment by Swift Geek (swiftgeek) - Tuesday, 28 August 2012, 12:54 GMT
After passing this weird long command with true false
1. systemd-timedated.service is started
2. ntpd.service (or whatever else) is started by systemd-timedated.service
3. systemd-timedated.service is stopped after some short time

After passing this weird long command with false false
1. systemd-timedated.service is started
2. ntpd.service (or whatever else) is stopped by systemd-timedated.service
3. systemd-timedated.service is stopped after some short time
Comment by Vasil Yonkov (spirtbrat) - Tuesday, 28 August 2012, 13:09 GMT
@swiftgeek
Thanks for the explanation.
I also can confirm that this thing works.
falconindy's argument about the VPN have merit, though.
Comment by Swift Geek (swiftgeek) - Wednesday, 05 September 2012, 14:52 GMT
  • Field changed: Percent Complete (100% → 0%)
I don't see it uploaded upstream
EDIT: It was uploaded few hours later. It can be closed now

Loading...