Bug#914319: kodi: stale process on kodi crash
Hi Ritesh,
Ritesh Raj Sarraf <rrs@debian.org> ezt írta (időpont: 2018. nov. 22., Cs, 6:54):
>
> Package: kodi
> Version: 2:17.6+dfsg1-4
> Severity: important
>
> Thank you for continuing to maintain Kodi. Hopefully, now that I've
> switched to the Debian one, I'll have some time to help.
>
> Meanwhile, here's something I noticed:
>
> rrs@lenovo:~$ ps aux | grep kodi
> root 25312 0.0 0.1 75284 13316 ? S 10:41 0:00 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-auth7a7c9e75-6afb-4ff5-969a-0aef94e4f40d --id 1 --start kodi-standalone --user rrs --autologin
> rrs 25315 0.0 0.0 2372 760 ? S 10:41 0:00 /bin/sh /usr/bin/kodi-standalone
> rrs 25354 0.0 0.0 5832 472 ? Ss 10:41 0:00 /usr/bin/ssh-agent kodi-standalone
> rrs 25358 0.0 0.0 2372 700 ? S 10:41 0:00 /bin/sh /usr/bin/kodi --standalone
> rrs 25360 11.3 3.9 2949992 318956 ? SLl 10:41 3:18 /usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalone
> rrs 28485 0.0 0.0 4764 940 pts/0 S+ 11:10 0:00 grep --color=auto kodi
> 11:10 ♒♒♒
>
>
>
>
> Nov 22 10:40:54 lenovo sddm[24877]: Message received from greeter: Connect
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Loading file:///usr/share/sddm/themes/debian-theme/Main.qml...
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Adding view for "eDP-1" QRect(0,0 1920x1080)
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Loading file:///usr/share/sddm/themes/debian-theme/Main.qml...
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Adding view for "HDMI-1" QRect(1920,0 1920x1080)
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Message received from daemon: Capabilities
> Nov 22 10:40:54 lenovo sddm-greeter[25128]: Message received from daemon: HostName
> Nov 22 10:41:04 lenovo kernel: kodi.bin[25043]: segfault at 0 ip 0000000000000000 sp 00007ffd1c3fd308 error 14 in kodi.bin[557762719000+43b000]
> Nov 22 10:41:04 lenovo kernel: Code: Bad RIP value.
> Nov 22 10:41:04 lenovo systemd[1]: Started Process Core Dump (PID 25157/UID 0).
> Nov 22 10:41:04 lenovo kernel: kodi.bin[24958]: segfault at 0 ip 0000000000000000 sp 00007ffd2e5b0578 error 14 in kodi.bin[55aaf6870000+43b000]
> Nov 22 10:41:04 lenovo kernel: Code: Bad RIP value.
> Nov 22 10:41:04 lenovo systemd[1]: Started Process Core Dump (PID 25159/UID 0).
> Nov 22 10:41:07 lenovo systemd-coredump[25158]: Process 25043 (kodi.bin) of user 1000 dumped core.
>
> Stack trace of thread 25043:
> #0 0x0000000000000000 n/a (n/a)
> Nov 22 10:41:07 lenovo systemd-coredump[25160]: Process 24958 (kodi.bin) of user 1000 dumped core.
>
> Stack trace of thread 24958:
> #0 0x0000000000000000 n/a (n/a)
> Nov 22 10:41:10 lenovo systemd-logind[24616]: Removed session 1.
> Nov 22 10:41:25 lenovo polkitd(authority=local)[11874]: Registered Authentication Agent for unix-process:25280:144345 (system bus name :1.375 [/usr
> Nov 22 10:41:26 lenovo polkitd(authority=local)[11874]: Operator of unix-process:25280:144345 successfully authenticated as unix-user:rrs to gain O
> Nov 22 10:41:26 lenovo sddm[24877]: Signal received: SIGTERM
> Nov 22 10:41:26 lenovo systemd[1]: Stopping Simple Desktop Display Manager...
> Nov 22 10:41:26 lenovo sddm-greeter[25128]: The X11 connection broke (error 1). Did the X11 server die?
> Nov 22 10:41:26 lenovo sddm[24877]: Greeter stopping...
> Nov 22 10:41:26 lenovo sddm[24877]: Socket server stopping...
> Nov 22 10:41:26 lenovo sddm[24877]: Socket server stopped.
> Nov 22 10:41:26 lenovo sddm[24877]: Display server stopping...
> Nov 22 10:41:26 lenovo sddm-helper[25113]: [PAM] Closing session
> Nov 22 10:41:26 lenovo sddm-helper[25113]: pam_unix(sddm-greeter:session): session closed for user sddm
> Nov 22 10:41:26 lenovo sddm-helper[25113]: [PAM] Ended.
> Nov 22 10:41:26 lenovo systemd-logind[24616]: Session 7 logged out. Waiting for processes to exit.
> Nov 22 10:41:26 lenovo systemd-logind[24616]: Removed session 7.
> Nov 22 10:41:26 lenovo systemd[1]: user-runtime-dir@129.service: Unit not needed anymore. Stopping.
> Nov 22 10:41:26 lenovo systemd[1]: Stopping User Manager for UID 129...
>
> The recommendation been made is to not use kodi through any systemd
> service script. Instead, users are recommended to setup an autologin
> mechanism with a window manager of their choice, and then autostart
> kodi. This works fine in an ideal world.
>
> But, in cases where kodi crashes, it leaves stray processes behind. Then
> a respawn of new kodi instance ends up having conflicts because part
> process from the previous invocation is still occupying services, like
> 8080 and 9090.
>
> Why are you recommending against the systemd service approach ? IIRC,
> when I had set it up on my RPi, the systemd slice would reliably clean
> all leftover processes when there was a crash.
The reason was detailed in debian/NEWS a bit:
kodi (2:17.6+dfsg1-2) unstable; urgency=medium
For a period of time it was recommended to start Kodi as a systemd
service, but upstream does not recommend that [1] anymore. The
recommended method now is setting up a lightweight display manager
to log in a user automatically and starting kodi in the user's session.
The kodi package shipped kodi.service as a disabled systemd service
as a starting point for users to set up Kodi to run in standalone mode
but the service file is not shipped anymore following the change in
upstream's recommendation. If you enabled the service and used it for
running Kodi please switch to starting it from a user session or
install the service file from any other source.
[1] https://kodi.wiki/view/HOW-TO:HOW-TO:Autostart_Kodi_for_Linux
-- Balint Reczey <rbalint@ubuntu.com> Sat, 28 Apr 2018 20:53:08 +0200
The funny part is that since then upstream started documenting the
standalone way, too:
https://kodi.wiki/index.php?title=HOW-TO:HOW-TO:Autostart_Kodi_for_Linux&offset=20180426031518&action=history
It is a bug that stale processes are left behind. It should be fixed
and I believe with that fixed the recommendation is sound because
setting up the service is more complicated and works with X11 and not
with Wayland which Debian and others seem to prefer going forward.
BTWS Kodi 18.1 is ready for being uploaded but it waits for the
flatbuffers package to appear in the archive first, see #926922.
Cheers,
Balint
Reply to: