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 user@1001.service
● user@1001.service - User Manager for UID 1001
   Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/user@.service.d
   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]: user@1001.service: 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/user@1001.service/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]: user@1001.service: 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/user@.service
#  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

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/

| improve this answer | |
  • 3
    But that directory is created on reboot. So I am trying to figure out where that permission is set. – benzeno Mar 6 '19 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 '19 at 8:17
  • I had similar issue on fedora, fixed with chmod o+rwx -R /sys/fs/cgroup/systemd/ – Alec Istomin Jul 1 '19 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 at 4:39

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

| improve this answer | |
  • 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 '19 at 23:33
  • 1
    Unfortunately, installing this package did not help. – Mischa Nov 21 '19 at 14:25
  • Did you logout and in or reboot. – Carlos Hernandez Nov 22 '19 at 15:03

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
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.