On Mon, Jan 06, 2014 at 04:30:58PM +0800, Yin Kangkai wrote: > On 2014-01-04, 21:08 -0800, Patrick McCarty wrote: > > 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.
That works fine as well. > [ 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 > > 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 ] Technically, we could use either UID or user name, but the UID is the more common convention in systemd -- required value for the "User" key in service files, etc. -- so I felt UID was more appropriate. Also, the call to getpwuid(3) (or getpwnam(3) in the alternate case) validates the system account and populates the passwd struct, so the associated user name would be available to pass to PAM when opening the session. > > 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? Yes, this feature was added in systemd 198. > > > 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. What PAM config changes would you propose? > 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"? I'm not seeing the advantage of moving units out of the "app" user session if they are going to run as "app", with all capabilities dropped. If there should be only *one* instance of a service (e.g. a middleware service), then we should move it to the system session, but it wouldn't run as "app" in this case. > 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've been thinking about this problem as well... Installing user session units system-wide for multiple users is going to result in a cluttered /usr/lib/systemd/user directory. Also, I think it would be useful to configure the default target on a per-user basis, possibly in /etc/systemd/logind.conf, so that we have more flexibility in specifying per-user units to start. Regards, Patrick _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
