3

Details

We have a systemd service file with the following pertinent directives: Type=forking User=me Restart=always

The WantedBy directive is currently not set.

We have a cron job that executes su –l me –c '<some command>'.

Preconditions

We noticed that given:

  • The service is started
  • The user me is not logged into the system

Observations

Everytime the cron job finishes executing, the System V IPC queues disappears and the service restarts since the processes reading/sleeping on the queues wake up to find the queues are gone and hence enter a failed state.

After the cron job finishes we noticed the following in the syslog:
… systemd[1]: Stopped User Manager for UID XXX

Possible Solution

We installed a file such that:

$ cat /etc/systemd/logind.conf.d/my-service.conf
[Login]
KillUserProcesses=no
RemoveIPC=no

Question

After reading systemd changelog for changes with 230, we are still confused if our Possible Solution mentioned above is enough.

We are confused in particular about the additional steps are necessary to allow intentionally long-running processes to survive logout.

The services parent as reported by systemd-cgls is system.slice so that makes us believe the prescribed step to start the service using systemd-run does not apply here - is this true? We are currently starting the service with systemctl start my-service.service

Would we still need to enable lingering for the user me?

Thanks for help.

1 Answer 1

2

You shouldn't even need KillUserProcesses=no. RemoveIPC=no should be sufficient.

Enabling lingering for the user me would be an alternative to that. It would differ in that it would leave a systemd --user instance running all the time.

This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout.

What the quote means is that "additional steps" are necessary to allow e.g. GNU Screen to continue running after logout, if and only if KillUserProcesses=yes. The additional steps are basically systemd-run --user --scope COMMAND, AND enabling lingering.

This is not related to your desire. Because your service process does not run within a login session.

Your conclusion from looking at systemd-cgls is exactly correct.


An alternative would be to never log in as the user me. su counts as a login. User crontabs potentially count as a log in (unless /etc/pam.d/cron avoids invoking pam_systemd, directly or indirectly). For example you can replace your use of su with setpriv, or instead of cron use a systemd timer unit which starts a oneshot service which has User=me.

2
  • Thanks for this. The command loginctl enable-linger <user-id> was enough to prevent systemd from cleaning up some symlinks to the host that were setup inside a container using a startup script. Commented Feb 16 at 8:37
  • Important to note that linger must be enabled for each user's session files you wish to retain. For example if you enable it for alice, systemd is still going to cleanup the session files for user bob and everyone else who's not alice Commented Feb 16 at 8:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .