systemd 206 systemd --user problem

Javafant · 2013-07-24 09:16:52

@nierro I never used user-session@.service but instead I started systemd --user in my ~/.zprofile which gets executed automaticly when I login. Now I simply removed this. user@.service starts automatcly after login in by default and this starts my user session. To start X I’m using xorg-launch-helper.

nierro · 2013-07-24 10:25:43

How do you manage to login (i guess you mean in a vt), if you're using xorg-launch-helper (whose aim is to avoid login in a tty and starting x from there)?
I mean, with xorg-launch-helper .bash_profile (.zprofile in your case) isn't executed at all.

EDIT: i probably understand: you used autologin to vt and instead of autostarting x, you just ran systemd --user from within the vt, and in your systemd user units you put "After=xorg.target" etc etc. Right?
so now you say we don't need to run systemd --user anymore...but is dbus running for your session? I mean dbus.socket and dbus.service, provided by user-session-units (https://github.com/sofar/user-session-u … units/user)

Last edited by nierro (2013-07-24 11:12:50)

Javafant · 2013-07-24 11:39:32

I didn’t use autologin. I booted into a getty and logged in there. This executed .zprofile which started systemd --user and the user session then took care of starting X and the rest. I still boot into a getty and log in there. The only difference is that, there’s no need to start systemd --user in my .profile because it’s started automaticly. I didn’t change anything in my services. To get dbus running I had to modify user@1000.service as I described in a previous post. systemctl --user status dbus.socket or dbus.service shows that it is running. Also programs using dbus (notify-send) are working fine.

nierro · 2013-07-24 11:41:26

Ok thanks, i'll try and report back here! Let's see how far will I go

nierro · 2013-07-24 14:59:48

Ok, i can confirm Javafant method is working pretty well, although it seems we're now forced to use autologin to vt ( or to log to a getty manually), then user@1000.service does the rest (you have to add those two Environment variables Javafant wrote some posts ago), and autostart your user session. I'm now wondering if we can get past autologin to vt, ie if user@1000.service can be started like user-session@1000.service was before, without have to call a vt and login.
Any idea?

EDIT: it seems i cannot reboot or poweroff from within my x systemd user session. "Access denied", even if i put "session required pam_systemd.so" in /etc/pam.d/login and system-auth.
I have to systemctl --user exit and then reboot. I've got no idea why it isn't working. I can't mount usb stick too. Really strange.

EDIT2: @65kid: this was the solution you came up with, and you are having same troubles too. Sorry, i recalled that now!

Last edited by nierro (2013-07-24 17:30:45)

Javafant · 2013-07-24 18:56:08

I’m also having trouble using reboot and poweroff. It work fine as root even though it takes a lot of time to power off.

nierro · 2013-07-24 18:58:15

@Javafant: try to add a "TimeoutStopSec=2" in /etc/systemd/system/user@.service.

hobarrera · 2013-07-24 20:59:44

I was starting "systemd --user" through my .xinitrc. Is there any fix for that scenario? Or am I now forced to use xorg-launch-helper?

ngoonee · 2013-07-24 23:38:26

Javafant wrote:

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.

To add on to nierro's question, you don't use xorg-launch-helper either I take it?

hobarrera · 2013-07-25 05:49:27

Javafant wrote:

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.

I was launching systemd --user via my .xinitrc.
Systemd then managed my wm, user-daemons, etc.

I've now been forced to install systemd-user-session-units-git and systemd-xorg-launch-helper-git to get everything running again. I've also had to modify all services which require xorg to now include

After=xorg.target

I also had to apply the modifications described a few posts back.

The upside, if that daemons that don't require X (eg: offlineimap) will not start without waiting for X.

I hope this helps a few out there who still haven't gotten systemd-206 working.

I do have one question though; now that "dbus-launch /usr/lib/systemd/systemd --user" isn't the last line on my .xinitrc, what should I put there? What did you guys put? I just left a

while [ true ]; do sleep 1d; done

Honestly, I don't like the idea of systemd in control of my user session anyomore. To being with, I now require two additional aur packages for it to work, and, most importantly, I don't want software with these sort of extremely poorly documented changes that render your desktop useless in charge of my desktop session.

I'll start hacking something similar to OpenBSD's rc.d to manage user sessions as soon as I have the time. Quite similar to Arch's old mechanism, in case anybody's interested, though, surprisingly, simpler.

Mind you, it's not a rant against Arch devs, but rather systemd devs. I've had no issue with systemd --system, but it's far from the first time systemd --user breaks like this.

---

Edit:

