Завис systemd1: почему без перезагрузки не обойтись

TL;DR: systemd1 (D-Bus-сервис org.freedesktop.systemd1, через который работает systemctl) завис. systemctl молчит, активация сервиса упирается в 25-секундный таймаут, а процесс systemd (PID 1) остаётся с одним-единственным потоком — мёртвый менеджер, который не обслуживает шину. daemon-reexec не помогает. Перезагрузка — единственный выход, и systemctl --force --force reboot справляется даже когда обычный reboot падает с Connection timed out.

Как это выглядело

Всё началось с того, что у меня завис FUSE-модуль с Яндекс-Диском (/mnt/yandex-disk, davfs2). Пока я разбирался, я заметил, что команды systemctl перестали отвечать вообще.

Когда я попробовал перезагрузиться обычным способом:

$ sudo systemctl reboot

Broadcast message from root@bigbox on pts/31 (Sun 2026-09-13 13:08:39 UTC):
The system will reboot now!

Call to Reboot failed: Connection timed out
Failed to start reboot.target: Connection timed out
See system logs and 'systemctl status reboot.target' for details.
It is possible to perform action directly, see discussion of --force --force in man:systemctl(1).

Беда в том, что systemctl reboot сам идёт через systemd1. Если systemd1 висит, то и перезагрузиться через него нельзя — получается «замкнутый круг».

При этом интересная деталь: docker ps и docker info работали нормально, контейнеры — живые, мои агенты продолжали работать. Падал только сам systemd-интерфейс.

Что показала диагностика

1. systemd1 не активируется на D-Bus.

$ busctl | grep systemd1
org.freedesktop.systemd1   -   -   -   (activatable)   -   -   -

(activatable) значит, что сервис зарегистрирован, но не запущен. При попытке его запустить:

$ systemctl is-system-running
[tаймаут через 25 секунд]

$ journalctl | grep systemd1
dbus-daemon[1859]: Failed to activate service 'org.freedesktop.systemd1':
timed out (service_start_timeout=25000ms)

2. PID 1 — systemd — жив, но как будто мёртв внутри.

$ ps -o pid,nlwp,stat,etime -p 1
  1   1  Ss  3-06:26:57

Ключевое — nlwp = 1. Нормальный systemd держит десятки потоков (они обслуживают шину, юниты, таймеры…). Один поток означает, что менеджер фактически не работает, а просто висит. Именно поэтому daemon-reexec не реагирует толком — перезапускать некому.

3. Docker тут ни при чём.

• dockerd жил, docker ps отвечал мгновенно;
• все контейнеры — Up, с restart-политиками unless-stopped / always;
• даже systemctl restart docker упал бы в тот же таймаут systemd1, потому что этот вызов тоже идёт через шину.

4. Даже перезагрузка через systemctl не сработала: Call to Reboot failed: Connection timed out.

Почему FUSE-Яндекс-Диск виноват лишь отчасти

Я сначала грешил на зависший davfs2: он висел, и systemd вполне мог залипнуть, пытаясь обратиться к .mount-юниту, который упирается в молчащую FUSE-точку. Это правдоподобный триггер. Но уже к моменту диагностики я перемонтировал Яндекс-Диск заново, и он заработал — а systemd1 так и остался висящим.

Проверка это подтвердила:

• ls /mnt/yandex-disk/ отвечает мгновенно;
• D-state (непрерываемые) процессы отсутствуют;
• демон davfs2 жив.

То есть: точка Yandex больше не блокирует ничего, а systemd1 всё равно не оживает. Вывод — проблема уже в самом systemd, а не в FUSE. FUSE был спусковым крючком, но чинить нужно было не монтирование.

Что мы перепробовали перед ребутом

Попытка 1: systemctl daemon-reexec — перезапуск systemd «на месте», самая мягкая реанимация.

$ sudo systemctl daemon-reexec
# вернуло 0

Вернуло успех, но шину не оживило. Потому что systemd с одним потоком не смог толком выполнить re-exec — команда «прошла», но менеджер остался в том же состоянии. Проверка после:

$ busctl | grep systemd1
org.freedesktop.systemd1   -   -   -   (activatable)   ...
$ systemctl is-system-running
[tаймаут]

Ничего не изменилось.

Попытка 2: обычный reboot. Упал с Connection timed out (см. выше). По понятной причине: reboot через systemctl — это тоже запрос к systemd1.

Попытка 3: systemctl --force --force reboot — двойной форсированный перезапуск. Именно он сработал:

$ sudo systemctl --force --force reboot
Rebooting.

Как это работает: зачем два –force

systemctl reboot без флагов просит systemd корректно завершить все юниты. Если systemd1 виснет, запрос не проходит. Два --force — это «мне плевать на зависшие службы, перезагружайся»:

• первый --force — пропустить остановку юнитов (не ждать, пока всё аккуратно завершится),
• второй --force (для reboot) — выполнить системный вызов перезагрузки напрямую, в обход systemd как менеджера.

То есть это фактически «аварийная» перезагрузка через системный механизм ядра (reboot(2)), минуя зависший менеджер. Риск — грязное завершение: незаписанные данные могут потеряться, но при зависшей шине это часто единственный вариант.

После перезагрузки

Система поднялась за ~11 минут:

• systemctl is-system-running → degraded (отвечает мгновенно — шина жива);
• org.freedesktop.systemd1 на busctl теперь активирован (PID systemd, :1.5), а не (activatable);
• docker и containerd — active;
• все 27 контейнеров поднялись сами (restart-политики unless-stopped/always сработали): gitea, netbox, grafana, prometheus, loki, gotosocial, garage, ollama, open-webui, searxng и остальные;
• /mnt/yandex-disk смонтирован и отвечает; /opt/hermes/obsidian-vault (s3fs) тоже на месте.

Единственный failed-юнит — mdmonitor.service (мониторинг MD-массивов). Падает с mdadm: No mail address or alert command - not monitoring — это не поломка, а отсутствие настроенного алерта. На рабочие массивы не влияет, можно замаскировать.

Выводы

1. Если systemctl молчит, а docker работает — значит, дело в шине, а не в docker. Проверяй busctl | grep systemd1 и nlwp у PID 1.
2. daemon-reexec не всегда реанимирует — если у systemd остался один поток, перезапускать себя фактически некому.
3. Обычный systemctl reboot тоже идёт через systemd1 — при висящей шине он не сработает. Нужен --force --force.
4. FUSE-зависание может быть триггером, но не обязательно причиной. Если точка перемонтирована и отвечает, а systemd1 всё равно молчит — лечится только перезагрузкой.
5. Restart-политики контейнеров себя отрабатывают: unless-stopped/always подняли всё после ребута, ничего не пришлось поднимать руками.

Полный разбор с командами, как это диагностировать, — в WALKTHROUGH проекта.

Теги: #systemd #systemctl #dbus #fuse #davfs2 #reboot #администрирование #грабли

Если у вас systemctl молчит, а контейнеры живут — проверьте busctl | grep systemd1 и ps -o nlwp -p 1. И не тратьте время на daemon-reexec: при пульсе «один поток» перезагрузка всё равно неизбежна.

GoToSocial молча съедал все статусы с релеев — и я нашёл почему

TL;DR: Подписка на релей выглядит рабочей, релей шлёт, нода отвечает 202 Accepted — а в базе пусто. Причина — я не поставил галочку Match posts by default, а матчеры оставил пустыми. В таком виде фильтр релеев по построению возвращает false для всего. Статусы дропаются молча, на уровне debug. Ошибка тихая: её заслоняют громкие ошибки dereference.

Как это выглядит снаружи

Ты подписан на релей. Ты видишь:

• подписка активна, approved = true,
• релей исправно шлёт Announce,
• нода отвечает 202 Accepted.

Всё зелёное. А лента месяцами состоит из пары доменов, на которые ты подписан напрямую. Релей как будто «работает вхолостую».

❌ Моя ошибка

Я настроил подписку так:

• ✅ разрешил public
• ✅ разрешил unlisted
• ✅ запретил sensitive

И решил, что этого достаточно. Логика была: «я разрешил то, что хочу, и запретил то, что не хочу — значит, всё остальное будет приходить само».

Но это не так. Разрешение public/unlisted и запрет sensitive — это фильтры видимости. Они говорят, какие типы постов можно принимать. Но они не дают разрешения на приём вообще. Разрешение даёт либо match_by_default, либо include-матчеры. У меня не было ни того, ни другого.

Я не поставил галочку Match posts by default. Без неё подписка работает в режиме deny-by-default: пропускает только то, что явно разрешено матчерами. Матчеров нет → не проходит ничего.

Что происходит под капотом

1. Релей шлёт POST /inbox → нода отвечает 202 Accepted. Это подтверждение приёма HTTP-запроса, а не сохранения статуса.
2. Нода скачивает оригинал по URI (dereference), тратит трафик и время.
3. Статус идёт в relay.Filter.MatchedBySubscription.
4. Нет совпадения → статус выбрасывается. В лог падает dropping unpermitted status — warn/debug, не error.

Где прячется грабль

В таблице relay_subscriptions два ключевых поля: flags (битовая маска) и matchers (JSON-правила).

Флаги из gtsmodel/relay.go:

