systemd-logind: Failed to start session: Max sessions exceeded Linux / DevOps

Ошибка systemd-logind: Failed to start session: Max sessions exceeded — Исправление

Обновлено: 18.08.2026 · Официальная база знаний

Пользователи не могут войти по SSH или через локальную консоль TTY. Служба авторизации возвращает отказ, а в системном журнале фиксируется: systemd-logind: Failed to start session: Max sessions exceeded.

Индикатор сбоя	Конфигурационный параметр	Типичная причина
Отказ SSH PAM session	`SessionsMax=8192`	Утечка фоновых cron/CI сессий без корректного закрытия
Отказ локального login	`UserTasksMax`	Исчерпание лимита процессов cgroup пользователя
Рост числа активных сессий	`loginctl list-sessions`	Зависшие сессии автоматизации / мониторинга

Проверьте количество и состояние открытых сессий в системе:
```
loginctl list-sessions --no-pager | wc -l
loginctl list-users
```
Завершите зависшие сессии пользователей автоматизации (например, zabbix, ansible):
```
loginctl terminate-user <username>
```
Увеличьте максимальный лимит сессий в /etc/systemd/logind.conf:
```
sudo nano /etc/systemd/logind.conf

[Login]
SessionsMax=32768
InhibitDelayMaxSec=30
```
Перезапустите демон (сессии пользователей сохранятся):
```
sudo systemctl restart systemd-logind
```

Внимание: Убедитесь, что в PAM-стеке (/etc/pam.d/common-session) включен модуль pam_systemd.so, чтобы закрытые соединения не оставались висеть в памяти.

Практический опыт инженера: Проверьте конфигурацию cron: скрипты, выполняющие su/sudo каждую минуту, могут генерировать до 1440 сессий в сутки без garbage collection.

Частые вопросы (FAQ)

Оборвутся ли текущие SSH-подключения при перезапуске systemd-logind?

Нет, перезапуск systemd-logind спроектирован так, чтобы не разрывать существующие пользовательские процессы и соединения.

Почему скапливаются тысячи неактивных сессий?

Частая причина — частый запуск скриптов через cron или SSH без TTY, где PAM создает сессию, но не закрывает ее корректно.