LINUX.ORG.RU

История изменений

Исправление 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 именно тем и занимается, что перенаправляет одно в другое.