On Mon, Mar 28, 2016 at 9:45 PM, John <[email protected]> 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 <[email protected]>
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
