[systemd-devel] No signal sent to stop service

Michal Koutný mkoutny at suse.com
Thu Aug 13 09:54:34 UTC 2020


Hello David.

On Tue, Aug 11, 2020 at 02:33:11PM +1200, David Cunningham <dcunningham at voisonics.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200813/d942fd0e/attachment.sig>


More information about the systemd-devel mailing list