systemd 206 systemd --user problem

falconindy · 2013-08-16 02:21:38

hobarrera wrote:

If you read properly, you'll notice I said there's a devel list, but not one for users, and my request for help regarding the changes never made it past moderation.

I've no idea what moderation you're referring to. If you subscribe to the list you can post there. Users ask user-based questions all the time.

Last edited by falconindy (2013-08-16 02:21:50)

ngoonee · 2013-08-16 02:53:32

hobarrera wrote:

ngoonee wrote:
That's probably because its meant to be integrated, not used. The main question is whether systemd --user is actually supported or whether its an oddity which is subject to change.
Integrated into what? DEs won't use it because it's linux-specific, and even less if there's no documentation of upstream response on how to upgrade.

Integrated by the distros. Ideally users don't even know what systemd is. The administrator for my university's cluster has no idea what systemd is (and he's been using linux for research for years and is currently using it with the latest opensuse.

HalosGhost · 2013-08-16 02:57:59

I've had `systemd --user` functioning without issue even with systemd-206. I understand that's not the case for everyone and it doesn't have official support. But, I just want to make sure people know that it is a valid avenue for managing user-sessions.

All the best,

-HG

hobarrera · 2013-08-16 17:27:29

falconindy wrote:

hobarrera wrote:
If you read properly, you'll notice I said there's a devel list, but not one for users, and my request for help regarding the changes never made it past moderation.
I've no idea what moderation you're referring to. If you subscribe to the list you can post there. Users ask user-based questions all the time.

I couldn't:

Return-Path: systemd-devel-bounces+hugo=osvaldobarrera.com.ar@lists.freedesktop.org
Delivered-To: hugo@osvaldobarrera.com.ar
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]);
        by mx1.ubertech.com.ar (OpenSMTPD) with ESMTP id 604e22e9;
        for <hugo@osvaldobarrera.com.ar>;
        Thu, 25 Jul 2013 23:13:50 +0000 (GMT)
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
        by gabe.freedesktop.org (Postfix) with ESMTP id D6917E7248
        for <hugo@osvaldobarrera.com.ar>; Thu, 25 Jul 2013 16:13:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Your message to systemd-devel awaits moderator approval
From: systemd-devel-bounces@lists.freedesktop.org
To: hugo@osvaldobarrera.com.ar
Message-ID: <mailman.79180.1374794037.26620.systemd-devel@lists.freedesktop.org>
Date: Thu, 25 Jul 2013 16:13:57 -0700
Precedence: bulk
X-BeenThere: systemd-devel@lists.freedesktop.org
X-Mailman-Version: 2.1.13
List-Id: systemd Development Mailing List <systemd-devel.lists.freedesktop.org>
X-List-Administrivia: yes
Sender: systemd-devel-bounces+hugo=osvaldobarrera.com.ar@lists.freedesktop.org
Errors-To: systemd-devel-bounces+hugo=osvaldobarrera.com.ar@lists.freedesktop.org

Your mail to 'systemd-devel' with the subject
                                             
    Support channels / Documentation?         

Is being held until the list moderator can review it for approval.

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:
                                             
    http://lists.freedesktop.org/mailman/confirm/systemd-devel/6ac18c099fdaaee342f4cd9ba457f8e775f8f36f

The message never made it past moderation:
http://lists.freedesktop.org/archives/s … /date.html

falconindy · 2013-08-16 18:50:55

falconindy wrote:

If you subscribe to the list you can post there.

and according to the subscriber list, you aren't subscribed.

Stebalien · 2013-08-16 19:26:37

It works pretty well for managing persistent user daemons but not so well for managing session specific applications. There are a few GNOME people trying to use it but it doesn't play well with polkit at the moment (https://bugs.freedesktop.org/show_bug.cgi?id=67728).

I'm currently using it to manage dbus, dunst, gconf, at-spi, offlineimap, pulseaudio, tmux, gconf, etc. If you have a specific problem I might be able to help; I plan on eventually uploading my units to github and writing full tutorial but the following should get you started:

You need to set DISPLAY in your user@.service file (I put it in /etc/systemd/system/user@.service.d/environment.conf).

You will probably want some way to delay the start of X applications until the first X server starts. You can do this using xorg target and xorg path units:
xorg.path:

[Unit]
Description=Xorg Display Exists

[Path]
PathExists=%t/X11-display
Unit=xorg.target

[Install]
WantedBy=paths.target

