Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 733034 - media-tv/kodi-18.7.1 autostart on boot does not work with non-suid Xorg/elogind
Summary: media-tv/kodi-18.7.1 autostart on boot does not work with non-suid Xorg/elogind
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Craig Andrews
Depends on:
Reported: 2020-07-17 08:21 UTC by Tobias Klausmann
Modified: 2020-08-23 21:30 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Klausmann gentoo-dev 2020-07-17 08:21:04 UTC
As per the subject. The problem is that starting X11 as non-root needs a session,  which openrc doesn't seem to be able to provide. The classical way of starting kodi on boot, as illustrated here:

does not work anymore. I haven't tried the inittab approach.

What did work was re-merging Xorg with USE=suid and adding this to /etc/X11/X11/Xwrapper.config (yes there are two dirs named X11 in that path):

allowed_users = anybody
needs_root_rights = yes

Ideally, we'd find a way to start kodi on boot without having to have Xorg suid set.
Comment 1 gerion 2020-08-15 01:31:28 UTC
I encountered the same problem and have found the following Gentoo related workaround so far (just to link it here):
Comment 2 gerion 2020-08-15 02:45:23 UTC
I did a little more research and think that the issue lays in start-stop-daemon is not fixable in a trivial way.

When logging in within a TTY as the kodi user and typing:
$ startx /usr/bin/kodi-standalone
everything works without a suid enabled X. xinit on it's own does not work but need an argument more (that is set automatically by startx):
$ tty_num = $(tty)
$ tty_num = ${tty#/dev/tty/}
$ xinit /usr/bin/kodi-standalone -- vt${tty_num}
This command forces X to start in the same virtual terminal 	 	respectively session the current kodi user is logged in (this can also be checked with loginctl). Starting X on another virtual terminal (and session) does not work. This is also the difference to the suid enabled X. This X can open another virtual terminal and start in this terminal.

That means that the openrc script somehow needs to provide a new virtual terminal together with an (e)logind session as user kodi _before_ starting X (btw, that is exactly that what a login manager does).

In the OpenRC example in the wiki the only "login manager" is start-stop-deamon, since start-stop-deamon runs as root and changes the user to kodi. However, start-stop-deamon is only capable of changing the user but does _not_ assign a new virtual terminal to it and also doesn't manage the (e)logind session in any way (I'm not sure, if systemd provides such functionality). At least, I have not found an option in the manpage for that.

Within the "exec" part of start-stop-deamon we cannot do anything anymore, since we are already user kodi and are not permitted to start a new session anymore.

So I guess, the only good solution is to extend start-stop-deamon with elogind support.
Comment 3 gerion 2020-08-15 03:03:35 UTC
Seems not to be trivial on systemd, too:
Comment 4 Anthony Ryan 2020-08-17 04:43:31 UTC
Just switched to flameeyes lightdm configuration as well.

It does seem like it might be the best way to proceed forward. I did find USE=gnome was required on lightdm personally to pull in the accountsservice dependency.

Unless someone comes up with something better, I'll probably update the wiki in 1-2 days with that as a recommended replacement.

It adds an extra layer in the stack, but I think we can count on lightdm working more reliably into the future than the alternatives. I expect we'd all rather be watching a movie than debugging why we got a shell instead of Kodi.
Comment 5 Anthony Ryan 2020-08-23 21:30:55 UTC
The Wiki has been updated with a lightdm replacement:

Feedback and changes are welcome. If we have a few people happy with those instructions then we can likely close this issue.