[РЕШЕНО] systemd: как заткнуть фонтан в tty?

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

Natrio
Единственный способ, которым мне пока удалось это сделать, представляется мне несколько э… ужасным, хотя он и работает.
Ну как он может работать если в этот юнит просто перезапускает демонов. соответственно делает лишнюю работу. Возможно результат подходящий, но это побочный эффект.


Natrio
Результат: замедления не замечено.
А у меня замечен. Пару сек замедление стабильно…
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
это сильно противоречит смыслу, как ударить стену ногой и удивиться что нога заболела. У юнита есть параметр вывода сообщений, как точно не кажу , но думаю кто хочет быстро откопает в мане, обычно там стоит чтото вроде inherit , т.е. обычно это то куда обычно процесс и срет, т.е. терминалы. Мне кажется чтобы изменить ситуацию, нужно както передать всем юнитам, которые явно не оглашают свой выхлоп, слать сообщения куданито еще, например валить все к ядерным запискам. Так вот, учитывая что сейчас активно пилят системы логирования, предлагаю озвучить вопрос разработчику, так как ,имхо, тут мы не разберемся, (нигде в манах я не видел похожих по смыслу записей), без встроенного функционала. Учитывая что сам Ленарт любит такиеже эксперименты с суперпупер “быстрой” загрузкой, думаю он должен был столькнуться с подобной проблемой и по крайней мере иметь варинат, а лучше конечно заложить ему мысль о добавление функции еще одной)))
Способ озвученный выше, конечно работает, но видится мне как попытка заткнуть дрищ пальцем. Скажу честно, он мне не нравится, поставь такой способ гденито в районе sysinit и бог знает что может случится. Все таки не хватает анализаторов системе, хотелось бы получить больше отчетности от системы как она запускает юниты, опять же не для интереса , а скоее для дебага своих нестандартных “кривых затей”.
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
agetty на каждой консоли запускается ТОЛЬКО ПОСЛЕ переключения на неё.
Вывод сообщений прекращается по достижении заданной при запуске цели, то есть той, на которую указывает ссылка default.target
Если вывод продолжается во время логина, значит эта цель в данным момент ещё не достигнута. Я уже нашел один способ отключать эти сообщения досрочно (см. первый пост), просто мне хочется сделать всё более правильным и надёжным методом :)

Я это понял. Просто можно плясать из инициализации потока вывода в другую консоль. Если её (инициализацию в другую консоль) запретить, то все должно работать как вы хотите. Сейчас ищу этот кусок в сервисах
не знаю, пробежался мельком по манам, которые еще не одолел, единственно чтото похожее в мане к самой системе.
       --show-status=
           Show terse service status information while booting. This switch has no effect when run as user instance. Takes a boolean argument which may be omitted
           which is interpreted as true.
       --default-standard-output=, --default-standard-error=
           Sets the default output resp. error output for all services and sockets, i.e. controls the default for StandardOutput= resp.  StandardError= (see
           systemd.exec(5) for details). Takes one of inherit, null, tty, journal, journal+console, syslog, syslog+console, kmsg, kmsg+console. If the argument is
           omitted --default-standard-output= defaults to journal and --default-standard-error= to inherit.
Правда меня не покидает чувство, что я вообще не то ищу… не могу никак понять очучение))
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
jim945
Не это ли?
       TTYPath=
           Change the console TTY to use if ForwardToConsole=yes is
           used. Defaults to /dev/console.
man journald.conf
Спасибо, интересная вещь :)
Но это немного другое. Этим способом перенаправляется вывод САМИХ демонов, который без этого обычно смешивается с выводом systemd, который независимо от этой настройки направляется, видимо, в /dev/console

nafanja
Ну как он может работать если в этот юнит просто перезапускает демонов. соответственно делает лишнюю работу. Возможно результат подходящий, но это побочный эффект.
Команда systemctl daemon-reexec перезапускает ТОЛЬКО ОДИН ДЕМОН, как и следует из единственного числа в названии. Имя этому демону – systemd
man systemctl
       daemon-reexec
           Reexecute the systemd manager. This will serialize the manager
           state, reexecute the process and deserialize the state again. This
           command is of little use except for debugging and package upgrades.
           Sometimes it might be helpful as a heavy-weight daemon-reload.
           While the daemon is reexecuted all sockets systemd listens on on
           behalf of user configuration will stay accessible.
Метод перенаправления вывода в другую консоль пока представляется мне таким:
1) Сразу при запуске командой chvt 12 переходим в нужную консоль, и сообщения сыплются туда, поскольку /dev/console это реальная, а не виртуальная консоль, и сообщения оттуда остаются в той консоли, которая в данным момент была активна.
2) Перед запуском getty отрубаем вывод systemd и делаем chvt 1 . После этого в tty12 проболжается только вывод демонов
daemon-reload
Reload systemd manager configuration. This will reload all unit files and recreate the entire dependency tree. While the daemon is reloaded, all sockets
systemd listens on on behalf of user configuration will stay accessible.
я бы не сильно доверял бы трактовки названия команд, ну по крайней мере точному переводу(это касается не только системд). ;)
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
sleepycat
daemon-reload
Reload systemd manager configuration. This will reload all unit files and recreate the entire dependency tree. While the daemon is reloaded, all sockets
systemd listens on on behalf of user configuration will stay accessible.
я бы не сильно доверял бы трактовки названия команд, ну по крайней мере точному переводу(это касается не только системд). ;)
Как вы представляете себе reload all unit files ? Как перезагрузку демонов?
Нет, это именно то, что написано – systemd всего лишь заново ПРОЧТЁТ ФАЙЛЫ юнитов, и “recreate the entire dependency tree” заново построит у себя (схему) дерево зависимостей, чтобы по ней дальше ориентироваться :)
Natrio, ты не понел просто что я хотел сказать.
Можно поинтересоваться так сказать у попробоваашего, о работе reexec. Останавливается ли инициализация юнитов(которые еще не активизировались до этой команды), когда поступает такая команда?
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
sleepycat
Можно поинтересоваться так сказать у попробоваашего, о работе reexec. Останавливается ли инициализация юнитов(которые еще не активизировались до этой команды), когда поступает такая команда?
Если бы останавливалась, это не было бы решением :)
Юниты продолжают грузиться с того же места, но новый экземпляр systemd уже ничего не выводит в консоль.
Если посмотреть лог, можно увидеть всё, что происходит по этой команде: systemd говорит что сейчас перезапустится, dbus тут же вопит, что потерял с ним связь, потом systemd восстанавливается, и юниты грузятся дальше.
да нет физически на момент рестарта процесс останавливается?
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
 
Зарегистрироваться или войдите чтобы оставить сообщение.