Re: [systemd-devel] Converting xinetd files
Dear Wol, Am 11.02.22 um 01:57 schrieb Wol: I've found the pid0 blog, and had no real trouble (I think, I haven't tested it yet :-) converting an xinetd setup. Please always provide the URL, if you refer to some resource. But the documentation (man systemd.service) didn't tell me how to convert a couple of settings, namely xinetd had "user=" and "group=". Okay, user= was root, so group= probably doesn't matter either, but how do you get a service to change user and drop privileges? systemd has several manual pages. I always look at systemd.directives(7), and go to the right one from there. In this case, `User=` and `Group=` are documented in systemd.exec(5). It would be nice to know for the future, even the near future to try and modify qm/scarletdme so it doesn't need root and lower any possible attack surface. Sorry, no idea, what you mean. Kind regards, Paul
Re: [systemd-devel] Converting xinetd files
On Fri, 11 Feb 2022 01:53:32 + Wol wrote: > On 11/02/2022 01:08, Stephen Hemminger wrote: > > On Fri, 11 Feb 2022 00:57:11 + > > Wol wrote: > > > >> I've found the pid0 blog, and had no real trouble (I think, I haven't > >> tested it yet :-) converting an xinetd setup. > >> > >> But the documentation (man systemd.service) didn't tell me how to > >> convert a couple of settings, namely xinetd had "user=" and "group=". > >> Okay, user= was root, so group= probably doesn't matter either, but how > >> do you get a service to change user and drop privileges? It would be > >> nice to know for the future, even the near future to try and modify > >> qm/scarletdme so it doesn't need root and lower any possible attack > >> surface. > >> > >> Cheers, > >> Wol > > > > You probably want DynamicUser= > > Thanks. Just looked in the man page and it doesn't appear to be there... > How many other undocumented options are there? :-) > > Cheers, > Wol https://0pointer.net/blog/dynamic-users-with-systemd.html
Re: [systemd-devel] Converting xinetd files
On 11/02/2022 01:08, Stephen Hemminger wrote: On Fri, 11 Feb 2022 00:57:11 + Wol wrote: I've found the pid0 blog, and had no real trouble (I think, I haven't tested it yet :-) converting an xinetd setup. But the documentation (man systemd.service) didn't tell me how to convert a couple of settings, namely xinetd had "user=" and "group=". Okay, user= was root, so group= probably doesn't matter either, but how do you get a service to change user and drop privileges? It would be nice to know for the future, even the near future to try and modify qm/scarletdme so it doesn't need root and lower any possible attack surface. Cheers, Wol You probably want DynamicUser= Thanks. Just looked in the man page and it doesn't appear to be there... How many other undocumented options are there? :-) Cheers, Wol
Re: [systemd-devel] Converting xinetd files
On Fri, 11 Feb 2022 00:57:11 + Wol wrote: > I've found the pid0 blog, and had no real trouble (I think, I haven't > tested it yet :-) converting an xinetd setup. > > But the documentation (man systemd.service) didn't tell me how to > convert a couple of settings, namely xinetd had "user=" and "group=". > Okay, user= was root, so group= probably doesn't matter either, but how > do you get a service to change user and drop privileges? It would be > nice to know for the future, even the near future to try and modify > qm/scarletdme so it doesn't need root and lower any possible attack surface. > > Cheers, > Wol You probably want DynamicUser=
[systemd-devel] Converting xinetd files
I've found the pid0 blog, and had no real trouble (I think, I haven't tested it yet :-) converting an xinetd setup. But the documentation (man systemd.service) didn't tell me how to convert a couple of settings, namely xinetd had "user=" and "group=". Okay, user= was root, so group= probably doesn't matter either, but how do you get a service to change user and drop privileges? It would be nice to know for the future, even the near future to try and modify qm/scarletdme so it doesn't need root and lower any possible attack surface. Cheers, Wol
[systemd-devel] Antw: Re: Antw: Re: [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
>>> Mantas Mikulenas schrieb am 10.02.2022 um 14:15 in Nachricht : > On Thu, Feb 10, 2022 at 3:11 PM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> >>> Etienne Champetier schrieb am >> 10.02.2022 um >> 12:47 in Nachricht >> : >> > Le jeu. 10 févr. 2022 à 11:49, Ulrich Windl >> > a écrit : >> >> >> >> >>> Lennart Poettering schrieb am 10.02.2022 >> um >> 11:31 >> >> in >> >> Nachricht : >> >> > On Mi, 09.02.22 22:05, Etienne Champetier ( >> champetier.etie...@gmail.com) >> >> > wrote: >> >> > >> >> >> Hello systemd hackers, >> >> >> >> >> >> After flashing the firmware of some pcie card I need to power cycle >> >> >> the server to finish the flashing process. >> >> >> For now I have a simple script in lib/systemd/system-shutdown/ >> running >> >> >> "ipmitool power cycle" but I would like to make sure it runs after >> >> >> other scripts like fwupd.shutdown or mdadm.shutdown >> >> >> >> >> >> Is there any way to have systemd cleanly power cycle my server >> instead >> >> >> of rebooting it ? >> >> > >> >> > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't >> >> > "systemctl reboot" suffice? >> >> >> >> My guess is that some smart cards with their own firmware and CPu do not >> >> reboot unless they are power cycled, so maybe if the firmware upgrade on >> the >> >> card does not force it to reboot, it my need a power cycle. >> >> >> >> > >> >> > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS >> >> > transitions back into the initrd — the initrd will then detach the >> >> > root fs (i.e. undo what it attached at boot) and actually reboot. This >> >> > means if your command turns off the power source you should stick it >> >> > in the initrd's shutdown logic, and not into >> >> > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means >> >> > into dracut. But adding it there is something to better discuss with >> >> > the dracut community than here. >> >> >> >> My guess is that it would be handled best by some special GRUB boot >> menu >> > entry >> >> (like "boot 'power cycle' once). >> > >> > This is pretty clean but it means going through "BIOS" init twice >> > which can be pretty long on physical servers >> >> Hi! >> >> Of course I have a better solution: Use an external server and just before >> restarting send a command to that server that will, after a carefully tuned >> delay, will trigger the IPMI power-cycle remotely ;-) >> I believe that it's almost impossible to trigger a power cycle through IPMI >> while also doing a clean shutdown/reboot, unless the the IPMI features a >> delayed execution itself. >> > > Asking the BMC to power the system off is no different than asking the > system to power itself off – what makes it a "clean shutdown" is stopping > services, syncing and unmounting filesystems, etc. So in theory these > shutdown hooks should do the job. > > Though a better place would be a "shutdown initramfs" which runs from a > tmpfs after *all* storage has been unmounted. I think Dracut has that, and > explicitly specifies the order for its shutdown hooks, so it should be > possible to put ipmitool there. Another solution comes to my mind: How about programming the RTC for time-based wakeup (say in 5 minutes from now), then "shutdown -h"... > > -- > Mantas Mikulėnas
Re: [systemd-devel] [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)
On Thu, Feb 10, 2022 at 3:08 PM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Mantas Mikulenas schrieb am 10.02.2022 um 12:30 in > Nachricht > : > > On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl < > > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > >> >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht > <6204E61B.426 > >> : > >> 161 : > >> 60728>: > >> Mantas Mikulenas schrieb am 10.02.2022 um > 10:34 > >> in > >> > Nachricht > >> > : > >> > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl < > >> > > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> > > > >> > >> Hi! > >> > >> > >> > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) > >> where > >> > >> smartd is restarted for no obvious reason. Support says everything > is > >> fine, > >> > >> but I disagree. > >> > >> Specifically smartd.service uses: > >> > >> > >> > >> [Service] > >> > >> Type=notify > >> > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts > >> > >> ExecStart=/usr/sbin/smartd -n $smartd_opts > >> > >> ExecReload=/bin/kill -HUP $MAINPID > >> > >> > >> > >> And mostly I wonder to what types of changes "notify" does react. > >> > >> > >> > > > >> > > None. It's not an activation mechanism and not a configuration > >> monitoring > >> > > mechanism – it's a readiness indication mechanism. > >> > > > >> > > Type=notify expects the service to send a message to a Unix socket > (at > >> > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some > >> custom > >> > > text to show in 'systemctl status'.) > >> > > >> > Mantas, > >> > > >> > thanks for explaining; obviously I was wrong. But still: How can I > find > >> out > >> > >> > why the smartd.service restarts? > >> > >> Hi! > >> > >> I digged further into it: > >> smartd_generate_opts.path has: > >> [Path] > >> Unit=smartd_generate_opts.service > >> PathChanged=/etc/sysconfig/smartmontools > >> > >> smartd_generate_opts.service has: > >> [Service] > >> Type=oneshot > >> ExecStart=/usr/lib/smartmontools/generate_smartd_opts > >> > >> Finally /usr/lib/smartmontools/generate_smartd_opts is not documented. > >> > >> But running that program causes a restart of smartd! > >> > > > > I'm not saying this is complete garbage but ugh. > > > > At least it doesn't seem to be an upstream thing. > > > > > >> The "Change" date was most likely caused by backup software resetting > the > >> Access time. > >> > > > > The backup software really ought to start using open(O_NOATIME) and avoid > > having to "reset" anything in the first place... > > > > > >> So back to systemd: What time stamp does it use for PathChanged=? > >> > > > > Technically none – it watches *inotify* events (all except IN_MODIFY). > > Specifically PathChanged= reacts to: > > > > [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB | > > IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO, > > > > (https://github.com/systemd/systemd/blob/main/src/core/path.c#L37) > > > > So basically a) any kind of rename, delete, attribute change (stuff that > > changes ctime), or b) whenever the file gets *closed* after it has been > > written to (stuff that changes mtime). > > Hi! > > So a unit using PathChanged= is expected to check again what actually has > changed? > Yes, .path units (not unlike .timer units) only activate another unit but can't inform it of *why* it just got activated. > Doesn't really sound like being useful, as must users probably assume that > "Changed" refers to file content change. > Which is what PathChanged= includes. (The difference between PathChanged and PathModified is that the latter triggers immediately for each individual write (IN_MODIFY), while PathChanged delays the trigger until the file is closed. That makes PathModified the less useful one, in most situations.) -- Mantas Mikulėnas
Re: [systemd-devel] Antw: Re: [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
On Thu, Feb 10, 2022 at 3:11 PM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Etienne Champetier schrieb am > 10.02.2022 um > 12:47 in Nachricht > : > > Le jeu. 10 févr. 2022 à 11:49, Ulrich Windl > > a écrit : > >> > >> >>> Lennart Poettering schrieb am 10.02.2022 > um > 11:31 > >> in > >> Nachricht : > >> > On Mi, 09.02.22 22:05, Etienne Champetier ( > champetier.etie...@gmail.com) > >> > wrote: > >> > > >> >> Hello systemd hackers, > >> >> > >> >> After flashing the firmware of some pcie card I need to power cycle > >> >> the server to finish the flashing process. > >> >> For now I have a simple script in lib/systemd/system-shutdown/ > running > >> >> "ipmitool power cycle" but I would like to make sure it runs after > >> >> other scripts like fwupd.shutdown or mdadm.shutdown > >> >> > >> >> Is there any way to have systemd cleanly power cycle my server > instead > >> >> of rebooting it ? > >> > > >> > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't > >> > "systemctl reboot" suffice? > >> > >> My guess is that some smart cards with their own firmware and CPu do not > >> reboot unless they are power cycled, so maybe if the firmware upgrade on > the > >> card does not force it to reboot, it my need a power cycle. > >> > >> > > >> > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS > >> > transitions back into the initrd — the initrd will then detach the > >> > root fs (i.e. undo what it attached at boot) and actually reboot. This > >> > means if your command turns off the power source you should stick it > >> > in the initrd's shutdown logic, and not into > >> > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means > >> > into dracut. But adding it there is something to better discuss with > >> > the dracut community than here. > >> > >> My guess is that it would be handled best by some special GRUB boot > menu > > entry > >> (like "boot 'power cycle' once). > > > > This is pretty clean but it means going through "BIOS" init twice > > which can be pretty long on physical servers > > Hi! > > Of course I have a better solution: Use an external server and just before > restarting send a command to that server that will, after a carefully tuned > delay, will trigger the IPMI power-cycle remotely ;-) > I believe that it's almost impossible to trigger a power cycle through IPMI > while also doing a clean shutdown/reboot, unless the the IPMI features a > delayed execution itself. > Asking the BMC to power the system off is no different than asking the system to power itself off – what makes it a "clean shutdown" is stopping services, syncing and unmounting filesystems, etc. So in theory these shutdown hooks should do the job. Though a better place would be a "shutdown initramfs" which runs from a tmpfs after *all* storage has been unmounted. I think Dracut has that, and explicitly specifies the order for its shutdown hooks, so it should be possible to put ipmitool there. -- Mantas Mikulėnas
[systemd-devel] Antw: Re: [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
>>> Etienne Champetier schrieb am 10.02.2022 um 12:47 in Nachricht : > Le jeu. 10 févr. 2022 à 11:49, Ulrich Windl > a écrit : >> >> >>> Lennart Poettering schrieb am 10.02.2022 um 11:31 >> in >> Nachricht : >> > On Mi, 09.02.22 22:05, Etienne Champetier (champetier.etie...@gmail.com) >> > wrote: >> > >> >> Hello systemd hackers, >> >> >> >> After flashing the firmware of some pcie card I need to power cycle >> >> the server to finish the flashing process. >> >> For now I have a simple script in lib/systemd/system-shutdown/ running >> >> "ipmitool power cycle" but I would like to make sure it runs after >> >> other scripts like fwupd.shutdown or mdadm.shutdown >> >> >> >> Is there any way to have systemd cleanly power cycle my server instead >> >> of rebooting it ? >> > >> > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't >> > "systemctl reboot" suffice? >> >> My guess is that some smart cards with their own firmware and CPu do not >> reboot unless they are power cycled, so maybe if the firmware upgrade on the >> card does not force it to reboot, it my need a power cycle. >> >> > >> > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS >> > transitions back into the initrd — the initrd will then detach the >> > root fs (i.e. undo what it attached at boot) and actually reboot. This >> > means if your command turns off the power source you should stick it >> > in the initrd's shutdown logic, and not into >> > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means >> > into dracut. But adding it there is something to better discuss with >> > the dracut community than here. >> >> My guess is that it would be handled best by some special GRUB boot menu > entry >> (like "boot 'power cycle' once). > > This is pretty clean but it means going through "BIOS" init twice > which can be pretty long on physical servers Hi! Of course I have a better solution: Use an external server and just before restarting send a command to that server that will, after a carefully tuned delay, will trigger the IPMI power-cycle remotely ;-) I believe that it's almost impossible to trigger a power cycle through IPMI while also doing a clean shutdown/reboot, unless the the IPMI features a delayed execution itself. Regards, Ulrich > > Etienne > >> Regards, >> Ulrich >> >> > >> > Lennart >> > >> > -- >> > Lennart Poettering, Berlin
Re: [systemd-devel] Failed to add PIDs to scope's control group: No such process
On Do, 03.02.22 18:39, Gena Makhomed (g...@csdoc.com) wrote: > Hello, All! > > Periodically I see in /var/log/messages error message about > > Failed to add PIDs to scope's control group: No such process > Failed with result 'resources'. > > How I can resolve or workaround this error? It usually just means that the process that makes up a user session dies more quickly than we have time to actually set up the session for it. It's not really a problem, mostly just noise. If this is reproducible on current upstream systemd versions, please file a bug upstream and we can look into fixing this. But fixing would mostly entail to just downgrade logging in this case, i.e. just cosmetically suppressing the noisy logging about this case. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Need a systemd unit example that checks /etc/fstab for modification and sends a text message
On Di, 08.02.22 17:27, Tony Rodriguez (unixpro1...@gmail.com) wrote: > From my understanding, it is frowned by systemd developers to > "automatically" reload systemd via "systemctl daemon-reload" when /etc/fstab > is modified. Guessing this is why such functionality hasn't already been > incorporated into systemd. However, I would like to send a simple text > message. Instructing users to manually invoke "systemctl deamon-reload" > after modifying /etc/fstab via dmesg command or inside /var/log/messages. > > Unsure how to do so inside a systemd UNIT. Will someone please provide an > example how to do so? At least Fedora puts a comment about this in /etc/fstab, explaining the situation. Tht sounds a lot more appropriate to me rather then making this appear in the logs... You can use a PathModified= .path unit for this if you like. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Strange behavior of socket activation units
Hello, Ok thank you for support and I'll figure out. Tuukka Lennart Poettering kirjoitti 10.2.2022 klo 12.50: On Do, 10.02.22 10:09, Tuukka Pasanen (pasanen.tuu...@gmail.com) wrote: Hello, Thank you for your sharp answer. Is there any way to debug what launches these sockets and makes socket activation? these log messages look like they are generated client side. hence figure out where they come from. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
Le jeu. 10 févr. 2022 à 11:49, Ulrich Windl a écrit : > > >>> Lennart Poettering schrieb am 10.02.2022 um 11:31 > in > Nachricht : > > On Mi, 09.02.22 22:05, Etienne Champetier (champetier.etie...@gmail.com) > > wrote: > > > >> Hello systemd hackers, > >> > >> After flashing the firmware of some pcie card I need to power cycle > >> the server to finish the flashing process. > >> For now I have a simple script in lib/systemd/system-shutdown/ running > >> "ipmitool power cycle" but I would like to make sure it runs after > >> other scripts like fwupd.shutdown or mdadm.shutdown > >> > >> Is there any way to have systemd cleanly power cycle my server instead > >> of rebooting it ? > > > > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't > > "systemctl reboot" suffice? > > My guess is that some smart cards with their own firmware and CPu do not > reboot unless they are power cycled, so maybe if the firmware upgrade on the > card does not force it to reboot, it my need a power cycle. > > > > > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS > > transitions back into the initrd — the initrd will then detach the > > root fs (i.e. undo what it attached at boot) and actually reboot. This > > means if your command turns off the power source you should stick it > > in the initrd's shutdown logic, and not into > > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means > > into dracut. But adding it there is something to better discuss with > > the dracut community than here. > > My guess is that it would be handled best by some special GRUB boot menu entry > (like "boot 'power cycle' once). This is pretty clean but it means going through "BIOS" init twice which can be pretty long on physical servers Etienne > Regards, > Ulrich > > > > > Lennart > > > > -- > > Lennart Poettering, Berlin
Re: [systemd-devel] Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
Le jeu. 10 févr. 2022 à 11:31, Lennart Poettering a écrit : > > On Mi, 09.02.22 22:05, Etienne Champetier (champetier.etie...@gmail.com) > wrote: > > > Hello systemd hackers, > > > > After flashing the firmware of some pcie card I need to power cycle > > the server to finish the flashing process. > > For now I have a simple script in lib/systemd/system-shutdown/ running > > "ipmitool power cycle" but I would like to make sure it runs after > > other scripts like fwupd.shutdown or mdadm.shutdown > > > > Is there any way to have systemd cleanly power cycle my server instead > > of rebooting it ? > > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't > "systemctl reboot" suffice? "power cycle" is "power off", wait ~2sec with server turned off, then "power on" During a normal reboot a pcie card still gets power and just receive a reset signal if I understand correctly > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS > transitions back into the initrd — the initrd will then detach the > root fs (i.e. undo what it attached at boot) and actually reboot. This > means if your command turns off the power source you should stick it > in the initrd's shutdown logic, and not into > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means > into dracut. But adding it there is something to better discuss with > the dracut community than here. Thanks for the pointer, I'll look in that direction Etienne > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)
On Thu, Feb 10, 2022 at 12:41 PM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426 > : > 161 : > 60728>: > Mantas Mikulenas schrieb am 10.02.2022 um 10:34 > in > > Nachricht > > : > > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl < > > > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > > > >> Hi! > > >> > > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) > where > > >> smartd is restarted for no obvious reason. Support says everything is > fine, > > >> but I disagree. > > >> Specifically smartd.service uses: > > >> > > >> [Service] > > >> Type=notify > > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts > > >> ExecStart=/usr/sbin/smartd -n $smartd_opts > > >> ExecReload=/bin/kill -HUP $MAINPID > > >> > > >> And mostly I wonder to what types of changes "notify" does react. > > >> > > > > > > None. It's not an activation mechanism and not a configuration > monitoring > > > mechanism – it's a readiness indication mechanism. > > > > > > Type=notify expects the service to send a message to a Unix socket (at > > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some > custom > > > text to show in 'systemctl status'.) > > > > Mantas, > > > > thanks for explaining; obviously I was wrong. But still: How can I find > out > > > why the smartd.service restarts? > > Hi! > > I digged further into it: > smartd_generate_opts.path has: > [Path] > Unit=smartd_generate_opts.service > PathChanged=/etc/sysconfig/smartmontools > > smartd_generate_opts.service has: > [Service] > Type=oneshot > ExecStart=/usr/lib/smartmontools/generate_smartd_opts > > Finally /usr/lib/smartmontools/generate_smartd_opts is not documented. > > But running that program causes a restart of smartd! > I'm not saying this is complete garbage but ugh. At least it doesn't seem to be an upstream thing. > The "Change" date was most likely caused by backup software resetting the > Access time. > The backup software really ought to start using open(O_NOATIME) and avoid having to "reset" anything in the first place... > So back to systemd: What time stamp does it use for PathChanged=? > Technically none – it watches *inotify* events (all except IN_MODIFY). Specifically PathChanged= reacts to: [PATH_CHANGED] = IN_DELETE_SELF | IN_MOVE_SELF | IN_ATTRIB | IN_CLOSE_WRITE | IN_CREATE | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO, (https://github.com/systemd/systemd/blob/main/src/core/path.c#L37) So basically a) any kind of rename, delete, attribute change (stuff that changes ctime), or b) whenever the file gets *closed* after it has been written to (stuff that changes mtime). -- Mantas Mikulėnas
Re: [systemd-devel] systemd-journald namespace persistence
On Mi, 09.02.22 10:18, Roger James (ro...@beardandsandals.co.uk) wrote: > How do I create a persistent systemd-journald namespace? > > I have a backup service that is run by a systemd timer. I would like that to > use it's own namespace. I can create the namespace manually using systemctl > start systemd-journald@mynamespace.service. However I cannot find a way to > do that successfully at boot time. I have tried a RequiredBy and a Requires > in the timer unit but neither seem to work. Not sure I follow? the journald instance sockets should get auto-activated as dependency of your backup service, implicitly, as LogNamespace= side effect. There should be no need to run it all the time. The socket units come with StopWhenUnneeded=yes set, so they automatically go away if no service needs them. Why would you want to run those services continously? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Strange behavior of socket activation units
On Do, 10.02.22 10:09, Tuukka Pasanen (pasanen.tuu...@gmail.com) wrote: > Hello, > > Thank you for your sharp answer. Is there any way to debug what launches > these sockets and makes socket activation? these log messages look like they are generated client side. hence figure out where they come from. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
>>> Lennart Poettering schrieb am 10.02.2022 um 11:31 in Nachricht : > On Mi, 09.02.22 22:05, Etienne Champetier (champetier.etie...@gmail.com) > wrote: > >> Hello systemd hackers, >> >> After flashing the firmware of some pcie card I need to power cycle >> the server to finish the flashing process. >> For now I have a simple script in lib/systemd/system-shutdown/ running >> "ipmitool power cycle" but I would like to make sure it runs after >> other scripts like fwupd.shutdown or mdadm.shutdown >> >> Is there any way to have systemd cleanly power cycle my server instead >> of rebooting it ? > > What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't > "systemctl reboot" suffice? My guess is that some smart cards with their own foirmware and CPu do not reboot unless they are power cycled, so maybe if the firmware upgrade on the card does not force it to reboot, it my need a power cycle. > > /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS > transitions back into the initrd — the initrd will then detach the > root fs (i.e. undo what it attached at boot) and actually reboot. This > means if your command turns off the power source you should stick it > in the initrd's shutdown logic, and not into > /usr/lib/systemd/system-shutdown/. If you are using RHEL this means > into dracut. But adding it there is something to better discuss with > the dracut community than here. My guess is that it would be handled best by some special GRUB boot menu entry (like "boot 'power cycle' once). Regards, Ulrich > > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] mdmon@md127 is stopped early
On Mi, 09.02.22 17:16, Mariusz Tkaczyk (mariusz.tkac...@linux.intel.com) wrote: > It is probably wrong, but it worked this way for many years: > "Again: if your code is being run from the root file system, then this > logic suggested above is NOT for you. Sorry. Talk to us, we can > probably help you to find a different solution to your problem."[3] > > How can I block the service from being stopped? In initramfs there is a > mdmon restart procedure, for example in dracut[4]. I need to save > mdmon process from being stopped. > > I will try to adapt our implementation to your[3] suggestions but it is > longer topic, I want to workaround the issue first. > > [1]https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git > [2]https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd/mdmon@.service So with that unit systemd shouldn#t stop it the service at all, given that you set DefaultDependencies=no. It would be good to figure out why it is stopped anyway. i.e. check with "systemctl show" on the unit what kind of requirement/conflicts deps there are which might explain it. Otherwise there might simply be another program that explicitly tells systemd to shut this stuff down, i.e. some script or so. Turn on debug logging (systemd-analyze log-level debug) before shutting down, the logs should tell you a thing or two about why the service is stopped. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)
>>> Ulrich Windl schrieb am 10.02.2022 um 11:16 in Nachricht <6204E61B.426 : 161 : 60728>: Mantas Mikulenas schrieb am 10.02.2022 um 10:34 in > Nachricht > : > > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl < > > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > >> Hi! > >> > >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) where > >> smartd is restarted for no obvious reason. Support says everything is fine, > >> but I disagree. > >> Specifically smartd.service uses: > >> > >> [Service] > >> Type=notify > >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts > >> ExecStart=/usr/sbin/smartd -n $smartd_opts > >> ExecReload=/bin/kill -HUP $MAINPID > >> > >> And mostly I wonder to what types of changes "notify" does react. > >> > > > > None. It's not an activation mechanism and not a configuration monitoring > > mechanism – it's a readiness indication mechanism. > > > > Type=notify expects the service to send a message to a Unix socket (at > > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some custom > > text to show in 'systemctl status'.) > > Mantas, > > thanks for explaining; obviously I was wrong. But still: How can I find out > why the smartd.service restarts? Hi! I digged further into it: smartd_generate_opts.path has: [Path] Unit=smartd_generate_opts.service PathChanged=/etc/sysconfig/smartmontools smartd_generate_opts.service has: [Service] Type=oneshot ExecStart=/usr/lib/smartmontools/generate_smartd_opts Finally /usr/lib/smartmontools/generate_smartd_opts is not documented. But running that program causes a restart of smartd! h16:~ # stat /etc/sysconfig/smartmontools File: /etc/sysconfig/smartmontools Size: 1377Blocks: 8 IO Block: 4096 regular file Device: 2dh/45d Inode: 92175 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2022-02-10 00:13:44.843774074 +0100 Modify: 2022-01-27 09:19:36.0 +0100 Change: 2022-02-09 00:03:12.774336278 +0100 Birth: 2020-11-27 09:05:09.867171140 +0100 The "Change" date was most likely caused by backup software resetting the Access time. So back to systemd: What time stamp does it use for PathChanged=? (I failed to find documentation in the obvious systemd.* manual pages; whare is it documented?) Regards, Ulrich > > Regards, > Ulrich > > > > > -- > > Mantas Mikulėnas > > > >
Re: [systemd-devel] Run "ipmitool power cycle" after lib/systemd/system-shutdown scripts
On Mi, 09.02.22 22:05, Etienne Champetier (champetier.etie...@gmail.com) wrote: > Hello systemd hackers, > > After flashing the firmware of some pcie card I need to power cycle > the server to finish the flashing process. > For now I have a simple script in lib/systemd/system-shutdown/ running > "ipmitool power cycle" but I would like to make sure it runs after > other scripts like fwupd.shutdown or mdadm.shutdown > > Is there any way to have systemd cleanly power cycle my server instead > of rebooting it ? What does "power cycle" entail that "reboot" doesnt? i.e. why doesn't "systemctl reboot" suffice? /usr/lib/systemd/system-shutdown/ drop-ins are executed before the OS transitions back into the initrd — the initrd will then detach the root fs (i.e. undo what it attached at boot) and actually reboot. This means if your command turns off the power source you should stick it in the initrd's shutdown logic, and not into /usr/lib/systemd/system-shutdown/. If you are using RHEL this means into dracut. But adding it there is something to better discuss with the dracut community than here. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: Help understanding "notify" (SLES15 SP3 restarting smartd)
>>> Mantas Mikulenas schrieb am 10.02.2022 um 10:34 in Nachricht : > On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> Hi! >> >> I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) where >> smartd is restarted for no obvious reason. Support says everything is fine, >> but I disagree. >> Specifically smartd.service uses: >> >> [Service] >> Type=notify >> EnvironmentFile=-/var/lib/smartmontools/smartd_opts >> ExecStart=/usr/sbin/smartd -n $smartd_opts >> ExecReload=/bin/kill -HUP $MAINPID >> >> And mostly I wonder to what types of changes "notify" does react. >> > > None. It's not an activation mechanism and not a configuration monitoring > mechanism – it's a readiness indication mechanism. > > Type=notify expects the service to send a message to a Unix socket (at > $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some custom > text to show in 'systemctl status'.) Mantas, thanks for explaining; obviously I was wrong. But still: How can I find out why the smartd.service restarts? Regards, Ulrich > > -- > Mantas Mikulėnas
Re: [systemd-devel] systemd.sockets vs xinetd
On Do, 10.02.22 08:41, Yolo von BNANA (y...@bnana.de) wrote: > Hello, > > i read the following in an LPIC 1 Book: > > " > If you’ve done any investigation into systemd.sockets, you may believe that > it makes super servers like xinetd obsolete. At this point in time, that is > not true. The xinetd super server offers more functionality than > systemd.sockets can currently deliver. > " > > I thought, that this information could be deprecated. > > Is systemd.sockets at this point in time a good replacement for xined? xinetd supports various things systemd does not: - tcp_wrappers support - implementation of various internal mini-servers, such as RFC868 time server and so on - SUN RPC support - configurable access times - precise configuration of generated log message contents - stream redirection and a couple of other minor things. The first 3 of these are outright obsolete I am sure. We don't implement them for that reason. Instead of configurable access times we allow you to start/stop the socket units individually any time, and you could bind that to a clock on anything else really, it's up to you. I think systemd's logic is vastly more powerful there. For stream redirection we have systemd-socket-proxy, which should be at least as good, but is not implemented in the socket unit logic itself, but as an auxiliary service. So yes, it does some stuff we don't. Are there some people who want those things? I guess there are. But I am also sure that they are either obsolete if you look at the bigger pictue or better ways to do them, which we do support. Or to say this differently: it has been years that anyone filed an RFE bug on systemd github asking for a feature from xinetd that we lack. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Help understanding "notify" (SLES15 SP3 restarting smartd)
On Thu, Feb 10, 2022 at 11:21 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > Hi! > > I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) where > smartd is restarted for no obvious reason. Support says everything is fine, > but I disagree. > Specifically smartd.service uses: > > [Service] > Type=notify > EnvironmentFile=-/var/lib/smartmontools/smartd_opts > ExecStart=/usr/sbin/smartd -n $smartd_opts > ExecReload=/bin/kill -HUP $MAINPID > > And mostly I wonder to what types of changes "notify" does react. > None. It's not an activation mechanism and not a configuration monitoring mechanism – it's a readiness indication mechanism. Type=notify expects the service to send a message to a Unix socket (at $NOTIFY_SOCKET) indicating that it is "ready". (And optionally some custom text to show in 'systemctl status'.) -- Mantas Mikulėnas
[systemd-devel] Help understanding "notify" (SLES15 SP3 restarting smartd)
Hi! I have a support case for SLES15 SP3 (systemd-246.16-7.33.1.x86_64) where smartd is restarted for no obvious reason. Support says everything is fine, but I disagree. Specifically smartd.service uses: [Service] Type=notify EnvironmentFile=-/var/lib/smartmontools/smartd_opts ExecStart=/usr/sbin/smartd -n $smartd_opts ExecReload=/bin/kill -HUP $MAINPID And mostly I wonder to what types of changes "notify" does react. Specifically the smartd_opts was never changed, but stil lsmartd is restarted (by SIGTERM, not SIGHUP, BTW). h16:~ # ll /var/lib/smartmontools/smartd_opts -rw-r--r-- 1 root root 74 Feb 9 00:03 /var/lib/smartmontools/smartd_opts h16:~ # stat /var/lib/smartmontools/smartd_opts File: /var/lib/smartmontools/smartd_opts Size: 74 Blocks: 8 IO Block: 4096 regular file Device: 3ah/58d Inode: 34314 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2022-02-09 11:17:21.464795678 +0100 Modify: 2022-02-09 00:03:12.0 +0100 Change: 2022-02-09 00:05:01.012019105 +0100 Birth: 2020-11-27 09:05:09.871171180 +0100 The file just contains: h16:~ # cat /var/lib/smartmontools/smartd_opts # Generated by /usr/lib/smartmontools/generate_smartd_opts smartd_opts="" -- (Access was the time when I had looked into it) Logs near 00:03:12: Feb 09 00:03:12 h16 systemd[1]: Starting Generate issue file for login session... Feb 09 00:03:12 h16 systemd[1]: Starting Update smartd options... Feb 09 00:03:13 h16 systemd[1]: issue-generator.service: Succeeded. Feb 09 00:03:13 h16 systemd[1]: Finished Generate issue file for login session. Feb 09 00:03:13 h16 smartd[40401]: smartd received signal 15: Terminated Feb 09 00:03:13 h16 systemd[1]: Stopping Self Monitoring and Reporting Technology (SMART) Daemon... Feb 09 00:03:13 h16 smartd[40401]: Device: /dev/bus/0 [megaraid_disk_00] [SAT], state written to /var/lib/smartmontools/smartd... Feb 09 00:03:13 h16 smartd[40401]: Device: /dev/bus/0 [megaraid_disk_01] [SAT], state written to /var/lib/smartmontools/smartd... Feb 09 00:03:13 h16 smartd[40401]: smartd is exiting (exit status 0) Feb 09 00:03:13 h16 systemd[1]: smartd.service: Succeeded. Feb 09 00:03:13 h16 systemd[1]: Stopped Self Monitoring and Reporting Technology (SMART) Daemon. Feb 09 00:03:13 h16 systemd[1]: Starting Self Monitoring and Reporting Technology (SMART) Daemon... Feb 09 00:03:13 h16 smartd[11734]: smartd 7.0 2019-05-21 r4917 [x86_64-linux-5.3.18-150300.59.43-default] (SUSE RPM) Logs near 00:05:01: Feb 09 00:01:23 h16 systemd[1]: Started DATA-PROTECTOR-INET (172.20.16.3:44300). ... Feb 09 00:05:11 h16 systemd[1]: omni@168-172.20.16.16:-172.20.16.3:44300.service: Succeeded. So out backup software was active in that interval, and one feature it has is to reset the access times of the files. (In the past that feature also has ruined SUSE's cron.daily jonbs as they were querying the wrong timestamp, but refused to fix it) Regards, Ulrich
Re: [systemd-devel] systemd.sockets vs xinetd
On Thu, 10 Feb 2022, Yolo von BNANA wrote: > Hello, > > i read the following in an LPIC 1 Book: > > " If you’ve done any investigation into systemd.sockets, you may believe > that it makes super servers like xinetd obsolete. At this point in time, > that is not true. The xinetd super server offers more functionality than > systemd.sockets can currently deliver. " > > I thought, that this information could be deprecated. > > Is systemd.sockets at this point in time a good replacement for xined? > > Is there a good resource to dive deeper into it? > > > Yolo Surely it would be up to the author of that book to justify that claim? They say it "offers more functionality". Do they say anything more than that... like precisely what functionality they're talking about?
Re: [systemd-devel] Strange behavior of socket activation units
Hello, Thank you for your sharp answer. Is there any way to debug what launches these sockets and makes socket activation? Tuukka Lennart Poettering kirjoitti 7.2.2022 klo 14.40: My educated guess is that some script specific to mariadb in debian assumes that you only run templated instances of mariadb, and if you don#t things break. Plese work with the mariadb people at Debian to figure this out, there's nothing much we can do from systemd upstream about that. Lennart -- Lennart Poettering, Berlin
