Нормально скорее всего никак. journald даже другому удалённому journald не умеет слать данные без костылей (ну или я просто не оценил эти remote/gateway).
Не очень просто. С «удалённым syslog» journald вообще взаимодействовать никак не умеет, с фильтрами или без, поэтому «настроить» ты ничего не сможешь, нужно писать код. Общий подход примерно такой: включаешь journalctl (хотя бы в режиме Storage=volatile), потом забираешь данные из самого журнала с нужными фильтрами и отсылаешь куда нужно в произвольном формате.
А как обстоят дела с отдельно взятыми юнитами? Можно ли без костылей и рукосуйств в скрипты для одного юнита сделать выхлоп в дефолтный журнал, для другого в /dev/null итп?
StandardOutput=
Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one of inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console, file:path, socket or fd:name.
Слушай! Я и не заметил. В последних версиях сделали, по ходу. Можно перенаправлять в файл (или в конкретный socket при socket-активации, но это слегка не то). Делаешь именованный пайп и всё. Тебе остаётся только враппер написать.
В journald немного другая идея. Даже если сам по себе файл журнала (бинарь) тебе не нужен, он всё равно играет роль своеобразного буфера между генератором логов и потребителями. Делаешь Storage=volatile (хранить файлы в RAM) и настраиваешь минимальные лимиты, типа 10 MB суммарно. Думаю, десяток мегабайт в RAM ты найдёшь.
С ума сойти, до чего прогресс дошёл. А этот параметр к пользовательским сессиям можно приделать, чтобы не гадить в journal килотоннами stderr графической сессии?
В теории можно, но каждая сессия лежит в отдельном .scope-юните, они генерируются автоматически, так что придётся существенно обкостыливать. Даже не очень представляю, как.
А как называется юнит, от которого пишется журнал? Я попробовал перекрыть user@1000.service, параметры применились, но это не оно. Вообще, если более конкретно, я хочу избавиться от того, что современные версии GDM шлют в journal, раньше это был печально известный .xsession-errors
Брр. Да, действительно, я протупил. Если это .scope, то процессы запускаются не лично systemd, а кем-то ещё, следовательно, их стандартные потоки из systemd не управляются. Наверное, это действительно наследуется из DM. Можно задать StandardOutput=/StandardError= для gdm, но ты потеряешь вывод самого gdm.
Ну если от него делать list-dependencies --before, то у gdm там только его сессия на одном уровне с моей. В любом случае, изменение настроек вывода для gdm.service изменило ничего. Для user@1000.service — тоже. Для user@124.service (GDM)... тоже! Видимо, всё хитрее, хотя мне что-то (man systemd-journald, в основном) подсказывает, что это это какой-то .service.
а разве нельзя настроить редирект всех сообщений из журнала в сокет какой нибудь другой системы логирования (rsyslog например) и уже в этой системе настраивать фильтры, ротацию и прочую лабуду? intelfx
Нэ, это левое поделие, работающее по крону. Я потому и перешёл на journal, что там ротация сделана по уму. Ещё неплохо сделано в логгере из runit, но это очевидно не для реального применения.
вообще то это полувопросительная частица из японского языка. ставится всегда в конце предложения и употребляется когда ты делаешь утверждение и ждёшь от собеседника какого то ответа на это утверждение