вопрос на засыпку по systemd

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

читал, но как не поиронизировать?

скорее бы уже beta редхата появилась...

Цель всех этих изменений какая? Стало от них кому-то лучше?

Да. Мне. Я все логи системы смотрю в одном месте удобной утилитой. За исключением приложений, которые их генерируют действительно много. Такое бывает, но отнюдь не всегда.

пусть логи в двух местах пишутся

Если ты не хочешь использовать journald, то ты отключаешь хранение им логов и они хранятся только в syslog. Хочешь пользоваться journald - включаешь хранение логов, выключаешь форвард в syslog. Они хранятся только в journald. При этом приложения, если надо, по-прежнему могут писать в syslog (не в journald-dev-log).

Не нужно ее чинить и т.д.

Её не чинили, её заменили. При этом, для тех кто хочет, оставили возможность вернуть как было. Мне вот эти изменения понравились. Journald не идеален, но он лучше, чем syslog.

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

Я может не правильно понял, и речь о чём-то другом, но я catalina.out logrotate'ом обрабатываю и УМВР. Если нравится, можно использовать встроенный ротатор томката. А можно и logrotate. Но вот journald тут вообще ни при чём. Что он есть, что его нет, ситуация не поменяется.

Вот этого я не понял. journald получает логи «из всех возможных источников», чтобы это не значило. А как на твой взгляд получает сообщения syslog?

Из /dev/log, так же как и любой другой syslog. Как это изменить? Просто:

# systemctl disable systemd-journald-dev-log.socket
# sed -i 's|SysSock.Use="off"|SysSock.Use="on"|g' /etc/rsyslog.conf

$ sudo ss -lnp  | grep /dev
u_dgr             UNCONN              0                    0                                                                       /run/systemd/journal/dev-log 4728889                                                * 0                       users:(("systemd-journal",pid=8153,fd=6),("systemd",pid=1,fd=19))              
u_dgr             UNCONN              0                    0                                                                                           /dev/log 4716222                                                * 0                       users:(("rsyslogd",pid=7567,fd=4))

Проверил на федоре 28. Правда, перезагружаться мне лень. Но рестарты различные ничего не испортили.

Просто я знаю, как он работает, а тебя по-моему какая-то своя версия.

Да чё-то я да, не правильно выразился.

Если в итоге у тебя выйдет три отдельных способа получения логов: syslog, tomcat и journald

Если ты считаешь, что journald - плохой способ ведения логов, то ты можешь его отключить. Более того, это всё элементарно скриптуется. Сделать это надо один раз, работать будет на всех Centos 7. Что там будет на 8 нужно смотреть.

После того, как ты отключишь journald, у тебя будет всё ровно тоже, что и раньше. Тот же syslog, те же файлики. Ничего не сломается.

Дизайн journald не предполагал remote logging. Что-то там сейчас допилили, но вроде курам на смех.

Мне так ни разу и не довелось его попробовать. Но он есть как в journald, так его можно сделать и средствами syslog. Опять же, ничего не сломали.

Не кончатся. Куча юнитов представляет из себя /etc/init.d/servicename <start|restart|stop>

Куча только в дебиане. И порой это доставляет неудобства. Ибо вместо того, чтобы посмотреть понятный unit-файл приходится лезть в баш-скрипт на десяток экранов. Я понимаю, что умеючи можно в нём быстро разобраться. Но учиться этому как-то совсем не хочется. Порой проще самому новый юнит написать.

Я все логи системы смотрю в одном месте удобной утилитой.

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

В дебиане в дефолте sysv.

Если ты не хочешь использовать journald, то ты отключаешь хранение им логов и они хранятся только в syslog.

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

Её не чинили, её заменили.

я сейчас где-нибудь попробую journald отключить и запустить rsyslogd

Ну про десяток экранов это ты загнул. :)

Про написание юнитов. Как сделать в systemd проверку, поменялось ли время изменения файла конфигурации с прошлого раза или нет, чтобы понять, надо ли его перечитывать или можно взять всё из кеша? Это есть в инит-скрипте ferm, например.

к слову об удобный утилитах:

systemctl stop systemd-jour*

