Re: [systemd-devel] Direct connection between peers in sd-bus
On Fri, Jan 18, 2019 at 1:19 AM Stanislav Angelovič wrote: > Hi, > > In sd-bus, I guess it is possible to have a one-to-one connection between > a service and a client, i.e. connection without D-bus daemon), am I right? > If yes, is there any example (in systemd source tree or elsewhere) of > sd-bus one-to-one communication usage that I could look at for inspiration > and learning on how is that done? > Yes, that's how `systemctl` works when it has privileges. See bus_connect_system_systemd() and bus_connect_user_systemd() in src/shared/bus-util.c. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On 18/01/19 2:29 am, Lennart Poettering wrote: On Do, 17.01.19 07:05, Amish (anon.am...@gmail.com) wrote: On 16/01/19 11:52 pm, Lennart Poettering wrote: On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote: Jérémy ROSEN wrote on 16/01/2019 08:24: yes... adding a "this is the start of the freeze" tag sounds like a low hanging fruit... it's almost no work for the core team to do, and it would be a clear signal that the freeze period is starting... And automated mails to the list when this happens would be nice too, as some folk will likely still follow the list more than they login to github (and for those that do login to github they may have many other projects so it could get lost in the noise) Hmm, I figure we'd need to set up a webhook for that... but someone would have to host this? Anyone wants to set this up? If so, that'd be excellent of course! Thanks, Lennart May be a user (say systemd-watch) with systemd-devel@lists.freedesktop.org as email id can be created on Github. And that user activates "Watch" feature with "Releases only" mode set. So Github will automatically send email to mailing list. (needs some testing by mailing list administrator) Hmm, interesting idea. But that would mean if people would everuse @systemd-watch in any comment on the github page they'd spam our mailing list? Or is there a way to turn that off? As I said - it needs some testing. May be filter can be put in mailing list which ignores mails from github with @mentions. We can check some sample emails received from Github and create filters accordingly. I have activated that option for me - so next time I would come to know difference in two types of emails. Regards, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Direct connection between peers in sd-bus
Hi, In sd-bus, I guess it is possible to have a one-to-one connection between a service and a client, i.e. connection without D-bus daemon), am I right? If yes, is there any example (in systemd source tree or elsewhere) of sd-bus one-to-one communication usage that I could look at for inspiration and learning on how is that done? Thanks a lot. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 2:42 PM, Lennart Poettering wrote: On Do, 17.01.19 14:35, Christopher Cox (c...@endlessnow.com) wrote: On 1/17/19 2:25 PM, Lennart Poettering wrote: On Do, 17.01.19 12:38, Christopher Cox (c...@endlessnow.com) wrote: it defaults to YES and the whole discussions as that changed where about nohup'd processes long ago Changing it to "no"... I'll let you know if this fixes things or not. Actually, as it turns out the nohup'd processes are all owned by root, so changing to "no" didn't fix, but it's my understanding that if the setting isn't set root is always excluded anyhow. The sessions of root are excluded, which is semantically slightly different from processes of root. Out of the 18 processes that are running, my script only sees 6 of them. Again, it's just doing a "ps -ef" to a file. All 18 processes exist prior to shutdown and the script shows that if I run manually. Which systemd version is this? Note that on old systemd versions systemd-user-sessions.service would go on its own killing spree early on. Maybe you have such an old version? Quite possible. This is CentOS 7.6 using what it calls "systemd-219-62" So, if you order your service After=systemd-user-sessions.service, does that change things? I changed it to use After=systemd-user-sessions.service Did not seem to change the behavior. Only getting subset in the file (this time only 2 of 18 processes). But, systemctl list-dependencies --after systemd-user-sessions.service, doesn't show my service. Should it? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Do, 17.01.19 07:05, Amish (anon.am...@gmail.com) wrote: > On 16/01/19 11:52 pm, Lennart Poettering wrote: > > On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > > > > Jérémy ROSEN wrote on 16/01/2019 08:24: > > > > yes... adding a "this is the start of the freeze" tag sounds like a low > > > > hanging fruit... it's almost no work for the core team to do, and it > > > > would be a clear signal that the freeze period is starting... > > > And automated mails to the list when this happens would be nice too, as > > > some folk will likely still follow the list more than they login to > > > github (and for those that do login to github they may have many other > > > projects so it could get lost in the noise) > > Hmm, I figure we'd need to set up a webhook for that... but someone > > would have to host this? Anyone wants to set this up? If so, that'd be > > excellent of course! > > > > Thanks, > > > > Lennart > > May be a user (say systemd-watch) with systemd-devel@lists.freedesktop.org > as email id can be created on Github. > > And that user activates "Watch" feature with "Releases only" mode set. > > So Github will automatically send email to mailing list. (needs some testing > by mailing list administrator) Hmm, interesting idea. But that would mean if people would everuse @systemd-watch in any comment on the github page they'd spam our mailing list? Or is there a way to turn that off? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Do, 17.01.19 14:35, Christopher Cox (c...@endlessnow.com) wrote: > On 1/17/19 2:25 PM, Lennart Poettering wrote: > > On Do, 17.01.19 12:38, Christopher Cox (c...@endlessnow.com) wrote: > > > > > > > it defaults to YES and the whole discussions as that changed where > > > > > about > > > > > nohup'd processes long ago > > > > > > > > Changing it to "no"... I'll let you know if this fixes things or not. > > > > > > > > > > Actually, as it turns out the nohup'd processes are all owned by root, so > > > changing to "no" didn't fix, but it's my understanding that if the setting > > > isn't set root is always excluded anyhow. > > > > The sessions of root are excluded, which is semantically slightly > > different from processes of root. > > > > > Out of the 18 processes that are > > > running, my script only sees 6 of them. Again, it's just doing a "ps -ef" > > > to a file. All 18 processes exist prior to shutdown and the script shows > > > that if I run manually. > > > > Which systemd version is this? Note that on old systemd versions > > systemd-user-sessions.service would go on its own killing spree early > > on. Maybe you have such an old version? > > Quite possible. This is CentOS 7.6 using what it calls "systemd-219-62" So, if you order your service After=systemd-user-sessions.service, does that change things? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 2:25 PM, Lennart Poettering wrote: On Do, 17.01.19 12:38, Christopher Cox (c...@endlessnow.com) wrote: it defaults to YES and the whole discussions as that changed where about nohup'd processes long ago Changing it to "no"... I'll let you know if this fixes things or not. Actually, as it turns out the nohup'd processes are all owned by root, so changing to "no" didn't fix, but it's my understanding that if the setting isn't set root is always excluded anyhow. The sessions of root are excluded, which is semantically slightly different from processes of root. Out of the 18 processes that are running, my script only sees 6 of them. Again, it's just doing a "ps -ef" to a file. All 18 processes exist prior to shutdown and the script shows that if I run manually. Which systemd version is this? Note that on old systemd versions systemd-user-sessions.service would go on its own killing spree early on. Maybe you have such an old version? Quite possible. This is CentOS 7.6 using what it calls "systemd-219-62" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Do, 17.01.19 12:38, Christopher Cox (c...@endlessnow.com) wrote: > > > it defaults to YES and the whole discussions as that changed where about > > > nohup'd processes long ago > > > > Changing it to "no"... I'll let you know if this fixes things or not. > > > > Actually, as it turns out the nohup'd processes are all owned by root, so > changing to "no" didn't fix, but it's my understanding that if the setting > isn't set root is always excluded anyhow. The sessions of root are excluded, which is semantically slightly different from processes of root. > Out of the 18 processes that are > running, my script only sees 6 of them. Again, it's just doing a "ps -ef" > to a file. All 18 processes exist prior to shutdown and the script shows > that if I run manually. Which systemd version is this? Note that on old systemd versions systemd-user-sessions.service would go on its own killing spree early on. Maybe you have such an old version? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: idea for a pstore systemd service
Lennart, I've some homework to do based on your feedback and will report back. As I understand it, I need to do this in C as well. Regards, eric On 1/15/19 12:49 PM, Lennart Poettering wrote: On Di, 15.01.19 11:23, Eric DeVolder (eric.devol...@oracle.com) wrote: Systemd-devel, Below is a write-up I've done to explain a new service for archiving pstore contents. I've attached the pstore.service files (/lib/systemd/system/pstore.service and bin/pstore-tool). These are trivial right now, but easy to build upon if periodic, rather than just on-boot, examination of the pstore is desirable. If you look at the TODO list in our git tree, you'll find that importing and flushing pstore has been a long-time TODO list item for us. Our original idea was to make this another input for the journal, but as I understand these days the pstore files are not necessarily in log format, hence maybe handling it similar to coredumps is an option too. i.e. drop it into some directory in /var like we do it for /var/lib/coredump/, and then link that up with the journal through some structured log message. So yeah, it appears to me that you have similar ideas there. And yes, we'd welcome such work. ACPI is generic and standard enough to make this generically useful, and the code for this is simple enough hence I think this sounds like something acceptable for our tree. That said, I wonder what else is generally found in pstore these days, besides the dmesg stuff? i.e. is there well-known other stuff, such as firmware stuff? The questions I have for you are: - Is a new unit pstore.service the right approach for this? If not, what unit do you recommend augmenting with these actions? Well, our own code is usually placed in service units whose name begins with "systemd-", hence systemd-pstore.service sounds more systematic. But yeah, by all means, please submit a proposal as PR. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 12:09 PM, Christopher Cox wrote: On 1/17/19 11:54 AM, Reindl Harald wrote: Am 17.01.19 um 18:51 schrieb Christopher Cox: On 1/17/19 11:21 AM, Reindl Harald wrote: Am 17.01.19 um 18:17 schrieb Christopher Cox: On 1/17/19 11:01 AM, Lennart Poettering wrote: Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... These are nohup'd background processes not tied to any tty. give that a try! [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf [Login] KillUserProcesses=no It's default, that is, already set to "no" (shouldn't matter anyway, again the processes are nohup'd) it is NOT default it defaults to YES and the whole discussions as that changed where about nohup'd processes long ago Changing it to "no"... I'll let you know if this fixes things or not. Actually, as it turns out the nohup'd processes are all owned by root, so changing to "no" didn't fix, but it's my understanding that if the setting isn't set root is always excluded anyhow. Out of the 18 processes that are running, my script only sees 6 of them. Again, it's just doing a "ps -ef" to a file. All 18 processes exist prior to shutdown and the script shows that if I run manually. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 11:54 AM, Reindl Harald wrote: Am 17.01.19 um 18:51 schrieb Christopher Cox: On 1/17/19 11:21 AM, Reindl Harald wrote: Am 17.01.19 um 18:17 schrieb Christopher Cox: On 1/17/19 11:01 AM, Lennart Poettering wrote: Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... These are nohup'd background processes not tied to any tty. give that a try! [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf [Login] KillUserProcesses=no It's default, that is, already set to "no" (shouldn't matter anyway, again the processes are nohup'd) it is NOT default it defaults to YES and the whole discussions as that changed where about nohup'd processes long ago Changing it to "no"... I'll let you know if this fixes things or not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Thu, Jan 17, 2019 at 12:54 PM Reindl Harald wrote: > > > > Am 17.01.19 um 18:51 schrieb Christopher Cox: > > On 1/17/19 11:21 AM, Reindl Harald wrote: > >> > >> Am 17.01.19 um 18:17 schrieb Christopher Cox: > >>> On 1/17/19 11:01 AM, Lennart Poettering wrote: > Hmm, what kind of processes are you missing? user session stuff? How > do you shut down? Note that display managers are likely to terminate > the user sessions first, and only initiate system shutdown then... > >>> These are nohup'd background processes not tied to any tty. > >> give that a try! > >> > >> [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf > >> [Login] > >> KillUserProcesses=no > > > > It's default, that is, already set to "no" (shouldn't matter anyway, > > again the processes are nohup'd) > > it is NOT default > > it defaults to YES and the whole discussions as that changed where about > nohup'd processes long ago Unless he is compiling systemd himself, the default is determined by the distro he is using. Several distros default it to "no" via the default-kill-user-processes meson option. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 11:59 AM, Lennart Poettering wrote: On Do, 17.01.19 11:17, Christopher Cox (c...@endlessnow.com) wrote: [Install] WantedBy=multi-user.target In my case, my script rolls through the currently running processes, looking for certain ones, determines listening port (ss) and gets the time the process was started (stat) and outputs info to a file. What I'm seeing is a file at shutdown that does not contain all the processes. Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... These are nohup'd background processes not tied to any tty. Well, how is that stuff started? Note that if systemd --user or --system manages your process then it will keep track of it through cgroups, and "nohup" is not a concept for evading that. Nohup'd processes started by an ssh as a user. Process "parent" pid 1. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Do, 17.01.19 11:17, Christopher Cox (c...@endlessnow.com) wrote: > > > [Install] > > > WantedBy=multi-user.target > > > > > > In my case, my script rolls through the currently running processes, > > > looking > > > for certain ones, determines listening port (ss) and gets the time the > > > process was started (stat) and outputs info to a file. > > > > > > What I'm seeing is a file at shutdown that does not contain all the > > > processes. > > Hmm, what kind of processes are you missing? user session stuff? How > > do you shut down? Note that display managers are likely to terminate > > the user sessions first, and only initiate system shutdown then... > > These are nohup'd background processes not tied to any tty. Well, how is that stuff started? Note that if systemd --user or --system manages your process then it will keep track of it through cgroups, and "nohup" is not a concept for evading that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
Am 17.01.19 um 18:51 schrieb Christopher Cox: > On 1/17/19 11:21 AM, Reindl Harald wrote: >> >> Am 17.01.19 um 18:17 schrieb Christopher Cox: >>> On 1/17/19 11:01 AM, Lennart Poettering wrote: Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... >>> These are nohup'd background processes not tied to any tty. >> give that a try! >> >> [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf >> [Login] >> KillUserProcesses=no > > It's default, that is, already set to "no" (shouldn't matter anyway, > again the processes are nohup'd) it is NOT default it defaults to YES and the whole discussions as that changed where about nohup'd processes long ago https://news.ycombinator.com/item?id=14734854 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 11:21 AM, Reindl Harald wrote: Am 17.01.19 um 18:17 schrieb Christopher Cox: On 1/17/19 11:01 AM, Lennart Poettering wrote: Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... These are nohup'd background processes not tied to any tty. give that a try! [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf [Login] KillUserProcesses=no It's default, that is, already set to "no" (shouldn't matter anyway, again the processes are nohup'd) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
Am 17.01.19 um 18:17 schrieb Christopher Cox: > On 1/17/19 11:01 AM, Lennart Poettering wrote: >> Hmm, what kind of processes are you missing? user session stuff? How >> do you shut down? Note that display managers are likely to terminate >> the user sessions first, and only initiate system shutdown then... > > These are nohup'd background processes not tied to any tty. give that a try! [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf [Login] KillUserProcesses=no ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 11:01 AM, Lennart Poettering wrote: On Do, 17.01.19 10:18, Christopher Cox (c...@endlessnow.com) wrote: On 1/17/19 5:50 AM, Lennart Poettering wrote: With that you can now put together a unit that is terminated relatively early on during shutdown: just make it "After=multi-user.target graphical.target default.target", so that it gets activated at boot very late, and thus deactivated at shutdown very early. Thanks, I think I had this on one of my many attempts. But changed to suit. [Unit] Description=my-service-save save run state After=multi-user.target graphical.target default.target [Service] Type=oneshot ExecStop=/usr/local/bin/my-services.sh save RemainAfterExit=yes [Install] WantedBy=multi-user.target In my case, my script rolls through the currently running processes, looking for certain ones, determines listening port (ss) and gets the time the process was started (stat) and outputs info to a file. What I'm seeing is a file at shutdown that does not contain all the processes. Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... These are nohup'd background processes not tied to any tty. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Do, 17.01.19 10:18, Christopher Cox (c...@endlessnow.com) wrote: > On 1/17/19 5:50 AM, Lennart Poettering wrote: > > With that you can now put together a unit that is terminated > > relatively early on during shutdown: just make it > > "After=multi-user.target graphical.target default.target", so that it > > gets activated at boot very late, and thus deactivated at shutdown > > very early. > > Thanks, I think I had this on one of my many attempts. But changed to suit. > > [Unit] > Description=my-service-save save run state > After=multi-user.target graphical.target default.target > > [Service] > Type=oneshot > ExecStop=/usr/local/bin/my-services.sh save > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > > In my case, my script rolls through the currently running processes, looking > for certain ones, determines listening port (ss) and gets the time the > process was started (stat) and outputs info to a file. > > What I'm seeing is a file at shutdown that does not contain all the > processes. Hmm, what kind of processes are you missing? user session stuff? How do you shut down? Note that display managers are likely to terminate the user sessions first, and only initiate system shutdown then... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219
Mailing List SVR wrote on 16/01/2019 21:03: > Il 16/01/19 19:24, Lennart Poettering ha scritto: >> On Mi, 16.01.19 09:20, Mailing List SVR (li...@svrinformatica.it) wrote: >> >>> Well, this command will make the sd devices readable inside the >>> container on >>> centos 7 too >>> >>> echo 'b 8:* rw' > >>> /sys/fs/cgroup/devices/machine.slice/machine-bionic\\x2druntime.scope/devices.allow >>> >>> >>> now I'll will search how to pass to systemd-nspawn using a command line >>> argument >> Use --property=DeviceAllow=… > > thanks but this does not seems available in systemd 219, the version > shipped with centos 7, it fails with unrecognized option error. > > Newer systemd versions work out of the box probably because they have > DevicePolicy=auto as default, > > so basically I ended up writing a systemd-nspawn wrapper that, launched > from a systemd service, wait for > /sys/fs/cgroup/devices/machine.slice/machine-.scope to appear and > then it sets the required permissions in devices.allow. > > If I use the reboot command inside the container then the cgroup dir is > recreated and the permissions are lost since my wrapper is not called > > luckily I can control the container and so I changed the reboot command > so it shutdowns the container instead and I set Restart=always in the > systemd service so the container is restarted automatically after the > shutdown, > > so the only way to shutdown the container is using systemctl stop service> but this is better than nothing, FWIW (and orthogonal to the actual problem), I think Facebook maintain a backported systemd package for CentOS 7 that might be worth investigating. Last time I looked there were still some manual deps you had to build yourself (or just copy the packages) from Fedora which is a bit rubbish but not impossible with a bit of jiggery pokery. There is some degree of confidence that at least the package is used in a "fairly large" deployment :-p Worth having a little look over (I haven't had the need yet - like yourself I've found workarounds for the itches I need to scratch that are fixed in newer systemds - but may do at some point) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/17/19 5:50 AM, Lennart Poettering wrote: With that you can now put together a unit that is terminated relatively early on during shutdown: just make it "After=multi-user.target graphical.target default.target", so that it gets activated at boot very late, and thus deactivated at shutdown very early. Thanks, I think I had this on one of my many attempts. But changed to suit. [Unit] Description=my-service-save save run state After=multi-user.target graphical.target default.target [Service] Type=oneshot ExecStop=/usr/local/bin/my-services.sh save RemainAfterExit=yes [Install] WantedBy=multi-user.target In my case, my script rolls through the currently running processes, looking for certain ones, determines listening port (ss) and gets the time the process was started (stat) and outputs info to a file. What I'm seeing is a file at shutdown that does not contain all the processes. Running the script while in the normal run state works just fine. But on shutdown, either the processes are gone or somehow my script is being terminated or something is preventing me from writing the whole file. So, I'm still stuck on this one. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Wed, Jan 16, 2019 at 07:18:15PM +0100, Lennart Poettering wrote: > On Mi, 16.01.19 01:06, Christian Hesse (l...@eworm.de) wrote: > > > Lennart Poettering on Tue, 2019/01/15 20:00: > > > Note that we don't branch releases right now. Instead when we are > > > getting closer to a release we simply don't merge PRs we don't > > > consider appropriate for the release anymore until after the > > > release. Or in other words: the master branch simply "stops" for a > > > while getting new stuff, and only gets bugfixes until we release the > > > version, which reopens the floodgates > > > > Most people do not notice when this happens. Having milestones on github is > > nice, but most of us miss that. Just make it obvious: add a tag when > > you start preparation for a release - no matter if you call it > > 'v241-freeze', > > 'v241-rc' or whatever. I guess 'communication' on the lowest level can help > > a > > lot here. > > (Hmm, are you sure a git tag is more "visible" than a github > milestone? I am not so sure) It is. `git pull` lists new tags: Resolving deltas: 100% (8291/8291), completed with 1265 local objects. From https://github.com/systemd/systemd 8724defeae..80aff27aeb master -> origin/master * [new tag] v240 -> v240 Updating 8724defeae..80aff27aeb It does not list any GitHub milestones. Having said that, I'm against proliferation of tags. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
Am 17.01.19 um 17:00 schrieb Christopher Cox: > On 1/16/19 11:10 PM, Reindl Harald wrote: >> that all is not really new and was not better with sysvinit, it only was >> slow enough, full of sleep/usleep hacks and so most of the time by luck >> worked but with no guarantess anyways > > What I said it that synchronous execution of a script was possible prior > to "the kills" in sysvinit. > > And that made it "better" in that regard. > > And still, I have no means of doing this in systemd. Anyone? see the other responses and just use After/Before proper in all units ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On 1/16/19 11:10 PM, Reindl Harald wrote: that all is not really new and was not better with sysvinit, it only was slow enough, full of sleep/usleep hacks and so most of the time by luck worked but with no guarantess anyways What I said it that synchronous execution of a script was possible prior to "the kills" in sysvinit. And that made it "better" in that regard. And still, I have no means of doing this in systemd. Anyone? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Mi, 16.01.19 22:44, Christopher Cox (c...@endlessnow.com) wrote: > On 01/16/2019 12:51 PM, Filipe Brandenburger wrote: > > If you want to run it early in the shutdown process, then keep > > DefaultDependencies=yes, in which case it will run before the base > > dependencies start to get stopped. > > > > If you need some other resources to be up, for instance network, then > > add After=network.target, etc. > > > > Remember that when shutting down, the dependencies are stopped in the > > opposite order as they're started up, so if you need your script to run > > *before* something else is stopped, then you need an After= dependency. > > > But only for services under systemd. Everything else gets sprayed a TERM > signal. Which is frustrating. So... having it execute first doesn't > guarantee (and we're talking less than a second or so) that it will have > time to do what it needs to do before the kill spray happens, and I need all > processes to be around until my script finishes. In systemd the emphasis is on defining correct deps. If you service needs some other service to shutdown properly, then it should order itself After= that other service, which makes sure your service is started after that other service started up, and stops before that other service shuts down. In general: if you are asking for absolutes such as "stop this first" or "start this last", then most likely the better approach would be to track down the actual deps you need, and use those instead... > Old sysvinit didn't have this limitation. Well, that's not precisely true. On LSB-style sysvinit you#d have to define deps in the sysvinit script header for ordering to work correctly. And on sysvinit predating that you'd have to use the right priority values compare to the services you wanted to be ordered after. This isn't too different from systemd really, except that we generally parallelize and sysvinit was only parallelized on some distros. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown
On Mi, 16.01.19 12:40, Christopher Cox (c...@endlessnow.com) wrote: > I need to be able to execute a script before anything gets shutdown. That > is, when somebody does a "reboot", "shutdown" or "poweroff", I need this > script to run first, and for it to finish before everything gets > whacked. Well, systemd doesn't know a concept of "before all" and "after all", as a unit marked that way would have to be the only one, and what do you do if multiple units are marked that way? Hence, systemd generally allows you to order units after or before specific other units, but there are no absolutes like "after all" or "before all". If you want to define a unit that runs code during shutdown the best approach is to make it a unit that gets started at boot, and then only uses ExecStop= (but not necessarily ExecStart=). Note that the shutdown order of units is generally the inverse of the startup order. Hence if you want unit A to stop before unit B, then you have to declare in A "After=B", so that A gets started *after* unit B, and thus stopped before B, as you need it here. Usually a system boots into multi-user.target or graphical.target (or generically default.target), and these are the last (or close to last) units that are reached. Due to the rule of "stop order is inverted start order" this also means these targets are the first ones to be stopped again when the system goes down. With that you can now put together a unit that is terminated relatively early on during shutdown: just make it "After=multi-user.target graphical.target default.target", so that it gets activated at boot very late, and thus deactivated at shutdown very early. > [Unit] > Description=my-service save status > DefaultDependencies=no No need to turn off default dependencies. > Before=reboot.target shutdown.target > Conflicts=reboot.target shutdown.target These two lines are unnecessary. > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStart=/bin/true This line is unnecessary on any remotely recent systemd version. > ExecStop=/usr/local/bin/my-service.sh save > StandardOutput=journal This line is redundant, as it is the implied default. > [Install] > WantedBy=multi-user.target Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
