On 2014-01-04, 21:08 -0800, Patrick McCarty wrote: > On Sat, Jan 04, 2014 at 06:44:36PM +0800, Yin Kangkai wrote: > > On 2014-01-03, 21:13 -0800, Kok, Auke-jan H wrote: > > > Patrick and me have been working on a solution upstream, both with > > > parts in systemd and in user-session-units. We can now start a logind > > > session properly for either wayland or Xorg. > > > > OK, may I know when will that land in Tizen? > > The first iteration of this code has already been submitted for Tizen > 3.0 in the user-session-units package. I know it was accepted in the IVI > project, and I'm pretty sure the SR was accepted for Mobile as well.
So seems Tizen mobile are missing this package - user-session-units. I checked the package, and the user-session-launch tool, this is interesting cause I was cooking yesterday exactly the same thing - user-session-trigger: a small utility to trigger user session creation through pam_systemd.so and hence systemd-logind, which is the new systemd user session model (for version > v205). :) So yes, I am pretty sure with this utility (user-session-launch) we will be successfully bring up systemd user session in Tizen mobile. > If the Mobile package is up-to-date, there is a new systemd service > available to use for starting a logind session at bootup. It is named > '[email protected]'. > > The instance name requires a specific format, SEAT-UID, so you can > quickly give it a test run by running: > > systemctl enable [email protected] > > and reboot. > > In the IVI 3.0 kickstart file, the symlink is created manually in the > /usr/lib/systemd hierarchy, so the Mobile kickstart file should do the > same. I would prefer we handle this in tizen-mobile-session package. We will make the necessary changes. [ BTW, a small discussion, about the "user" part, do you prefer uid or a name? i.e.: [email protected] vs [email protected] pam_systemd.so can handle user name (e.g.: app) quite well, plus benefits we don't need code to translate that 5000 into "app" in launcher.c ] > To avoid defining DISPLAY in [email protected], you could define it in a > service.d conf file instead, but it still means hardcoding the ":0". > Some example contents: > > $ cat /usr/lib/systemd/system/[email protected]/env.conf > [Service] > Environment=DISPLAY=:0 Hmm, is this format ([email protected]/env.conf) supported in upstream? > > Anyway, this is too early to talk into this level of details, you're > > right, this still needs a lot of work seems. We will try to contribute > > here as well. > > Yes, there are still a few major issues to sort out, especially to make > user sessions more future proof and align more with upstream. I think one major problem left in this user session setup is that, those user session services be run each time a new user session opens (e.g. somewhere another user "root" login). We can fiddle with PAM configurations (/etc/pam.d) to work around this. Or, we need to clean up all those user session units. I mean, do they really belongs to *user session*? bash-4.2# cd /lib/systemd/user bash-4.2# ls bluetooth-frwk-service.service quickpanel.service bluetooth.target scim.service boot-animation.service shutdown.target calendar.service smartcard.target contacts-service.service sockets.target contacts-service.socket sockets.target.wants core-efl.target sound.target core-efl.target.wants starter.path data-provider-master.service starter.service data-provider-master.socket systemd-exit.service dbus.service timers.target dbus.socket tizen-generate-env.service default.target tizen-middleware.target download-provider.service tizen-middleware.target.wants e17_early.service tizen-mobile-session.target e17.service tizen-mobile-session.target.wants email.service xmodmap.service exit.target xorg_done.service indicator.service xorg.service paths.target xorg.target printer.target xorg.target.wants bash-4.2# Most of these are middle ware services, can we move those into system session, and just run them with "User=app"? Ideally, we will leave /lib/systemd/user only those user session specific unit files, and make sure they do not conflict between different user login sessions. Regards, Kangkai _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
