Re: [systemd-devel] device unit files
On graph I have mmcblk.device taking 1.624s. From the point that this partition is where my rootfs lies, and systems does remounting of rootfs, I did look up for systemd-remount-fs.service, it took 231ms, and systemd-udev-trigger.service, as you suggested, it took 517ms to become active. But even after systemd-udev-trigger.service becomes active there is about 800ms for mmcblk.device to become active. Are those services related to the activation of the mmcblk.device? Can I consider those 231ms and 517ms as a part of the activation time of the mmcblk.device? How can I debug udev in this case? - - Elbek > On Apr 12, 2022, at 2:00 PM, Mantas Mikulėnas wrote: > > >> On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov >> wrote: >> How to track down the lifespan of the device unit file, i.e. the activating >> state? I have an embedded system where systemd-analyze plot shows that the >> unit file I am interested in, let’s say dev-mmcpartition.device, takes about >> 2 seconds to be become active. This partition (mmcpartition) holds my >> rootfs. I would like to know what is going on during those 2 seconds, what >> device unit file is doing, how to track what it is doing? Thanks in advance. > > Really the only thing a .device unit "does" is wait for udev to report that > the corresponding actual device is ready. As soon as udev sends out the > uevent with ACTION=add and systemd receives it, the .device unit becomes > active, that's all. > > So if that's slow, it might be the kernel not sending the initial 'add' event > *to* udev (AFAIK, systemd-udev-trigger.service is responsible for triggering > fake 'add' events for devices that already exist at boot time, so check where > that service shows up on the graph), or it might be udev taking a long time > to process its .rules for that device, or systemd not catching up fast > enough... Such delays for the mmcblk rootfs seem to be a frequent question > both here on the list as well as on IRC, but I don't think I remember any > specific answers. > > -- > Mantas Mikulėnas
Re: [systemd-devel] device unit files
On Mon, Apr 11, 2022 at 5:16 PM Elbek Mamajonov wrote: > How to track down the lifespan of the device unit file, i.e. the > activating state? I have an embedded system where systemd-analyze plot > shows that the unit file I am interested in, let’s say > dev-mmcpartition.device, takes about 2 seconds to be become active. This > partition (mmcpartition) holds my rootfs. I would like to know what is > going on during those 2 seconds, what device unit file is doing, how to > track what it is doing? Thanks in advance. > Really the only thing a .device unit "does" is wait for udev to report that the corresponding actual device is ready. As soon as udev sends out the uevent with ACTION=add and systemd receives it, the .device unit becomes active, that's all. So if that's slow, it might be the kernel not sending the initial 'add' event *to* udev (AFAIK, systemd-udev-trigger.service is responsible for triggering fake 'add' events for devices that already exist at boot time, so check where that service shows up on the graph), or it might be udev taking a long time to process its .rules for that device, or systemd not catching up fast enough... Such delays for the mmcblk rootfs seem to be a frequent question both here on the list as well as on IRC, but I don't think I remember any specific answers. -- Mantas Mikulėnas
[systemd-devel] Linux Inlaws about systemd and init systems from 2th April 2022
*listening now* tip: http://hackerpublicradio.org/eps.php?id=3588 https://linuxinlaws.eu/#episodes
[systemd-devel] device unit files
How to track down the lifespan of the device unit file, i.e. the activating state? I have an embedded system where systemd-analyze plot shows that the unit file I am interested in, let’s say dev-mmcpartition.device, takes about 2 seconds to be become active. This partition (mmcpartition) holds my rootfs. I would like to know what is going on during those 2 seconds, what device unit file is doing, how to track what it is doing? Thanks in advance. Best regards Elbek
Re: [systemd-devel] trivial net connection logs - ?
i want to unsubscribe these emails how to do it? kindly helpOn Monday, 11 April, 2022, 01:31:55 pm IST, Paul Menzel wrote: [Sorry for this resent to your personal address.] Dear L, Am 11.04.22 um 09:28 schrieb lejeczek: > I must have gone blind cause can't find it in man page and to my > surprise internet search does not help or my quering is broken. > 'systemctl' can show status for specific NM connection - what was that? Does NM mean NetworkManager? > - and can 'journalctl' do the same? (or was it the opposite way?) To my knowledge there is no such integration from NetworkManager and systemctl. You can only check if NetworkManager is running with systemctl status NetworkManager `networkctl` can show you information about the network configuration, also when it’s not managed by systemd-networkd. Lastly, NetworkManager also ships `nmcli` and `nmtui`, you can use on the command line. Kind regards, Paul PS: Next time, if you write an email to several hundreds/thousands of people, it’d be great if you could elaborate a little more.
Re: [systemd-devel] Starting one service when another one starts
On Mo, 11.04.22 12:41, Nick Howitt (n...@howitts.co.uk) wrote: > > You can add WantedBy=siad.service to [Install] section of > > clearshare-scheduler.service. In general you can always extend Wants by > > manually creating necessary links. This does not require you to edit > > unit definition itself. You can also create drop-in (although I am not > > sure whether they are already supported in your systemd version). > > I've tried this and can implement what you've described, but as you say, it > does not help me when starting the WantedBy service (siad). You must issue "systemctl enable" to actually make the stuff from [Install] apply. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Starting one service when another one starts
On Fr, 08.04.22 12:54, Nick Howitt (n...@howitts.co.uk) wrote: > Hi, > I apologise if this is not the right place for user help. If it is not, > please point me to the best place. > > I am trying to start a service (clearshare-scheduler) when another service > (siad) starts. Clearshare-scheduler is an odd service. When you start it it > may run for ages (days+) or it may terminate immediately so I have set it up > as a oneshot: That's not really necessary. You can set RemainAfterExit=yes to define units if the other types which will remain in "running" state even if all processes they define die. > > [Unit] > Description=Clearshare Scheduler > PartOf=siad.service > After=siad.service > > [Service] > Type=oneshot > Environment="TERM=dumb" > ExecStartPre=-/usr/bin/killall -15 -q > /usr/sbin/clearshare-scheduler.sh I hope this is for testing only.. > ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from > systemd" >> /var/log/scheduler.log systemd does not implement a shell, and ">>" is shell syntax, not systemd syntax. > ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null Similar. > ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh systemd will SIGTERM everything remaining in the service's cgroup anyway... > [Unit] > Description=Siad > After=syslog.target network.target clearsync.service syslog.target is long obsolete. > > [Service] > Type=simple > OOMScoreAdjust=500 > PIDFile=/var/run/siad.pid > EnvironmentFile=/etc/sysconfig/siad > Environment="SIA_DATA_DIR=/var/lib/siad-data" > ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh As above. > ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid systemd removes declared PID files automatically. > ExecStart=/usr/bin/siad $EXTRA_ARGS > ExecStop=/usr/bin/siac stop > WorkingDirectory=/var/lib/sia/ > ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad > > /var/run/siad.pid' > > [Install] > WantedBy=multi-user.target > > A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as one > of its properties but, in reverse, "systemctl show siad" does not list the > corresponding ConsistsOf property. systemd loads units lazily, as they are referenced. Thus "systemctl show siad" does not show the deps towards "clearshare-scheduler", then that's because there was no reason to load the latter if you just ask for the former. Usually you would solve that by just adding a "Wants=" line to your unit clearshare-scheduler.service towards siad.service. if you want "losely couple" this, i.e. don't want to modify "siad.ervice" in to point to "clearshare-scheduler.service", then use "WantedBy=siad.service" in "clearshare-scheduler.service"'s [Install] section.q Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Starting one service when another one starts
On 09/04/2022 06:17, Andrei Borzenkov wrote: On 08.04.2022 23:35, Nick Howitt wrote: Sorry, for the delay. Big internet outage. On 08/04/2022 15:15, Andrei Borzenkov wrote: On 08.04.2022 14:54, Nick Howitt wrote: Hi, I apologise if this is not the right place for user help. If it is not, please point me to the best place. I am trying to start a service (clearshare-scheduler) when another service (siad) starts. Clearshare-scheduler is an odd service. When you start it it may run for ages (days+) or it may terminate immediately so I have set it up as a oneshot: clearshare-scheduler.service [Unit] Description=Clearshare Scheduler PartOf=siad.service After=siad.service [Service] Type=oneshot Environment="TERM=dumb" ExecStartPre=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from systemd" >> /var/log/scheduler.log ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh [Install] WantedBy=multi-user.target The siad service looks like: siad.service [Unit] Description=Siad After=syslog.target network.target clearsync.service [Service] Type=simple OOMScoreAdjust=500 PIDFile=/var/run/siad.pid EnvironmentFile=/etc/sysconfig/siad Environment="SIA_DATA_DIR=/var/lib/siad-data" ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid ExecStart=/usr/bin/siad $EXTRA_ARGS ExecStop=/usr/bin/siac stop WorkingDirectory=/var/lib/sia/ ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad > /var/run/siad.pid' [Install] WantedBy=multi-user.target You do not show actual unit names which makes it rather difficult to follow. Done. See above A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as one of its properties but, in reverse, "systemctl show siad" does not list the corresponding ConsistsOf property. When I start siad, nothing happens to the clearshare-scheduler service. Why do you expect to happen? There is no Wants or Requires in the unit that is /probably/ siad.service so request to start siad.service will not pull in any additional units. Perhaps I have misunderstood, but from the documentation I understood you could PartOf in force (in this case) clearshare-scheduler.service to respond when siad.service was stopped or started. Have I misunderstood the docs? I am hoping to not do any changes to the siad.service. Documentation for PartOf says "limited to stopping and restarting of units". Nothing about "starting". PartOf complements normal startup dependencies, not replaces them. And yes, this is confusing, as are the names of almost any systemd dependency which mean something entirely different from what these names imply in English. You can add WantedBy=siad.service to [Install] section of clearshare-scheduler.service. In general you can always extend Wants by manually creating necessary links. This does not require you to edit unit definition itself. You can also create drop-in (although I am not sure whether they are already supported in your systemd version). I've tried this and can implement what you've described, but as you say, it does not help me when starting the WantedBy service (siad). As an alternative, which does affect the siad.service, is there any way I can run the clearshare-scheduler.sh script from the siad.service? I have tried starting it as a ExecStartPost, but it does not appear to work if the script does not exit immediately. If it runs for a while, then systemd says siad has failed to start. You can increase TimeoutStartSec. I've tried launching it with ExecStartPost=-/usr/sbin/clearshare-scheduler.sh "-" affects command that completed with failure status, in your case command does not complete so this does not have any effect. and ExecStartPost=-/usr/sbin/clearshare-scheduler.sh & and ExecStartPost=-/usr/bin/nohup /usr/sbin/clearshare-scheduler.sh & sytsemd is not shell, what made you think this would work? If you want to use shell syntax, you need to invoke shell /bin/sh -c "/usr/sbin/clearshare-scheduler.sh &" Using bash rather than sh: /bin/bash -c '/usr/sbin/clearshare-scheduler.sh &' This is not producing the results expected. It does not go into the background with the '&' and does not even appear to run. I have simplified the clearshare-scheduler.sh script to just: #!/bin/bash /usr/bin/sleep 10 /usr/bin/echo hello >> /var/log/scheduler.log If I do this the service start fails and times out. At the same time a "ps aux | grep scheduler" never shows the script running and "hello" is not output to /var/log/scheduler.log If I remove the '&', clearshare-scheduler.sh runs and outputs to file, but it is no good if the scheduler script does not terminate for a long time as the service fails when the unit file times out. I think I am stuck here. It does not try to start but it runs when I run it on its own.
Re: [systemd-devel] Samba Config Reload
On Mon, 11 Apr 2022 at 09:58:54 +0200, Lennart Poettering wrote: > dbus-daemon for example uses: > > ExecReload=/usr/bin/busctl call org.freedesktop.DBus > /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig > > Which is a synchronous call to reload the config: the daemon is told > to reload it, and "busctl call" then waits for the reply before > returning to systemd. ... and, crucially, the implementation of ReloadConfig in dbus-daemon also waits for its own reload to have actually been done (not just put in a queue, but actually done) *before* sending back its reply to the caller (in this case busctl). If you need to wait for something to have happened, then the whole chain of interactions needs to be synchronous: all it takes to break the chain is one component thinking "OK, I'll do that later". smcv
Re: [systemd-devel] Samba Config Reload
On Sa, 09.04.22 19:20, Leon Fauster (leonfaus...@googlemail.com) wrote: > It seems that killing with USR1|USR2|HUP is commonly used: > > $ grep -R ExecReload /usr/lib/systemd/|grep -v kill|wc -l > 19 > $ grep -R ExecReload /usr/lib/systemd/|grep kill|wc -l > 27 Yes. I am aware. It's less than ideal. There are simple services where the synchronous vs. asynchronous reload thing doesn't matter, because there are no services the daemon offers to local clients that might rely on the synchronous execution. But most daemons are probably not like that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] trivial net connection logs - ?
[Sorry for this resent to your personal address.] Dear L, Am 11.04.22 um 09:28 schrieb lejeczek: I must have gone blind cause can't find it in man page and to my surprise internet search does not help or my quering is broken. 'systemctl' can show status for specific NM connection - what was that? Does NM mean NetworkManager? - and can 'journalctl' do the same? (or was it the opposite way?) To my knowledge there is no such integration from NetworkManager and systemctl. You can only check if NetworkManager is running with systemctl status NetworkManager `networkctl` can show you information about the network configuration, also when it’s not managed by systemd-networkd. Lastly, NetworkManager also ships `nmcli` and `nmtui`, you can use on the command line. Kind regards, Paul PS: Next time, if you write an email to several hundreds/thousands of people, it’d be great if you could elaborate a little more.
Re: [systemd-devel] trivial net connection logs - ?
On Mon, Apr 11, 2022 at 08:28:28AM +0100, lejeczek wrote: > Hi gents > > I must have gone blind cause can't find it in man page and to my surprise > internet search does not help or my quering is broken. > 'systemctl' can show status for specific NM connection - what was that? - > and can 'journalctl' do the same? (or was it the opposite way?) There's no such integration, although there are some options: - `nmcli`, and `nmcli c` in particualar, native NM tool to manage connections - `networkctl` can show information about interface, including the ones managed by NM - NM put some additional fields in journal, you can filter on them with for example `journalctl NM_DEVICE=wlp61s0`; to see more fields use something like: `journalctl -u NetworkManager -o export | grep ^NM_` - some distribution (Arch?) have a generator creating a instance unit for each interface, but I do not know specifics -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. to...@pipebreaker.pl Your routes will be aggreggated. -- Alex Yuriev
Re: [systemd-devel] Samba Config Reload
On Sa, 09.04.22 08:00, Yolo von BNANA (y...@bnana.de) wrote: > --- Original Message --- > On Friday, April 8th, 2022 at 13:49, Lennart Poettering > wrote: > > > This could be done better. Plugging in just a "kill" here, means the > > reload is async. i.e. "systemctl reload" will basically return > > immediately without the reload being complete, thus subsequent > > commands can't rely the new config is already in place. > > > > > It's typically nicer to invoke some synchronous command from > > ExecReload=. > > > Can you please explain this in more Detail? > > What does this mean: " "systemctl reload" will basically return > immediately without the reload being complete"? reload-via-SIGHUP means that the ExecReload= will just enqueue the SIGHUP signal in the daemon and immdiately return. The daemon then might take a while before it notices that the signal was queued, and then take a while until it completed the reload. Thus, if you have some script change a config file and then immediately call "systemctl reload" on the relevant service, and immediately expect the setting to be applied, then it might happen that the daemon still hasn't noticed or completed the result. Hence, typically it's better to plug in some tool into ExecReload= that will not just enqueue a reload, but then wait until the daemon reported back that the reload is now complete. > And what is an Example for an synchronous command for ExecReload= dbus-daemon for example uses: ExecReload=/usr/bin/busctl call org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig Which is a synchronous call to reload the config: the daemon is told to reload it, and "busctl call" then waits for the reply before returning to systemd. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Intercepting/Delaying the boot process
On Mo, 11.04.22 07:56, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Lennart Poettering schrieb am 08.04.2022 um > >>> 15:14 in > Nachricht : > > ... > > This reminds of an RFE we have had for a while, and which I think > > would make sense to add directly to systemd: a generator that detects > > whether the battery is nearly empty at boot, and if so redirects boot > > to some special target showing a nice message for a bit and then > > powering off. > > Why does it have to be a generator; can't a normal unit detect and handle > that? Sure. But it should be nicer to move the whole system into a specific state for such cases, so that services explicitly have to opt-into running in that state (by means of enabling themselves in the low-battery.target unit), instead of all being pulled in, and waiting forever in the queue. After all, in such a low battey case you want to waste as little resources as you can, hence when the state is detecte you really just want to bring the message to screen and then shut down after a while, and not start a myriad of low-level system services. (Also, for robust embedded devices you probably want to put an overall timeout on the boot process via JobTimeoutSec=+JobTimeoutAction= on multi-user.target. And that would collide with any scheme where we just stall the boot process for a long time) Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [systemd‑devel] Antw: [EXT] Re: Samba Config Reload
>>> "Ulrich Windl" schrieb am 11.04.2022 um 08:26 in Nachricht <6253ca1802a100049...@gwsmtp.uni-regensburg.de>: > Hi! > Sorry for the typos: > I thin Lennart had pointed it out: If the sapplication being reloaded does s/thin/think/ > not provide any feedback when the reloading is complete, you can never be > sure what it did complete. s/what/when/ > Adding some sleep may catch a grat number of cases whule waiting too long in s/grat/great/; s/whule/while/ > most cases. > > So before discussing systemd meachnisms: How do you know when reload is > complete? > > Regards, > Ulrich > Wols Lists schrieb am 09.04.2022 um 17:10 in > Nachricht : >> On 09/04/2022 09:00, Yolo von BNANA wrote: >>> Can you please explain this in more Detail? >>> >>> What does this mean: " "systemctl reload" will basically return >>> immediately without the reload being complete"? >>> >>> And what is an Example for an synchronous command for ExecReload= >>> >> Do you understand the difference between "synchronous" and >> "asynchronous"? The words basically mean "aligned in time" and "without >> timed alignment". >> >> Think of writing to files. In the old days of MS‑DOS et al, when your >> program called "write", the CPU went off, saved the data to disk, and >> returned to your program. That's "synchronous", all nicely ordered in >> time, and your program knew the data was safe. >> >> Now, when your linux program calls write, linux itself replies "got it", >> and your program goes off knowing that something else is going to take >> care of actually saving the data to disk ‑ that's "asynchronous". Except >> that sometimes the program needs to know that the data HAS been safely >> squirreled away (hence all these fsync calls). >> >> So when systemd calls ExecReload *A*synchronously, it goes off and fires >> off a load more stuff, knowing that the ExecReload IS GOING (future >> tense) to happen. What the previous poster wanted was a synchronous >> ExecReload, so that when systemd goes off do the next thing, the >> ExecReload HAS ALREADY HAPPENED (past tense). (Which in general is a bad >> thing because it *seriously* knackers performance). >> >> Cheers, >> Wol
[systemd-devel] Antw: [EXT] Re: Samba Config Reload
Hi! I thin Lennart had pointed it out: If the sapplication being reloaded does not provide any feedback when the reloading is complete, you can never be sure what it did complete. Adding some sleep may catch a grat number of cases whule waiting too long in most cases. So before discussing systemd meachnisms: How do you know when reload is complete? Regards, Ulrich >>> Wols Lists schrieb am 09.04.2022 um 17:10 in Nachricht : > On 09/04/2022 09:00, Yolo von BNANA wrote: >> Can you please explain this in more Detail? >> >> What does this mean: " "systemctl reload" will basically return >> immediately without the reload being complete"? >> >> And what is an Example for an synchronous command for ExecReload= >> > Do you understand the difference between "synchronous" and > "asynchronous"? The words basically mean "aligned in time" and "without > timed alignment". > > Think of writing to files. In the old days of MS-DOS et al, when your > program called "write", the CPU went off, saved the data to disk, and > returned to your program. That's "synchronous", all nicely ordered in > time, and your program knew the data was safe. > > Now, when your linux program calls write, linux itself replies "got it", > and your program goes off knowing that something else is going to take > care of actually saving the data to disk - that's "asynchronous". Except > that sometimes the program needs to know that the data HAS been safely > squirreled away (hence all these fsync calls). > > So when systemd calls ExecReload *A*synchronously, it goes off and fires > off a load more stuff, knowing that the ExecReload IS GOING (future > tense) to happen. What the previous poster wanted was a synchronous > ExecReload, so that when systemd goes off do the next thing, the > ExecReload HAS ALREADY HAPPENED (past tense). (Which in general is a bad > thing because it *seriously* knackers performance). > > Cheers, > Wol
