[systemd-devel] Input on a systemd service for kodi and strangeness with permissions on /dev/null (systemd 229)

[Lennart Poettering]

On Mon, 28.03.16 18:45, John (da_audiophile at yahoo.com) wrote:

> I am trying to write a service that will start and stop kodi[1] on Linux.  The best working draft I have so far is here[2] but it does not end in a clean state if I `systemctl stop kodi` so I am looking for a good way to use an ExecStop= statement or perhaps even rewrite the service entirely.
> 
> Attached is the output of a `systemctl stop kodi` to illustrate:
> 
> % journalctl -b -u kodi
> -- Logs begin at Sun 2016-03-20 16:00:01 EDT, end at Mon 2016-03-28 10:47:39 EDT. --
> Mar 28 10:46:21 ruby systemd[1]: Started Starts instance of Kodi using xinit.
> Mar 28 10:46:21 ruby systemd[572]: pam_unix(login:session): session opened for user kodi by (uid=0)
> Mar 28 10:47:20 ruby systemd[1]: Stopping Starts instance of Kodi using xinit...
> Mar 28 10:47:20 ruby systemd[733]: pam_unix(login:session): session opened for user kodi by (uid=0)
> Mar 28 10:47:20 ruby systemd[733]: pam_systemd(login:session): Cannot create session: Already occupied by a session
> Mar 28 10:47:20 ruby systemd[1]: kodi.service: Control process exited, code=exited status=1
> Mar 28 10:47:21 ruby systemd[1]: kodi.service: Main process exited, code=exited, status=1/FAILURE
> Mar 28 10:47:21 ruby systemd[1]: Stopped Starts instance of Kodi using xinit.
> Mar 28 10:47:21 ruby systemd[1]: kodi.service: Unit entered failed state.
> Mar 28 10:47:21 ruby systemd[1]: kodi.service: Failed with result 'exit-code'.
> 
> Interestingly, if I add the following line, the service does stop cleanly but the permissions on /dev/null gets screwed-up: ExecStop=/usr/bin/pkill kodi
> 
> Before I stop the service:
> % ls -lh /dev/null
> crw-rw-rw- 1 root root 1, 3 Mar 28 14:20 /dev/null
> 
> After I stop the service:
> % ls -lh /dev/null
> crw--w---- 1 kodi root 1, 3 Mar 28 14:20 /dev/null
> 
> Suggestions are welcomed.  Thank you in advance.

I don't see how systemd could be responsible for the chmod... Consider
running "strace -f -p 1 -e fork,execve,chmod,open,close,fchmod" or so, to see
where chmod is called, and which process might be the one that invokes
chmod() or fchmod() on the /dev/null device node.

Lennart

-- 
Lennart Poettering, Red Hat