История изменений
Исправление intelfx, (текущая версия) :
Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?
Зависит от значения директивы StandardOutput=. Варианты:
- в journald;
- в низкоуровневую консоль (путь к которой указан директивой
TTYPath=); - в сокет (если это сокет-активируемый юнит);
- в никуда.
такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?
Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».
systemd-networkd
По умолчанию не включен.
systemd-vconsole-setup
Отключается путём маскирования.
А возможно ли отключить journald
Отключается путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).
сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»
А это уже зависит от тебя и от демонов. Сообщения тех демонов, которые умеют самостоятельно писать в сислог — попадут в сислог. А чей-либо stdout/stderr не попадёт никуда, потому что внезапно journald именно тем (в частности) и занимается, что перенаправляет одно в другое.
А вообще я скоро допишу статью, в которой про всё это написано. Она должна была войти в SIA #3, но я не успел.
Исправление intelfx, :
Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?
Зависит от значения директивы StandardOutput=. Варианты:
- в journald;
- в низкоуровневую консоль (путь к которой указан директивой
TTYPath=); - в сокет (если это сокет-активируемый юнит);
- в никуда.
такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?
Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».
systemd-networkd
По умолчанию не включен.
systemd-vconsole-setup
Отключается путём маскирования.
А возможно ли отключить journald
Отключается путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).
сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»
А это уже зависит от тебя и от демонов. Сообщения тех демонов, которые умеют самостоятельно писать в сислог — попадут в сислог. А чей-либо stdout/stderr не попадёт никуда, потому что внезапно journald именно тем и занимается, что перенаправляет одно в другое.
А вообще я скоро допишу статью, в которой про всё это написано. Она должна была войти в SIA #3, но я не успел.
Исправление intelfx, :
Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?
Зависит от значения директивы StandardOutput=. Варианты:
- в journald;
- в низкоуровневую консоль (путь к которой указан директивой
TTYPath=); - в сокет (если это сокет-активируемый юнит);
- в никуда.
такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?
Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».
systemd-networkd
По умолчанию не включен.
systemd-vconsole-setup
Отключается путём маскирования.
А возможно ли отключить journald
Отключается путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).
сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»
А это уже зависит от тебя и от демонов. Те сообщения, которые демоны будут самостоятельно писать в сислог — попадут в сислог. А stdout/stderr не попадёт никуда, потому что внезапно journald именно тем и занимается, что перенаправляет одно в другое.
А вообще я скоро допишу статью, в которой про всё это написано. Она должна была войти в SIA #3, но я не успел.
Исправление intelfx, :
Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?
Зависит от значения директивы StandardOutput=. Варианты:
- в journald;
- в низкоуровневую консоль (путь к которой указан директивой
TTYPath=); - в сокет (если это сокет-активируемый юнит);
- в никуда.
такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?
Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».
systemd-networkd
По умолчанию не включен.
systemd-vconsole-setup
Отключается путём маскирования.
А возможно ли отключить journald
Отключается путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).
сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»
А это уже зависит от тебя. Те сообщения, которые демоны будут писать в сислог — попадут в сислог. А stdout/stderr не попадёт никуда, потому что внезапно journald именно тем и занимается, что перенаправляет одно в другое.
А вообще я скоро допишу статью, в которой про всё это написано. Она должна была войти в SIA #3, но я не успел.
Исходная версия intelfx, :
Если программа, запускаемая юнитом, попытается что-нибудь написать в stdout или stderr, куда попадут эти записи?
Зависит от значения директивы StandardOutput=. Варианты:
- в journald;
- в низкоуровневую консоль (путь к которой указан директивой
TTYPath=); - в сокет (если это сокет-активируемый юнит);
- в никуда.
такие компоненты как systemd-networkd, systemd-vconsole-setup вообще отключать можно или нет?
Отключать можно всё. Главное — не ныть потом на ЛОРе по поводу того, что «всё сломалось, Поттеринг криворукий мудак».
systemd-networkd
По умолчанию не включен.
systemd-vconsole-setup
Отключается путём маскирования.
А возможно ли отключить journald
Возможно, путём маскирования (внимание: не только systemd-journald.service, но и соотв. сокета systemd-journald.socket).
сделать так, чтобы сообщения ядра и демонов сыпались в привычный syslog, который умеет раскладывать журналы «по полочкам»
А это уже зависит от тебя. Те сообщения, которые демоны будут писать в сислог — попадут в сислог. А stdout/stderr не попадёт никуда, потому что внезапно journald именно тем и занимается, что перенаправляет одно в другое.