Re: [systemd-devel] Fwd: make pystemd part of systemd repo.
[I misplaced the original mail, so I'm replying to a forward. Apologies if threading is broken.] > What do we propose to do? > - > > We want to bring pystemd[1] into the systemd organization, and merge > (functionality wise) with python-systemd[2], so that there is a single > Python library, supported by the systemd community, that interacts > with the systemd API. In short, you propose to subsume bring pystemd under the systemd org umbrella and to subsume python-systemd functionality into pystemd. I think this makes the most sense. > systemd has a Python library already under the organization: > python-systemd. This library does some interesting stuff with the > journal (my personal favorite is creating a Python logger that talks > directly with the journal, kudos to whoever did that!). Marti Raudsepp, 603876167a7ea78d0a71d70766f65979618ca423. > But in my honest opinion, this library is missing some core > functionality to interact with systemd: the service manager, > start/stop/interaction with Units, create ephemeral units, etc. At > Meta (the company formerly known as Facebook) we created a python > library that does that… among other things. The functionality in python-systemd is fairly cleanly split between the python frontent, and the the C backend which is a thin wrapper around libsystemd. When pystemd functions replace the backend, it should be possible to move the higher-level code without minimal changes. > with Unit(b'postfix.service') as unit: >if unit.Unit.ActiveState == b"active": >unit.Unit.Stop(b'replace') Not that it matters for this discussion, but what with all those b'' prefixes? systemd itself doesn't do non-unicode, so it should all be trivially translatable to and from str. > How do we propose to do this? > - > > Preliminary plan (of course we are open to any suggestions) look like this: > > 1. We move pystemd repo [1] into the systemd org, something like > https://github.com/systemd/pystemd > 2. People with commit access to this repo (Davide, Anita and me) would > remain having commit access to this repo, and whoever has access to > the python-systemd repo [2] would be added here. > 3. We merge all features of python-systemd (that are not in pystemd > yet) into pystemd, this will probably mean re-writing most of those > features. Development would be done by mostly me, with code review and > from hopefully as close to the original authors as possible… Basically > I don't want to be disrespectful of python-systemd. This sounds all good. > 4. If we want to keep the name python-systemd (and the import > namespace of systemd) we can rename the repo as python-systemd, if we > want to keep pystemd as the name of the package and the import > namespace, we can make python-systemd as “a link” to pystemd > 5. Whatever we decide on the last point, we cut the version 1.0.0 of > pystemd, or the next version of python-systemd. And we let the new era > of Python bindings start! I'd keep the names as they are. Renames create confusion, and I think everything will be easier if we keep the original names and keep things parallel-installable. Thank you for doing this. Zbyszek
Re: [systemd-devel] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
Ok, that makes a lot of sense, I was confusing timedated and timesyncd, and indeed the latter is what would be able to broadcast the event, even if it does not yet. I wasn't aware of /run/systemd/timesync/synchronized, looks fine to me, will investigate that. Thanks! Le mer. 17 août 2022 à 15:17, Mantas Mikulėnas a écrit : > > 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. > > 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
Re: [systemd-devel] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
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. 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
Re: [systemd-devel] [EXT] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
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. 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 > > > >
[systemd-devel] Antw: [EXT] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
>>> 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
[systemd-devel] org.freedesktop.timedate1.NTPSynchronized not signaled: rationale?
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? Thanks, Etienne
Re: [systemd-devel] Detecting when running under systemd
you want to check specifically whether stderr is tied to the journal, for which you can use JOURNAL_STREAM You are right, nice catch! (In addition to disabling the timestamps you should *at least* add message priority indicators as well, either by using SyslogLevelPrefix=, or by avoiding stderr entirely and using the syslog() API for logging – if not going all the way with sd_journal_send*().) It's an application written in crystal, so while it would be straight forward to either use the syslog API or write bindings for sd_journal_send, my logging requirements are basic (to put it mildly) and simply dumping to stderr works well enough when paired with the priority parsing provided by SyslogLevelPrefix. Thank you!
Re: [systemd-devel] Detecting when running under systemd
On Wed, Aug 17, 2022 at 5:05 AM Peter Hoeg wrote: > > Hi all, > > I have a small program that queries an external web API, massages the data > and passes it off to something else. As I only need it to run during > certain windows and I didn't want to have to bother with making sure it was > alive, I am starting it using a systemd timer which is sufficiently > flexible. All good and it's super nice to be able to "outsource" all that > to systemd. > > My question is - what is the canonical way to detect that I'm running > under systemd so that I can adjust accordingly? Currently I'm checking for > the existence of the "_SYSTEMD_INVOCATION_ID" environment variable in order > to change the logging function as the default logger includes a timestamp > which is redundant when journald is picking it up. > > I'm also using LoadCredential for passing tokens but that just comes down > to looking for the right file name where the CREDENTIALS_DIRECTORY variable > points, so that really isn't systemd specific and there is a fallback in > case that isn't set or the directory/file doesn't exist anyway. > > I could of course also add a --systemd flag that toggles this but if I can > do "TheRightThing(tm)" out of the box, why not. > What *is* specific to systemd that you need to check for and how would that change the program's behavior? It sounds to me that being started by pid1 is irrelevant here – if you want to alter your logging, then you want to check specifically whether stderr is tied to the journal, for which you can use JOURNAL_STREAM (like in https://github.com/systemd/systemd/blob/main/src/basic/log.c#L217). (In addition to disabling the timestamps you should *at least* add message priority indicators as well, either by using SyslogLevelPrefix=, or by avoiding stderr entirely and using the syslog() API for logging – if not going all the way with sd_journal_send*().) -- Mantas Mikulėnas
