Re: [systemd-devel] Q: A way to log peak memory footprint of deactivating units?
Hello. On Sat, Aug 13, 2022 at 04:39:50AM -0500, Russell Haley wrote: > Since systemd logs the total CPU time used when the unit deactivates, I > wonder if there's a way to make it log the peak memory footprint too, > kind of like the time command's "maxresident". The unit does have > MemoryAccounting=yes. > > It turned out that it was simple to write a shell script loop to wait > until packagekit was activated and sample the memory usage before the > timeout expired. (About 228 MiB.) However, I am still interested to > know if there might be a better/more general method. > > P.S. Since I had to re-send this mail with the correct From: address, I > looked into it and apparently kernel 5.19 added a memory.peak to cgroups > v2, so I think it very recently become possible to have an elegant > implementation of this. You need the kernel with memory.peak (sampling is unrealiable) and then quick n' dirty > MemoryAccounting=yes > ExecStopPost=/usr/bin/cat /sys/fs/cgroup/system.slice/%n/memory.peak Output goes to journald by default: > Aug 19 00:13:29 machine cat[7433]: 2924544 If you wanted to have this reported by default, PRs for memory.peak support are welcomed :-) Michal
[systemd-devel] KillMode=none replacement suggestions
Hi, I'm coming here from linux-raid community. Coly proposed to remove "Killmode=none" from our mdmon@.service[1]. Community accepted the change because it is reasonable, the option will removed in the future. Now when the change is incorporated with distributions we are observing hang tasks during shutdown when the raid resource is mounted and systemd tries to umount it on umount.target. Please take a look into this thread for details[2]. With "KillMode=none" process preserves systemd service stop, thus allows us to proceed with shutdown. Removing it (and setting default) causes that process is killed to early. I tried to fix that on multiple ways but I failed, see[3]. Ideally, we would like to have same behavior as with "Killmode=none" but solution where service will be stopped after umount.target should be also acceptable. Do you have any suggestions? TIA, Mariusz [1]https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=52c67fcdd6dadc4138ecad73e65599551804d445 [2]https://lore.kernel.org/linux-raid/20220728110140.3...@linux.intel.com/ [3]https://lore.kernel.org/linux-raid/20220802174305.0...@linux.intel.com/
[systemd-devel] Antw: Re: [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
>>> Mantas Mikulenas schrieb am 18.08.2022 um 10:20 in Nachricht : > On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> >>> Mantas Mikulenas schrieb am 17.08.2022 um 15:17 in >> Nachricht >> : >> > On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms >> wrote: >> > >> >> Hi, >> >> >> >> I'm developing an application for an embedded system that needs to >> >> wait for proper NTP synchronization. systemd-timesyncd is running and >> >> I can read NTPSynchronized from /org/freedesktop/timedate1 using >> >> D-Bus. I read in the manual that this property is not signaled, and >> >> that I need to do some weird magic with timerfd's >> >> TFD_TIMER_CANCEL_ON_SET flag. >> >> >> >> It works, but having the ECANCELLED on the read() means that something >> >> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially >> >> that I got a proper NTP synchronization. Then, I still need to query >> >> NTPSynchronized after, and retry the timerfd thing if it didn't switch >> >> to "true", which is still some kind of polling (but very unlikely, >> >> sure). >> >> >> >> As a result, I'm a bit curious, what was the rationale of not simply >> >> signaling NTPSynchronized? >> >> >> > >> > timedated itself doesn't have knowledge of that event, because it isn't >> the >> > daemon that performs actual synchronization (that's timesyncd), so all >> that >> > the D-Bus property does is report you the status of adjtimex() – >> > specifically it returns whether ".maxerror < 1600". Timedated would >> > still need to poll and/or do timerfd tricks in order to see that state >> > being reached. (Currently timedated is not a continuously running daemon >> – >> > it starts up only whenever properties are queried and exits when idle.) >> > >> > A better question is why the timesyncd daemon does not have such a D-Bus >> > signal; looks like it *almost* does >> > (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only >> > emits the raw messages and not whether they resulted in a successful >> sync. >> >> Maybe because a "successful sync" is actually not sharply defined. >> There can be very interesing scenarios (like requiring three "surviving >> clocks", but only two were found) >> > > It's an SNTP client, it only deals with one timeserver at a time. And it > already has a specific definition of "synced" in the code because it sets a > flag file on the filesystem when that happens, just doesn't do the same via > D-Bus. So strictly speaking the event is not "time synced", but "time set". The difference will be obvious after a week or so ;-) Regards, Ulrich > > -- > Mantas Mikulėnas
Re: [systemd-devel] [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
On Thu, Aug 18, 2022 at 10:47 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Mantas Mikulenas schrieb am 17.08.2022 um 15:17 in > Nachricht > : > > On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms > wrote: > > > >> Hi, > >> > >> I'm developing an application for an embedded system that needs to > >> wait for proper NTP synchronization. systemd-timesyncd is running and > >> I can read NTPSynchronized from /org/freedesktop/timedate1 using > >> D-Bus. I read in the manual that this property is not signaled, and > >> that I need to do some weird magic with timerfd's > >> TFD_TIMER_CANCEL_ON_SET flag. > >> > >> It works, but having the ECANCELLED on the read() means that something > >> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially > >> that I got a proper NTP synchronization. Then, I still need to query > >> NTPSynchronized after, and retry the timerfd thing if it didn't switch > >> to "true", which is still some kind of polling (but very unlikely, > >> sure). > >> > >> As a result, I'm a bit curious, what was the rationale of not simply > >> signaling NTPSynchronized? > >> > > > > timedated itself doesn't have knowledge of that event, because it isn't > the > > daemon that performs actual synchronization (that's timesyncd), so all > that > > the D-Bus property does is report you the status of adjtimex() – > > specifically it returns whether ".maxerror < 1600". Timedated would > > still need to poll and/or do timerfd tricks in order to see that state > > being reached. (Currently timedated is not a continuously running daemon > – > > it starts up only whenever properties are queried and exits when idle.) > > > > A better question is why the timesyncd daemon does not have such a D-Bus > > signal; looks like it *almost* does > > (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only > > emits the raw messages and not whether they resulted in a successful > sync. > > Maybe because a "successful sync" is actually not sharply defined. > There can be very interesing scenarios (like requiring three "surviving > clocks", but only two were found) > It's an SNTP client, it only deals with one timeserver at a time. And it already has a specific definition of "synced" in the code because it sets a flag file on the filesystem when that happens, just doesn't do the same via D-Bus. -- Mantas Mikulėnas
[systemd-devel] Antw: [EXT] Re: org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
>>> Mantas Mikulenas schrieb am 17.08.2022 um 15:17 in Nachricht : > On Wed, Aug 17, 2022 at 1:59 PM Etienne Doms wrote: > >> Hi, >> >> I'm developing an application for an embedded system that needs to >> wait for proper NTP synchronization. systemd-timesyncd is running and >> I can read NTPSynchronized from /org/freedesktop/timedate1 using >> D-Bus. I read in the manual that this property is not signaled, and >> that I need to do some weird magic with timerfd's >> TFD_TIMER_CANCEL_ON_SET flag. >> >> It works, but having the ECANCELLED on the read() means that something >> somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially >> that I got a proper NTP synchronization. Then, I still need to query >> NTPSynchronized after, and retry the timerfd thing if it didn't switch >> to "true", which is still some kind of polling (but very unlikely, >> sure). >> >> As a result, I'm a bit curious, what was the rationale of not simply >> signaling NTPSynchronized? >> > > timedated itself doesn't have knowledge of that event, because it isn't the > daemon that performs actual synchronization (that's timesyncd), so all that > the D-Bus property does is report you the status of adjtimex() – > specifically it returns whether ".maxerror < 1600". Timedated would > still need to poll and/or do timerfd tricks in order to see that state > being reached. (Currently timedated is not a continuously running daemon – > it starts up only whenever properties are queried and exits when idle.) > > A better question is why the timesyncd daemon does not have such a D-Bus > signal; looks like it *almost* does > (org.freedesktop.timesync1.Manager.NTPMessage) but it looks like it only > emits the raw messages and not whether they resulted in a successful sync. Maybe because a "successful sync" is actually not sharply defined. There can be very interesing scenarios (like requiring three "surviving clocks", but only two were found) when the status output of NTP looks as if synchronized, but in fact the time is "running away". Acually "NTP sync" is not a Boolean, but more like an indicator ranging from 0 (unsynced) to 1 (well-synced). (I tried to implement such an indicator in the past, but only very few servers have a score of "1.0") Regards, Ulrich > > For now, if you're using timesyncd you can use inotify to watch > /run/systemd/timesync/synchronized, which is touched after a sync. > > -- > Mantas Mikulėnas
[systemd-devel] Antw: Re: [EXT] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
>>> Etienne Doms schrieb am 17.08.2022 um 14:49 in Nachricht : > Oh, should have added a bit more context, indeed. > > The piece of software is bringing a specific interface up, checking > that something is connected (link going up or not), then issues a DHCP > request onto it to fetch an IP and NTP servers, and then waits for > proper NTP synchronization to keep on. If the remote is not present, > or if it fails to answer us within a given time frame, we give up and > do something else. > > Maybe we can play with dedicated .service/.target using Requires/After > and OnFailure to drive all that mecanic with different oneshot > processes, but using libsystemd internally in a single process sounded > just more KISS for our usage. > > I'm just confused that I cannot have a proper "NTP sync'ed" event, the > documentation explicitly states "we don't signal it, use some timerfd > things" and I'm curious about the rationale of this choice. Hi! I suspect such an event wasn't implemented, because you would typically get at most one per host boot. (For completeness the opposite event should be there, too) What will your software do if NTP sync is lost? Regards, Ulrich > > Le mer. 17 août 2022 à 14:01, Ulrich Windl > a écrit : >> >> >>> Etienne Doms schrieb am 17.08.2022 um 12:58 in >> Nachricht >> : >> > Hi, >> > >> > I'm developing an application for an embedded system that needs to >> > wait for proper NTP synchronization. systemd-timesyncd is running and >> >> What's wrong with time-sync.target? Or maybe even time-set.target? >> >> > I can read NTPSynchronized from /org/freedesktop/timedate1 using >> > D-Bus. I read in the manual that this property is not signaled, and >> > that I need to do some weird magic with timerfd's >> > TFD_TIMER_CANCEL_ON_SET flag. >> > >> > It works, but having the ECANCELLED on the read() means that something >> > somewhere did clock_settime(CLOCK_REALTIME, <...>), not especially >> > that I got a proper NTP synchronization. Then, I still need to query >> > NTPSynchronized after, and retry the timerfd thing if it didn't switch >> > to "true", which is still some kind of polling (but very unlikely, >> > sure). >> > >> > As a result, I'm a bit curious, what was the rationale of not simply >> > signaling NTPSynchronized? >> > >> > Thanks, >> > Etienne >> >> >> >>
