кастомные логи для юнитов

Нормально скорее всего никак. journald даже другому удалённому journald не умеет слать данные без костылей (ну или я просто не оценил эти remote/gateway).

Не очень просто. С «удалённым syslog» journald вообще взаимодействовать никак не умеет, с фильтрами или без, поэтому «настроить» ты ничего не сможешь, нужно писать код. Общий подход примерно такой: включаешь journalctl (хотя бы в режиме Storage=volatile), потом забираешь данные из самого журнала с нужными фильтрами и отсылаешь куда нужно в произвольном формате.

А как обстоят дела с отдельно взятыми юнитами? Можно ли без костылей и рукосуйств в скрипты для одного юнита сделать выхлоп в дефолтный журнал, для другого в /dev/null итп?

Формат syslog, например:

journalctl -u apache2 -o short

А есть ли что из коробки хз, в ынтырпрайзе надо искать, а мы велосипедисты.

Зачем в девнуль, если ты можешь взять только то в выхлоп что нужно, не нужное пусть в бинарнике и остается, не надо его дергать.

Так а если локально оно не нужно и даже складывать некуда?

intelfx уже сказал: не умеет, только может выплюнуть в нужном формате, а дальше сами. Бида, да.

Можно ли без костылей и рукосуйств в скрипты для одного юнита сделать выхлоп в дефолтный журнал, для другого в /dev/null итп?

Да, можно. man 5 systemd.exec:

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-активации, но это слегка не то). Делаешь именованный пайп и всё. Тебе остаётся только враппер написать.

mandala

Но это криво, лучше забирать из журнала, как я написал выше. Иначе потеряешь метаданные или придётся вручную собирать.

не нужно и даже складывать некуда

В journald немного другая идея. Даже если сам по себе файл журнала (бинарь) тебе не нужен, он всё равно играет роль своеобразного буфера между генератором логов и потребителями. Делаешь Storage=volatile (хранить файлы в RAM) и настраиваешь минимальные лимиты, типа 10 MB суммарно. Думаю, десяток мегабайт в RAM ты найдёшь.

С ума сойти, до чего прогресс дошёл. А этот параметр к пользовательским сессиям можно приделать, чтобы не гадить в journal килотоннами stderr графической сессии?

В теории можно, но каждая сессия лежит в отдельном .scope-юните, они генерируются автоматически, так что придётся существенно обкостыливать. Даже не очень представляю, как.

Во, кажется это я и искал, но отчего-то не нашел!

А как называется юнит, от которого пишется журнал? Я попробовал перекрыть user@1000.service, параметры применились, но это не оно. Вообще, если более конкретно, я хочу избавиться от того, что современные версии GDM шлют в journal, раньше это был печально известный .xsession-errors

А как называется юнит, от которого пишется журнал?

В контексте твоего вопроса — session-$XDG_SESSION_NAME.scope.

Вообще, если более конкретно, я хочу избавиться от того, что современные версии GDM шлют в journal

Это не gdm.

$ journalctl -b -u gdm | cat
-- Logs begin at Tue 2018-02-20 13:10:54 MSK, end at Mon 2018-02-26 18:17:19 MSK. --
фев 26 18:03:00 intelfx-laptop systemd[1]: Starting GNOME Display Manager...
фев 26 18:03:00 intelfx-laptop systemd[1]: Started GNOME Display Manager.
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_unix(gdm-password:session): session opened for user intelfx by (uid=0)
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): pam_putenv("SSH_ASKPASS=/usr/lib/seahorse/seahorse-ssh-askpass")
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): remove variable "SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh"
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): remove variable "QT_QPA_PLATFORMTHEME=qt5ct"
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): remove variable "WINEDLLOVERRIDES=winemenubuilder.exe=d"
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): remove variable "EDITOR=/usr/bin/vim"
фев 26 18:03:08 intelfx-laptop gdm-password][1367]: pam_env(gdm-password:session): remove variable "PAGER=/usr/bin/less"

Всё остальное уже от имени запущенной сессии.

Выбор не такой уж и большой. Напрямую твой вопрос эта настройка всё равно не решает.

session-$XDG_SESSION_NAME.scope

Но у него нету свойств StandardOutput и StandardError. Где-то захардкожено?

Это не gdm.

Я не говорил, что это прямо он, просто мне казалось, что с исчезновением .xsession-errors сообщения пошли в journal. Сейчас припоминаю, что вроде нет.

Брр. Да, действительно, я протупил. Если это .scope, то процессы запускаются не лично systemd, а кем-то ещё, следовательно, их стандартные потоки из systemd не управляются. Наверное, это действительно наследуется из DM. Можно задать StandardOutput=/StandardError= для gdm, но ты потеряешь вывод самого gdm.

Не, вряд ли DM. Скорее из logind ноги растут, если смотреть на зависимости юнитов. В общем, надо копать глубже %)

Откуда там logind? Процесс сессии запускается из DM и наследует его stdin/stdout/stderr.

Ну если от него делать list-dependencies --before, то у gdm там только его сессия на одном уровне с моей. В любом случае, изменение настроек вывода для gdm.service изменило ничего. Для user@1000.service — тоже. Для user@124.service (GDM)... тоже! Видимо, всё хитрее, хотя мне что-то (man systemd-journald, в основном) подсказывает, что это это какой-то .service.

Тогда происходит что-то странное. Я ставлю на то, что это просто захардкожено в gdm.

а разве нельзя настроить редирект всех сообщений из журнала в сокет какой нибудь другой системы логирования (rsyslog например) и уже в этой системе настраивать фильтры, ротацию и прочую лабуду? intelfx

уже в этой системе настраивать фильтры, ротацию и прочую лабуду?

Вот если бы в rsyslog была нормальная (да вообще хоть какая-то) ротация...

logrotate, нэ?

Нэ, это левое поделие, работающее по крону. Я потому и перешёл на journal, что там ротация сделана по уму. Ещё неплохо сделано в логгере из runit, но это очевидно не для реального применения.

Я потому и перешёл на journal

Будьте честны. Это не вы «перешли» это «вас перешли» на *d

Нэ

вообще то это полувопросительная частица из японского языка. ставится всегда в конце предложения и употребляется когда ты делаешь утверждение и ждёшь от собеседника какого то ответа на это утверждение

Будем честны: я бы ушёл с Debian, если бы он не перешёл на systemd.

Ну так и пиши на японском, по двум буквам не так-то просто определить язык.

Или тильду длинную ставь, лол.