Why is the kodi user now always in the "input" group? about kodi-standalone-service HOT 15 CLOSED

After having a look at the AUR comments I guess this is a cause of the switch away from a proper user session.

I'm starting to doubt that this actually was a good idea. Did you ever try if automounting of an USB hard drive still works? With an user session this worked flawlessly.

The problem does not occur when shutting down from the Kodi "Power menu", right? If so, I guess I'll create a fork from the last state which still used a user session.

from kodi-standalone-service.

Staying out of the user.slice is needed to avoid data lost on reboot/shutdown. See my commit comments here: 34515c3

I need to review the requirements for group membership, but I believe it's need for mouse support possibly keyboard? I am unfamiliar with how cage (wayland) works so this would require empirical testing unless I can find some documentation that spells it out clearly.

I have not tried automounting a USB device. Never had a use case for this. Based on your question and comment, it sounds like you have. Can you please try and let me know if it works, also let me know which kodi-xxx.service you're using.

The shutdown menu missing 'reboot' and 'shutdown' is solved by polkit rules. Are you experiencing this with them installed?

from kodi-standalone-service.

I'm still on a setup with user.slice where everything works as expected.

The issue about reboot/shutdown only happens if manually shutting down from shell, right? If so, I don't think that this is a too big problem. Most users with fullscreen Kodi will shut down from the Kodi menu.

What I tried to say is that I doubt that it really is worth all the hacks just to work around a properly created user shell. If I have open documents on my Linux desktop and call "sudo poweroff", then I loose my work, too. IMHO everything is nice as long as things work well when shutting down from the Kodi Power menu.

from kodi-standalone-service.

I in my case, I routinely reboot/shutdown that box from the shell. I haven't tested from the kodi menu but if it's going through systemd, the same problem would occur unless kodi writes out all its data and then calls systemd.

from kodi-standalone-service.

Actually I hope so and it is very likely as I never had problems so far. For me kodi-standalone-service is a tool to start Kodi fullscreen on my HTPC. I don't access it via SSH that often and if I do, I usually don't do any setting changes in Kodi while being logged in via SSH, so a "hard shutdown" would not erase any work.

But maybe it's better to have a look at the sourcecode at some time to find out if Kodi handles this properly. If it doesn't, then shutdown will also be problematic if using Kodi using the X session and a desktop manager. Or in other words: If Kodi doesn't do this, then config saving should have never worked.

IMHO Kodi is similar to a Desktop setup. If I do some work on Linux Desktop machine, don't save it and SSH into this box and run "systemctl reboot", then nothing stops systemd from killing my work. This is expected behavior in my opinion.

from kodi-standalone-service.

https://forum.kodi.tv/showthread.php?tid=359559

from kodi-standalone-service.

Actually I never get through to "XBApplicationEx: application stopped!".
Not with the "user session based" kodi-standalone-service but also not with lightdm as a desktop manager, which, as far as I know, is a recommended way to autostart Kodi.

from kodi-standalone-service.

Here is what a graceful kodi.log looks like when you systemctl stop kodi-x11 and it exits in a clean state:

...
2021-01-03 08:33:16.576 T:695      INFO <general>: Quitting due to POSIX signal
2021-01-03 08:33:16.616 T:695      INFO <general>: Stopping player
2021-01-03 08:33:16.616 T:695      INFO <general>: Storing total System Uptime
2021-01-03 08:33:16.616 T:695      INFO <general>: Saving settings
2021-01-03 08:33:16.622 T:695      INFO <general>: Saving skin settings
2021-01-03 08:33:16.623 T:695      INFO <general>: Stopping all
2021-01-03 08:33:16.623 T:695      INFO <general>: ES: Stopping event server
2021-01-03 08:33:16.623 T:695      INFO <CWebserver[8080]>: Stopped
2021-01-03 08:33:16.825 T:734      INFO <general>: ES: UDP Event server stopped
2021-01-03 08:33:16.848 T:730      INFO <general>: Python interpreter interrupted by user
2021-01-03 08:33:16.865 T:732      INFO <general>: Python interpreter interrupted by user
2021-01-03 08:33:17.076 T:695      INFO <general>: Application stopped
2021-01-03 08:33:17.276 T:695      INFO <general>: XBApplicationEx: destroying...
2021-01-03 08:33:17.340 T:695      INFO <general>: unload skin
2021-01-03 08:33:17.354 T:695      INFO <general>: Unloaded skin
2021-01-03 08:33:17.356 T:695      INFO <general>: unload sections
2021-01-03 08:33:17.362 T:695      INFO <general>: XRANDR: /usr/lib/kodi/kodi-xrandr --screen 0 --output HDMI-2 --mode 0x48
2021-01-03 08:33:17.409 T:695      INFO <general>: XBApplicationEx: application stopped!

So you can test out your configuration and look for those lines in the kodi log. Another test is to
grep totaluptime /var/lib/kodi/.kodi/userdata/guisettings.xml
Make note of the value, then shutdown or reboot through whatever means you wish to test for a graceful exit. If the value is adjusted up, at least that portion of the shutdown was clean. You have to wait at least 60 sec for that to work and it does not rule out race conditions.

from kodi-standalone-service.

If I have open documents on my Linux desktop and call "sudo poweroff", then I loose my work, too. IMHO everything is nice as long as things work well when shutting down from the Kodi Power menu.

You do make a good point about that. I am not happy with systemd's behavior of allowing system.slice stuff to go down gracefully but more or less instantly killing user.slice stuff under the same scenario.

from kodi-standalone-service.

Actually I never get through to "XBApplicationEx: application stopped!".

I am just guessing here, but perhaps key are these lines:

2021-01-03 08:33:16.616 T:695      INFO <general>: Storing total System Uptime
2021-01-03 08:33:16.616 T:695      INFO <general>: Saving settings
2021-01-03 08:33:16.622 T:695      INFO <general>: Saving skin settings

The data loss I have experienced are adjustments relating to the skin (resizing the GUI or repositioning subtitles, etc). Having the uptime get saved is also nice.

from kodi-standalone-service.

xbmc/xbmc#19014

And at this point I'm giving up for now and just use the old kodi-standalone-service that worked well for me.

Autostarting properly into Kodi always was a nightmare on a AMD64 system and maybe always will. The common ARM based distributions seem to be able to care for this way more reliably.

from kodi-standalone-service.

Not sure which ARM distro to which you refer ... I maintain ArchARM and use these for it 😄

from kodi-standalone-service.

LibreELEC. Never had a problem with this.

Actually kind of funny that Kodi seems to be less problematic on small ARM boards than on big full-featured HTPC systems.

from kodi-standalone-service.

LibreLE is very different in that you are running kodi as the root user.

LibreELEC:~ # ps aux |grep kodi
  498 root      0:00 {kodi.sh} /bin/sh /usr/lib/kodi/kodi.sh --standalone -fs
  515 root      0:38 /usr/lib/kodi/kodi.bin --standalone -fs

They also ship a number of kodi-related units that call custom shell scripts:

LibreELEC:~ # ls /usr/lib/systemd/system/|grep kodi
kodi-autostart.service
kodi-cleanlogs.service
kodi-halt.service
kodi-lirc-suspend.service
kodi-poweroff.service
kodi-reboot.service
kodi-waitonnetwork.service
kodi.service
kodi.service.wants
kodi.target
kodi.target.wants

from kodi-standalone-service.

Keep the conversation going if you want but I reverted the system.slice move.

from kodi-standalone-service.