это работает, а это

systemctl disable systemd-jour*

нет.

это работает, а это
нет.

кто нибудь, попросите этого «я одмин 10 лет и мне платят, а вы трллли» начать читать маны.
это уже сюр какой-то.

да, разница с RHEL6 только в том, что он не выдает такого сообщения «Reloaded Berkeley Internet Name Domain (DNS).»

Но зелёненький ок тем не менее выдаёт при выполнении команды. А то, что он не пишет (вообще, даже если всё успешно) о своих действиях, я бы не считал плюсом.

Да и вообще, systemd же пишет, если главный процесс грохнулся об этом в журнале. Да, он сперва пишет, что успешно сделал reload, а потом, что сервис мёртв. С named было не так?

т.е. init скрипт в rhel6 делал нужную проверку, а после миграции на systemd ее потеряли.

Ну бывает такое, ошибаются люди. Тем более это федора, она для того и есть, чтоб ловить ошибки. С upstart, как выяснилось, люди тоже ошибаются. Причём годами.

Я честно сказать не знаю, что ты имеешь ввиду. RHEL, Debian и Ubuntu использовали upstart, а скрипты для сервисов были на баше.

Емнип в дебиан, всё-таки был sysv, нет? А вообще в rpm-based не было, как минимум, start-stop-daemon'а, поэтому инит скрипты из одного нельзя было использовать в другом. С systemd - можно, максимум придётся подправить пути/названия. В общем с тем, чтобы осилить systemd у меня проблем не было практически никаких. А вот sysv/upstart и т.п., лично мне доставляли много боли, когда я пытался заворачивать в них свои сервисы. И ещё до кучи, они не умеют systemd'шный Type=simple, что вообще фу-фу-фу.

одно было взято из legacy файлов, другое новенькое. и сервис сломался. во веселуха!

Речь про /etc/sysconfig/$service_name чтоли? Или про что, я не понимаю.

sysconfig вроде никто упразднять не собирался. Вполне штатное место для конфигурации сервисов, в том числе запускающихся systemd.

уж лучше бы они вообще никакой совместимости не делали, чем вот такое «всегда работает, но иногда неожиданно ломается».

Единственная альтернатива в линуксе, это «всегда не работает». Что-то сложное всегда может сломаться при обновлении.

И всё-таки не понятно, про какую ты совместимость.

Но зелёненький ок тем не менее выдаёт при выполнении команды.

[со вздохом] нечего тебе возразить...

однако вот посмотри, какую я картину наблюдаю уже 20 минут. это все. зависон.

https://imgur.com/a/zsFRwaK

systemd тупо завис в топе, 100% загрузки. это при остановленном journald. ну, как мне уже объяснили, в федоре просто дибилы ... виноват не systemd

как будешь чинить целостность журнала, если она нарушится и смотреть логи?

Это уже пофиксили. Теперь journalctl показывает всё, что уцелело сам, без починки.

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

Вот именно этими ключами и удобна. Да хотя бы просмотр лога сервиса с момента загрузки сервера. Накостылять подобное grep'ом я не осилю.

но чуть-чуть он попал под нагрузку и мне вообще его пришлось отключить.

Под отключаешь хранение логов подразумевалось storage=none, ибо volatile хранит в раме.

к слову об удобный утилитах

Про disable systemd-journald-dev-log.socket я фигню написал. Он не нужен, просто ставишь rsyslog и разрешаешь ему занять системный /dev/log. Этого достаточно.

Да, он сперва пишет, что успешно сделал reload, а потом, что сервис мёртв. С named было не так?

Aug 20 03:30:56 dell.inter named[31699]: reloading configuration failed: unexpected token
Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

Ну бывает такое, ошибаются люди.

как же это они два раза на одном и том же месте... ведь им такую удобную вещь сделали...

Емнип в дебиан, всё-таки был sysv, нет?

да? я его давно сам не гонял.

А вообще в rpm-based не было, как минимум, start-stop-daemon'а, поэтому инит скрипты из одного нельзя было использовать в другом. ... А вот sysv/upstart и т.п., лично мне доставляли много боли

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

И ещё до кучи, они не умеют systemd'шный Type=simple, что вообще фу-фу-фу.

