The officially official Devuan Forum!

markus23

Member

Registered: 2025-08-21

Posts: 20  

elogind leaks session cgroups

Server: Devuan 6 excalibur in a VM

Problem: elogind (sysvinit hosts) creates one cgroup per login session at /sys/fs/cgroup/<session-id> and never removes it. On one server a CheckMK's per-minute SSH logins leaked 65533 of them, which exhausted the kernel's memory cgroup IDs and made every docker build/docker run fail with device or resource busy.

Workaround: hourly cron job that does cleanup

Is this a known problem? Is there a better solution?

markus23

Member

Registered: 2025-08-21

Posts: 20  

Re: elogind leaks session cgroups

Upstream bug might be https://github.com/elogind/elogind/issues/381

EDX-0

Member

From: Guatemala

Registered: 2020-12-12

Posts: 270  

Re: elogind leaks session cgroups

yeh, seems like it is patched on the 257 stable branch but that branch has had no release since june with 257.16 and devuan unstable ships 257.13 so it is a matter of waiting for the commits to land in a release and the release packaged by devuan...

on the meantime perhaps cobbling a sort of "hook" script to run at the elogind session end, perhaps a simple daemon to compare the output of loginctl list-sessions with the subdirs of /sys/fs/cgroup/* and prune the missing ones, doing some quick commands the terminal loginctl list-sessions | tail -n +2 | head -n -2 | awk '{print $1}' gets only the current active session ids, may cobble a simple daemon later

markus23

Member

Registered: 2025-08-21

Posts: 20  

Re: elogind leaks session cgroups

Thanks for confirming that this could be the issue and might be fixed with next stable release. Will Devuan take this into a point release or will this have to wait until Freia?

We already have a working solution from Paul Bachinger, we can share it:

#!/usr/bin/env bash

# elogind without systemd creates one cgroup per login session directly
# below the cgroup root, named after the session ID, and never removes it.

# License you can choose either:
# Perma License to be published at https://www.perma.health
# AGPL
# BSD-3-Clause
# MIT

# Install the script to run about hourly.

# This script will not be needed after bug is fixed:
# patched on the 257 stable branch, so should be in release 257.17
# https://dev1galaxy.org/viewtopic.php?pid=66324#p66324

# Detailed problem:
# Leaked cgroups exhaust the kernel's memory cgroup IDs, after which e.g. Docker
# can no longer start containers ("mkdir ...: device or resource busy").

set -euo pipefail

CGROUP_ROOT=/sys/fs/cgroup
LOCK_FILE=/run/lock/session-cgroups-cleanup.lock

exec 9> "$LOCK_FILE"

if ! flock --nonblock 9
then
  echo "$(date): Another session cgroups cleanup is active; skipping"
  exit 0
fi

if ! pgrep -x elogind-daemon > /dev/null
then
  echo "$(date): elogind is not running; skipping"
  exit 0
fi

ACTIVE_SESSIONS=" $(
  timeout 30 loginctl list-sessions --no-legend | awk '{ print $1 }' | tr '\n' ' '
) "

# Session IDs increase monotonically. A session newer than this snapshot
# may not have moved its first process into its cgroup yet, so only IDs up
# to the highest known session are removed.
MAX_ACTIVE_SESSION="$(
  tr ' ' '\n' <<< "$ACTIVE_SESSIONS" | grep -E '^[0-9]+$' | sort -n | tail -1 || true
)"

if [[ -z "$MAX_ACTIVE_SESSION" ]]
then
  echo "$(date): No numeric elogind sessions found; skipping"
  exit 0
fi

REMOVED_COUNT=0

while IFS= read -r -d '' cgroup
do
  session="${cgroup##*/}"

  if (( session > MAX_ACTIVE_SESSION ))
  then
    continue
  fi

  if [[ "$ACTIVE_SESSIONS" == *" $session "* ]]
  then
    continue
  fi

  if ! grep -qx 'populated 0' "$cgroup/cgroup.events"
  then
    continue
  fi

  # rmdir is refused by the kernel for cgroups that still have processes or children
  if rmdir -- "$cgroup" 2> /dev/null
  then
    REMOVED_COUNT=$((REMOVED_COUNT + 1))
  fi
done < <(
  find "$CGROUP_ROOT" \
    -mindepth 1 \
    -maxdepth 1 \
    -type d \
    -regextype posix-extended \
    -regex '.*/[0-9]+' \
    -print0
)

echo "$(date): Removed session cgroups: $REMOVED_COUNT"
echo "$(date): Remaining cgroups: $(awk '/^nr_descendants /{ print $2 }' "$CGROUP_ROOT/cgroup.stat")"

fsmithred

Administrator

Registered: 2016-11-25

Posts: 3,015  

Re: elogind leaks session cgroups

If I run that script manually, I get an error message that elogind-daemon is not running. I checked 'ps' and I agree that it's not running, but elogind is running. I changed one line in the script from

if ! pgrep -x elogind-daemon > /dev/null

to

if ! pgrep -x elogind > /dev/null

and the error message goes away.

Script works to remove cruft in /sys/fs/cgroups, but it doesn't fix a different problem I have in the freia desktop-live iso - gparted works on first login but does not start on subsequent logins. Message in /var/log/auth.log is "The gnome keyring socket is not owned with the same credentials as the user login: /home/devuan/.cache/keyring-4FE4X3/control"  I'm not sure if it's supposed to fix that.

markus23

Member

Registered: 2025-08-21

Posts: 20  

Re: elogind leaks session cgroups

For us it is called elogind-daemon. Maybe that changed between excalibur and freia?

The problem with wrong permissions in the ~/.cache file seems to be unrelated, our script does not do anything there.

Btw. the cron config we use is /etc/cron.d/session_cgroups_cleanup

20 * * * * root /usr/local/bin/session-cgroups-cleanup.sh >> /var/log/session-cgroups-cleanup.log 2>&1