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.
