On Thu, 2014-12-18 at 11:40 +0200, Jussi Laako wrote: > On 17.12.2014 20:05, Kaskinen, Tanu wrote: > > Could VTNr=0 be a problem? On my Fedora laptop my graphical session > > doesn't have TTY set, but VTNr is set to 1. > > Well, if it is VTNr=2 it doesn't work either. VTNR is equal to > corresponding tty. Why is /dev/tty1 special here?
I don't know. Someone on systemd-devel might know. If logind is showing the session as active, but ACLs don't get set properly, that sounds like a bug in logind. > For example weston-launch requires that there's VT open, that's why we > open first free/unused VT (/dev/tty7) for genivi user, otherwise Weston > cannot start. This is the same that happens if you run "startx" from > normal Linux text login, it'll find first free VT and attach there. But > for user sessions that run on top of the system compositor, technically > there's no need to have any VT because they share the parent (genivi) > VT. And genivi session is not a normal user session and thus logind > doesn't know anything about it, otherwise it would attempt to launch all > systemd user services for it, such as crosswalk which is precisely what > we don't want. Similar to ssh sessions in current setup. > > Or then someone would need to teach systemd/logind about different user > session types, that for session type X service set A is started and for > session type Z service B is started. Instead of blindly triggering > systemd --user and launching all user services for all logins regardless > of session type... Here's one idea: assuming that you control how systemd --user is started, you could start systemd --user for the genivi user too, but instead of using default.target that pulls all kinds of stuff you don't want to run for the genivi user, you could specify a different target using the --unit option of systemd. I don't see how this would help with the ACL problems, though. I'm just mentioning this as an alternative solution to the problem that the genivi user shouldn't run the normal user services. -- Tanu _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