это, который один раз? не это который не умеет делать detach процесса, да? нет, у меня как-то все очень складно с запуском сервисов всегда было.

Речь про /etc/sysconfig/$service_name чтоли? Или про что, я не понимаю.

что-то типа того. или /etc/default/... нет под рукой.

sysconfig вроде никто упразднять не собирался.

ну вот и будет бардак. два крона, два-три «дефолтных» места с конфигами...

Единственная альтернатива в линуксе, это «всегда не работает». Что-то сложное всегда может сломаться при обновлении.

Вот ты не поверишь я за 10 лет научился это так готовить, чтобы такой хрени не было.

Это уже пофиксили. Теперь journalctl показывает всё, что уцелело сам, без починки.

о, я же говорю, надо скипать RHEL7 и ждать RHEL8:)))

Накостылять подобное grep'ом я не осилю.

старый мастер смотрит на тебя с сочувствием

Под отключаешь хранение логов подразумевалось storage=none,

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

я фигню написал

а это ничего, я типа думаю, пока набиваю:)

Ну про десяток экранов это ты загнул. :)

Преувеличил. Немного.

Как сделать в systemd проверку, поменялось ли время изменения файла конфигурации с прошлого раза или нет, чтобы понять, надо ли его перечитывать или можно взять всё из кеша? Это есть в инит-скрипте ferm, например.

В данном случае только в execstartpre запихиваешь скрипт, который сделает все нужные проверки.

Для более распространённых хотелок есть всякие кондишоны, хотя их тоже можно в скрипте в execstartpre выполнять.

То, что это лучше и понятнее, чем вообще всю логику, каждый раз в скрипте писать, я надеюсь, ты не оспариваешь?

https://imgur.com/a/zsFRwaK

systemd тупо завис в топе, 100% загрузки. видимо, что-то у него где-то не клеится. потом на dell посмотрю.

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

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html...

да я через lock это сделаю в три строчки при стандартном init.

Aug 20 03:30:56 dell.inter named[31699]: reloading configuration failed: unexpected token

Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

А entered failed state ниже не было? Это странно как-то.

как же это они два раза на одном и том же месте... ведь им такую удобную вещь сделали...

Ну то есть вся суть твоей притензии была в том, что systemd не решает вообще все проблемы, и люди по-прежнему могут накосячить. С этим никто не спорил, и то, что c systemd нельзя накосячить никто не утверждал. Сложнее - да. Но по-прежнему можно.

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

Я не сомневаюсь в том, что есть люди, хорошо разбирающиеся в инит-скриптах. Но вот я не осилил. А с systemd всё просто.

это, который один раз? не это который не умеет делать detach процесса, да? нет, у меня как-то все очень складно с запуском сервисов всегда было.

Это тот, для которого демонизацию и дабл-форк можно не делать. Я им например q4wine из контейнера запускаю. Очень удобно.

Да и с любой самописной вещью заморачиваться не надо. Можно вообще ничего не знать про дабл-форк. Просто запустился и работаешь, как из tmux'а.

ну вот и будет бардак. два крона, два-три «дефолтных» места с конфигами...

Мест с конфигами осталось столько же, сколько и было. Таймеры добавились, да.

Вот ты не поверишь я за 10 лет научился это так готовить, чтобы такой хрени не было.

Что, у тебя федора до systemd никогда не ломалась на обновах?

systemd тупо завис в топе, 100% загрузки. это при остановленном journald. ну, как мне уже объяснили, в федоре просто дибилы ... виноват не systemd

Не, не, не. journald останавливать нельзя. Он нужен для работы systemd.

Мест с конфигами осталось столько же, сколько и было.

1) unit file там можно экспоритровать переменные среды, 2) /etc/default/..., 3) /etc/sysconfig, 4. собственно конфиг сервиса

А entered failed state ниже не было? Это странно как-то.

это уже из journalctl. я не знаю, отражается ли там state.

Ну то есть вся суть твоей притензии была в том, что systemd не решает вообще все проблемы, и люди по-прежнему могут накосячить.