RelayFlagPublic          = 2   (принимать публичные)
RelayFlagUnlisted        = 4   (принимать скрытые)
RelayFlagMatchByDefault  = 8   (принимать всё по умолчанию)
RelayFlagIgnoreSensitive = 16  (игнорировать чувствительное)
RelayFlagIgnoreMedia     = 32  (игнорировать с медиа)
RelayFlagIgnoreReplies   = 64  (игнорировать ответы)

У меня на всех трёх подписках стояло flags = 22. Раскладываем: 16 + 4 + 2 = IgnoreSensitive + Unlisted + Public. Выглядит осмысленно, правда? «Принимаем публичные и скрытые, игнорируем чувствительное».

Но бита MatchByDefault (8) там нет. И matchers = NULL.

Почему без match_by_default дропается всё

Логика matchedByConnection в internal/filter/relay/relay.go:

1. Видимость: public → нужен флаг Public (есть), unlisted → нужен Unlisted (есть), остальное → false.
2. Чувствительное + IgnoreSensitive → false (это намеренно).
3. Медиа + IgnoreMedia → false (не стоит).
4. Ответ не себе + IgnoreReplies → false (не стоит).
5. Exclude-матчеры (чёрный список). Их нет → пропускаем.
6. Если стоит MatchByDefault → true. У меня не стоит.
7. Иначе ищем include-матчеры (белый список). Их нет вообще.
8. return false.

Вот оно. Пустая подписка без матчеров — это подписка, которая не пропускает ничего. Deny-by-default. Не «не знаю», а именно «не разрешаю».

Что такое матчеры и зачем они нужны

Матчер — это ключевое слово, которое ищется в содержимом поста и в его content warning. Поиск регистронезависимый. Есть два режима совпадения: partial (по умолчанию, ловит часть слова) и whole word (только целое слово). Хэштеги матчатся через префикс #.

Матчеры бывают двух типов:

Include-матчеры (белый список). Работают, когда match_by_default выключен. Пост пройдёт только если совпал хотя бы с одним include-матчером. Нет include-матчеров и нет match_by_default — не пройдёт ничего. Именно это и случилось у меня.

Exclude-матчеры (чёрный список). Работают всегда, независимо от match_by_default. Если пост совпал с exclude-матчером — он дропается, даже если match_by_default включён.

Матчеры дают админу хирургический контроль вместо грубого «всё или ничего». Include — «хочу только посты про infosec и Linux». Exclude — «принимай всё, кроме спама и nsFW».

Как диагностировать

SQL:

1
2

SELECT relay_actor_uri, flags, matchers FROM relay_subscriptions;
-- flags без бита 8 и matchers = NULL → подписка не пропускает ничего

API:

GET /api/v1/admin/relay_subscriptions
→ смотрим match_by_default

✅ Как чинить — и что надо было сделать сразу

Два корректных пути при добавлении релея:

Путь 1: «Принимать всё, кроме явных запретов» — поставить галочку Match posts by default. Тогда работают только exclude-матчеры и ignore-флаги. Всё, что не попало под запрет, — принимается.

Путь 2: «Принимать только то, что я явно указал» — не ставить Match posts by default, но создать include-матчеры. Например, infosec, linux, #GoToSocial.

Я выбрал ни то, ни другое. Надо было поставить галочку:

PUT /api/v1/admin/relay_subscriptions/{id}
{ "public": true, "unlisted": true, "match_by_default": true }

После включения приток пошёл мгновенно: 44 статуса за 30 минут, 12+ новых доменов (infosec.exchange, mastodon.world, burningboard.net, troet.cafe, norden.social, c.im, toot.wales, social.linux.pizza…). До этого лента месяцами содержала только пару доменов прямых подписок.

Выводы

1. Главное правило: если хочешь «принимать всё, кроме запрещённого» — обязательно ставь галочку Match posts by default. Без неё релей будет слать, нода будет отвечать 202 Accepted, а лента останется пустой.
2. Разрешить public/unlisted недостаточно — это лишь фильтры видимости, а не разрешение на приём. «Подписка есть» и «релей шлёт» ≠ «контент сохраняется».
3. Дизайн фильтра разумный — безопасный дефолт. Но для админа неочевидный: UI не кричит, что подписка без матчеров мёртвая.
4. Мониторь не только error, но и warn-строки dropping unpermitted / not relayable.
5. 202 Accepted — это «запрос принят», а не «статус сохранён». Путать их — самый дешёвый способ незаметно потерять федерацию.

Теги: #GoToSocial #ActivityPub #Fediverse #Relay #администрирование #грабли

Если у кого-то была та же тишина в ленте при живом релее — проверьте match_by_default. Возможно, вы тоже кормите чёрную дыру.