systemd 206 systemd --user problem

nierro · 2013-07-23 15:34:41

Hi!
I was using xorg-launch-helper and user-session-units previously (systemd 204), and everything worked flawlessly.
Since i upgraded to systemd 206, those units won't work. So i came back to old .xinitrc, autologin to vt and autostart x. Well...it isn't working.
In .xinitrc I have "exec /usr/lib/systemd/systemd" so i guess that is the problem.
In fact, just putting in .xinitrc

#exec /usr/lib/systemd/systemd
xfce4-panel & 
xfdesktop &

exec xfwm4

works as expected.
What should i do in order to go on using my systemd --user session? And, if it is possible, how can i go on using xorg-launch-helper and user-session-units too?
Thanks!

EDIT: starting /usr/lib/systemd/systemd gives me:

Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied

Last edited by nierro (2013-07-23 15:51:33)

karol · 2013-07-23 16:21:03

Have you seen https://mailman.archlinux.org/pipermail … 25118.html & https://mailman.archlinux.org/pipermail … 25194.html ?

No idea if this is relevant to your problem, because it's all black magic to me.

nierro · 2013-07-23 16:29:37

I already read those, but i can't find a solution..only i understood that cgroup change is the "issue" for me, and for everyone running a systemd user session.

misc · 2013-07-23 16:44:40

I've run into a separate issue with 206: Sound now requires root privileges, even though the user is member of the audio group.

Last edited by misc (2013-07-23 16:44:51)

falconindy · 2013-07-23 16:50:37

You can only start a user session manager through user@.service

misc wrote:

I've run into a separate issue with 206: Sound now requires root privileges, even though the user is member of the audio group.

Not at all related. You should never need to be a part of the audio group -- this is the point of uaccess and ACLs. Doing this can lead to problems, as you're seeing.

Last edited by falconindy (2013-07-23 16:51:42)

HalosGhost · 2013-07-23 16:55:02

falconindy wrote:

You can only start a user session manager through user@.service

