Why does exiting this systemd service result in an error code?

graysky · 2016-03-28 12:25:11

I "forked" the kodi systemd service back when it was removed from [community]. It works fine, but I have noticed that when one stops the service, then queries the service status, systemd shows it in a failed state. Why? If this is the result of killing xinit (ie expected) is there a better way to call the /usr/bin/kodi-standalone?

Link to the service file itself. Thanks!

Example showing error code:

● kodi.service - Starts instance of Kodi using xinit
   Loaded: loaded (/usr/lib/systemd/system/kodi.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2016-03-28 08:23:05 EDT; 1min 2s ago
  Process: 565 ExecStart=/usr/bin/xinit /usr/bin/dbus-launch --exit-with-session /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7 (code=exited, status=1/FAILURE)
 Main PID: 565 (code=exited, status=1/FAILURE)

Mar 28 08:22:45 ruby systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 08:22:46 ruby systemd[565]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 08:23:04 ruby systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 08:23:05 ruby systemd[1]: kodi.service: Main process exited, code=exited, status=1/FAILURE
Mar 28 08:23:05 ruby systemd[1]: Stopped Starts instance of Kodi using xinit.
Mar 28 08:23:05 ruby systemd[1]: kodi.service: Unit entered failed state.
Mar 28 08:23:05 ruby systemd[1]: kodi.service: Failed with result 'exit-code'.

Trilby · 2016-03-28 12:59:41

You don't have an ExecStop line, add one. Without the ExecStop, only SIGTERM (and then SIGHUP and SIGKILL) signals are sent: x clients generally do not respond to these signals.

graysky · 2016-03-28 13:21:56

Interesting idea... I didn't see anything in `man xinit` that suggests a call to /usr/bin/xinit to stop a running process. Am I interpreting your suggestion too literally?

EDIT: I did find [extra]/xorg-xkill but per it's man page:

Xkill is a utility for forcing the X server to close connections to clients. This program is very dangerous...

Last edited by graysky (2016-03-28 13:25:07)

Trilby · 2016-03-28 14:19:06

No you can't use xinit for this. You need to cleanly exit Kodi. Xkill would be one way of doing this: use xkill to exit Kodi, not xinit. Xinit will then exit successfully as its only client completed. You can see this thread for some details and alternatives.

graysky · 2016-03-28 14:48:32

Thanks for the tip and link. I read through it and it would seem that code you posted to github is not needed if one simply called `xkill -all` if I read and understood that correctly. I modified the service with 'ExecStop=/usr/bin/xkill -a' but after a `systemctl daemon-reload` I am finding that the modified service still ends with an error state. What am I missing?

% 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'.

EDIT: I also tried using your code in an ExecStop line but found the same unclean exit

% journalctl -b -u kodi
-- Logs begin at Sun 2016-03-20 16:00:01 EDT, end at Mon 2016-03-28 11:11:32 EDT. --
Mar 28 11:10:23 quartz systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 11:10:23 quartz systemd[584]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 11:11:04 quartz systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 11:11:04 quartz systemd[744]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 11:11:04 quartz systemd[744]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Mar 28 11:11:04 quartz systemd[746]: pam_unix(login:session): session closed for user kodi
Mar 28 11:11:04 quartz systemd[1]: kodi.service: Control process exited, code=exited status=1
Mar 28 11:11:05 quartz systemd[1]: kodi.service: Main process exited, code=exited, status=1/FAILURE
Mar 28 11:11:05 quartz systemd[1]: Stopped Starts instance of Kodi using xinit.
Mar 28 11:11:05 quartz systemd[1]: kodi.service: Unit entered failed state.
Mar 28 11:11:05 quartz systemd[1]: kodi.service: Failed with result 'exit-code'.

EDIT2: I think I stumbled upon the solution to a clean exit:

1) Remove Type=Simple
2) Add ExecStop=/usr/bin/pkill kodi.bin

Now...

% journalctl -b -u kodi
-- Logs begin at Sun 2016-03-20 16:00:01 EDT, end at Mon 2016-03-28 11:36:27 EDT. --
Mar 28 11:33:35 quartz systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 11:33:35 quartz systemd[575]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 11:34:15 quartz systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 11:34:15 quartz systemd[788]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 11:34:15 quartz systemd[788]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Mar 28 11:34:16 quartz systemd[1]: Stopped Starts instance of Kodi using xinit.

Last edited by graysky (2016-03-28 15:48:54)

graysky · 2016-03-28 15:47:32

Grrr... seemingly solving one problem has created another problem. When I use the attached kodi.service, I can stop it and have it end in a 0 exit code BUT doing so has created a problem: I can't access /dev/null or so my shell informs me upon an ssh connection:

% ssh quartz
Last login: Mon Mar 28 11:45:59 2016 from 10.1.10.3
-bash: /dev/null: Permission denied

Autojump fails throwing errors related to /dev/null permissions as well. WTF

Trilby · 2016-03-28 16:34:58

Ah, xkill likely wouldn't work as-is as it needs - at very least - to be passed the proper DISPLAY variable.

If there isn't a way to request kodi to exit, I'd make a separate script to do this. For example, make an xinitrc that uses 'trap' to listen for a SIGTERM, then on SIGTERM runs xkill -a. But this is all really assuming there is a problem to the failed exit state. If you shutdown x clients via SIGTERM/SIGKILL then it is expected that the exit code will not be 0.

