On Mon, Jan 6, 2014 at 12:30 AM, Yin Kangkai <kangkai....@intel.com> wrote: > 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 >> 'user-session-launch@.service'. >> >> The instance name requires a specific format, SEAT-UID, so you can >> quickly give it a test run by running: >> >> systemctl enable user-session-launch@seat0-5000.service >> >> 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.: user-session-launch@seat0-5000.service vs > user-session-launch@seat0-app.service
ever since systemd-185 or so it has standardized on uid's, so we should use them everywhere as much as we can. > 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 ] struct passwd pw = getpwuid(uid); -> pw.pw_nam easy enough, and we don't have problems with escaping, utf-8 user names, etc etc.... >> To avoid defining DISPLAY in user@.service, 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/user@.service.d/env.conf >> [Service] >> Environment=DISPLAY=:0 > > Hmm, is this format (user@.service.d/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). step #2 isn't done yet - we need a user service (e.g. seat@.service) that can start the proper seat for a user and then start either X with DISPLAY=whatever or start wayland if the seat was designated by the user for a wayland session.... this code isn't written yet. > 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*? they belong to the user, we don't need them on every installation.... but they are not system stuff. > 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"? Nope, nope, no hard coded end users. That's completely wrong. We're trying to get rid of all the hard coded usernames and uid's, we should be removing them, not add more occurrences. > 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. I'm not sure what you mean by this... Cheers, Auke _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
