On my Ubuntu 18.04.1 system the User Manager of systemd fails to start. I suppose this to be the root cause of other problems that I currently encounter. Any ideas how to get rid of this?

systemd version

$ systemd --version
systemd 237

Ubuntu 18.04.1 LTS Version

$ uname -a
Linux example.com 4.15.0 #1 SMP Wed Jul 25 19:09:31 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

systemctl unit status

 $ sudo systemctl status [email protected][email protected] - User Manager for UID 1001
   Loaded: loaded (/lib/systemd/system/[email protected]; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/[email protected]
   Active: failed (Result: protocol) since Tue 2019-01-08 10:33:08 CET; 1min 42s ago
  Process: 315 ExecStart=/lib/systemd/systemd --user (code=exited, status=1/FAILURE)
 Main PID: 315 (code=exited, status=1/FAILURE)

Jan 08 10:33:08 example.com systemd[1]: Starting User Manager for UID 1001...
Jan 08 10:33:08 example.com systemd[315]: pam_unix(systemd-user:session): session opened for user mischa by (uid=0)
Jan 08 10:33:08 example.com systemd[1]: [email protected]: Failed with result 'protocol'.
Jan 08 10:33:08 example.com systemd[1]: Failed to start User Manager for UID 1001.

The syslog says

Jan  8 10:33:08 example.com systemd[1]: Starting User Manager for UID 1001...
Jan  8 10:33:08 example.com systemd[315]: Failed to create /user.slice/user-1001.slice/[email protected]/init.scope control group: Permission denied
Jan  8 10:33:08 example.com systemd[315]: Failed to allocate manager object: Permission denied
Jan  8 10:33:08 example.com systemd[1]: [email protected]: Failed with result 'protocol'.
Jan  8 10:33:08 example.com systemd[1]: Failed to start User Manager for UID 1001.

My user service unit file

$ cat /lib/systemd/system/[email protected]
#  SPDX-License-Identifier: LGPL-2.1+
#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

Description=User Manager for UID %i

ExecStart=-/lib/systemd/systemd --user
Delegate=pids cpu

4 Answers 4


This happened to me after upgrading Ubuntu... you might want to check permissions in the following directory chain.


So you need to make sure other has read and execute permissions all the way up so your user can create that directory. For me, the upgrade must not have set the right permissions for /sys/fs/cgroup/systemd/ So I did the following:

chmod o+rx /sys/fs/cgroup/systemd/

  • 3
    But that directory is created on reboot. So I am trying to figure out where that permission is set.
    – benzeno
    Mar 6, 2019 at 12:06
  • Hmmm, it is true that this directory structure does not have o+rx on all directories. However, on another Ubuntu 18 system that I have access to, which does not have this problem, the permissions are exactly the same... So it must be something different?
    – Mischa
    Mar 13, 2019 at 8:17
  • I had similar issue on fedora, fixed with chmod o+rwx -R /sys/fs/cgroup/systemd/ Jul 1, 2019 at 3:35
  • 1
    I'm resorting to the same solution, but it doesn't survive reboots. I'm running Ubuntu in a VPS using openVZ and I wonder if that has anything to do with it.
    – ddffnn
    Feb 2, 2020 at 4:39

Issue with Ubuntu is a key package is missing, it is libpam-cgfs

  • 1
    Hi, welcome to the site! Could you please include a general summary of the relevant technical information that's at the link you provided, so that this answer will still be useful if that page is later deleted or inaccessible? That might sound unlikely, but Stack Exchange answers are still referred to even ten years after they were written. :)
    – Wildcard
    Oct 16, 2019 at 23:33
  • 1
    Unfortunately, installing this package did not help.
    – Mischa
    Nov 21, 2019 at 14:25
  • Did you logout and in or reboot. Nov 22, 2019 at 15:03
  • 1
    @CarlosHernandez I know its was a long time ago, but I'm having the same problem in ubuntu 20.04 inside a openvz vps. Do you remember why you suggested libpam-cgfs? After installing libpam-cgfs the error changed to systemd[1]: [email protected]: Main process exited, code=exited, status=219/CGROUP
    – Sarim
    Oct 9, 2021 at 1:25
  • I also saw this error on OpenVZ with Ubuntu 20.04. This answer didn't entirely resolve my problems but it did seem to help... Jul 21 at 18:11

I believe this is a bug in systemd version 237 with a unified cgroup hierarchy.

It's also reproducible using systemd-run:

The workaround is to add a kernel parameter to disable the unified cgroup hierarchy.

I fixed my problem using the workaround from here: https://github.com/flathub/org.gimp.GIMP/issues/23#issuecomment-394911840

The steps are:

  1. Edit /etc/default/grub, change:


GRUB_CMDLINE_LINUX_DEFAULT="quiet splash systemd.legacy_systemd_cgroup_controller=1"
  1. sudo update-grub
  2. Reboot

It happened to me after using umount -a, followed by mount -a.

some directories became read-only; remounting it with rw solved; but I guess I did not cover it all.

... manually creating the file folder structure for each active service with

mkdir /sys/fs/cgroup/systemd/[slice]/service

followed by: ...

chmod o+rx /sys/fs/cgroup/systemd/ -R
systemctl daemon-reload
systemctl daemon-reexec

solved the issue without restart (had to avoid it as we have services running) Important notice: used chmod -R

  • This works in general, but won't survive a reboot.
    – Larsen
    Apr 28, 2021 at 9:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .