[opensuse-factory] ntpd stop script hanging since conversion to systemd unit
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved. But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all the stuff that the current start script is doing should go into ExecStartPre? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz composed on 2018-11-13 21:24 (UTC+0100):
The handling of ntpd apparently switched from an old-style rc script to a systemd unit....
I think you are right. NTP has apparently been deprecated. I've been doing: # zypper rm ntp # systemctl enable systemd-timesyncd # systemctl start systemd-timesyncd No NTP stop hangs for me. :-) -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata writes:
I think you are right. NTP has apparently been deprecated. I've been doing:
I actually use it to provide a stratum-1 network time source based on a GPS PPS, so timesyncd (which like all SNTP clients you shouldn't be using either if you care about time) isn't cutting it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Dienstag, 13. November 2018 21:52:13 CET Achim Gratz wrote:
Felix Miata writes:
I think you are right. NTP has apparently been deprecated. I've been doing: I actually use it to provide a stratum-1 network time source based on a GPS PPS, so timesyncd (which like all SNTP clients you shouldn't be using either if you care about time) isn't cutting it.
NTPd has been replaced by chrony. It supports GPS PPS. https://chrony.tuxfamily.org/comparison.html timesyncd is completely sufficient for most desktop users who only need their clock to be accurate in the millisecond range. Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Brüns, Stefan wrote:
timesyncd is completely sufficient for most desktop users who only need their clock to be accurate in the millisecond range.
Are you really trusting it to better than say 25ms? (I'm running it on the laptop, too. But not on any machine that needs single-digit ms accuracy...) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Brüns, Stefan writes:
NTPd has been replaced by chrony.
Please, I have asked about an apparent problem with systemd integration for NTPd, not unsolicited (and often hilariously wrong) advice about other time services.
timesyncd is completely sufficient for most desktop users who only need their clock to be accurate in the millisecond range.
Accuracy doesn't even figure into your set of requirements if you use an SNTP client unless you can ensure that the single source of time that gets chosen is under your control at all times. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mittwoch, 14. November 2018 21:00:20 CET Achim Gratz wrote:
Brüns, Stefan writes:
NTPd has been replaced by chrony.
Please, I have asked about an apparent problem with systemd integration for NTPd, not unsolicited (and often hilariously wrong) advice about other time services.
Chrony very likely is a suitable replacement for NTPd, so using chrony instead will avoid the problems you have with NTPd. Do you have any requirements beyond GPS PPS you forgot to mention? As ntpd no longer is the default ntp server implementation for (open)SUSE, it is likely more issues appear over the course of time. No reason to be rude ... Regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Donnerstag, 15. November 2018 09:36:00 CET Stefan Seyfried wrote:
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true.
The very last paragraph in the comparison I linked previously, ntp-refclock is mentioned: https://github.com/mlichvar/ntp-refclock Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 15.11.18 um 16:53 schrieb Brüns, Stefan:
On Donnerstag, 15. November 2018 09:36:00 CET Stefan Seyfried wrote:
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true.
The very last paragraph in the comparison I linked previously, ntp-refclock is mentioned:
OK, so I should replace ntpd with ntpd plus chrony? Sounds like a very good idea. NOT. I'll probably just keep using ntpd. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Samstag, 17. November 2018 13:00:10 CET Stefan Seyfried wrote:
Am 15.11.18 um 16:53 schrieb Brüns, Stefan:
On Donnerstag, 15. November 2018 09:36:00 CET Stefan Seyfried wrote:
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true.
The very last paragraph in the comparison I linked previously, ntp-refclock is mentioned:
OK, so I should replace ntpd with ntpd plus chrony?
No. ntp-refclock *reuses* hardware drivers distributed as part of ntp and makes them work standalone. It is a very tiny part of ntp. Of course someone could just do a fork of ntp with only the drivers and delete the ntp daemon itself. That would be a win for everybody, nobody would cry "NIH", or blame someone for segmentation. NOT! The NTP *core* is showing its age, so it makes sense to replace it, but reuse as much as possible. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Am 17.11.18 um 17:23 schrieb Stefan Brüns:
On Samstag, 17. November 2018 13:00:10 CET Stefan Seyfried wrote:
Am 15.11.18 um 16:53 schrieb Brüns, Stefan:
On Donnerstag, 15. November 2018 09:36:00 CET Stefan Seyfried wrote:
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true.
The very last paragraph in the comparison I linked previously, ntp-refclock is mentioned:
OK, so I should replace ntpd with ntpd plus chrony?
No. ntp-refclock *reuses* hardware drivers distributed as part of ntp and makes them work standalone. It is a very tiny part of ntp.
OK, and then I need a "ntp-broadcast" deamon in addition to chrony to use broadcast / multicast ntp etc.,
Of course someone could just do a fork of ntp with only the drivers and delete the ntp daemon itself. That would be a win for everybody, nobody would cry "NIH", or blame someone for segmentation.
NOT!
The NTP *core* is showing its age, so it makes sense to replace it
Well, it works well for me, despite its age ;-) And I'm not going to replace it with something that does not support the things I use at all... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Samstag, 17. November 2018 19:34:53 CET Stefan Seyfried wrote:
Am 17.11.18 um 17:23 schrieb Stefan Brüns:
On Samstag, 17. November 2018 13:00:10 CET Stefan Seyfried wrote:
Am 15.11.18 um 16:53 schrieb Brüns, Stefan:
On Donnerstag, 15. November 2018 09:36:00 CET Stefan Seyfried wrote:
Am 14.11.18 um 22:06 schrieb Brüns, Stefan:
Chrony very likely is a suitable replacement for NTPd,
If I'd only find out how to connect my serial DCF77 clock to chrony, this might become true.
The very last paragraph in the comparison I linked previously, ntp-refclock is mentioned:
OK, so I should replace ntpd with ntpd plus chrony?
No. ntp-refclock *reuses* hardware drivers distributed as part of ntp and makes them work standalone. It is a very tiny part of ntp.
OK, and then I need a "ntp-broadcast" deamon in addition to chrony to use broadcast / multicast ntp etc.,
Chrony can broadcast. I does not listen to broadcasts, see https:// chrony.tuxfamily.org/ faq.html#_can_code_chronyd_code_be_driven_from_broadcast_multicast_ntp_servers for the reasoning. How many clients do you have in your network? 10.000? 100.000? Or is this just a strawman? Using a GPS PPS clock and broadcast mode is contradicting ... Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Am 17.11.18 um 19:47 schrieb Stefan Brüns:
On Samstag, 17. November 2018 19:34:53 CET Stefan Seyfried wrote:
No. ntp-refclock *reuses* hardware drivers distributed as part of ntp and makes them work standalone. It is a very tiny part of ntp.
OK, and then I need a "ntp-broadcast" deamon in addition to chrony to use broadcast / multicast ntp etc.,
Chrony can broadcast. I does not listen to broadcasts, see https:// chrony.tuxfamily.org/ faq.html#_can_code_chronyd_code_be_driven_from_broadcast_multicast_ntp_servers for the reasoning.
How many clients do you have in your network? 10.000? 100.000?
about 20, but ntp broadcast is just an easy no-configuration-needed setup that I'm using now since about 15 years. But yes, changing this to e.g. dhcp based config would be a solution. For most of the clients probably also systemd-timesyncd would be good enough, but my "maschine-schoen.sh" script that runs after installation definitely would need changing ;-)
Or is this just a strawman? Using a GPS PPS clock and broadcast mode is contradicting ...
It's a DCF77 serial port receiver, and it worked beautifully with broadcast. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried wrote:
Am 17.11.18 um 19:47 schrieb Stefan Brüns:
On Samstag, 17. November 2018 19:34:53 CET Stefan Seyfried wrote:
No. ntp-refclock *reuses* hardware drivers distributed as part of ntp and makes them work standalone. It is a very tiny part of ntp.
OK, and then I need a "ntp-broadcast" deamon in addition to chrony to use broadcast / multicast ntp etc.,
Chrony can broadcast. I does not listen to broadcasts, see https:// chrony.tuxfamily.org/
faq.html#_can_code_chronyd_code_be_driven_from_broadcast_multicast_ntp_servers
for the reasoning.
How many clients do you have in your network? 10.000? 100.000?
about 20, but ntp broadcast is just an easy no-configuration-needed setup that I'm using now since about 15 years.
FWIW, exactly the same config here, including the DCF77 serial clock. -- Per Jessen, Zürich (2.1°C) member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 14 2018, "Brüns, Stefan" <Stefan.Bruens@rwth-aachen.de> wrote:
Chrony very likely is a suitable replacement for NTPd,
Netconfig doesn't appear to support chrony yet. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz composed on 2018-11-13 21:52 (UTC+0100):
Felix Miata writes:
I think you are right. NTP has apparently been deprecated. I've been doing:
I actually use it to provide a stratum-1 network time source based on a GPS PPS, so timesyncd (which like all SNTP clients you shouldn't be using either if you care about time) isn't cutting it.
I forgot to mention why "I've been doing" (the switch to systemd-timesyncd) was because of the ntp shutdown delays, which I mentioned on the opensuse list, without getting a solution, last May: https://lists.opensuse.org/opensuse/2018-05/msg00912.html Failure to get a solution repeated in July: https://lists.opensuse.org/opensuse-support/2018-07/msg00003.html I only discovered systemd-timesyncd around two weeks ago. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2018-11-13 21:34, Felix Miata wrote:
Achim Gratz composed on 2018-11-13 21:24 (UTC+0100):
The handling of ntpd apparently switched from an old-style rc script to a systemd unit....
I think you are right. NTP has apparently been deprecated. I've been doing:
Not deprecated, just.. timesyncd is good enough for some people who do not require the extra features of NTP. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz wrote:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits.
Cannot reproduce/confirm on Leap15: office38:~ # time (systemctl stop ntpd) real 0m0.498s user 0m0.011s sys 0m0.003s According to the manpage(s), when there is no specific ExecStop action, the process will just be sent a SIGTERM. -- Per Jessen, Zürich (8.2°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Per Jessen writes:
According to the manpage(s), when there is no specific ExecStop action, the process will just be sent a SIGTERM.
That's my assumption, too. But obviously systemd doesn't think the process has terminated and keeps waiting for that to happen: Nov 13 21:54:55 Gertrud systemd[1]: Stopping Login Service... Nov 13 21:54:55 Gertrud systemd[1]: Stopped target System Time Synchronized. Nov 13 21:54:55 Gertrud systemd[1]: Stopping NTP Server Daemon... Nov 13 21:54:55 Gertrud systemd[1]: Stopping Permit User Sessions... Nov 13 21:54:55 Gertrud systemd[1]: Received SIGRTMIN+20 from PID 17247 (plymouthd). Nov 13 21:54:55 Gertrud kernel: pps pps0: removed Nov 13 21:54:55 Gertrud systemd[1]: Stopped Permit User Sessions. Nov 13 21:54:55 Gertrud systemd[1]: Stopped target Remote File Systems. Nov 13 21:54:55 Gertrud systemd[1]: Stopping Login and scanning of iSCSI devices... Nov 13 21:54:55 Gertrud systemd[1]: Stopped target Remote File Systems (Pre). Nov 13 21:54:55 Gertrud systemd[1]: Started Show Plymouth Power Off Screen. Nov 13 21:54:55 Gertrud iscsiadm[17249]: iscsiadm: No matching sessions found Nov 13 21:54:55 Gertrud iscsiadm[17250]: iscsiadm: No matching sessions found Nov 13 21:54:55 Gertrud systemd[1]: Stopped Login and scanning of iSCSI devices. Nov 13 21:54:55 Gertrud systemd[1]: Stopped Login Service. Nov 13 21:54:55 Gertrud systemd[1]: Stopped target User and Group Name Lookups. Nov 13 21:54:55 Gertrud systemd[1]: Stopped Restore /run/initramfs on shutdown. Nov 13 21:55:57 Gertrud systemd[1]: Stopped NTP Server Daemon. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
14.11.2018 23:05, Achim Gratz пишет:
Per Jessen writes:
According to the manpage(s), when there is no specific ExecStop action, the process will just be sent a SIGTERM.
That's my assumption, too. But obviously systemd doesn't think the process has terminated
You asked systemd and it told you so privately? May be process really has not terminated? Do you have any evidence that at 21:44:55 ntpd processes were stopped and so it was systemd fault to not notice it?
and keeps waiting for that to happen:
If you can reproduce it reliably, enable systemd debug output before shutdown (/bin/kill -RTMIN+22 1) and check whether (and when) ntpd processes terminated.
Nov 13 21:54:55 Gertrud systemd[1]: Stopping Login Service... Nov 13 21:54:55 Gertrud systemd[1]: Stopped target System Time Synchronized. Nov 13 21:54:55 Gertrud systemd[1]: Stopping NTP Server Daemon... Nov 13 21:54:55 Gertrud systemd[1]: Stopping Permit User Sessions... Nov 13 21:54:55 Gertrud systemd[1]: Received SIGRTMIN+20 from PID 17247 (plymouthd). Nov 13 21:54:55 Gertrud kernel: pps pps0: removed Nov 13 21:54:55 Gertrud systemd[1]: Stopped Permit User Sessions. Nov 13 21:54:55 Gertrud systemd[1]: Stopped target Remote File Systems. Nov 13 21:54:55 Gertrud systemd[1]: Stopping Login and scanning of iSCSI devices... Nov 13 21:54:55 Gertrud systemd[1]: Stopped target Remote File Systems (Pre). Nov 13 21:54:55 Gertrud systemd[1]: Started Show Plymouth Power Off Screen. Nov 13 21:54:55 Gertrud iscsiadm[17249]: iscsiadm: No matching sessions found Nov 13 21:54:55 Gertrud iscsiadm[17250]: iscsiadm: No matching sessions found Nov 13 21:54:55 Gertrud systemd[1]: Stopped Login and scanning of iSCSI devices. Nov 13 21:54:55 Gertrud systemd[1]: Stopped Login Service. Nov 13 21:54:55 Gertrud systemd[1]: Stopped target User and Group Name Lookups. Nov 13 21:54:55 Gertrud systemd[1]: Stopped Restore /run/initramfs on shutdown. Nov 13 21:55:57 Gertrud systemd[1]: Stopped NTP Server Daemon.
Regards, Achim.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov writes:
If you can reproduce it reliably, enable systemd debug output before shutdown (/bin/kill -RTMIN+22 1) and check whether (and when) ntpd processes terminated.
Nov 18 11:40:06 Gertrud systemd[1]: Received SIGRTMIN+22 from PID 4387 (kill). Nov 18 11:40:06 Gertrud systemd[1]: Setting log level to debug. Nov 18 11:40:28 Gertrud systemd[1]: Bus private-bus-connection: changing state UNSET → OPENING Nov 18 11:40:28 Gertrud systemd[1]: Bus private-bus-connection: changing state OPENING → AUTHENTICATING Nov 18 11:40:28 Gertrud systemd[1]: Accepted new private connection. Nov 18 11:40:28 Gertrud systemd[1]: Bus private-bus-connection: changing state AUTHENTICATING → RUNNING Nov 18 11:40:28 Gertrud systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.syste> Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Trying to enqueue job ntpd.service/stop/replace Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Installed new job ntpd.service/stop as 3220 Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Enqueued job ntpd.service/stop as 3220 Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 s> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=JobNew> Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Changed running -> stop-sigterm Nov 18 11:40:28 Gertrud systemd[1]: Stopping NTP Server Daemon... Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.f> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.f> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.freedesktop.DBus.Prope> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.freedesktop.DBus.Prope> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/job/3220 interface=org.freedesktop.> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/job/3220 interface=org.freedesktop.DBus.Properties membe> Nov 18 11:40:28 Gertrud systemd[1]: Received SIGCHLD from PID 1674 (ntpd). Nov 18 11:40:28 Gertrud systemd[1]: Child 1674 (ntpd) died (code=exited, status=0/SUCCESS) Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Child 1674 belongs to ntpd.service. Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Main process exited, code=exited, status=0/SUCCESS Nov 18 11:40:28 Gertrud systemd[1]: ntpd.service: Changed stop-sigterm -> final-sigterm Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.f> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.f> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.freedesktop.DBus.Prope> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=org.freedesktop.DBus.Prope> Nov 18 11:40:28 Gertrud systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.syste> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=8 reply_cookie=2 s> Nov 18 11:40:28 Gertrud systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1/unit/ntpd_2eservice interface=o> Nov 18 11:40:28 Gertrud systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=9 reply_cookie=3 s> Nov 18 11:40:35 Gertrud systemd[1]: Received SIGCHLD from PID 1677 (ntpd). Nov 18 11:40:35 Gertrud systemd[1]: Child 1677 (ntpd) died (code=exited, status=0/SUCCESS) Nov 18 11:40:35 Gertrud systemd[1]: ntpd.service: Child 1677 belongs to ntpd.service. Nov 18 11:40:35 Gertrud systemd[1]: ntpd.service: cgroup is empty Nov 18 11:40:35 Gertrud systemd[1]: ntpd.service: Changed final-sigterm -> dead Nov 18 11:40:35 Gertrud systemd[1]: ntpd.service: Job ntpd.service/stop finished, result=done Nov 18 11:40:35 Gertrud systemd[1]: Stopped NTP Server Daemon. So it seems that indeed the asynchronous resolver is what hangs, while ntpd itself has already exited. Why it does that is not clear, but I have a hunch… one of my rasPi shredded its SD card recently, so I took it out of service until I get a replacement. It's still resolved in DNS, but of course won't answer. I have removed that server from the config, let's see if that helps (a quick restart went smoothly, but that may not mean much). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
So it seems that indeed the asynchronous resolver is what hangs, while ntpd itself has already exited. Why it does that is not clear, but I have a hunch… one of my rasPi shredded its SD card recently, so I took it out of service until I get a replacement. It's still resolved in DNS, but of course won't answer. I have removed that server from the config, let's see if that helps (a quick restart went smoothly, but that may not mean much).
The peer config for the non-answering rasPi was indeed the reason for hanging up the async resolver process on exit. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-11-13 at 21:24 +0100, Achim Gratz wrote:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown.
Strange - AFAICS the systemd unit files for ntp have existed for more than 4 years in factory.
I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved.
Not really involved. For forking daemons, systemd simply kills and checks the PID mentioned in the PIDfile directive.
But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all the stuff that the current start script is doing should go into ExecStartPre?
Please consider opening a bug. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
15.11.2018 2:34, Martin Wilck пишет:
On Tue, 2018-11-13 at 21:24 +0100, Achim Gratz wrote:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown.
Strange - AFAICS the systemd unit files for ntp have existed for more than 4 years in factory.
This is not the first report that ntpd service takes long time on shutdown.
I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved.
Not really involved. For forking daemons, systemd simply kills and checks the PID mentioned in the PIDfile directive.
systemd waits for all processes to stop. ntpd starts at least one more process for asynchronous resolver. It's possible that this process may get blocked and ignores SIGTERM. It is even possible that it gets blocked somewhere in a library call and so the reason is outside of ntpd. I am not sure how to debug it, given that it seems to happen on shutdown only (and logs presented here are obviously from system shutdown as well). I thought that it may be related to network being stopped too early, but simple minded "systemctl stop network; systemctl stop ntpd" still has no delay. But if someone can reproduce it with high probability (I cannot) running with systemd debug level output is the first step.
But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all
systemd does exactly the same in both cases - it either runs ExecStop or sends signal, so I do not see how it is going to change anything.
the stuff that the current start script is doing should go into ExecStartPre?
Please consider opening a bug.
Martin
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov writes:
systemd waits for all processes to stop. ntpd starts at least one more process for asynchronous resolver. It's possible that this process may get blocked and ignores SIGTERM. It is even possible that it gets blocked somewhere in a library call and so the reason is outside of ntpd.
OK, I didn't think about the DNS resolver. That might be another push to make the switch to NTPsec on this machine also.
I am not sure how to debug it, given that it seems to happen on shutdown only (and logs presented here are obviously from system shutdown as well). I thought that it may be related to network being stopped too early, but simple minded "systemctl stop network; systemctl stop ntpd" still has no delay.
Well, I could actually reproduce it by shutting down ntpd via systemctl.
But if someone can reproduce it with high probability (I cannot) running with systemd debug level output is the first step.
After yesterday's kernel update the shutdown was without any delay. I actually rebooted and did another (immediate) shutdown and that went OK also. If it's still reproduceable, I'll follow up with your suggestion about the systemd debugging.
systemd does exactly the same in both cases - it either runs ExecStop or sends signal, so I do not see how it is going to change anything.
OK. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2018-11-13 a las 21:24 +0100, Achim Gratz escribió:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits.
I understand because it also updates the CMOS battery backed clock. This should only require about two or three seconds (the write is done on the second boundary, IIRC), so I don't know the reason for the rest; maybe some more reads, which may take a second each. Perhaps it tells network peers that it is going down, does some calculations like local clock drift and stores them... I don't know. - -- Cheers Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCW+zTVBQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1R0fAKCTxsweZe+sAo0cHieu3yGc6qkOygCd ELZ7Du9fNMSOpj4/q/u3ygYbwxM= =Tkqd -----END PGP SIGNATURE-----
Il 13/11/18 18:24, Achim Gratz ha scritto:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved. But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all the stuff that the current start script is doing should go into ExecStartPre?
Regards, Achim.
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd. Despite this it seems ntp package being still necessary (?) or could be removed by the system? To verify if my system is synchronized I use the command "timedatectl": marco@linux-turion64:~> timedatectl Local time: dom 2018-11-18 11:40:48 -02 Universal time: dom 2018-11-18 13:40:48 UTC RTC time: dom 2018-11-18 11:40:48 Time zone: America/Sao_Paulo (-02, -0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: yes To get more details chronyd has its client commands available through "chronyc" marco@linux-turion64:~> sudo chronyc chrony version 3.4 Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public License version 2 for details. chronyc> tracking Reference ID : B03A5878 (lhr1.m-d.net) Stratum : 3 Ref time (UTC) : Sun Nov 18 13:41:00 2018 System time : 0.002480803 seconds fast of NTP time Last offset : +0.002829565 seconds RMS offset : 0.006423603 seconds Frequency : 9.606 ppm slow Residual freq : -21.809 ppm Skew : 0.606 ppm Root delay : 0.221706599 seconds Root dispersion : 0.040505521 seconds Update interval : 64.5 seconds Leap status : Normal chronyc> activity 200 OK 4 sources online 0 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address chronyc> sources 210 Number of sources = 4 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^+ speglar.simnet.is 2 6 377 2 +2930us[+2930us] +/- 132ms ^* lhr1.m-d.net 2 6 377 2 -1424us[-1726us] +/- 131ms ^+ ns5.asda.gr 2 6 377 2 +39us[ -263us] +/- 152ms ^- ntp2.torix.ca 1 6 377 2 -1161us[-1161us] +/- 583ms chronyc> But I don't know if ntpd "being better" than chronyd or not... Cheers, -- Marco Calistri Build: openSUSE Tumbleweed 20181116 Kernel: 4.19.1-1-default - Cinnamon 3.8.9
On 18/11/2018 14.51, Marco Calistri wrote:
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
To verify if my system is synchronized I use the command "timedatectl":
marco@linux-turion64:~> timedatectl Local time: dom 2018-11-18 11:40:48 -02 Universal time: dom 2018-11-18 13:40:48 UTC RTC time: dom 2018-11-18 11:40:48 Time zone: America/Sao_Paulo (-02, -0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: yes
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient. It also, now that I think, does not display the network time at all, in my case from ntp, so I do not know how well my clock is synced - or not. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
El 18-11-2018 a las 15:56, Carlos E. R. escribió:
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient.
It also, now that I think, does not display the network time at all,
Of course, it displays the system time.. not the network time. in
my case from ntp, so I do not know how well my clock is synced - or not.
"NTP service:" will always be "inactive" if you are running anything but systemd-timesyncd.. it no longer knows about the status of other implementations -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/11/2018 20.27, Cristian Rodríguez wrote:
El 18-11-2018 a las 15:56, Carlos E. R. escribió:
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient.
It also, now that I think, does not display the network time at all,
Of course, it displays the system time.. not the network time.
in my case from ntp, so I do not know how well my clock is synced - or not.
"NTP service:" will always be "inactive" if you are running anything but systemd-timesyncd.. it no longer knows about the status of other implementations
But I don't. All my systems are still using ntpd, except my new and tiny laptop which uses chrony :-) I do not know yet what advantages chrony brings. My laptops might use systemd-timesyncd, but I have not changed any of them yet, not seeing the advantage either. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
El 18-11-2018 a las 16:52, Carlos E. R. escribió:
I do not know yet what advantages chrony brings.
Let's say the traditional ntp daemon has not aged very well.. and is steadly bitrotting. until ntimed, which is the reference implementation replacement is mature enough, chrony is probably the best alternative if you need an NTP *server* or a very high precision client. otherwise, just use systemd-timesyncd. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/2018 14.09, Cristian Rodríguez wrote:
El 18-11-2018 a las 16:52, Carlos E. R. escribió:
I do not know yet what advantages chrony brings.
Let's say the traditional ntp daemon has not aged very well.. and is steadly bitrotting. until ntimed, which is the reference implementation replacement is mature enough, chrony is probably the best alternative if you need an NTP *server* or a very high precision client. otherwise, just use systemd-timesyncd.
Well, it seems openSUSE 15.0 defaults to chrony, that's what my small laptop got on fresh install. If it uses less memory, I'm certainly very interested. How does it cope if there is no internet? I have said often that the installation should ask what type of computer it is, and if it is a laptop, it should change things, like installing systemd-timesyncd instead. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Op maandag 19 november 2018 15:19:35 CET schreef Carlos E. R.:
I have said often that the installation should ask what type of computer it is, and if it is a laptop, it should change things, like installing systemd-timesyncd instead.
Normally a laptop does have a battery to keep the clock running, so when starting the system without an Internet connection it still has a proper notion of the current time. However when such a system does not have such a clock, like single board computers (SBCs), systemd-timesyncd is the proper utility to be used. In that case, when files are generated, these files will have timestamps later than the time before the start of the system. Early log entries may still have times before that time, but in the journal you will see when the time is set by systemd-timesyncd. Only after an established Internet connection the time will be synchronized with the world clock. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I have said often that the installation should ask what type of computer it is, and if it is a laptop, it should change things, like installing systemd-timesyncd instead.
Normally a laptop does have a battery to keep the clock running [...]
However when such a system does not have such a clock [...]
This is also a nice example why every installer component needs an expert mode: There are always exceptions. Here, a laptop's cmos battery may be empty, e.g. due to age. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/2018 15.54, Freek de Kruijf wrote:
Op maandag 19 november 2018 15:19:35 CET schreef Carlos E. R.:
I have said often that the installation should ask what type of computer it is, and if it is a laptop, it should change things, like installing systemd-timesyncd instead.
Normally a laptop does have a battery to keep the clock running, so when starting the system without an Internet connection it still has a proper notion of the current time.
Yes. But previous tools took notice on how much the CMOS clock drifted while the computer was off, before setting up the system time. Similarly, the frequency of the system clock was adjusted. Does systemd-timesyncd take this into account?
However when such a system does not have such a clock, like single board computers (SBCs), systemd-timesyncd is the proper utility to be used. In that case, when files are generated, these files will have timestamps later than the time before the start of the system. Early log entries may still have times before that time, but in the journal you will see when the time is set by systemd-timesyncd. Only after an established Internet connection the time will be synchronized with the world clock.
Yes; I see that in my router, for instance. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Op maandag 19 november 2018 20:00:23 CET schreef Carlos E. R.:
Yes. But previous tools took notice on how much the CMOS clock drifted while the computer was off, before setting up the system time. Similarly, the frequency of the system clock was adjusted.
Does systemd-timesyncd take this into account?
The system time is stored regularly. When systemd-timesyncd is executed early in the boot process, the clock is restored at the time as can be seen in the journal. Obviously there is no indication of how well the system time changes. It changes in the same rate by which it changes between synchronization with the Internet clock before the boot. Later when an Internet connection is established the clock changes again to the world clock. After that it changes by some clock device in the processor until it is synchronized again with the world clock. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2018 15.19, Carlos E. R. wrote:
On 19/11/2018 14.09, Cristian Rodríguez wrote:>> El 18-11-2018 a las 16:52, Carlos E. R. escribió:
I do not know yet what advantages chrony brings.
Let's say the traditional ntp daemon has not aged very well.. and is steadly bitrotting. until ntimed, which is the reference implementation replacement is mature enough, chrony is probably the best alternative if you need an NTP *server* or a very high precision client. otherwise, just use systemd-timesyncd.
Well, it seems openSUSE 15.0 defaults to chrony, that's what my small laptop got on fresh install.
If it uses less memory, I'm certainly very interested.
chrony: top - 13:21:03 up 13 days, 12:59, 3 users, load average: 0.23, 0.46, 0.54 Tasks: 342 total, 1 running, 341 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1096244 free, 2397364 used, 448592 buff/cache KiB Swap: 12582908 total, 9669852 free, 2913056 used. 1185596 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 13757 cer 20 0 41344 4176 3564 0 R 22.22 0.106 0:00.06 top ... 1166 chrony 20 0 90388 76 0 132 S 0.000 0.002 0:00.72 chronyd systemd-timesyncd top - 13:25:34 up 13 days, 13:03, 3 users, load average: 0.39, 0.60, 0.59 Tasks: 323 total, 1 running, 322 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1002344 free, 2444456 used, 495400 buff/cache KiB Swap: 12582908 total, 9683932 free, 2898976 used. 1113416 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ... 14070 systemd+ 20 0 133332 3024 2560 S 0.000 0.077 0:00.03 systemd-timesyn Well, no, it seems systemd-timesyncd uses much more memory. I'm going back to chrony. - -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCW/VQswAKCRC1MxgcbY1H 1fc3AJ0ZT3lyk1Uh2Rn6GWIJRiEQvrphUwCcDYTc5FrFkP7x/QWCpTIu1GhW5Xw= =AVqP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 21 Nov 2018 13:33:56 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 19/11/2018 15.19, Carlos E. R. wrote:
On 19/11/2018 14.09, Cristian Rodríguez wrote:>> El 18-11-2018 a las 16:52, Carlos E. R. escribió:
[...]
Let's say the traditional ntp daemon has not aged very well.. and is steadly bitrotting. until ntimed, which is the reference implementation replacement is mature enough, chrony is probably the best alternative if you need an NTP *server* or a very high precision client. otherwise, just use systemd-timesyncd.
Well, it seems openSUSE 15.0 defaults to chrony, that's what my small laptop got on fresh install.
If it uses less memory, I'm certainly very interested.
chrony:
top - 13:21:03 up 13 days, 12:59, 3 users, load average: 0.23, 0.46, 0.54 Tasks: 342 total, 1 running, 341 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1096244 free, 2397364 used, 448592 buff/cache KiB Swap: 12582908 total, 9669852 free, 2913056 used. 1185596 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 1166 chrony 20 0 90388 76 0 132 S 0.000 0.002 0:00.72 chronyd
systemd-timesyncd
top - 13:25:34 up 13 days, 13:03, 3 users, load average: 0.39, 0.60, 0.59 Tasks: 323 total, 1 running, 322 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1002344 free, 2444456 used, 495400 buff/cache KiB Swap: 12582908 total, 9683932 free, 2898976 used. 1113416 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14070 systemd+ 20 0 133332 3024 2560 S 0.000 0.077 0:00.03 systemd-timesyn
Well, no, it seems systemd-timesyncd uses much more memory.
I'm going back to chrony.
If size is the only argument, ntpd is the smallest USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND ntp 1533 1 20 0 9962 14:48:24 - 0:00:05 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf ntp 1538 1533 20 0 9962 14:48:24 - 0:00:00 ntpd: asynchronous dns resolver USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND chrony 346 1 20 0 22305 13:43:27 - 0:00:00 /usr/sbin/chronyd PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1534 ntp 20 0 39848 4080 3300 S 0.000 0.025 0:00.00 ntpd 1535 ntp 20 0 39848 776 0 S 0.000 0.005 0:00.00 ntpd PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 346 chrony 20 0 89220 2484 2300 S 0.000 0.015 0:00.01 chronyd -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On 21/11/2018 13.51, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 13:33:56 +0100, "Carlos E. R." <> wrote:
If it uses less memory, I'm certainly very interested.
chrony:
top - 13:21:03 up 13 days, 12:59, 3 users, load average: 0.23, 0.46, 0.54 Tasks: 342 total, 1 running, 341 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1096244 free, 2397364 used, 448592 buff/cache KiB Swap: 12582908 total, 9669852 free, 2913056 used. 1185596 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 1166 chrony 20 0 90388 76 0 132 S 0.000 0.002 0:00.72 chronyd
systemd-timesyncd
top - 13:25:34 up 13 days, 13:03, 3 users, load average: 0.39, 0.60, 0.59 Tasks: 323 total, 1 running, 322 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1002344 free, 2444456 used, 495400 buff/cache KiB Swap: 12582908 total, 9683932 free, 2898976 used. 1113416 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14070 systemd+ 20 0 133332 3024 2560 S 0.000 0.077 0:00.03 systemd-timesyn
Well, no, it seems systemd-timesyncd uses much more memory.
I'm going back to chrony.
If size is the only argument, ntpd is the smallest
USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND ntp 1533 1 20 0 9962 14:48:24 - 0:00:05 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf ntp 1538 1533 20 0 9962 14:48:24 - 0:00:00 ntpd: asynchronous dns resolver
USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND chrony 346 1 20 0 22305 13:43:27 - 0:00:00 /usr/sbin/chronyd
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1534 ntp 20 0 39848 4080 3300 S 0.000 0.025 0:00.00 ntpd 1535 ntp 20 0 39848 776 0 S 0.000 0.005 0:00.00 ntpd
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 346 chrony 20 0 89220 2484 2300 S 0.000 0.015 0:00.01 chronyd
Chrony uses half the resident size than ntpd (top output). The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Wed, 21 Nov 2018 14:07:13 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 21/11/2018 13.51, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 13:33:56 +0100, "Carlos E. R." <> wrote:
[...]
chrony:
top - 13:21:03 up 13 days, 12:59, 3 users, load average: 0.23, 0.46, 0.54 Tasks: 342 total, 1 running, 341 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1096244 free, 2397364 used, 448592 buff/cache KiB Swap: 12582908 total, 9669852 free, 2913056 used. 1185596 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 1166 chrony 20 0 90388 76 0 132 S 0.000 0.002 0:00.72 chronyd
systemd-timesyncd
top - 13:25:34 up 13 days, 13:03, 3 users, load average: 0.39, 0.60, 0.59 Tasks: 323 total, 1 running, 322 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.9 us, 4.7 sy, 0.1 ni, 76.7 id, 0.1 wa, 0.0 hi, 0.5 si, 0.0 st KiB Mem : 3942200 total, 1002344 free, 2444456 used, 495400 buff/cache KiB Swap: 12582908 total, 9683932 free, 2898976 used. 1113416 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14070 systemd+ 20 0 133332 3024 2560 S 0.000 0.077 0:00.03 systemd-timesyn
Well, no, it seems systemd-timesyncd uses much more memory.
I'm going back to chrony.
If size is the only argument, ntpd is the smallest
USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND ntp 1533 1 20 0 9962 14:48:24 - 0:00:05 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf ntp 1538 1533 20 0 9962 14:48:24 - 0:00:00 ntpd: asynchronous dns resolver
USER PID PPID PRI NI SIZE STIME TTY TIME COMMAND chrony 346 1 20 0 22305 13:43:27 - 0:00:00 /usr/sbin/chronyd
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1534 ntp 20 0 39848 4080 3300 S 0.000 0.025 0:00.00 ntpd 1535 ntp 20 0 39848 776 0 S 0.000 0.005 0:00.00 ntpd
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 346 chrony 20 0 89220 2484 2300 S 0.000 0.015 0:00.01 chronyd
Chrony uses half the resident size than ntpd (top output).
But more than twice virtual memory
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-?
The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack). -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On 21/11/2018 14.21, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 14:07:13 +0100, "Carlos E. R." <> wrote:
Chrony uses half the resident size than ntpd (top output).
But more than twice virtual memory
Yes, but as Stefan Seyfried says, that is not relevant, it is not occupy ram chips.
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-?
The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack).
Ah, it counts virtual size too. Then it is not useful for this comparison. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 2018-11-21 14:32, Carlos E. R. wrote:
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-? The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack). Ah, it counts virtual size too. Then it is not useful for this comparison.
I have to check some home made things from time to time. Top and ps is fine but when I need to dig deeper i turn to procfs. /proc/[PID]/stat /proc/[PID]/statm /proc/[PID]/status Status is probably the most readable for humans :) egrep -i -e ^rss -e ^vm /proc/[PID]/status And then check "man procfs" and section "/proc/[pid]/status" Cheers, -- /bengan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
On 21/11/2018 14.21, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 14:07:13 +0100, "Carlos E. R." <> wrote:
Chrony uses half the resident size than ntpd (top output). But more than twice virtual memory Yes, but as Stefan Seyfried says, that is not relevant, it is not occupy ram chips.
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-? The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack). Ah, it counts virtual size too. Then it is not useful for this comparison.
Carlos, Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics" :-) Cheers, -- The best thing about a boolean is even if you are wrong, you are only off by a bit. -- Anonymous -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/11/2018 02:24, Marco Calistri wrote:
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
On 21/11/2018 14.21, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 14:07:13 +0100, "Carlos E. R." <> wrote:
Chrony uses half the resident size than ntpd (top output). But more than twice virtual memory Yes, but as Stefan Seyfried says, that is not relevant, it is not occupy ram chips.
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-? The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack). Ah, it counts virtual size too. Then it is not useful for this comparison.
Carlos,
Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics" :-)
Cheers,
I will be that somebody, guys this is the third or forth thread in a row where the same group of people have caused a thread of 10+ emails within a day that are not related to the development of openSUSE please stop. Consider this your last warning before I escalate it to the board. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/11/2018 23.19, Simon Lees wrote:
On 22/11/2018 02:24, Marco Calistri wrote:
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
On 21/11/2018 14.21, H.Merijn Brand wrote:
On Wed, 21 Nov 2018 14:07:13 +0100, "Carlos E. R." <> wrote:
Chrony uses half the resident size than ntpd (top output). But more than twice virtual memory Yes, but as Stefan Seyfried says, that is not relevant, it is not occupy ram chips.
The other output is from "ps", I guess; I don't know there what "SIZE" means, what exact concept. :-? The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack). Ah, it counts virtual size too. Then it is not useful for this comparison.
Carlos,
Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics" :-)
Cheers,
I will be that somebody, guys this is the third or forth thread in a row where the same group of people have caused a thread of 10+ emails within a day that are not related to the development of openSUSE please stop. Consider this your last warning before I escalate it to the board.
I nice and polite reminder is enough. Please do not menace. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Mittwoch, 21. November 2018 23:24:05 CET Carlos E. R. wrote:
On 21/11/2018 23.19, Simon Lees wrote:
On 22/11/2018 02:24, Marco Calistri wrote:
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
Carlos,
Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics"
:-)
Cheers,
I will be that somebody, guys this is the third or forth thread in a row where the same group of people have caused a thread of 10+ emails within a day that are not related to the development of openSUSE please stop. Consider this your last warning before I escalate it to the board.
I nice and polite reminder is enough. Please do not menace.
If reminding twice a week apparently does not cut it, and some of the posters even show an attitude of - "I know I am off-topic, but I don't care", I would understand some lack of politeness, which I can *not* see here. Simon politely asked to stop, and gave a warning what will happen *iff* the misbehaviour continues. Whoever shows a lack of respect for others will have to live with the consequences. Regards, Stefan-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/11/2018 00.06, Brüns, Stefan wrote:
On Mittwoch, 21. November 2018 23:24:05 CET Carlos E. R. wrote:
On 21/11/2018 23.19, Simon Lees wrote:
On 22/11/2018 02:24, Marco Calistri wrote:
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
Carlos,
Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics"
:-)
Cheers,
I will be that somebody, guys this is the third or forth thread in a row where the same group of people have caused a thread of 10+ emails within a day that are not related to the development of openSUSE please stop. Consider this your last warning before I escalate it to the board.
I nice and polite reminder is enough. Please do not menace.
If reminding twice a week apparently does not cut it, and some of the posters even show an attitude of - "I know I am off-topic, but I don't care", I would understand some lack of politeness, which I can *not* see here.
Simon politely asked to stop, and gave a warning what will happen *iff* the misbehaviour continues. Whoever shows a lack of respect for others will have to live with the consequences.
Marco asked politely. I stopped this thread when I saw his post. Simon's was redundant and aggressive. I'm not aware of other threads. As I do not detect what you consider offtopic or excessive chat here, I ask a *kind* request on every such thread. Usually Patrick does that. - -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCW/akZQAKCRC1MxgcbY1H 1ZsdAJ0ZQ/IWmsABFG5VVm6ZqwDUN3YqCwCfZV8R0z66THnaY930Pcn7C+F/vAg= =+KMp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [11-22-18 07:43]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22/11/2018 00.06, Brüns, Stefan wrote:
On Mittwoch, 21. November 2018 23:24:05 CET Carlos E. R. wrote:
On 21/11/2018 23.19, Simon Lees wrote:
On 22/11/2018 02:24, Marco Calistri wrote:
Il 21/11/2018 11:32, Carlos E. R. ha scritto:
Carlos,
Be warned that "somebody" could complain about the fact that you are taking the space of the factory list for "not pretty development topics"
:-)
Cheers,
I will be that somebody, guys this is the third or forth thread in a row where the same group of people have caused a thread of 10+ emails within a day that are not related to the development of openSUSE please stop. Consider this your last warning before I escalate it to the board.
I nice and polite reminder is enough. Please do not menace.
If reminding twice a week apparently does not cut it, and some of the posters even show an attitude of - "I know I am off-topic, but I don't care", I would understand some lack of politeness, which I can *not* see here.
Simon politely asked to stop, and gave a warning what will happen *iff* the misbehaviour continues. Whoever shows a lack of respect for others will have to live with the consequences.
Marco asked politely. I stopped this thread when I saw his post. Simon's was redundant and aggressive.
I'm not aware of other threads. As I do not detect what you consider offtopic or excessive chat here, I ask a *kind* request on every such thread. Usually Patrick does that.
yet the "Thread" continues and is still off-topic here. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Patrick, On Thu, 22 Nov 2018, 14:46:55 +0100, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [11-22-18 07:43]:
[...] Marco asked politely. I stopped this thread when I saw his post. Simon's was redundant and aggressive.
I'm not aware of other threads. As I do not detect what you consider offtopic or excessive chat here, I ask a *kind* request on every such thread. Usually Patrick does that.
yet the "Thread" continues and is still off-topic here.
if *you* want to complain about people following up on this thread here, why don't you re-direct them using the usual ways to other media? One way would be to *not* post to the same list... To be honest, *iff* you/other board members believe, we need a pure, development only list, then *create one*! _factory_ doesn't imply to me (and I'm not a new member by any stretch!), this is only dealing with really new stuff, i.e. development. Factory to me means, this is the facility to deal with any issues with my installation (which is my factory). Sorry, but appr. 50% of this thread is mostly dealing with complaints about messages which don't belong here. If the board believes decisions about "ntpd is too old" vs. "chrony is new enough" (because bug reports still come in), then OK, please blame me and potentially black-list me, but I'm really over it now (TM). Cheers. l8er manfred
On Thu, 2018-11-22 at 15:15 +0100, Manfred Hollstein wrote:
Hi Patrick,
On Thu, 22 Nov 2018, 14:46:55 +0100, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [11-22-18 07:43]:
[...] Marco asked politely. I stopped this thread when I saw his post. Simon's was redundant and aggressive.
I'm not aware of other threads. As I do not detect what you consider offtopic or excessive chat here, I ask a *kind* request on every such thread. Usually Patrick does that.
yet the "Thread" continues and is still off-topic here.
if *you* want to complain about people following up on this thread here, why don't you re-direct them using the usual ways to other media? One way would be to *not* post to the same list...
To be honest, *iff* you/other board members believe, we need a pure, development only list, then *create one*!
We have, its this one, most people seem to understand that fine you just need to update the mapping in your head so that factory == development, since the dawn of time openSUSE development has happened in the factory project / repository. Yes some people don't get the name at first so we remind them, but in our opinion its not worth the effort to rename / move this list when most people get it anyway. What openSUSE mailing lists are used for is decided collectively by the openSUSE project not by what someone thinks they should be.
Sorry, but appr. 50% of this thread is mostly dealing with complaints about messages which don't belong here. If the board believes decisions about "ntpd is too old" vs. "chrony is new enough" (because bug reports still come in), then OK, please blame me and potentially black-list me, but I'm really over it now (TM).
Well this thread started with what probably should have been a bug report, but unless someone is consistently posting here rather then making bug reports we will generally let it slide. The rest of the thread might have made sense if we were having a discussion on why we should change the system default rather then what makes sense atm in someones personal case. For reference we are currently following what SLE is / will be using as it means we get enterprise support for free along with additional testing / QA, if someone put together a really compelling argument about why we should not be following SLE for the system default then lets have that discussion. If you just want to discuss the merits of each for your use case then we have the opensuse@ and opensuse-offtopic@ mailing lists, if you need help configuring one of the services we also have opensuse-support@ -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.11.18 um 13:33 schrieb Carlos E. R.:
Well, no, it seems systemd-timesyncd uses much more memory.
You are looking at the wrong field. Nobody realy cares how much virtual memory a process has mapped / reserved, but instead how big its resident set size is. Example how to "use" 4G of memory: seife@strolchi:/dev/shm> cat test.c #include <sys/mman.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define handle_error(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0) int main(int argc, char *argv[]) { char *addr; size_t length = 1024L*1024*1024*4; /* 4GB */ int fd = open(argv[1], O_RDONLY); if (fd == -1) handle_error("open"); addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, 0); if (addr == MAP_FAILED) handle_error("mmap"); while (1) sleep(1); /* not reached */ munmap(addr, length); close(fd); return 0; } seife@strolchi:/dev/shm> gcc test.c -o test seife@strolchi:/dev/shm> truncate -s 10G test.file seife@strolchi:/dev/shm> ./test test.file & [1] 1905 seife@strolchi:/dev/shm> ps u 1905 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND seife 1905 0.0 0.0 4198484 672 pts/10 S 13:52 0:00 ./test test.file recompile with different "length=" and you can "use" even more. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/11/2018 13.55, Stefan Seyfried wrote:
Am 21.11.18 um 13:33 schrieb Carlos E. R.:
Well, no, it seems systemd-timesyncd uses much more memory.
You are looking at the wrong field.
Nobody realy cares how much virtual memory a process has mapped / reserved, but instead how big its resident set size is.
I looked at the resident size :-) 76 chronyd 3024 systemd-timesyn
Example how to "use" 4G of memory:
seife@strolchi:/dev/shm> cat test.c #include <sys/mman.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h>
#define handle_error(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0) int main(int argc, char *argv[]) { char *addr; size_t length = 1024L*1024*1024*4; /* 4GB */ int fd = open(argv[1], O_RDONLY); if (fd == -1) handle_error("open"); addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, 0); if (addr == MAP_FAILED) handle_error("mmap");
while (1) sleep(1);
/* not reached */ munmap(addr, length); close(fd); return 0; } seife@strolchi:/dev/shm> gcc test.c -o test seife@strolchi:/dev/shm> truncate -s 10G test.file seife@strolchi:/dev/shm> ./test test.file & [1] 1905 seife@strolchi:/dev/shm> ps u 1905 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND seife 1905 0.0 0.0 4198484 672 pts/10 S 13:52 0:00 ./test test.file
recompile with different "length=" and you can "use" even more.
Thanks for the example :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Am 21.11.18 um 14:00 schrieb Carlos E. R.:
On 21/11/2018 13.55, Stefan Seyfried wrote:
Am 21.11.18 um 13:33 schrieb Carlos E. R.:
Well, no, it seems systemd-timesyncd uses much more memory.
You are looking at the wrong field.
Nobody realy cares how much virtual memory a process has mapped / reserved, but instead how big its resident set size is.
I looked at the resident size :-)
Ok, I was confused by the "top" line.
76 chronyd 3024 systemd-timesyn
But something is fishy there. If even my pretty minimal example program uses 772kB (with 708kB shared) according to top,then I cannot imagine how chrony will work with just 76kb. You are also using different tools on both machines (see the different output columns), so the results might not be comparable. It would of course be highly embarassing if a stupid sntp client like systemd-timesyncd really uses more memory than a full fledged ntp server implementation like chronyd. Judging from other systemd experiences, I would not be surprised, though. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/11/2018 14.10, Stefan Seyfried wrote:
Am 21.11.18 um 14:00 schrieb Carlos E. R.:
On 21/11/2018 13.55, Stefan Seyfried wrote:
Am 21.11.18 um 13:33 schrieb Carlos E. R.:
Well, no, it seems systemd-timesyncd uses much more memory.
You are looking at the wrong field.
Nobody realy cares how much virtual memory a process has mapped / reserved, but instead how big its resident set size is.
I looked at the resident size :-)
Ok, I was confused by the "top" line.
76 chronyd 3024 systemd-timesyn
But something is fishy there. If even my pretty minimal example program uses 772kB (with 708kB shared) according to top,then I cannot imagine how chrony will work with just 76kb.
I don't know. But I guess it is waiting for an event to happen, then load the rest of the code. The "S" means it sleeping IIRC, so it matches. Ie, the clock is OK, and it is waiting some timer till checking the clock on internet again. Maybe after some hours running the systemd implementation does the same, dunno.
You are also using different tools on both machines (see the different output columns), so the results might not be comparable.
No, the testing was done on the same laptop, minutes of difference (you can see the uptime on the first line), and both times I used "top -b n1 | less". Once as user and the other as root by mistake, though. Why do you think it was different machines? :-?
It would of course be highly embarassing if a stupid sntp client like systemd-timesyncd really uses more memory than a full fledged ntp server implementation like chronyd. Judging from other systemd experiences, I would not be surprised, though.
:-} -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 21/11/2018 14:10, Stefan Seyfried wrote:
It would of course be highly embarassing if a stupid sntp client like systemd-timesyncd really uses more memory than a full fledged ntp server implementation like chronyd. Judging from other systemd experiences, I would not be surprised, though.
I'm glad you added that last sentence. It would not surprise me in the least. And I don't think that the systemd team would be in the least bit embarrassed by it, either... -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/11/2018 14:09, Cristian Rodríguez wrote:
Let's say the traditional ntp daemon has not aged very well.. and is steadly bitrotting.
I believe it's a bit contentious, but is NTPsec relevant to this? -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 18/11/18 16:56, Carlos E. R. ha scritto:
On 18/11/2018 14.51, Marco Calistri wrote:
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
To verify if my system is synchronized I use the command "timedatectl":
marco@linux-turion64:~> timedatectl Local time: dom 2018-11-18 11:40:48 -02 Universal time: dom 2018-11-18 13:40:48 UTC RTC time: dom 2018-11-18 11:40:48 Time zone: America/Sao_Paulo (-02, -0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: yes
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient.
It also, now that I think, does not display the network time at all, in my case from ntp, so I do not know how well my clock is synced - or not.
Hello Carlos, My Linux box is not a 24/24 server then I decided to switch to chronyd: https://www.thegeekdiary.com/centos-rhel-7-chrony-vs-ntp-differences-between... Cheers, -- Marco Calistri Build: openSUSE Tumbleweed 20181116 Kernel: 4.19.1-1-default - Cinnamon 3.8.9
* Marco Calistri <mcalistri@hotmail.com> [11-18-18 16:24]:
Il 18/11/18 16:56, Carlos E. R. ha scritto:
On 18/11/2018 14.51, Marco Calistri wrote:
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
To verify if my system is synchronized I use the command "timedatectl":
marco@linux-turion64:~> timedatectl Local time: dom 2018-11-18 11:40:48 -02 Universal time: dom 2018-11-18 13:40:48 UTC RTC time: dom 2018-11-18 11:40:48 Time zone: America/Sao_Paulo (-02, -0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: yes
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient.
It also, now that I think, does not display the network time at all, in my case from ntp, so I do not know how well my clock is synced - or not.
Hello Carlos,
My Linux box is not a 24/24 server then I decided to switch to chronyd: https://www.thegeekdiary.com/centos-rhel-7-chrony-vs-ntp-differences-between...
being a server is not a requirement for ntpd vs chronyd, it is a choice. one may choose either for any connected box providing any service. 18:07 toshiba: ~ # systemctl status chronyd;timedatectl;ntptime ● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: disabled) Active: inactive (dead) since Sun 2018-11-18 15:04:42 EST; 3h 3min ago Docs: man:chronyd(8) man:chrony.conf(5) Main PID: 2192 (code=exited, status=0/SUCCESS) Nov 18 11:31:34 toshiba.wahoo.no-ip.org systemd[1]: Starting NTP client/server... Nov 18 11:31:35 toshiba.wahoo.no-ip.org chronyd[2192]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVD> Nov 18 11:31:35 toshiba.wahoo.no-ip.org chronyd[2192]: Frequency -15.548 +/- 0.076 ppm read from /var/lib/chrony/drift Nov 18 11:31:35 toshiba.wahoo.no-ip.org systemd[1]: Started NTP client/server. Nov 18 11:31:40 toshiba.wahoo.no-ip.org chronyd[2192]: Selected source 199.102.46.73 Nov 18 15:04:42 toshiba.wahoo.no-ip.org chronyd[2192]: chronyd exiting Nov 18 15:04:42 toshiba.wahoo.no-ip.org systemd[1]: Stopping NTP client/server... Nov 18 15:04:42 toshiba.wahoo.no-ip.org systemd[1]: Stopped NTP client/server. Local time: Sun 2018-11-18 18:08:30 EST Universal time: Sun 2018-11-18 23:08:30 UTC RTC time: Sun 2018-11-18 18:08:30 Time zone: America/Indiana/Indianapolis (EST, -0500) System clock synchronized: no NTP service: active RTC in local TZ: yes Warning: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'. ntp_gettime() returns code 5 (ERROR) time df9c6f6e.4eed1394 Sun, Nov 18 2018 18:08:30.308, (.308305198), maximum error 1412500 us, estimated error 0 us, TAI offset 0 ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 12.379 us, frequency 18.604 ppm, interval 1 s, maximum error 1412500 us, estimated error 0 us, status 0x6041 (PLL,UNSYNC,NANO,MODE), time constant 7, precision 0.001 us, tolerance 500 ppm, 18:10 wahoo: ~ # systemctl status ntpd;timedatectl;ntptime ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/ntpd.service.d └─50-insserv.conf-$time.conf Active: active (running) since Sun 2018-11-18 18:05:22 EST; 5min ago Docs: man:ntpd(1) Process: 20973 ExecStart=/usr/sbin/start-ntpd start (code=exited, status=0/SUCCESS) Main PID: 20984 (ntpd) Tasks: 2 (limit: 512) CGroup: /system.slice/ntpd.service ├─20984 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf └─20985 ntpd: asynchronous dns resolver Nov 18 18:05:22 wahoo systemd[1]: Starting NTP Server Daemon... Nov 18 18:05:22 wahoo ntpd[20983]: ntpd 4.2.8p10@1.3728-o Fri May 26 14:07:29 UTC 2017 (1): Starting Nov 18 18:05:22 wahoo ntpd[20983]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf Nov 18 18:05:22 wahoo ntpd[20984]: proto: precision = 0.084 usec (-23) Nov 18 18:05:22 wahoo ntpd[20984]: switching logging to file /var/log/ntp Nov 18 18:05:22 wahoo start-ntpd[20973]: Starting network time protocol daemon (NTPD) Nov 18 18:05:22 wahoo systemd[1]: Started NTP Server Daemon. Hint: Some lines were ellipsized, use -l to show in full. Local time: Sun 2018-11-18 18:11:15 EST Universal time: Sun 2018-11-18 23:11:15 UTC RTC time: Sun 2018-11-18 23:11:15 Time zone: America/Indiana/Indianapolis (EST, -0500) Network time on: yes NTP synchronized: yes RTC in local TZ: no ntp_gettime() returns code 0 (OK) time df9c7013.f22003ac Sun, Nov 18 2018 18:11:15.945, (.945801052), maximum error 169215 us, estimated error 1875 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -836.944 us, frequency -8.556 ppm, interval 1 s, maximum error 169215 us, estimated error 1875 us, status 0x2001 (PLL,NANO), time constant 6, precision 0.001 us, tolerance 500 ppm, in this particular case the server happens to be running ntpd but could just as well be running chronyd. the time precision reported is the same. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 18/11/18 21:14, Patrick Shanahan ha scritto:
* Marco Calistri <mcalistri@hotmail.com> [11-18-18 16:24]:
Il 18/11/18 16:56, Carlos E. R. ha scritto:
On 18/11/2018 14.51, Marco Calistri wrote:
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
To verify if my system is synchronized I use the command "timedatectl":
marco@linux-turion64:~> timedatectl Local time: dom 2018-11-18 11:40:48 -02 Universal time: dom 2018-11-18 13:40:48 UTC RTC time: dom 2018-11-18 11:40:48 Time zone: America/Sao_Paulo (-02, -0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: yes
Interesting command! I did not know about it. But it would be rather more interesting if it displayed milliseconds, as it does it is not sufficient.
It also, now that I think, does not display the network time at all, in my case from ntp, so I do not know how well my clock is synced - or not.
Hello Carlos,
My Linux box is not a 24/24 server then I decided to switch to chronyd: https://www.thegeekdiary.com/centos-rhel-7-chrony-vs-ntp-differences-between...
being a server is not a requirement for ntpd vs chronyd, it is a choice. one may choose either for any connected box providing any service.
I was referring specifically to the fact that my Linux computer is not connected to Internet all day long: https://chrony.tuxfamily.org/faq.html#_how_does_code_chrony_code_compare_to_...
Nov 18 18:05:22 wahoo systemd[1]: Starting NTP Server Daemon... Nov 18 18:05:22 wahoo ntpd[20983]: ntpd 4.2.8p10@1.3728-o Fri May 26 14:07:29 UTC 2017 (1): Starting Nov 18 18:05:22 wahoo ntpd[20983]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf Nov 18 18:05:22 wahoo ntpd[20984]: proto: precision = 0.084 usec (-23) Nov 18 18:05:22 wahoo ntpd[20984]: switching logging to file /var/log/ntp Nov 18 18:05:22 wahoo start-ntpd[20973]: Starting network time protocol daemon (NTPD) Nov 18 18:05:22 wahoo systemd[1]: Started NTP Server Daemon. Hint: Some lines were ellipsized, use -l to show in full. Local time: Sun 2018-11-18 18:11:15 EST Universal time: Sun 2018-11-18 23:11:15 UTC RTC time: Sun 2018-11-18 23:11:15 Time zone: America/Indiana/Indianapolis (EST, -0500) Network time on: yes NTP synchronized: yes RTC in local TZ: no ntp_gettime() returns code 0 (OK) time df9c7013.f22003ac Sun, Nov 18 2018 18:11:15.945, (.945801052), maximum error 169215 us, estimated error 1875 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -836.944 us, frequency -8.556 ppm, interval 1 s, maximum error 169215 us, estimated error 1875 us, status 0x2001 (PLL,NANO), time constant 6, precision 0.001 us, tolerance 500 ppm,
in this particular case the server happens to be running ntpd but could just as well be running chronyd. the time precision reported is the same.
I personally dislike using two daemons doing practically the same job, if I can just use one. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20181116 Kernel: 4.19.1-1-default - Cinnamon 3.8.9
On 19/11/2018 01.33, Marco Calistri wrote:
Il 18/11/18 21:14, Patrick Shanahan ha scritto:
in this particular case the server happens to be running ntpd but could just as well be running chronyd. the time precision reported is the same.
I personally dislike using two daemons doing practically the same job, if I can just use one.
I understand it is two computers: Nov 18 11:31:34 toshiba.wahoo.no-ip.org systemd[1]: Starting NTP client/server... Nov 18 11:31:35 toshiba.wahoo.no-ip.org chronyd[2192]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVD> vs Nov 18 18:05:22 wahoo systemd[1]: Starting NTP Server Daemon... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 19/11/2018 00:21, Marco Calistri wrote:
Il 13/11/18 18:24, Achim Gratz ha scritto:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved. But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all the stuff that the current start script is doing should go into ExecStartPre?
Regards, Achim.
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
It shouldn't be necessary into the future, there have been a couple of issues making that happen but hopefully it will be done soon if not now. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 19/11/18 01:18, Simon Lees ha scritto:
On 19/11/2018 00:21, Marco Calistri wrote:
Il 13/11/18 18:24, Achim Gratz ha scritto:
The handling of ntpd apparently switched from an old-style rc script to a systemd unit. Since then the stop script will take somewhere between ten seconds to a minute to declare success and continue with the shutdown. I don't see why it should take that long to shut down since ntpd really just closes the ntp logs and exits. The systemd unit file treats it as a forking daemon, which probably makes the check of whether the daemon has exited more involved. But ntpd can easily be told not to fork, so I think it should use the "-n" option in ExecStart and all the stuff that the current start script is doing should go into ExecStartPre?
Regards, Achim.
I was relying on ntpd service since ever until I read about "chronyd" as the substitute of ntpd adopted by new opensuse releases, then I switched to chronyd.
Despite this it seems ntp package being still necessary (?) or could be removed by the system?
It shouldn't be necessary into the future, there have been a couple of issues making that happen but hopefully it will be done soon if not now.
I had removed (zypper rm) ntpd some weeks ago but it went installed again at first zypper dup. Also would like to report a known *bug* or perhaps a not expected behaviour of chronyd about wrong permission warning on /var/run/chrony: sudo systemctl status chronyd ● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor pre> Active: active (running) since Mon 2018-11-19 09:03:20 -02; 4min 32s ago Docs: man:chronyd(8) man:chrony.conf(5) Process: 1405 ExecStartPost=/usr/share/chrony-helper update-daemon (code=exit> Process: 1067 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUC> Main PID: 1103 (chronyd) Tasks: 1 (limit: 4592) Memory: 1.2M CGroup: /system.slice/chronyd.service └─1103 /usr/sbin/chronyd nov 19 09:03:12 linux-turion64 systemd[1]: Starting NTP client/server... nov 19 09:03:13 linux-turion64 chronyd[1103]: chronyd version 3.4 starting (+CM> nov 19 09:03:13 linux-turion64 chronyd[1103]: Wrong permissions on /var/run/chr> nov 19 09:03:13 linux-turion64 chronyd[1103]: Disabled command socket /var/run/> nov 19 09:03:13 linux-turion64 chronyd[1103]: Frequency -12.652 +/- 26.222 ppm > nov 19 09:03:20 linux-turion64 systemd[1]: Started NTP client/server. It has been reported also for other distros, I mean it is not a specific opensuse's chrony error. In addition I also would like to ask about the second warning: "Disabled command socket /var/run/" is it an error we can correct in some way or it is just an informative message? Thanks and regards, -- Marco Calistri Build: openSUSE Tumbleweed 20181116 Kernel: 4.19.1-1-default - Cinnamon 3.8.9
participants (24)
-
Achim Gratz -
Andreas Schwab -
Andrei Borzenkov -
Bengt Gördén -
Brüns, Stefan -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Felix Miata -
Freek de Kruijf -
H.Merijn Brand -
Jan Engelhardt -
Joachim Wagner -
Liam Proven -
Manfred Hollstein -
Marco Calistri -
Marco Calistri -
Martin Wilck -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Simon Lees -
Stefan Brüns
-
Stefan Seyfried