Did that change in 206, or did you mean user-session@.service (or are we talking about something else that went over my head (for a moment))? (Not trying to be a smartass, I'm genuinely wondering)

All the best,

-HG

Last edited by HalosGhost (2013-07-23 17:16:22)

nierro · 2013-07-23 17:02:33

@falcondy: how am i supposed to manage my user session with user@.service? I see it is very similar to user-session@.service (provided by AUR user-session-units package), so, all i need is to enable user@1000.service? What else should I do?
Thank you very much for your help!

Last edited by nierro (2013-07-23 17:02:43)

misc · 2013-07-23 17:33:01

falconindy wrote:

Not at all related. You should never need to be a part of the audio group -- this is the point of uaccess and ACLs. Doing this can lead to problems, as you're seeing.

Well, this is the first time that I've run into that rather small note in the wiki about systemd supposedly rendering most group membership redundant. So I've removed myself from those listed there, and now I'm really having issues:

Previously mpv would simply complain about insufficient rights for playback, now it won't even find the soundcard (neither does alsamixer anymore). Similar for video playback, which (with opengl as vo) is now refused.

Note that this is a relatively fresh setup (1 month) without any custom configuration for audio nor video.

edit: Found the reason, methinks. I don't use a login manager and thus, without session management, the permissions granted by logind are apparently not transferred to the tty X actually runs on. Previously the group memberships still gave me all the missing permissions, no the don't anymore (for audio). I don't see anything immediately relevant to fix this in the wiki, but I'll update this post if I find a solution.

edit2: After some misadventures with user@/slim, which brought me deeper into the troubles talked about in this thread (plus spontaneous xserver combustion, mpd still missing the same rights, zshenv ignored with user@, etc.), I noticed falconindy's fixes in systemd-git. Installed that, and whereas it would somewhat work now with slim (eg. with a session dependent tmux), it's back to the ever-so-outdated but perfectly working, minimal mingetty+groups again.

Last edited by misc (2013-07-25 13:53:09)

falconindy · 2013-07-23 17:50:13

misc wrote:

falconindy wrote:
Not at all related. You should never need to be a part of the audio group -- this is the point of uaccess and ACLs. Doing this can lead to problems, as you're seeing.
Well, this is the first time that I've run into that rather small note in the wiki about systemd supposedly rendering most group membership redundant. So I've removed myself from those listed there, and now I'm really having issues:
Previously mpv would simply complain about insufficient rights for playback, now it won't even find the soundcard (neither does alsamixer anymore). Similar for video playback, which (with opengl as vo) is now refused.
Note that this is a relatively fresh setup (1 month) without any custom configuration for audio nor video.

Then your session setup is broken. It's really not related to this thread in any way.

WonderWoofy · 2013-07-23 18:44:31

When I just updated, I noticed that my user wouldn't even correctly log in. So I logged in as root and looked around, and realized that user@.service automatically gets launched now. This is trying to run "systemd --user" so if you are experiencing significant problems (like not being able to log into the TTY even), then you need to disable some of the user units. In particular, if you use "systemd --user" to launch your WM/DE/X, that needs to be removed, as it will just cause a black screen.

Otherwise, I have no solutions to this problem. I would be interested to know if using "systemd --user" to handle the entire graphical session is still possible, so I will follow this thread.

@misc, please stop trying to derail this thread. Maybe this is related to your problem. But if not, start a new thread.

nierro · 2013-07-23 18:48:20

@wonderwoofy: what about masking user@.service? It should be considered madness? By the way i noticed that even if i'm using startx and old xinitrc stuff, "systemctl status user@1000.service" will prompt something like "calised.service failed"... so i guess you're right, it seems to start some of the .config/systemd/user/ stuff. I don't understand how it works now.
And honestly I don't understand why nobody blogged about this change and how to face it from a systemd user session perspective.

WonderWoofy · 2013-07-23 18:58:38

Well, it was talked about pretty extensively on the systemd mailing list. I read through the stuff there, and pretty much just kind of expected to run into some problems. But I keep the old "startx" method set-up anyway, so I guess I was ready.

I don't think you should mask user@<UID>.service. It has become a central part of logind and the cgroup setup. So it would likely cause breakage of some kind. If you look at the service file and compare it to the old user-session@.service, you will see that there is even a whole new way of configuring the cgroup stuff. So what is in user-session@.service is now no longer supported whatsoever.

Maybe it might be possible to use the alternate (or additional) PAMName= variable that is used in user-session@.service, but I don't really know, as I have not had a chance to try things yet.

Maybe you might want to follow the systemd mailing list for a bit to see if there is any discussion there. I am sure it is bound to happen sooner rather than later.

karol · 2013-07-23 19:02:12

@nierro
If you're using [testing], you should subscribe to arch-dev-public ML, where Dave Reisner kindly reposted a headsup from systemd-devel ML a month ago: https://mailman.archlinux.org/pipermail … 25118.html

nierro · 2013-07-23 19:03:58

I read that systemd 205 would break systemd user sessions, but i guessed only xorg-launch-helper and user-session-units would have been affected.
If my .config/systemd/user/ units worked fine, i couldn't see any reason they wouldn't do anymore. Instead they stopped working.
By the way i had my old .xinitrc set up for this kind of events, so i'm not having huge problems, but i'd like to have my systemd session working again!

EDIT: @karol: i read it. And i read systemd 205-206 release announcement as i always do with every new version.

Last edited by nierro (2013-07-23 19:05:08)

65kid · 2013-07-23 19:19:19

I've also been trying to figure this out and at least managed to start my user session as before (more or less). Note that I didn't start systemd --user from .xinitrc like some people do (and if I understand falconindy and the mailing list posts correctly this will not work anymore). Instead I used the user-session@.service.

The only thing I needed to actually start up the X server and the session as before was the following drop in config:

# /etc/systemd/system/user@1000.service.d/env.conf
[Service]
Environment=DISPLAY=:0
Environment=XDG_RUNTIME_DIR=/run/user/%U

Then I can start the session by logging into tty1 as my user. Starting user@1000 manually does not work however (same thing for autostarting user@1000 by linking it into multi-user.target.wants).

The session is active and sound etc. work, but reboot/suspend/poweroff still give me access denied.

Note that I don't consider this a solution, I just wanted to share what I found out. From my understanding starting the X server from within the user session like user-session@ does or did is not actually how all of this is supposed to work. Instead the user@ service would autostart as soon as the user logs in via the display manager. All just theory on my part, feel free to correct me...

The question is what the best approach would be for people who don't want/need a display manager. Maybe some kind of minimal display manager that does nothing but autologin the user? No, I'm not talking about getty. getty starts pretty late and I always considered having a logged-in terminal in the background kind of a hack.

Javafant · 2013-07-23 19:34:32

WonderWoofy wrote:

Otherwise, I have no solutions to this problem. I would be interested to know if using "systemd --user" to handle the entire graphical session is still possible, so I will follow this thread.

I can confirm that it’s still possible. I had to create user@.service in /etc/systemd/system to get dbus working correctly.

.include /usr/lib/systemd/system/user@.service
[Service]
Environment=DISPLAY=:0
Environment=XDG_RUNTIME_DIR=/run/user/%I

I’m still having a problem with urxvt, which is for some weird reason not running zsh even though it’s my default shell and the getty, xterm and gnome-terminal are running it.

WonderWoofy · 2013-07-23 19:37:31

@Javafant, add that as "Environment=SHELL=/usr/bin/zsh" to that drop-in modification.

Last edited by WonderWoofy (2013-07-23 19:37:46)

Javafant · 2013-07-23 20:28:18

@WonderWoofy Thanks, now it works. Strange that only urxvt seems to require this.

hobarrera · 2013-07-24 03:15:09

Javafant wrote:

WonderWoofy wrote:
Otherwise, I have no solutions to this problem. I would be interested to know if using "systemd --user" to handle the entire graphical session is still possible, so I will follow this thread.
I can confirm that it’s still possible. I had to create user@.service in /etc/systemd/system to get dbus working correctly.
.include /usr/lib/systemd/system/user@.service
[Service]
Environment=DISPLAY=:0
Environment=XDG_RUNTIME_DIR=/run/user/%I
I’m still having a problem with urxvt, which is for some weird reason not running zsh even though it’s my default shell and the getty, xterm and gnome-terminal are running it.

This didn't work for me. Still getting

Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied

Are you launching systemd via .xinitrc?

ngoonee · 2013-07-24 03:21:44

Ended up downgrading, unfortunately. Javafant (or whoever else has gotten this to work), more details would be good. In particular, it seems as if you've only gotten a user session up, but not with your WM being controlled by it (which is what WonderWoofy was saying he could not get to work).

Just like WonderWoofy, subscribing here in hopes that something comes up

HalosGhost · 2013-07-24 03:26:12

ngoonee wrote:

Just like WonderWoofy, subscribing here in hopes that something comes up

I'm on this list too. I've used `systemd --user` to manage my X session and login for a while now, and I would like to continue doing so. I'm holding off on the upgrade until it seems more likely that this may be a possibility.

All the best,

-HG

nierro · 2013-07-24 07:11:38

As i said, I found it really strange that nobody (read Lennart) blogged about this change and how to implement an user session again.
By the way, as everyone over there, waiting for anyone that knows how to solve.

Javafant · 2013-07-24 08:46:01

hobarrera wrote:

This didn't work for me. Still getting
Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied
Are you launching systemd via .xinitrc?

You don”t have to start systemd --user manually. It gets started automaticly when you login.

Javafant · 2013-07-24 08:48:16

ngoonee wrote:

Ended up downgrading, unfortunately. Javafant (or whoever else has gotten this to work), more details would be good. In particular, it seems as if you've only gotten a user session up, but not with your WM being controlled by it (which is what WonderWoofy was saying he could not get to work).
Just like WonderWoofy, subscribing here in hopes that something comes up

The user session is starting X, awesom WM and everything else I want to have started automaticly. Basicly the only thing I did was removing systemd --user from my ~/.zprofile and modifying user@1000.service. Then it worked just fine.

nierro · 2013-07-24 09:00:34

@javafrant: so you're not using user-session@.service anymore? Instead you rely on "official" user@.service, shipped with systemd? And are you using xorg-launch-helper too?

Arch Linux

#1 2013-07-23 15:34:41

systemd 206 systemd --user problem

#2 2013-07-23 16:21:03

Re: systemd 206 systemd --user problem

#3 2013-07-23 16:29:37

Re: systemd 206 systemd --user problem

#4 2013-07-23 16:44:40

Re: systemd 206 systemd --user problem

#5 2013-07-23 16:50:37

Re: systemd 206 systemd --user problem

#6 2013-07-23 16:55:02

Re: systemd 206 systemd --user problem

#7 2013-07-23 17:02:33

Re: systemd 206 systemd --user problem

#8 2013-07-23 17:33:01

Re: systemd 206 systemd --user problem

#9 2013-07-23 17:50:13

Re: systemd 206 systemd --user problem

#10 2013-07-23 18:44:31

Re: systemd 206 systemd --user problem

#11 2013-07-23 18:48:20

Re: systemd 206 systemd --user problem

#12 2013-07-23 18:58:38

Re: systemd 206 systemd --user problem

#13 2013-07-23 19:02:12

Re: systemd 206 systemd --user problem

#14 2013-07-23 19:03:58

Re: systemd 206 systemd --user problem

#15 2013-07-23 19:19:19

Re: systemd 206 systemd --user problem

#16 2013-07-23 19:34:32

Re: systemd 206 systemd --user problem

#17 2013-07-23 19:37:31

Re: systemd 206 systemd --user problem

#18 2013-07-23 20:28:18

Re: systemd 206 systemd --user problem

#19 2013-07-24 03:15:09

Re: systemd 206 systemd --user problem

#20 2013-07-24 03:21:44

Re: systemd 206 systemd --user problem

#21 2013-07-24 03:26:12

Re: systemd 206 systemd --user problem

#22 2013-07-24 07:11:38

Re: systemd 206 systemd --user problem

#23 2013-07-24 08:46:01

Re: systemd 206 systemd --user problem

#24 2013-07-24 08:48:16

Re: systemd 206 systemd --user problem

#25 2013-07-24 09:00:34

Re: systemd 206 systemd --user problem

Board footer