да нет же, systemd очень хорошо _помогает_ людям накосячить.:) (и создает проблемы при миграции) и, смотри скриншот, он висит в топе с загрузкой 100%

А с systemd всё просто.

если начинать учиться и делать все с нуля по одним каким-то правилам, это заметно проще, чем иметь legacy. по этой причине я и говорю, что лучше бы они совсем совместимость убрали. позиционировали бы как что-то отдельное, новое.

Но вот я не осилил.

жаль-жаль. а когда-то юникс админы кроме скриптов легко на Си писали. мельчаем...

Не, не, не. journald останавливать нельзя. Он нужен для работы systemd.

ну вот, приплыли...

Что, у тебя федора до systemd никогда не ломалась на обновах?

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

p.s.

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

В данном случае только в execstartpre запихиваешь скрипт, который сделает все нужные проверки.

Для более распространённых хотелок есть всякие кондишоны, хотя их тоже можно в скрипте в execstartpre выполнять.

Т.е. все эти ненавистные скрипты так и остались. Я про это.

То, что это лучше и понятнее, чем вообще всю логику, каждый раз в скрипте писать, я надеюсь, ты не оспариваешь?

А вот тут частично соглашусь, частично нет. Я как-то поднимал здесь тему, когда мне надо было разнообразные параметры передать при старте. В скрипте это . /etc/defaults/servicename и далее $SERVICENAME $OPTIONS. В systemd пришлось немного повозиться. В простейших ситуациях юнит-файлы удобны. Когда надо сделать что-то сложнее, надо долго пилить эти самые юниты и дописывать собственные скрипты. Причём в некоторых ситуациях использовать уже готовые нарботки из lsb уже нельзя(тот же log_end_msg будет вести себя не так как задумано).

Повторюсь. На мой взгляд сейчас systemd не готов для прода, так как слишком много надо дорабатывать и допиливать. И одна из основных идей так и нереализована - от скриптов пока никуда не уйти. Т.е. поменяли шило на мыло.

Когда надо сделать что-то сложнее, надо долго пилить эти самые юниты и дописывать собственные скрипты.

именно. я абсолютно того же мнения.

и я совершенно не понимаю, почему баш-скрипты стали врагами админов.

слишком много надо дорабатывать и допиливать

сама идея по-большому счету уже меняться не будет. это уже новое поколение Linux, со своими systemd-админами.

sysconfig вроде никто упразднять не собирался.

Вроде собирались и от него избавиться.

старый мастер смотрит на тебя с сочувствием

Ради интереса, может расскажешь, как бы ты это сделал?

как-то так, я думаю https://imgur.com/a/dhLt1QH

Ок, а

Да хотя бы просмотр лога сервиса с момента загрузки сервера.

Да хотя бы просмотр лога сервиса с момента загрузки сервера.

просмотр лога сервиса с момента инициализации системы? странный вопрос. обычно нам нужно найти какой-то конкретный ивент, а не просто почитать логи. ну ты выведешь его с начала запуска сервиса и утонешь в нем. какой смысл? могу предположить, что ты хочешь меня подловить на том, что journalctl позволяет делать поиск по таймстампу. типа как удобно набирать --since 09:00 --until «1 hour ago» - но пока ты это будешь набирать (кучу черточек и все это) я уже less'ом открою нужный лог за нужный день и поиском найду начало просмотра. ивент или дату.

если я подвоха не понял, ты уж объясни мне...

ты хочешь меня подловить

Нет, я просто хотел, посмотреть, как бы ты это сделал. А в ответ какие-то маневры.

типа как удобно набирать --since 09:00 --until «1 hour ago» - но пока ты это будешь набирать (кучу черточек и все это) я уже less'ом открою нужный лог за нужный день и поиском найду начало просмотра. ивент или дату.

Так может и быстрее, если нужно только найти и посмотреть. А если например попросили прислать логи с 09:00 до 18:00, а там с 17:30 до 19:30 ничего нет. Искать когда он оборвался и перебирать регулярки для sed'а тоже будет быстрее?

ну мне просто затея не ясна.

Так может и быстрее, если нужно только найти и посмотреть.

а ты и спросил «просмотр лога»

