LINUX.ORG.RU
ФорумAdmin

systemd отключение journald

 ,


0

1

Всем привет.

Я только начал изучение systemd.
Везде пишут что journal нельзя отключить, можно только перенаправлять логи.
почитал документацию, увидел что вроде отключается параметрами.

vim /etc/systemd/journal.conf

Storage=none
ForwardToSyslog=yes
пытаюсь далее посмотреть логи
journalctl  --boot                                                                                                                                 
No journal files were found.
Получается, что отключается?
syslog вроде сам может принимать логи, без ForwardToSyslog=yes


Это не значит что демон отключен. Он работает и перенаправляет логи, как тебе и сказали.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

«Начиная с systemd версии 216 эта опция была отключена по-умолчанию, так как rsyslog и syslog-ng уже могут читать самостоятельно сообщения journal. »

Ну хотя бы логи в бинарном виде хранить не будет.

carter
() автор топика
Ответ на: комментарий от carter

Система через некоторое время тихо умрёт. Выяснение того, почему (и как это обойти), остаётся в качестве упражнения юному хейтеру бинарных логов :3

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Deleted

Не пытайся убедить этого фанбоя что систумд зло, это бесполезно. У меня иногда возникает чувство что он Поцтеру даже свечку держать согласится.

ТС, забей на эту тухлую штуку, поставь генту и не сношай себе мозг

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Не, я подтруниваю.

После того, как увидел что он преднамеренно дезинформирует людей - и убедить и убеждаться перестал :)

Deleted
()
Ответ на: комментарий от carter

Если просто замаскировать systemd-journald, через некоторое время все программы, которые хоть что-то в него пишут (даже косвенно), начнут поочерёдно падать (как кошки с неба в конце второго Postal'а).

intelfx ★★★★★
()
Ответ на: комментарий от arcanis

Всё просто: journald же сокет-активируемый. Приложения всё равно будут писать в заботливо заранее открытый сокет и через какое-то время переполнят внутриядерный буфер. Другими словами, надо вместе с .service замаскировать ещё и .socket.

intelfx ★★★★★
()
Ответ на: комментарий от AS

Естественно. Если лезть в кишки любого достаточно сложного софта без должного понятия о том, как эти кишки устроены — то в любом случае рано или поздно получишь unexpected behavior.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

он большой. много того что мне не нужно.

carter
() автор топика
Ответ на: комментарий от intelfx

По той, что это «достаточно сложный софт» ?

Совершенно верно. ПО такой сложности не должно быть в основе функционирования ОС.

Это проблема мозга администратора

И да, это проблема мозга архитектора ОС.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

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

carter
() автор топика
Ответ на: комментарий от carter

Раздражает скорее неустойчивое, переусложненное Д. Против всяких upstart и т.д. не было такого шума. Вот например мне не нужна система инициализации которая в любой момент может «что-то» сделать не то и в результате уронить систему, причем даже на десктопе, когда открыты необходимые для работы приложения и вдруг «фигак» получить не хочется. Вобщем раздражает ненадежность.

anc ★★★★★
()
Ответ на: комментарий от carter

наверно всех раздражает скорее отсутствие выбора

Тогда уж вместе. Да, можно было бы не обращать внимания на комбайн (который просто не может быть надёжен из-за перегруженности функционалом), если бы он, дополнительно, не тянул на себя одеяло.

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.