You will probably also need a way to forward your xauthority file. While you could theoretically just set the XAUTHORITY environment file, I had some problems with this so I use the following unit (this one is for lightdm, your xauthority is probably at ~/.Xauthority):

[Unit]
Description=LightDM XAuthority Forwarding
ConditionPathExists=/run/lightdm/%u/xauthority
Before=xorg.target

[Service]
Type=oneshot
Environment=XAUTHORITY=/run/lightdm/%u/xauthority
ExecStart=/usr/bin/xhost +si:localuser:%u

[Install]
RequiredBy=xorg.target

To prevent services from starting before gnome-keyring, I use the following units and have all units that need the keyring ordered after keyring.target:
gnome-keyring.path:

[Unit]
Description=Keyring Control path exists

[Path]
PathExistsGlob=%t/keyring-*/control

[Install]
WantedBy=paths.target

gnome-keyring.service:

[Unit]
Description=Setup Gnome Keyring Environment
Before=keyring.target
Wants=keyring.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'shopt -s nullglob; VAR=(%t/keyring-*/); test -n "$VAR" && /usr/bin/systemctl --user set-environment "GNOME_KEYRING_CONTROL=$VAR"'

keyring.target:

[Unit]
Description=Keyring Target

I've tried patching gnome-keyring to use socket activation but it doesn't really work (mostly because gnome-keyring doesn't actually have a way to specify where it's control socket should be created). However, if you are interested in working on this, here is a patch:

diff -ru a/configure.ac b/configure.ac
--- a/configure.ac	2013-05-04 15:55:14.000000000 -0400
+++ b/configure.ac	2013-07-31 11:44:03.483758624 -0400
@@ -372,6 +372,19 @@
 AC_SUBST([LIBGCRYPT_LIBS])
 
 # -------------------------------------------------------------------
+# systemd
+#
+
+PKG_CHECK_MODULES(SD, libsystemd-daemon)
+
+DAEMON_CFLAGS="$DAEMON_CFLAGS $SD_CFLAGS"
+DAEMON_LIBS="$DAEMON_LIBS $SD_LIBS"
+
+AC_SUBST(SD_CFLAGS)
+AC_SUBST(SD_LIBS)
+
+
+# -------------------------------------------------------------------
 # libcap-ng
 #
 
diff -ru a/daemon/control/gkd-control-server.c b/daemon/control/gkd-control-server.c
--- a/daemon/control/gkd-control-server.c	2013-05-01 12:34:54.000000000 -0400
+++ b/daemon/control/gkd-control-server.c	2013-07-31 11:45:58.080460191 -0400
@@ -34,6 +34,8 @@
 
 #include "login/gkd-login.h"
 
+#include <systemd/sd-daemon.h>
+
 #include <errno.h>
 #include <fcntl.h>
 #include <string.h>
@@ -379,31 +381,40 @@
 	gchar *path;
 	int sock;
 
