Система:
Альт Образование 11.2, x86_64, KDE Plasma.

Версия пакета: alterator-manager-0.1.33-alt2

Шаги воспроизведения:
1. От root: systemctl stop alterator-manager (чтобы считать с чистого запуска).
2. Открыть из меню «Центр управления системой» (служба активируется по D-Bus).
3. От root: journalctl -b _COMM=alterator-manag -o cat | wc -l
   и journalctl -b _COMM=alterator-manag -o verbose -n 1 | grep -E 'PRIORITY|SYSLOG_IDENTIFIER'

Ожидаемый результат:
Без --debug служба пишет в журнал только несколько строк о запуске и ошибки/предупреждения.
Отладочные сообщения (g_debug) — только при запуске с --debug.

Фактический результат:
За один запуск службы — около 3240 строк (на системе 535 файлов .backend, из них 499
autogenerated-component-*.backend), все с PRIORITY=7 (debug) и без SYSLOG_IDENTIFIER:
    548 methods[N] = Info
    504 methods[N] = Description
    502 methods[N] = DescriptionRaw
    500 methods[N] = Status
    499 backend_file (autogenerated-component-….backend) has thread_limit <= 0. This field may not have
        been set or may have been set incorrectly. It will be given a default value (10).
    499 Found backend file: /etc/alterator/backends/autogenerated-component-….backend
    …
Служба сама завершается («Backend files changed, exit.») при любом изменении в каталогах
/etc/alterator/backends{,/system,/user} и /usr/share/alterator/backends/{system,user} (установка и
удаление пакетов и компонентов), systemd (Restart=on-success) сразу запускает её снова, и каждый такой
перезапуск добавляет ещё ~3240 строк. Пока открыт модуль ЦУС, выход откладывается до его закрытия.
Проверено: первый запуск из меню и три перезапуска после изменений в каталогах backends — 3242, 3242,
3244 и 3241 строки. Воспроизводится всегда.

Дополнительно:
Следствие для пользователя: ЦУС → «Системные журналы» показывает последние 9998 строк журнала. После
первого запуска и трёх перезапусков службы 9773 из 9998 строк — alterator-manager, окно охватывает
около 5 минут, остальные сообщения системы из него вытеснены. Предупреждение про thread_limit выдаётся
для каждого автогенерированного компонента: либо генератор должен записывать thread_limit, либо
сообщение не должно выводиться без отладки.

Причина: src/main.c:42-43 — без --debug вызывается g_log_set_writer_func(g_log_writer_journald, NULL,
NULL). g_log_writer_journald, в отличие от g_log_writer_default, не отбрасывает G_LOG_LEVEL_DEBUG,
поэтому все g_debug уходят в журнал: src/alterator_manager_backends.c:63 («Found backend file»),
:327-328 (thread_limit), :452 («methods[%d] = %s») и др. Вариант исправления: собственный writer,
который без --debug отбрасывает G_LOG_LEVEL_DEBUG (или проверка g_log_writer_default_would_drop())
перед передачей в g_log_writer_journald. В Sisyphus (0.2.2-alt1) src/main.c тот же.

Вложения:
alterator-logs-flood-page.png — ЦУС → «Системные журналы»: целая страница отладочных строк
alterator-manager («null[PID]: methods[N] = Info/Description/Status», «backend_file … has thread_limit»).
alterator-manager-journal.txt — число строк за один запуск, PRIORITY=7 без SYSLOG_IDENTIFIER, сводка
сообщений, перезапуски службы при изменении каталогов backends и доля alterator-manager в последних
9998 строках журнала.