Система: Альт Образование 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 строках журнала.
Created attachment 22468 [details] ЦУС → «Системные журналы»: целая страница отладочных строк alterator-manager («null[PID]: methods[N] = Info/Description/Status», «backend_file … has thread_limit»)
Created attachment 22469 [details] число строк за один запуск, PRIORITY=7 без SYSLOG_IDENTIFIER, сводка сообщений, перезапуски службы при изменении каталогов backends и доля alterator-manager в послед