User can't suspend laptop/control wireless via dbus/systemd-logind if cgroups are disabled in kernel

Bug #1325309 reported by Rob A
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

This is kind of a long chain, but I think this is where it ends.

I custom compile my kernel for battery savings, as I spend lots of time flying. I recently went back to BFS in 3.14 as my scheduler, but immediately ran into lots of problems (it used to give me 15 more minutes on average). The most interesting, that I can't work around is this:
I disable cgroups because BFS doesn't use them at all. and when I did, even with the ubuntu linux-source package, I suddenly couldn't put my laptop to sleep, and I couldn't control my network connections anymore. Investigating lead me to discover that "start systemd-logind" was failing.

So, here's my relevant config:

rob@kubuntu4:~$ grep CGROUP /boot/config-`uname -r`; sudo start systemd-logind; dmesg |tail -1; ls /sys/fs/cgroup
# CONFIG_CGROUPS is not set
start: Job failed to start
[ 1450.848491] init: systemd-logind pre-start process (10865) terminated with status 32
ls: cannot access /sys/fs/cgroup: No such file or directory

the /sys/fs/cgroup folder doesn't exist because CONFIG_CGROUPS isn't set in the kernel. So what is "status 32" from the pre-script for systemd-logind ?

the problem seems to be in the mount statements in the systemd-logind prestart script:

grep mount /etc/init/systemd-logind.conf
    # this is being done by systemd or mountall usually, but not during
    if ! mountpoint -q /sys/fs/cgroup; then
        mount -t tmpfs -o uid=0,gid=0,mode=0755,size=1024 none /sys/fs/cgroup
    # mounting the cgroup does not work in LXC, there it uses cgmanager
    if [ ! -e /run/container_type ] && ! mountpoint -q /sys/fs/cgroup/systemd; then
        mount -t cgroup -o nosuid,noexec,nodev,none,name=systemd systemd /sys/fs/cgroup/systemd

Testing:
sudo mount -t tmpfs -o uid=0,gid=0,mode=0755,size=1024 none /sys/fs/cgroup; echo $?
[sudo] password for rob:
mount: mount point /sys/fs/cgroup does not exist
32

Rebooting into the stock ubuntu kernel, and I can put my laptop to sleep again, albeit at the cost of a bunch of battery life.

I don't understand why cgroups are required for dbus and PolicyKit to be able to allow me to put my laptop to sleep, so I'm filing this as a bug. the systemd pre-script doesn't bother to check if the /sys/fs/cgroup folder even exists, so there's definitely a "defensive programming" bug in systemd not handling this situation better.

currently "sudo pm_suspend" is an easy workaround for the sleep issue, but my wireless access issue has no workaround.

Revision history for this message
Martin Pitt (pitti) wrote :

I'm afraid logind does require cgroups to be available. The init script reflects that, as without the cgroup mount logind wouldn't work. You already noticed the failure to suspend etc., but I'm quite surprised that you get a desktop session at all. I expect that dynamic ACLs to devices (sound, USB, etc.) are also not working.

So I recommend enabling cgroups in your custom kernels. This should hardly have any power usage effect?

Changed in systemd (Ubuntu):
status: New → Invalid
Revision history for this message
Rob A (docsmooth) wrote :

Thanks Martin.

I confirmed that that single change in my .config restores proper operation.

No it shouldn't affect power usage, but it's not used in BFS (which isn't going to be mainline, I know), so I'm curious why suspend (and NetworkManager) require it? it seems to be completely unnecessary for the functions I need.

Regarding the desktop: a few apps wouldn't connect to pulse-audio, but I wasn't sure what was causing that, or if Skype was broken again. It turns out it was both this, and skype being broken again.

Revision history for this message
Martin Pitt (pitti) wrote :

suspend and NM only indirectly require it. logind does the management of user sessions, tracking of "foreground" sessions, dynamic ACLs etc. these days, and logind requires cgroups. NM, power management, device ACLs etc. all use logind's functionality.

In other words, cgroup support is pretty much a "must" these days. Not only for logind, but also for LXC and other things.

Revision history for this message
Michael Heuberger (michael.heuberger) wrote :

Not sure if my problem is related to this one. At the moment I experience issues installing/updating libpam-systemd:amd64. Then I followed the installation scripts and saw that /sys/fs/cgroup/systemd is missing and I wasn't able to create that manually or using the script. Looks like /sys/fs/cgroup is missing.

Sorry if this is off-topic but I am desperate to fix it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.