Re: need for open-minded help with popularity-contest with systemd timer
alimiracle <[email protected]> Sun, 26 Jul 2026 10:51:15 -0700
| Newsgroups | gmane.linux.debian.devel.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------DA06FWgn6DPDJ4d88rrMlgXV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On Mon, Jul 27, 2026 at 12:34:23AM +0900, Simon Richter wrote: > Systemd explicitly does not want to follow Unix semantics, so we cannot > assume that Unix semantics will hold unless there is an explicit > mechanism for them, and we are seeing breakage precisely where we're > using a Unix tool inside a non-Unix environment. Another possibility would be to use an init-inside-init approach. In other words, let systemd start a small init wrapper, and have that wrapper launch and supervise the actual service. That way, systemd remains the system's init process, but the service itself follows traditional Unix init semantics. Child processes can outlive the original process when appropriate, without depending on systemd-specific cgroup behavior or options such as `TimeoutStopSec=`. This might provide better compatibility for software that was originally designed with classic Unix process management in mind. على 7/26/2026 9:36 AM، كتب Florian Lohoff: > On Mon, Jul 27, 2026 at 12:34:23AM +0900, Simon Richter wrote: >> Systemd explicitly does not want to follow Unix semantics, so we >> cannot assume that Unix semantics will hold unless there is an >> explicit mechanism for them, and we are seeing breakage precisely >> where we're using a Unix tool inside a non-Unix environment. > > It changes the semantics but the creator of the unit chooses how > hardened it should be. > > I do have had the same issues with uucico calling systemd. uucico > spawns uuxqt which may linger around processing jobs. Strict > systemd kills all uuxqt when all data has been transferred. > > Solved it by giving uuxqt more time to finish its job: > > TimeoutStopSec=120s > > I remember having a different solution by instructing systemd to not > kill the whole cgroup when the main process exits, so basically > going back to "good ol days" in not cleaning up behind the job. > > Flo > -- > Florian Lohoff [email protected] > Any sufficiently advanced technology is indistinguishable from magic. --------------DA06FWgn6DPDJ4d88rrMlgXV Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>On Mon, Jul 27, 2026 at 12:34:23AM +0900, Simon Richter wrote:<br> <br> > Systemd explicitly does not want to follow Unix semantics, so we cannot<br> > assume that Unix semantics will hold unless there is an explicit<br> > mechanism for them, and we are seeing breakage precisely where we're<br> > using a Unix tool inside a non-Unix environment.<br> <br> Another possibility would be to use an init-inside-init approach. In other words, let systemd start a small init wrapper, and have that wrapper launch and supervise the actual service.<br> <br> That way, systemd remains the system's init process, but the service itself follows traditional Unix init semantics. Child processes can outlive the original process when appropriate, without depending on systemd-specific cgroup behavior or options such as `TimeoutStopSec=`.<br> <br> This might provide better compatibility for software that was originally designed with classic Unix process management in mind.<br> <br> </p> <div class="moz-cite-prefix">على 7/26/2026 9:36 AM، كتب Florian Lohoff:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-western">On Mon, Jul 27, 2026 at 12:34:23AM +0900, Simon Richter wrote: <br> <blockquote type="cite" style="color: #007cff;">Systemd explicitly does not want to follow Unix semantics, so we cannot assume that Unix semantics will hold unless there is an explicit mechanism for them, and we are seeing breakage precisely where we're using a Unix tool inside a non-Unix environment. <br> </blockquote> <br> It changes the semantics but the creator of the unit chooses how <br> hardened it should be. <br> <br> I do have had the same issues with uucico calling systemd. uucico <br> spawns uuxqt which may linger around processing jobs. Strict <br> systemd kills all uuxqt when all data has been transferred. <br> <br> Solved it by giving uuxqt more time to finish its job: <br> <br> TimeoutStopSec=120s <br> <br> I remember having a different solution by instructing systemd to not kill the whole cgroup when the main process exits, so basically <br> going back to "good ol days" in not cleaning up behind the job. <br> <br> Flo <br> <div class="moz-txt-sig"><span class="moz-txt-tag">-- <br> </span>Florian Lohoff <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a> <br> Any sufficiently advanced technology is indistinguishable from magic. <br> </div> </div> </blockquote> </body> </html> --------------DA06FWgn6DPDJ4d88rrMlgXV--