-	path = g_strdup_printf ("%s/control", gkd_util_get_master_directory ());
-	egg_cleanup_register (control_cleanup_channel, path);
-
-	unlink (path);
-
-	sock = socket (AF_UNIX, SOCK_STREAM, 0);
-	if (sock < 0) {
-		g_warning ("couldn't open socket: %s", g_strerror (errno));
-		return FALSE;
-	}
-
-	memset (&addr, 0, sizeof (addr));
-	addr.sun_family = AF_UNIX;
-	g_strlcpy (addr.sun_path, path, sizeof (addr.sun_path));
-	if (bind (sock, (struct sockaddr*) &addr, sizeof (addr)) < 0) {
-		g_warning ("couldn't bind to control socket: %s: %s", path, g_strerror (errno));
-		close (sock);
-		return FALSE;
-	}
-
-	if (listen (sock, 128) < 0) {
-		g_warning ("couldn't listen on control socket: %s: %s", path, g_strerror (errno));
-		close (sock);
-		return FALSE;
-	}
+    int nfd = sd_listen_fds(0);
+    if (nfd > 1) {
+        g_warning ("systemd passed too many sockets");
+        return FALSE;
+    } else if (nfd == 1) {
+        sock = SD_LISTEN_FDS_START + 0;
+    } else {
+
+        path = g_strdup_printf ("%s/control", gkd_util_get_master_directory ());
+        egg_cleanup_register (control_cleanup_channel, path);
+
+        unlink (path);
+
+        sock = socket (AF_UNIX, SOCK_STREAM, 0);
+        if (sock < 0) {
+            g_warning ("couldn't open socket: %s", g_strerror (errno));
+            return FALSE;
+        }
+
+        memset (&addr, 0, sizeof (addr));
+        addr.sun_family = AF_UNIX;
+        g_strlcpy (addr.sun_path, path, sizeof (addr.sun_path));
+        if (bind (sock, (struct sockaddr*) &addr, sizeof (addr)) < 0) {
+            g_warning ("couldn't bind to control socket: %s: %s", path, g_strerror (errno));
+            close (sock);
+            return FALSE;
+        }
+
+        if (listen (sock, 128) < 0) {
+            g_warning ("couldn't listen on control socket: %s: %s", path, g_strerror (errno));
+            close (sock);
+            return FALSE;
+        }
+    }
 
 	if (!egg_unix_credentials_setup (sock) < 0) {
 		close (sock);

Finally, if you want your user dbus services (gconf, dconf, etc.) managed by systemd, you will need to add `SystemdService` lines to the dbus service files (/usr/share/dbus-1/services/<interface>.service).

EvanPurkhiser · 2013-08-18 13:39:21

I spent some time tonight tinkering with 206 and here's my anecdotal experience:

Most things work fine as long as you set the XDG_RUNTIME_DIR=/run/user/%I and set all your environment variables in the user@.service (or do what I do and run a script to bring in the env instead of starting systemd --user directly)
It doesn't seem like there's going to be a way to get rid of the damn background shell after logging in and starting x
I'm fairly sure the reason that you can't run privileged commands (systemctl reboot, etc) is because when you try and run the command from a process started from your systemd --user instance the user session started by pam_systemd.so doesn't know about it so it's denied access. It doesn't matter if the session is active or not unless the process happens as a child of the logind user session.

To me it seems like the biggest problem is that you can no longer use PAMName=login to have the service start a logind user session. I think if you still could do this there would be no problem.

Edit: I've just confirmed my suspicion for that last bullet point. In order for privledged commands to work properly systemd --user needs to be the session leader

If you run `loginctl session-status [session-id]` you'll see that the systemd --user instance is not listed. That is why privileged commands don't work.

Last edited by EvanPurkhiser (2013-08-19 00:06:41)

Stebalien · 2013-08-18 17:17:50

Most things work fine as long as you set the XDG_RUNTIME_DIR=/usr/lib/%I and set all your environment variables in the user@.service (or do what I do and run a script to bring in the env instead of starting systemd --user directly)

I think you mean `/run/user/%I`.

I'm fairly sure the reason that you can't run privileged commands (systemctl reboot, etc) is because when you try and run the command from a process started from your systemd --user instance the user session started by pam_systemd.so doesn't know about it so it's denied access. It doesn't matter if the session is active or not unless the process happens as a child of the logind user session.

That's why I created the bug report. Restricting privileged commands to the active session provides no additional security over restricting privileged commands to the active user (user of the active session) (ptrace etc.).

In general, I don't think `systemd --user` is supposed to be used to manage session processes at all (just user daemons).

EvanPurkhiser · 2013-08-19 11:59:57

I didn't notice your bug report for polkit Stebalien, just read through it now, sounds promising.

Reading through some of what you wrote actually made me question myself about how systemd --user should be used. I certainly agree that it should be used to manage session independent daemons (ssh-agent, tmux, transmission, pulseaudio, etc..).

But at the same time I really liked the ability to have it manage my per-session things (terminal, chrome, X, WM, xbindkeys, etc..). The new systemd-run utility makes me especially believe that it's even better suited for this now than it was before.

I'm still tinkering around right now to see if I can get it to start it's own user session like it did before.

I did discover something though while reading through the source that might be of interest. It looks like when the user@.service gets started it is indeed supposed to have the XDG_RUNTIME_DIR env variable set. See here.. However, it looks like the problem is that no 'pam application' configuration file named "systemd-shared' exists in /etc/pam.d/. If you run `ln -s system-login /etc/pam.d/systemd-shared` then the systemd --user instance will be accessible without having to make any modifications to the user@.service. (Though I'm not sure what PAM directives should really be in systemd-shared)

EvanPurkhiser · 2013-09-20 09:59:29

So now that systemd-207 has hit [core] has anyone found any good solutions to continue to use systemd --user to manage X like in 204?

msthev · 2013-09-20 10:39:15

It's manageable, but a little bit unelegant…
1. Create /etc/systemd/system/user@.service.d/env.conf:

[Service]
Environment=XDG_RUNTIME_DIR=/run/user/%I SHELL=%s

2. Create an empty target ($XDG_CONFIG_DIR/systemd/user/empty.target) and set it as default.

3. In ~/.profile (or whatever startup file you prefer), when you want to start X (in my case it's `if [ "$XDG_VTNR" = 1 ] (…)`, change

/usr/lib/systemd/systemd --user

to

systemctl --user start session.target

Note: because of the way systemd --user is now started, you have two different environments (variable sets): one from login, and one from systemd. The latter one doesn't include stuff you have in ~/.profile, so you need to set them manually. Either:

Specify them in Environment= / EnvironmentFile= in /etc/systemd/system/user@.service.d/whatever.conf (unelegant, since it's system global);
Same as above, but do this for every service in your user config directory (of course you can do this in *.service, you don't need to create *.service.d/*.conf);
Convince systemd developers to enable specifying Environment= for .target units (so that you could set all the environment in one file);
In ~/.profile, before executing `systemctl --user start session.target`, do `systemctl --user set-environment VAR1="bla" VAR2=(…)`.

Frankly, I think the last one is the best in terms of both correctness and manageability.

EvanPurkhiser · 2013-09-20 10:53:37

I think the two biggest problems we have now that weren't problems before are:

You can no longer use commands that use polkit such as systemctl reboot or systemctl poweroff without having to type the root password. (See Stebalien posts)
There's going to be a login and bash process lingering around on whatever VT you logged in at. You can't exit the login or the user session will exit killing the systemd --user instance.

I was hoping a fix would be made in 207 so that you could use PAMName=login like before and not get permission errors. I did a little snooping through the source to try and determine what's causing the error, but didn't get far enough to figure out why a different cgroup is used than the one that had the user permissions set on it. I believe this is actually a bug in systemd, but can't say for sure.

pablox · 2013-09-21 05:43:02

msthev wrote:

It's manageable, but a little bit unelegant…
1. Create /etc/systemd/system/user@.service.d/env.conf:
[Service]
Environment=XDG_RUNTIME_DIR=/run/user/%I SHELL=%s
2. Create an empty target ($XDG_CONFIG_DIR/systemd/user/empty.target) and set it as default.
[snip]

What do you mean by that? How can I set it as a default?

HalosGhost · 2013-09-21 13:53:39

EvanPurkhiser wrote:

You can no longer use commands that use polkit such as systemctl reboot or systemctl poweroff without having to type the root password.

Well, those commands must be run as root, that does not actually mean that you'll have to type the root password.

As for the setup mentioned earlier in this thread, I have something similar, though not quite the same. and it is working fine, though I am having trouble replicating the setup on a new install (though I think the issue is largely unrelated). Once I verify that it can be setup from a new install, I will post it here.

All the best,

-HG

pablox · 2013-09-21 15:45:55

Ehm, well... I did something but I dunno why it worked (trying to follow @msthev idea), it just worked by following the first step....

msthev wrote:

1. Create /etc/systemd/system/user@.service.d/env.conf:
[Service]
Environment=XDG_RUNTIME_DIR=/run/user/%I SHELL=%s

I don't have any call to `systemctl --user` or `systemctl --user start session.target`...

Edit1:

Oh well... after fiddling around it looks like `/etc/profile` it's not being loaded at all, but sourcing `/etc/zsh/zprofile` by hand from `~/.zprofile` works as a workaround.

Edit2:

I touched files from /etc/zsh/zprofile and /etc/profile to see if those files were being sourced (taking out the call from ~/.zprofile of course), and the files are being read (both files appear), but I can't see variables that are defined inside the /etc/profile.d/ directory (like infinality-bundle for example, or the MOZPATH, ecc).

Edit3:

I can't find a way to correctly load from /etc/profile as msthev said before... sourcing them as I said before doesn't actually work, and every chance I've done to source /etc/profile doesn't work (in a service, by hand, ecc).

It's just the "new" systemd --user thingie doesn't load /etc/profile as a feature or it is a bug? Are we moving towards a world without /etc/profile.d/* stuff?

Last edited by pablox (2013-09-21 17:35:50)

darkraven · 2013-09-21 18:55:02

Ok, I've patched systemd myself so I can start systemd --user in my .xinitrc now, just like good old times.

Still waiting for a better solution coming from upstream though.

Last edited by darkraven (2013-09-21 19:01:56)

msthev · 2013-09-21 19:14:50

pablox wrote:

What do you mean by that? How can I set it as a default?

Create $XDG_CONFIG_HOME/systemd/user/default.target which points to an empty target (in my case it's a symlink to `empty.target`).

pablox wrote:

I don't have any call to `systemctl --user` or `systemctl --user start session.target`...

I wasn't clear about this; you don't have to do this, that's right. My point was to create a setup when everything in your X session is started only once and only when you want to — that's why I suggested starting an empty target by default and switching to the real one when needed.

pablox wrote:

Oh well... after fiddling around it looks like `/etc/profile` it's not being loaded at all, but sourcing `/etc/zsh/zprofile` by hand from `~/.zprofile` works as a workaround.

That's the part of my post about variables — since /etc/profile and ~/.profile are not sourced by systemd, you need to set all desired variables manually. I don't think there is a way to tell systemd to do this automagically, since systemd aims to be "shell-free"…

pablox wrote:

It's just the "new" systemd --user thingie doesn't load /etc/profile as a feature or it is a bug? Are we moving towards a world without /etc/profile.d/* stuff?

systemd never loaded /etc/profile, the environment was inherited from the login shell (I think — before v206 I started --user manually, not from user@.service). Now that systemd --user is started without this inheritance, the services have an environment which doesn't include things in /etc/profile. I don't like this, but what can you do… systemd devs have a particular vision of an "ideal setup" (the one that they have / want to have), and if you want something else, you're on your own (you can create hacks like this or give up on session management and switch to "the old way", with .xinitrc and its own set of problems).

darkraven wrote:

Ok, I've patched systemd myself so I can start systemd --user in my .xinitrc now, just like good old times.

I guess it's not possible to just mask user@.service? (Be right back, going to check this)

Edit:
It seems to be possible, but of course logind gets angry:

$ journalctl -p err
(…)
systemd-logind[187]: Failed to start unit user@1000.service: Unit user@1000.service is masked.
systemd-logind[187]: Failed to start user service: Unit user@1000.service is masked.
login[193]: pam_systemd(login:session): Failed to connect to system bus: Did not receive a reply.
  Possible causes include: the remote application did not send a reply, the message bus security
  policy blocked the reply, the reply timeout expired, or the network connection was broken.

Last edited by msthev (2013-09-21 19:37:24)

pablox · 2013-09-21 20:55:52

msthev wrote:

pablox wrote:
What do you mean by that? How can I set it as a default?
Create $XDG_CONFIG_HOME/systemd/user/default.target which points to an empty target (in my case it's a symlink to `empty.target`).
pablox wrote:
I don't have any call to `systemctl --user` or `systemctl --user start session.target`...
I wasn't clear about this; you don't have to do this, that's right. My point was to create a setup when everything in your X session is started only once and only when you want to — that's why I suggested starting an empty target by default and switching to the real one when needed.
pablox wrote:
Oh well... after fiddling around it looks like `/etc/profile` it's not being loaded at all, but sourcing `/etc/zsh/zprofile` by hand from `~/.zprofile` works as a workaround.
That's the part of my post about variables — since /etc/profile and ~/.profile are not sourced by systemd, you need to set all desired variables manually. I don't think there is a way to tell systemd to do this automagically, since systemd aims to be "shell-free"…
pablox wrote:
It's just the "new" systemd --user thingie doesn't load /etc/profile as a feature or it is a bug? Are we moving towards a world without /etc/profile.d/* stuff?
systemd never loaded /etc/profile, the environment was inherited from the login shell (I think — before v206 I started --user manually, not from user@.service). Now that systemd --user is started without this inheritance, the services have an environment which doesn't include things in /etc/profile. I don't like this, but what can you do… systemd devs have a particular vision of an "ideal setup" (the one that they have / want to have), and if you want something else, you're on your own (you can create hacks like this or give up on session management and switch to "the old way", with .xinitrc and its own set of problems).

Thanks for the insight. It makes a lot more sense that way. The issue of course, is that still is experimental, so quite logical to expect that most software still uses the "old way" (loading /etc/profile.d/*.sh stuff). Either way, it looks like the devs are still missing a elegant way to load environment stuff. The "..../env.conf" in /etc/systemd/.... seemed "better", but I'm quite surprised it can't load from an environment from *my* user.

msthev wrote:

Same as above, but do this for every service in your user config directory (of course you can do this in *.service, you don't need to create *.service.d/*.conf);

What did you mean by that?

EDIT: Nevermind the last part, I think I know what you mean.

I have now created a drop-in file following your idea about env.conf in my window manager service:

~/.config/systemd/user/xmonad@.service.d/env.conf

Inside the following works:

[Service]
Environment=WORKS=yes
EnvironmentFile=%h/.systemd-profile

# $HOME/.systemd-profile
A_VARIABLE=blabla
ANOTHER_ENV_VAR="here I am"

Both ways allows those variables to be available.

Of course, systemctl --user show-environment doesn't list them, but it's not too hard run `systemctl --user set-environment ` for each line of another file containing the desired variables.

Last edited by pablox (2013-09-21 22:20:44)

EvanPurkhiser · 2013-09-21 22:28:13

HalosGhost wrote:

EvanPurkhiser wrote:
You can no longer use commands that use polkit such as systemctl reboot or systemctl poweroff without having to type the root password.
Well, those commands must be run as root, that does not actually mean that you'll have to type the root password.

The idea is that you shouldn't have to type a password at all though because of the policies. If the program executing these commands isn't in part of a session, then you will get access denied when running this command as a non-root user. If the program executing these commands is part of the current session, but the session isn't considered "active" (there may be some other case here, I'm not positive), then you will get "Authentication is needed to run ...." and you will have to type the root password.

Of course you can use sudo to execute these commands, but then you have to type your password.

Since the user@.service isn't part of the session then you will just get access denied and are forced to use `sudo systemctl ...`

FrozenCow · 2013-09-22 02:32:01

I also had problems with my systemd --user setup. I had things setup that systemd --user would start xorg, awesomewm (and a couple of applications). Screen went black upon starting.

With the suggestions in this thread I've fixed it somewhat properly:

First I disabled user-session@me, since that's what I used before.
Next problem was the environment variables not being set for awesome and the applications (which is what seemed to be causing the black screen). Most important one is "DISPLAY=:0", but others might also affect your setup (PATH and such).

The env.conf file msthev mentioned earlier seemed like the way to go to set the environment variables for the whole user-session. I couldn't find a way to load the environment variabels from /etc/profile at runtime, so I made a script that converts the variables from /etc/profile (and DISPLAY=:0) to env.conf.

https://gist.github.com/FrozenCow/6654245

generate-systemd-envconf-from-profile.sh outputs what should be put in env.conf, so:

[Service]
Environment="DISPLAY=:0"
Environment="PATH=/home/me/.bin:/usr/local/bin:/usr/bin"
...

... and a lot more.

example.sh shows how you can use the script (and put it in /etc/systemd/system/user@1000.service.d/env.conf)
Also, don't be a smartass like I was and try user@yourname instead of user@youruid, because that will NOT work correctly without overriding the default user@.service.

The upside of this method is that it isn't hacky on the systemd side. The downside is that the script must be run every time /etc/profile (or something related) is changed. I'm interested what the Systemd devs will do to solve this issue properly, but for now this works nicely for me. My profile won't change that often. I still need to fix autologin though, but that's for another time.

EvanPurkhiser · 2013-09-22 02:45:38

I'm not positive that this works in systemd 205+, but the way I set my environment variables in the systemd --user instance was to set ExecStart=/usr/lib/systemd/systemd-user-startup and then put this script at that location. This will load all of the environment variables in /etc/profile as well as anything in $HOME/.confg/bash/environment. Then start systemd --user which should inherit those environment variables (again I'm not positive they are inherited in 204+)

If that doesn't work in 204+ you could use the same script and then do something like env -0 | xargs -0 systemd --user set-environment and then have the script executed with ExecStartPost.

Last edited by EvanPurkhiser (2013-09-22 02:45:54)

pablox · 2013-09-22 04:48:03

@FrozenCow

Looks nice, I'll give it a try. I also have a workaround, that's not that ambitious. I will post it as soon as I'm sure it works.

@EvanPurkhiser

I'm trying to follow your instructions but I'm not sure I am doing correctly... that ExecStart= line.. which file is?

EvanPurkhiser · 2013-09-22 04:59:17

I'm still using 204, but here's what my user-session@.service file looks like.

if you were going to use this with systemd 204+ you will want to override the user@.service file by creating the file `/etc/systemd/system/user@.service.d/with-env.conf` and putting this in there:

[Service]
ExecStart=/usr/lib/systemd/systemd-user-startup

(I think that will override the ExecStart, if that file won't start you may need to just copy /usr/lib/systemd/system/user@.service to /etc/systemd/system and just edit the ExecStart line there)

And make sure that this file is there.

You may also need to add export XDG_RUNTIME_DIR="/run/user/$(id -u)" to that file.

Then when you start user@.service it will execute the systemd-user-startup script which should source in all of your environment variables.

msthev · 2013-09-22 10:47:04

@EvanPurkhiser
DBUS_SESSION_BUS_ADDRESS is already set in /usr/lib/systemd/system/user@.service, you only need to set XDG_RUNTIME_DIR. I suggest moving those exports to the .service file itself (with Environment=) — that way you avoid invoking getent and id -u, since the results are already known before the ExecStart is executed (shell under %s and instance name under %I, which happens to be user's uid).
But besides that, your solution is really awesome.

@darkraven
Could you share your patches?

@topic
I have found another problem.
XDG Base Directory Specification

The lifetime of the [$XDG_RUNTIME_DIR] directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed.

It worked in v < 205. And look what we have now:

$ loginctl
   SESSION        UID USER             SEAT            
         3       1000 msthev           seat0           

1 sessions listed.
$ l /run/user/
total 0
drwx------ 3 root   root   60 Sep 22 12:14 0/
drwx------ 7 msthev users 240 Sep 22 12:16 1000/
$ ps -ef | grep 'systemd --user'
root       307     1  0 12:14 ?        00:00:00 /usr/lib/systemd/systemd --user
msthev     317     1  0 12:14 ?        00:00:00 /usr/lib/systemd/systemd --user
$ journalctl /usr/lib/systemd/systemd-logind -b
systemd-logind[192]: New seat seat0.
systemd-logind[192]: New session 1 of user root.
systemd-logind[192]: New session 2 of user msthev.
systemd-logind[192]: Removed session 2.
systemd-logind[192]: Removed session 1.
systemd-logind[192]: New session 3 of user msthev.

darkraven · 2013-09-22 14:15:42

@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.

Edit: Patch updated, fixing a bug

Last edited by darkraven (2013-09-23 13:00:22)

Arch Linux

#76 2013-08-16 02:21:38

Re: systemd 206 systemd --user problem

#77 2013-08-16 02:53:32

Re: systemd 206 systemd --user problem

#78 2013-08-16 02:57:59

Re: systemd 206 systemd --user problem

#79 2013-08-16 17:27:29

Re: systemd 206 systemd --user problem

#80 2013-08-16 18:50:55

Re: systemd 206 systemd --user problem

#81 2013-08-16 19:26:37

Re: systemd 206 systemd --user problem

#82 2013-08-18 13:39:21

Re: systemd 206 systemd --user problem

#83 2013-08-18 17:17:50

Re: systemd 206 systemd --user problem

#84 2013-08-19 11:59:57

Re: systemd 206 systemd --user problem

#85 2013-09-20 09:59:29

Re: systemd 206 systemd --user problem

#86 2013-09-20 10:39:15

Re: systemd 206 systemd --user problem

#87 2013-09-20 10:53:37

Re: systemd 206 systemd --user problem

#88 2013-09-21 05:43:02

Re: systemd 206 systemd --user problem

#89 2013-09-21 13:53:39

Re: systemd 206 systemd --user problem

#90 2013-09-21 15:45:55

Re: systemd 206 systemd --user problem

#91 2013-09-21 18:55:02

Re: systemd 206 systemd --user problem

#92 2013-09-21 19:14:50

Re: systemd 206 systemd --user problem

#93 2013-09-21 20:55:52

Re: systemd 206 systemd --user problem

#94 2013-09-21 22:28:13

Re: systemd 206 systemd --user problem

#95 2013-09-22 02:32:01

Re: systemd 206 systemd --user problem

#96 2013-09-22 02:45:38

Re: systemd 206 systemd --user problem

#97 2013-09-22 04:48:03

Re: systemd 206 systemd --user problem

#98 2013-09-22 04:59:17

Re: systemd 206 systemd --user problem

#99 2013-09-22 10:47:04

Re: systemd 206 systemd --user problem

#100 2013-09-22 14:15:42

Re: systemd 206 systemd --user problem

Board footer