Ok, so stuff works now, but I still have some issues.
If sxkhd starts as a systemd service, it doesn't work; it I start it via a terminal, it works (though I can't start a terminal without it). It doesn't matter if I restart it the systemd service AFTER xorg has started, it still won't work. It just silently does-nothing.
Therefore, even though "stuff works", I need to switch to a second TTY to start sxkhd.

Also, "xrdb -merge .Xresources" from .xinitrc runs AFTER some services start, so they ignore values loaded from there.

Last edited by hobarrera (2013-07-25 06:04:48)

progandy · 2013-07-25 05:59:51

hobarrera wrote:

Mind you, it's not a rant against Arch devs, but rather systemd devs. I've had no issue with systemd --system, but it's far from the first time systemd --user breaks like this.

I guess you found the reason why there is no documentation yet. The user session is not yet ready for the public, so no one bothers to write the manual. Developers are welcome to dissect the source code and help in bringing it to a useful state. Currently the workflow is becoming rather complicated, especially with multiple logins and graphical sessions.

hobarrera · 2013-07-25 07:17:49

progandy wrote:

hobarrera wrote:
Mind you, it's not a rant against Arch devs, but rather systemd devs. I've had no issue with systemd --system, but it's far from the first time systemd --user breaks like this.
I guess you found the reason why there is no documentation yet. The user session is not yet ready for the public, so no one bothers to write the manual. Developers are welcome to dissect the source code and help in bringing it to a useful state. Currently the workflow is becoming rather complicated, especially with multiple logins and graphical sessions.

Nothing complicated about my setup; autologin on TTY1, X autostarts... that's it. Single user setup.

Anyway, I did what Javafant suggested here, but reboot and shutdown don't work; I get prompted for the root password.

Has anyone else had this issue? Any hints?

nierro · 2013-07-25 07:21:29

nierro wrote:

EDIT: it seems i cannot reboot or poweroff from within my x systemd user session. "Access denied", even if i put "session required pam_systemd.so" in /etc/pam.d/login and system-auth.
I have to systemctl --user exit and then reboot. I've got no idea why it isn't working. I can't mount usb stick too. Really strange.
EDIT2: @65kid: this was the solution you came up with, and you are having same troubles too. Sorry, i recalled that now!

Sorry for the self quote
Yes it seems you're not alone Hobarrera. I can't understand how should we handle this. And I'd like to get rid of autologin to vt, just like it was before, with x started for my user as a system service.

hobarrera · 2013-07-25 07:42:42

nierro wrote:

nierro wrote:
EDIT: it seems i cannot reboot or poweroff from within my x systemd user session. "Access denied", even if i put "session required pam_systemd.so" in /etc/pam.d/login and system-auth.
I have to systemctl --user exit and then reboot. I've got no idea why it isn't working. I can't mount usb stick too. Really strange.
EDIT2: @65kid: this was the solution you came up with, and you are having same troubles too. Sorry, i recalled that now!
Sorry for the self quote
Yes it seems you're not alone Hobarrera. I can't understand how should we handle this. And I'd like to get rid of autologin to vt, just like it was before, with x started for my user as a system service.

That doesn't work for me:

$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active
Active=yes
$ reboot
==== AUTHENTICATING FOR org.freedesktop.login1.reboot ====
Authentication is required for rebooting the system.
Authenticating as: root

DBus is sort-of-running; if I run xfce4-notifyd as soon as I log in, it prompts:

Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No such file or directory

But running notify-send makes xfce4-notifyd autostart and run (???).

Also, WHEN I manage to reboot as root, it takes a couple of MINUTES for the system to go down.

---

Edit:

I managed to get sxhkd working as a service again.
The SHELL environment variable needs to be set for it to run (a bit hard to debug that one).

Sorry for the noise, but I'm hoping my progress will help other in similar cases - we're all new to this really.

Last edited by hobarrera (2013-07-25 07:57:30)

progandy · 2013-07-25 07:43:04

nierro wrote:

Sorry for the self quote
Yes it seems you're not alone Hobarrera. I can't understand how should we handle this. And I'd like to get rid of autologin to vt, just like it was before, with x started for my user as a system service.

I guess you'll have to run a global xorg service and a small display manager service that handles the login, runs your window manager unit, waits for the window manager to terminate and then exits the session.

nierro · 2013-07-25 07:55:20

