systemd 206 systemd --user problem

EvanPurkhiser · 2013-09-23 00:16:47

darkraven wrote:

@msthev I solve the problem via a pretty idiotic way. I add a User property to scope units, so a scope cgroup could be owned by a user, then systemd won't get permission denied when trying to manager its cgroup.
Patches:
https://gist.github.com/yshui/6660283
I can't say it's bug free, at least it works for me so far.

I'm curious if this will work with the old style user-session@.service using PAMName=login. I'll have to try this out later tonight.

jouke · 2013-10-17 12:09:38

I took a slightly different route than what most in this thread have chosen.
The difference is mainly about the role of the user session scope. With recent versions of systemd I'm back to defining my graphical session in .xinitrc, instead of using systemd units. Here is why.

If we look at dbus, we see three instances in the systemd-cgls output below.

├─user.slice
│ └─user-1000.slice
│   ├─session-1.scope
│   │ ├─ 367 /usr/bin/bash -l .xinitrc
│   │ ├─ 371 (sd-pam)
│   │ ├─ 378 dbus-launch --sh-syntax --exit-with-session
│   │ ├─ 379 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
│   │ └─1234 ...
│   └─user@1000.service
│     ├─368 /usr/lib/systemd/systemd --user
│     └─370 (sd-pam)               
│     └─dbus.service
│       └─2213 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
└─system.slice
  ├─1 /usr/lib/systemd/systemd
  ├─dbus.service
  │ └─265 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  ├─system-x.slice
  │ └─x@vt7.service
  │   └─267 /usr/bin/X -nolisten tcp -noreset vt7
  └─...
    └─123 ...

Here are their roles, per PID.
265: This is the system instance, which is used by systemd (PID 1).
2213: This instance is used for interfacing the systemd user insance (PID 368), regardless of the user session (i.e., for user processes that are not bound to a session).
379: This instance is bound to the user session and is used for communication between session-bound processes.

The environment for PID 379 contains session defining variables such as $DISPLAY, $XDG_SESSION_ID, and $XDG_SEAT. These variables could not be set in the environment of PID 2213, as we could imagine having multiple sessions for a user, while having only one user instance of systemd.

Additionally, by organizing the graphical session outside systemd units, full flexibility regarding the nature of user sessions is retained. Especially with regard to this concern, changes in the way systemd user instances are treated can be expected in future versions of systemd. In particular, the default target of a systemd user instance should not launch too much.

The practical summary:
I use (and wrote) xlogin, which is a very minimal set of files that provide the possibility of graphical login using .xinitrc. It does not require, xorg-xinit, or xorg-launch-helper. There is a README with more usage information, but basically, you just do:

# systemctl start xlogin@<username>

Environment definitions from .bash_profile are respected.

Last edited by jouke (2013-10-17 12:13:45)

Almehdin · 2013-12-19 11:00:29

@jouke: I tried and currently using the way you described. This is pretty new to me but have been reading up on it. It works great and is a very minimal way of getting X to run. I however do not understand how be able to launch further service files for the user. I am particular interested in having my wm to run as a service. Do you have any pointers how I would be able to do that?

alezost · 2013-12-19 11:56:49

I use systemd for managing X sessions (it's possible to configure
several X instances). I use jouke's x-daemon shell script.

If anyone is interested, my services can be found here.

Almehdin · 2013-12-19 12:39:13

Perfect! Probably exactly what I need. Thanks!

EvanPurkhiser · 2013-12-20 10:18:00

Using @jouke's method still doesn't allow for commands that interface using polkit to be started as or within user services correct? For example, if I have a xterm@.service and execute `systemctl shutdown` from within that terminal will it succeed?

I see that @alezost has a xterm@.service, are you able to run `systemctl shutdown` from that terminal?

Last edited by EvanPurkhiser (2013-12-20 10:20:56)

alezost · 2013-12-20 11:39:34

EvanPurkhiser wrote:

I see that @alezost has a xterm@.service, are you able to run `systemctl shutdown` from that terminal?

Did you mean "systemctl poweroff"? Anyway i can't turn off the computer
with either "systemctl poweroff" or "shutdown" (i know that "shutdown"
is a symlink to "systemctl") just like this.

That's why i use another approach. I added the following line to
sudoers file (with "visudo" command):

<user> <host>=NOPASSWD: /usr/bin/shutdown

And i added an alias to bash config:

alias shutdown='sudo shutdown'

After that "shutdown" works.

EvanPurkhiser · 2013-12-20 11:46:56

I did, sorry about that.

Ahh, that's too bad. Having programs run in the user session can be important for other things as well

Arch Linux

#101 2013-09-23 00:16:47

Re: systemd 206 systemd --user problem

#102 2013-10-17 12:09:38

Re: systemd 206 systemd --user problem

#103 2013-12-19 11:00:29

Re: systemd 206 systemd --user problem

#104 2013-12-19 11:56:49

Re: systemd 206 systemd --user problem

#105 2013-12-19 12:39:13

Re: systemd 206 systemd --user problem

#106 2013-12-20 10:18:00

Re: systemd 206 systemd --user problem

#107 2013-12-20 11:39:34

Re: systemd 206 systemd --user problem

#108 2013-12-20 11:46:56

Re: systemd 206 systemd --user problem

Board footer