Hello David. On Tue, Aug 11, 2020 at 02:33:11PM +1200, David Cunningham <dcunningham@xxxxxxxxxxxxx> wrote: > The problem is most likely with systemd thinking the program is stopped > because "systemctl status" reports: > Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Main process > exited, code=exited, status=1/FAILURE > Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Failed with > result 'exit-code'. This means there is a mismatch between what the service considers its man PID (17824) and what systemd tracks -- the tracked process apparently terminated with failure exit code. > 1:name=systemd:/user.slice/user-0.slice/session-623.scope > 0::/user.slice/user-0.slice/session-623.scope This suggests that the alleged main process (from PID file) was migrated out of the service's cgroup into session scope (pam_systemd, this can happen when daemon would switch uid calling into PAM, such as with su(do).) or it was started directly in the user session. My suggestion is to check whether MainPID (next time please share full `systemctl status output`) matches the contents of your PID file (while the service is "stoppable" and afterwards). Second, it's worth reviewing what happens around the time when the "Main process exited" message appears (you can increase PID 1 verbosity `systemd-analyze set-log-level debug` in order to rule out systemd issue). One idea is that someone starts another service instance from their user session which breaks the original instance and the new one is not tracked by systemd. HTH, Michal
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
