On Mon, Jan 06, 2014 at 11:06:30AM -0800, Patrick McCarty wrote: > 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 > > > '[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. > > That works fine as well.
I agree with Kangkai here, given that tizen-mobile-session also provides default.target for user session, a kind of link. > > > [ 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 ] > > 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 [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? > > 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). Also I think this is not a case for a shipped phone, however, we may treat root as a special case. For example, it's very noize if it start all user units when I login from UART console. > > > > 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. As we disscussed, Kangkai just take "app" as an example, it may the user pulse to run pulseaudio, messagebus to run dbus and so on. So here the "app" just an example of non-root user. Sorry for confusing. > > > 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... I also started a topic based on what kinds of dbus service the daemon provides, there are some of them should be moved to system session, see https://bugs.tizen.org/jira/browse/PTREL-118 -- Thanks, Chengwei > > 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
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
