Bug 67471 - >=sys-apps/systemd-205 - systemd --user: Failed to create root cgroup hierarchy: Permission denied
Summary: >=sys-apps/systemd-205 - systemd --user: Failed to create root cgroup hierarc...
Status: RESOLVED NOTABUG
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
: 67694 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-29 11:43 UTC by Franz Fellner
Modified: 2015-02-10 21:21 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Franz Fellner 2013-07-29 11:43:52 UTC
$ systemd --user
Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied

v205 release notes mention quite some changes regarding cgroups.
After downgrading to systemd-204 everything works as expected.
Comment 1 Zbigniew Jedrzejewski-Szmek 2013-07-29 14:22:08 UTC
Directly spawning systemd --user doesn't work anymore. A per-user systemd instance is launched when the user first logs in. Access issues should be fixed in systemd-206 (commit 8aa75193662).

I'm marking this as "not a bug", because it's working as currently intended.
Comment 2 Franz Fellner 2013-07-29 14:42:31 UTC
Probably I am missing something. Because there was no user session.
Of course I tried to run "systemctl --user start <service>" because I knew I started systemd in my .xinitrc. It did not start the service and the error message was not really helpful, something like "/bin/false returned 1".

I am using Gentoo. I first noticed the issue when trying to run offlineimap per user as systemd-service, using systemd-206.
Comment 3 Zbigniew Jedrzejewski-Szmek 2013-07-29 15:03:42 UTC
(In reply to comment #2)
> Probably I am missing something. Because there was no user session.
user@<UID>.service should be started by logind. Nevertheless, there are various issues with that currently.

> Of course I tried to run "systemctl --user start <service>" because I knew I
> started systemd in my .xinitrc. It did not start the service and the error
> message was not really helpful, something like "/bin/false returned 1".
Yes, that's currently not supported.
Comment 4 Franz Fellner 2013-07-29 16:07:00 UTC
So with systemd >=205, there is no possibility for users to start own services?
Is it planned to add it back, again? Are there alternative solutions?
Comment 5 Zbigniew Jedrzejewski-Szmek 2013-07-29 16:48:33 UTC
(In reply to comment #4)
> So with systemd >=205, there is no possibility for users to start own
> services?
> Is it planned to add it back, again? Are there alternative solutions?

It is possible. user@.service starts systemd --user for the user. You should be able to launch units there. By "issues" I meant that a) probably some bugs lurking, and b) many external things haven't been updated to the new scheme (e.g. integration with display manager is one of them). So things work, but might require tweaking.
Comment 6 Franz Fellner 2013-07-29 17:14:43 UTC
(In reply to comment #5)
> By "issues" I meant that a) probably some
> bugs lurking, and b) many external things haven't been updated to the new
> scheme (e.g. integration with display manager is one of them). So things
> work, but might require tweaking.
I am not using any Display Manager. I am logging in on TTY1 and run startx. So where can I read something about the "tweaking" (hopefully only some settings)?
Comment 7 Zbigniew Jedrzejewski-Szmek 2013-07-29 17:39:27 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > By "issues" I meant that a) probably some
> > bugs lurking, and b) many external things haven't been updated to the new
> > scheme (e.g. integration with display manager is one of them). So things
> > work, but might require tweaking.
> I am not using any Display Manager. I am logging in on TTY1 and run startx.
> So where can I read something about the "tweaking" (hopefully only some
> settings)?

First, make sure that user@.service has been sucessfully started, and that systemctl --user works.

For "tweaking", see e.g. thread http://lists.freedesktop.org/archives/systemd-devel/2013-July/012354.html.
Comment 8 Franz Fellner 2013-07-30 07:22:09 UTC
(In reply to comment #7)
> First, make sure that user@.service has been sucessfully started, and that
> systemctl --user works.
I just don't get it to work properly.
I enabled user@.service.

$ systemctl status user-1001.slice
user-1001.slice
   Loaded: loaded
   Active: active since Di 2013-07-30 08:02:33 CEST; 6min ago
   CGroup: /user.slice/user-1001.slice
           └─session-c1.scope
             ├─1691 /usr/bin/sddm
             ├─1759 /usr/bin/X :0 -auth /run/sddm//A:0-EXboAB -nolisten tcp vt07
             ├─1769 awesome
             ├─1780 /usr/bin/dbus-launch --sh-syntax --exit-with-session
             ├─1781 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 13 --session
             ├─1791 /bin/sh /usr/local/bin/term
             ├─1792 urxvt -bg black -fg grey -hc blue -cr white -pr black -pr2 grey -fn xft:Dejavu Sans Mono:pixelsiz...
             ├─1793 zsh
             ├─1869 /opt/firefox/firefox
             ├─1916 /usr/libexec/gconfd-2
             ├─1943 /opt/firefox/plugin-container /opt/Adobe/flash-player/flash-plugin/libflashplayer.so -greomni /op...
             └─1975 systemctl status user-1001.slice

$ systemctl status user@1001.service
user@1001.service - User Manager for 1001
   Loaded: loaded (/usr/lib64/systemd/system/user@.service; linked)
   Active: inactive (dead)

There is no systemd --user running. So my user services don't get started.
Are there any prerequisites I am missing? Is there really no documentation on how this stuff is supposed to work? I found a thread [1] about this issue on archlinux forums, but even with tat info I could not get it work.

[1] https://bbs.archlinux.org/viewtopic.php?id=167115
Comment 9 Zbigniew Jedrzejewski-Szmek 2013-08-03 13:41:21 UTC
*** Bug 67694 has been marked as a duplicate of this bug. ***
Comment 10 Franz Fellner 2015-02-09 16:17:51 UTC
Just tried it again, and I now (with systemd-218) have systemd --user started automatically at login. But it does not start my user-services. Starting manually works, but especially offlineimap should start automatically.
The service file:

$ cat ~/.config/systemd/user/offlineimap.service 
[Unit]
Description=Start offlineimap as a daemon
Wants=network-online.target
After=network.target

[Service]
ExecStart=/usr/bin/python2.7 /usr/bin/offlineimap -u basic
KillSignal=SIGUSR2
Restart=always

[Install]
WantedBy=multi-user.target

###

systemctl --user status offlineimap
● offlineimap.service - Start offlineimap as a daemon
   Loaded: loaded (/home/franz/.config/systemd/user/offlineimap.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Is there something wrong with the service file? Is something specific needed for this to work? Or is this use case still "not supported"?
I migrated from an own static network service-file to systemd-networkd just to get a working inplementation for network-online.target. Did not help.

Any hint is appreciated.
Comment 11 Lennart Poettering 2015-02-10 11:01:54 UTC
There is no such target "multi-user.target" in --user contexts... Use default.target in [Install]'s WantedBy= instead...
Comment 12 Franz Fellner 2015-02-10 21:21:32 UTC
(In reply to Lennart Poettering from comment #11)
> There is no such target "multi-user.target" in --user contexts... Use
> default.target in [Install]'s WantedBy= instead...

Yes, thx, that fixed my issues! I actually borrowed the file from arch wiki, and several other service files I found (also for --user) used multi-user.target.

BTW.: Is there an easy way to configure service restarting? Offlineimap + GMail make problems when suspending the machine. Restarting Offlineimap fixes this issue. I now created a new service "offlineimap-resume", works. But it would be nice to have something like "RestartAfter=suspend.target". Would that be possible?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.