[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [systemd-journald] Бессистемно теряется вывод пользовательской службы



Tim Sattarov <stimur@gmail.com> wrote:
> On 6/15/19 9:52 PM, Dmitry Alexandrov wrote:
>> Дано: Дебиан ГНУ/Линукс 9.9, искоробочный systemd 232.
>>
>> Из-под рута все, вроде бы, в порядке:
..
>> # for _ in {1..10}; do systemctl start test-echo.service; sleep 1; done
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
..
>> А теперь то же самое, но с пользовательской службой:
..
>> $ for _ in {1..10}; do systemctl --user start test-echo.service; sleep 1; done
>> Starting test-echo.service...
>> Hi there.
>> Started test-echo.service.
>> Starting test-echo.service...
>> Started test-echo.service.
>> Starting test-echo.service...
>> Started test-echo.service.
..
>
> А пробовал смотреть в логи системы вокруг (самого systemd) на предмет throttle/rate limit?

Да, ничего такого.  Более того, в нефильтрованном журнале и вывод test-echo.service весь есть.  То есть дело явно не в rate limit’е (тем более, что он, кажется, единый для всего журнала; по крайней мере, где его еще настроить, кроме как в /etc/systemd/journald.conf, я не знаю).

Я погуглил получше, и, думаю, что нашел релевантный баг от февраля 2017-го —  «Journalctl miss to show logs from unit» [0]:

Michal Sekletar:
| This is a known issue. systemd-journald sometimes fails to record information about unit from which log message originates. There is a higher probability of hitting this problem if the process that logs the message is short lived.

| It's just that for some log messages that originate from short lived processes journald can't figure out respective cgroup (unit). Thus you will not see those log lines if you apply filtering based on unit name. *We can't do anything about this* until kernel gives us a way to gather cgroup information in non racy way. But then again, logs are there and your first command that uses time based filtering proves that.

(выделение мое)

Баг закрыт как повтор бага от 2013 года под маловнятной темой «journald: we need a way to get audit, cgroup, ... information attached to log...» [1], который заканчивается жизнеутверждающим вопросом:

Rich Megginson 2017-08-11 16:42:37 UTC:
| What ever happened with the upstream [Linux] patch for this?

[0] https://bugzilla.redhat.com/1426152
[1] https://bugzilla.redhat.com/963620

Attachment: signature.asc
Description: PGP signature


Reply to: