On a clean v9.4 install with a trivial background process running that ignores signals- Rebooting would display a stop job which is in progress (for the mentioned process as expected) with no limits, yet running sudo systemctl show --all shows that DefaultTimeoutStopUSec=1min 30s
This doesn’t seem to be correct. Is there something I might be missing here?
Those settings do not apply to services with Type=oneshot. Might this be the case?
I’ve tried this again with a type=simple service and I’m still getting the same result:
The service file at /etc/systemd/system/ is as follows:
[Unit]
Description=Dummy Service that only waits for 60s
After=default.target
[Service]
Type=simple
ExecStart=/usr/local/bin/dummy
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
Did you reload the configuration with systemctl daemon-reload after you made changes? Somehow the process seems to keep hanging. Maybe check if the process is in an uninterruptible sleep (does not react to any signals).
ps aux | grep ' D '
or maybe increasing the LogLevel for systemd in /etc/systemd/system.conf will tell us some more:
[Manager]
LogLevel=debug
Yep, have made sure to reload after changes.
I’ve purposely written the service to ignore signals so I could see the stop job messages on shutdown- I am concerned with why the stop job always shows “no limit” even when a limit has been configured.
I initially noticed this issue through occasionaly seeing other services take a while longer than usual and display these stop messages with no limits. To create an easily reproducable example, I wrote this dummy service that ignores all SIGKILL and SIGTERM signals for 60 seconds.
My assumption is that on a clean Rocky build, systemd should display a finite limit on the stop job, especially since it is configured as such.
Okay, now I get it. I was able to reproduce it.
The correct timeout settings are being applied, though. Even if set in the unit file itself, it times out correctly, but no matter what, it shows ‘no limit’.
So are you saying it’s working correctly behind the scenes, but the message showing on the screen is wrong?
Yes, that is correct. I just reported it on the bug tracker:
https://bugs.rockylinux.org/view.php?id=7393
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.