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

[Mantas Mikulėnas]

On Mon, Mar 28, 2016 at 9:45 PM, 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
>

Those actually look like typical permissions that a /dev/tty* device would
have, so my guess would be that xinit (or something) first sets its stdout
to g-w (0600) on startup, to avoid being disturbed, and later tries to set
it back to g+w (0620) without actually checking whether its stdout is still
a tty...

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160329/66652424/attachment.html>