А если например попросили прислать логи с 09:00 до 18:00, а там с 17:30 до 19:30 ничего нет.

ну хорошо, бывает. попросили логи. с выборкой дня проблемы нет? срабатывает обычный grep «Aug 20» ... > /tmp/log.file

я лично перед отправкой всеравно смотрю глазками. так что смело открывай в редакторе, легко и непринужденно в два нажатия сноси все, что до 09.00 (выделяется автоматически до того места, куда перешел курсор после поиска), а потом спокойно переходи к 19.30 и двумя нажатиями сноси весь хвост. уверяю тебя, кнопок надо нажимать меньше.:) хоть с sed сравнивай, хоть с systemctl.:) потом читаешь, что осталось и узнаешь, что середины нет.

Для того чтобы совсем убрать скрипты - надо быть очень «opinionated». Такое бы Леннарту не простили, и так ругают. Да, в опции можно добавлять скрипты, но поведение systemd хорого документировано и адекватно.

Мне кажется всем этим тредом ты раздул из мухи слона. Ошибка реально очень детская, такая строчка никакое нормальное ревью не прошла бы. На это страшно смотреть. Я не знаю как такое просочилось, написание || в такой цепочке команд должно вызывать рвотный рефлекс автоматически у любого человека видевшего баш больше трех раз

Ну то есть вся суть твоей притензии была в том, что systemd не решает вообще все проблемы, и люди по-прежнему могут накосячить.

Именно. К этому выводу приходят все собеседники. А если быть более точно, то «systemd не решил все проблемы, потому не следовало решать 90% проблем»

Я даже не знаю

journalctl -b 
journalctl -b -1
journalctl --since "2015-01-10 17:15:00"
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
journalctl --since yesterday
journalctl --since 09:00 --until "1 hour ago"

да нет же, systemd очень хорошо _помогает_ людям накосячить.:) (и создает проблемы при миграции) и, смотри скриншот, он висит в топе с загрузкой 100%

Мне кажется...

а парк-то у тебя большой?

Я даже не знаю

ну я зато знаю...

# echo -n 'journalctl --since "2018-08-22 10:00" --until "2018-08-22 19:30"' | wc -c
64

а мне понадобится чуть-чуть подумать и 10 нажатий... вот и сравни свои 64 и мои 10...

Что-то сомневаюсь, что все эти телодвижения будут быстрее и удобней, чем journalctl --since "..." --until "..." >log.file и потом уже посмотреть.

ты спросил - я ответил. а для vertexua просто открыл тестовый лог, проделал с другим временем и посчитал. очень уж мне забавно было смотреть на его новый «эффективный способ»:) никакого подвоха.

В скрипте это . /etc/defaults/servicename и далее $SERVICENAME $OPTIONS

А в юните это

EnvironmentFile=-/etc/defaults/servicename
ExecStart=/path/to/service $OPTIONS

да уж... лоровцы такие умные, жаль, что не они мейнтейнят дистры

вопрос на засыпку по systemd (комментарий)

О, а можно я с небольшим парком в тред вкачусь?

find hiera/node -type f -print | wc -l
7210

Демону не передаются аргументы командной строки

Ну и? Решил же в итоге. То что файл парсится не как в баше - это не баг, а особенность, которую легко учитывать при написании своих юнитов.

Решил. Но в баше это было бы проще. О чём я и написал.

Это очень большая проблема и хуже своих самопальных дегенератских правил квотинга, интерполяции, семантики спецсимволов и эскейпинга, которые вроде как похожи на posix shell, но только на первый взгляд, уже нету. Привет всяким .service, .desktop файлам и прочим поделкам.

# это разумеется, с позиции людей, posix shell владеющих

Это очень большая проблема

Хз, я так не считаю. posix shell владею, но когда пишешь юнит, то пишешь ты его не на шелле. Или после шелла ты уже не можешь переключиться на что-то другое и все воспринимаешь, как шелл?

Открываешь документацию и делаешь что тебе нужно. Документация, кстати, у systemd хороша.

Сегодня 64, завтра 10000000

Ну это уже «спердобейся», нельзя же так. Я по машинам с SSH не бегаю, там все немного по другому работает.

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