@hobarrera: it is the same problem i'm having too, as my self-quote explained.
@progandy: i just can't understand why i can't poweroff/reboot/mount usb from within my session (which, as hobarrera pointed out, is ACTIVE).
What have we discovered:
1) user@.service will be executed as soon as an user logs in a tty.
2) we have to export the display variable in user@.service, otherwise our .config/systemd/user/* units, which need xorg.target (xorg-launch-helper), won't run.
3) it seems dbus.service and dbus.socket are running ( my xfce4-notifyd is working too), but we are not granted poweroff/reboot etc etc priviliges.
We need to understand if there's a proper way to reach those priviliges without having to use a display-manager...but it seems really hard.

Last edited by nierro (2013-07-25 07:56:09)

hobarrera · 2013-07-25 08:23:38

progandy wrote:

nierro wrote:
Sorry for the self quote
Yes it seems you're not alone Hobarrera. I can't understand how should we handle this. And I'd like to get rid of autologin to vt, just like it was before, with x started for my user as a system service.
I guess you'll have to run a global xorg service and a small display manager service that handles the login, runs your window manager unit, waits for the window manager to terminate and then exits the session.

Wow, now way; that's way too much bloat and too NOT-KISS.
There needs to be a simpler way around this.

I checked how long systemd waits for units to die before killing them, and the default is 90seconds.
I timed it, and it's taking 90 seconds for my PC to turn off, so it seems some service (I'm suspecting offlineimap) takes too long to exit on it's own and keeps everything waiting.
I don't know how to change that default though; any ideas? IMHO, 10 seconds is more than enough for anything sane to exit.

---

On another topic, I fixed the xrdb-not-loading-resources-before-apps-start issue by creating a new unit file:

$ cat .config/systemd/user/xrdb.service 
[Unit]
Description=Load X resources
After=xorg.service
Before=xorg.target

[Service]
ExecStart=/usr/bin/xrdb -merge /home/%u/.Xresources
Type=oneshot

[Install]
WantedBy=xorg.target

And the enabling it via

systemctl --user enable xrdb.service

---

As for dbus I noticed it wasn't running for me because I explicity need to add it. So did just that:

$ cat .config/systemd/user/default.target
[Unit]
Description=Compiz-based desktop
After=xorg.target
After=dbus.service
Requires=xorg.target
Requires=dbus.service

[Install]
Alias=default.target

nierro · 2013-07-25 08:28:30

@hobarrera:

I checked how long systemd waits for units to die before killing them, and the default is 90seconds.
I timed it, and it's taking 90 seconds for my PC to turn off, so it seems some service (I'm suspecting offlineimap) takes too long to exit on it's own and keeps everything waiting.
I don't know how to change that default though; any ideas? IMHO, 10 seconds is more than enough for anything sane to exit.

Add to unit user@.service a "TImeoutStopSec=2" under Service.

As for dbus I noticed it wasn't running for me because I explicity need to add it. So did just that:

So, is poweroff/reboot now working?

hobarrera · 2013-07-25 09:11:16

nierro wrote:

@hobarrera:
I checked how long systemd waits for units to die before killing them, and the default is 90seconds.
I timed it, and it's taking 90 seconds for my PC to turn off, so it seems some service (I'm suspecting offlineimap) takes too long to exit on it's own and keeps everything waiting.
I don't know how to change that default though; any ideas? IMHO, 10 seconds is more than enough for anything sane to exit.
Add to unit user@.service a "TImeoutStopSec=2" under Service.
As for dbus I noticed it wasn't running for me because I explicity need to add it. So did just that:
So, is poweroff/reboot now working?

Nope.

And the $XDG_SESSION_ID variable is not set either, so it seems my session is not active for some reason.

$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active
$

So I can't reboot, shutdown, or mount USB drives.

If I ssh in, however, it IS set. I've no idea why I'm not getting an XDG_SESSION_ID after logging in.

Even if I disable dbus (by undoing what I mentioned above), I still don't get an XDG_SESSION_ID.

Stebalien · 2013-07-25 12:12:29

Here is a script that will wait for a systemd unit to terminate before exiting: https://gist.github.com/Stebalien/6079034

Systemd really needs some sort of sub-environment/sub-instance system but for now I would just dump relevant environment variables to a temporary file and have services source this file using EnvironmentFile.

Last edited by Stebalien (2013-07-25 12:19:19)

progandy · 2013-07-25 12:52:34

You can also use "systemctl --user set-environment" if you want to set global environment variables for a user.

Stebalien · 2013-07-25 18:06:30

I've gotten it to mostly work now (except for privileged operations like shutting down, modifying the network, etc.). In case anyone is interested, here is a rough (and vastly simplified) sketch of my setup:

~/.xinitrc (where systemd-wait is the script I posted above):

# ... stuff ...

ENV_DIR=${XDG_RUNTIME_DIR:-/run/user/$UID}/env/
mkdir -p $ENV_DIR

env > $ENV_DIR/$XDG_SESSION_ID

systemctl --user start graphical@${XDG_SESSION_ID}.target
exec systemd-wait graphical@${XDG_SESSION_ID}.target

graphical@.target (where window-manager@.service is a symlink pointing to one's window manager).

[Unit]
Description=Graphical Interface
AllowIsolate=yes
Wants=session@.target window-manager@.service

session@.target (generic session target for programs that need a session but can run under either X or a TTY):

[Unit]
Description=User Session Target

bspwm@.service

[Unit]
Description=A binary space partitioning window manager
Documentation=man:bspwm(1)
Requisite=graphical@.target
PartOf=graphical@.target

[Service]
EnvironmentFile=%t/env/%i
ExecStartPre=-/usr/bin/mkfifo %t/bspwm-panel-fifo
ExecStart=/usr/bin/bspwm -s %t/bspwm-panel-fifo
Restart=always

[Install]
Alias=window-manager@.service

sxhkd@.service

[Unit]
Description=Simple Hotkey Daemon
# Only start if part of a session. Stop when the session ends.
Requisite=graphical@.target
PartOf=graphical@.target

[Service]
# Setup the environment
EnvironmentFile=%t/env/%i
ExecStart=/usr/bin/sxhkd
ExecReload=/bin/kill -SIGUSR1 $MAINPID
Restart=on-abort

[Install]
WantedBy=graphical@.target

Unfortunately, my dbus instance is a user instance instead of the usual session instance. AFAICT, this is what is preventing me from performing privileged operations (operations that require an active seat).

Last edited by Stebalien (2013-07-25 18:12:29)

hobarrera · 2013-07-25 22:53:27

Isn't there any upstream forum? A mailing list that ISN'T -devel? Anywhere to ask for help upstream?

HalosGhost · 2013-07-25 23:06:10

Stebalien wrote:

I've gotten it to mostly work now (except for privileged operations like shutting down, modifying the network, etc.). In case anyone is interested, here is a rough (and vastly simplified) sketch of my setup

Oooh, interesting. I may finally upgrade to 206. Thanks for your input!

All the best,

-HG

Stebalien · 2013-07-26 02:52:43

Actually, I ended up downgrading. The fact that the DBus daemon didn't run under X broke gnome-keyring.

Arch Linux

#26 2013-07-24 09:16:52

Re: systemd 206 systemd --user problem

#27 2013-07-24 10:25:43

Re: systemd 206 systemd --user problem

#28 2013-07-24 11:39:32

Re: systemd 206 systemd --user problem

#29 2013-07-24 11:41:26

Re: systemd 206 systemd --user problem

#30 2013-07-24 14:59:48

Re: systemd 206 systemd --user problem

#31 2013-07-24 18:56:08

Re: systemd 206 systemd --user problem

#32 2013-07-24 18:58:15

Re: systemd 206 systemd --user problem

#33 2013-07-24 20:59:44

Re: systemd 206 systemd --user problem

#34 2013-07-24 23:38:26

Re: systemd 206 systemd --user problem

#35 2013-07-25 05:49:27

Re: systemd 206 systemd --user problem

#36 2013-07-25 05:59:51

Re: systemd 206 systemd --user problem

#37 2013-07-25 07:17:49

Re: systemd 206 systemd --user problem

#38 2013-07-25 07:21:29

Re: systemd 206 systemd --user problem

#39 2013-07-25 07:42:42

Re: systemd 206 systemd --user problem

#40 2013-07-25 07:43:04

Re: systemd 206 systemd --user problem

#41 2013-07-25 07:55:20

Re: systemd 206 systemd --user problem

#42 2013-07-25 08:23:38

Re: systemd 206 systemd --user problem

#43 2013-07-25 08:28:30

Re: systemd 206 systemd --user problem

#44 2013-07-25 09:11:16

Re: systemd 206 systemd --user problem

#45 2013-07-25 12:12:29

Re: systemd 206 systemd --user problem

#46 2013-07-25 12:52:34

Re: systemd 206 systemd --user problem

#47 2013-07-25 18:06:30

Re: systemd 206 systemd --user problem

#48 2013-07-25 22:53:27

Re: systemd 206 systemd --user problem

#49 2013-07-25 23:06:10

Re: systemd 206 systemd --user problem

#50 2013-07-26 02:52:43

Re: systemd 206 systemd --user problem

Board footer