graysky · 2016-03-28 18:05:16

@Trilby - Thanks for the advice. Do you think the access problems to /dev/null is a bug?

Before:

% ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 28 13:58 /dev/null

And after

% ls -lh /dev/null
crw--w---- 1 kodi root 1, 3 Mar 28 12:05 /dev/null

How in the world should stopping the service file modify /dev/null permissions?

Last edited by graysky (2016-03-28 19:02:37)

Trilby · 2016-03-28 18:32:07

I really don't know how that could happen. I don't know anything about Kodi, does it perhaps chown /dev/null while it is running and reset the ownership upon a proper exit? This strikes me as absolutely horrible behavior, but I don't have any experience with Kodi - it shouldn't be able to chown/chmod /dev/null unless run as root.

FWIW, pkill will do no better than systemd's defualt. Pkill does not send X11 messages to xclients, it only sends SIGTERM which systemd already was doing. The problem is that Kodi (it would seem) doesn't respond to SIGTERM.

graysky · 2016-03-28 18:46:50

Thanks for the help. This is beyond me, let's see if the experts can help.

graysky · 2016-03-28 19:04:45

Trilby wrote:

FWIW, pkill will do no better than systemd's defualt. Pkill does not send X11 messages to xclients, it only sends SIGTERM which systemd already was doing. The problem is that Kodi (it would seem) doesn't respond to SIGTERM.

Well, if that is true, I cannot explain why, with the pkill in ExecStop=, it does in fact end with a 0 exit code (albeit screwing up /dev/null):

% journalctl -b -u  kodi
-- Logs begin at Sun 2016-03-20 16:00:01 EDT, end at Mon 2016-03-28 15:03:01 EDT. --
Mar 28 14:46:23 ruby systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 14:46:23 ruby systemd[574]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 15:02:58 ruby systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 15:02:58 ruby systemd[764]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 15:02:58 ruby systemd[764]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Mar 28 15:02:59 ruby systemd[1]: Stopped Starts instance of Kodi using xinit.

And

● kodi.service - Starts instance of Kodi using xinit
   Loaded: loaded (/usr/lib/systemd/system/kodi.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2016-03-28 15:02:59 EDT; 1min 37s ago
  Process: 764 ExecStop=/usr/bin/pkill kodi (code=exited, status=0/SUCCESS)
 Main PID: 574 (code=exited, status=0/SUCCESS)

Mar 28 14:46:23 ruby systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 14:46:23 ruby systemd[574]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 15:02:58 ruby systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 15:02:58 ruby systemd[764]: pam_unix(login:session): session opened for user kodi by (uid=0)
Mar 28 15:02:58 ruby systemd[764]: pam_systemd(login:session): Cannot create session: Already occupied by a session
Mar 28 15:02:59 ruby systemd[1]: Stopped Starts instance of Kodi using xinit.

Last edited by graysky (2016-03-28 19:05:06)

Trilby · 2016-03-28 21:10:59

graysky wrote:

Well, if that is true, I cannot explain why, with the pkill in ExecStop=, it does in fact end with a 0 exit code

I could speculate (wildly) that the final exit code is actually from the last Exec, so if pkill as ExecStop ran successfully, then the exit code is zero. Xkill could not run successfully without the proper DISPLAY variable.

graysky · 2016-03-28 22:06:04

Yes, but this is pkill not xkill

Trilby · 2016-03-28 22:29:48

Yes, and from what you describe pkill exits with 0 and xkill does not.

graysky · 2016-03-28 22:33:03

If I kill something that isn't running it throws a non-0 code:

% pkill foo
% echo $?
1

Trilby · 2016-03-28 23:06:06

But you didn't kill something that wasn't running, you killed something that was running.

Arch Linux

#1 2016-03-28 12:25:11

Why does exiting this systemd service result in an error code?

#2 2016-03-28 12:59:41

Re: Why does exiting this systemd service result in an error code?

#3 2016-03-28 13:21:56

Re: Why does exiting this systemd service result in an error code?

#4 2016-03-28 14:19:06

Re: Why does exiting this systemd service result in an error code?

#5 2016-03-28 14:48:32

Re: Why does exiting this systemd service result in an error code?

#6 2016-03-28 15:47:32

Re: Why does exiting this systemd service result in an error code?

#7 2016-03-28 16:34:58

Re: Why does exiting this systemd service result in an error code?

#8 2016-03-28 18:05:16

Re: Why does exiting this systemd service result in an error code?

#9 2016-03-28 18:32:07

Re: Why does exiting this systemd service result in an error code?

#10 2016-03-28 18:46:50

Re: Why does exiting this systemd service result in an error code?

#11 2016-03-28 19:04:45

Re: Why does exiting this systemd service result in an error code?

#12 2016-03-28 21:10:59

Re: Why does exiting this systemd service result in an error code?

#13 2016-03-28 22:06:04

Re: Why does exiting this systemd service result in an error code?

#14 2016-03-28 22:29:48

Re: Why does exiting this systemd service result in an error code?

#15 2016-03-28 22:33:03

Re: Why does exiting this systemd service result in an error code?

#16 2016-03-28 23:06:06

Re: Why does exiting this systemd service result in an error code?

Board footer