systemd 251

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

Получил команду на перезагрузку - отослал всем процессам с PIDами выше единицы команду добровольного завершения - подождал пока синкнется ФС (это важно, да) - послал в ACPI команду ребута или повероффа, или как там нынче управляется питалово. Все. Кто не успел, тот опоздал.

Бог с ним с перезагрузкой.

Какой фатальный недостаток был в ТЕКСТОВЫХ логах, что нужно было вводить это непарсируемое нормальным способом мракобесие ?

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

А откуда конкретный демон должен узнать, что пора завершаться?

Вы переключились в режим «давайте поговорим о филологии», или как? Есть конкретная проблема: команда останова сервиса зависла. В sysvinit вместе с ней намертво завис весь процесс завершения работы системы — что предлагаете делать, кроме Reset/SysRq?

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

А откуда конкретный демон должен узнать, что пора завершаться?

SIGTERM тащемта

«Тащемта» mysqladmin shutdown на kill -TERM не очень похож.

В большинстве случаев да, SIGTERM достаточно. Однако полно демонов, которые завершаются иначе, и MySQL лишь один из примеров.

А это уже проблемы MySQLя. Почему ? Да потому что даже я в своих говнодемонах на говнопыхе ловлю этот сигнал.

<?php
declare(ticks = 1);
pcntl_signal(SIGTERM, "killer");
function killer($signal) {
if ($signal==SIGTERM) {echo "SIGTERM received, killing ...\n";exit();}
while(1) {
echo "Тута наш полезный код \n";
sleep(1);
         }
?>

Но. Какая разница кто прибьет процесс по SIGKILL - баш-портянка, или С-портянка ?

И да, почему-то именно в init-скриптах есть куча говна в стиле «кто во что горазд» — порой за голову хватаешься, какие костылищи выдумывают их казалось бы компетентные авторы (примеры: killall maraidbd выше, gdm из FreeBSD).

Наверное, отсутствие внятной единой системы как раз и приводит к такому разброду и шатанию.

А это уже проблемы MySQLя. Почему ? Да потому что даже я в своих говнодемонах на говнопыхе ловлю этот сигнал.

Ну конечно. Пойдём перепишем все такие демоны. Включая те, которые не являются открытым ПО — пишите письма в конторку и ждите ответа.

init-система должна уметь работать с существующими демонами, поэтому несмотря на то что в том же systemd всегда предпочли бы Type=notify, существует и поддерживается Type=forking.

Какая разница кто прибьет процесс по SIGKILL - баш-портянка, или С-портянка ?

Разница в том, что bash-портянка запнётся на первой же зависшей команде. Пример см. выше.

Теперь я основательно запутался.

1. Система с sysv:

Есть демон. mariadbd;

Есть скрипт старта\стопа этого демона;

При необходимости кильнуть, скрипт отправляет kill -9.

2. Система с systemd:

Есть демон. mariadbd;

Есть херпойминакакомязыке (ага, учим еще один man) написанный юнит для старта\стопа этого демона;

При необходимости кильнуть, парсер того юнита на херпоймикакомязыке, отправляет kill -9.

Теперь kill -9 вызывается не со скрипта, а с бинарника парсящего другой скрипт. В чем здесь усовершенствование ?

Ну конечно. Пойдём перепишем все такие демоны.

Не совсем тебя понял. Если демонописец не предусмотрел для своего демона отлов SIGTERM и выход по нему - его ПРАВИЛЬНО не завершит ни портянка на баше, ни моднявый systemd, потому что правильность завершения у него не предусмотрена by design.

Разница между sysv и systemd в том, что в одном случае SIGTERM процессу посылает баш, во втором случае си. Равно как и киляет принудительно процесс в первом случае баш, во втором случае си.

Пример выше показывает лишь то, что mariadbd не умеет нормально завершать работу. Его прибить может как баш портянка, так и с-портянка.

Ты вообще о написании программ имеешь хоть малейшее представление ?

Смотри. Вот я пишу программу, которая ... а просто висит в памяти, ничего не делая. Вот она:

<?php
while (1) {sleep(1);}
?>

Когда я, разработчик этой программы, пихаю ее в пакет, я по хорошему, должен интегрировать ее в ОС. То есть это ИМЕННО Я ДОЛЖЕН написать набор команд системе инициализации.

Я как разработчик могу написать в баш портянке, чтобы программу завершал kill -9, ибо by design эта программа ничего не делает, никуда не пишет, буферы сбрасывать ей не нужно, посему она может завершаться как угодно.

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

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

Не зная, как работает моя программа, ты напишешь самый обыкновенный юнит;

По завершению работы в системе, твой комбайн, пошлет моей программе SIGTERM;

Моя программа сделает покерфейс, потому что в ней не предусмотрен выход по SIGTERM. И твой комбайн будет вынужден ждать определенное количество времени, а уже потом форсированно прибивать мою программу, хотя ему ничего не мешает это сделать раньше.

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

Это же самое можно сделать и с баш-портянки.

Поэтому возвращаюсь к сказанному выше: не поменялось НИЧЕГО кроме добавленного инструментария. Мне, как разработчику, все равно придется что-то писать. Просто не на языке шелла, а на языке комбайна.

Хочу увидеть пруфы.

Сейчас не знаю, где найти столь нестабильное железо. Во времена Windows Vista, где как раз завезли эту фичу, у меня на нвидии регулярно было - из колонок «тыдык!» и возле часов сообщение «Служба драйвера дисплея была перезапущена». Даже экран не моргал. Хоткей отдельный даже был, который ребутал видеодрова на горячую.

Если абстрагироваться достаточно высоко, то поездка на осле и поездка в комфортабельном Mercedes S-класса — одно и то же, ведь это лишь перемещение из пункта А в пункт Б…

Ваша проблема в том, что вы пытаетесь упростить модель до абсурда. Да, если смотреть издалека, то завершение работы системы в каждой реализации init проходит в целом одинаково: выполняются прописанные команды, посылаются сигналы и т.д. А по факту имеем зависшую систему с sysvinit и вполне нормально завершающий работу systemd (или upstart, или launchd, или…).

Одна из основных проблем init-скриптов в том, что они пишутся на абсолютно не приспособленном для таких задач языке без типизации, без примитивов синхронизации, без адекватной обработки ошибок (command || true, ага), с кучей подводных камней (забыл кавычки? фигурные скобки? x$var = xy? set -u? pipefail? subshell-ы в pipe-ах?) и неизбежными состояниями гонок. А запускает их система, которая даже не отслеживает состояние запускаемого.

Но если смотреть издалека да с близорукостью, то одинаково, ага.

Ну блин, на sysv, bsd-init и runit завершение работы не встаёт раком на полчаса. На sysD - иногда встаёт. В чём проблема это пофиксить или хотя бы десктопы по умолчанию настроить так, что не вставало в принципе никогда?

Моя программа сделает покерфейс, потому что в ней не предусмотрен выход по SIGTERM

Если вы не поставили свой обработчик сигнала, то выполнится дефолтный, который завершит работу процесса. Вы точно разработчик?

Ну а пространные рассуждения о том, что с помощью bash, говна и палок теоретически можно написать «хорошую» реализацию (кто б сомневался — ведь это Тьюринг-полный язык), мне слабо интересны. По факту это плохой язык для подобных программ, и имеем то, что имеем.

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

Разница в том, что на языке shell вам (и всем остальным) придётся писать свою императивную реализацию (отсюда и все эти killall да pkill), а «комбайн» абстрагирует это в гораздо более примитивный, но оттого и более понятный декларативный язык.

Плюс расширяемость. Плюс отсутствие гонок из-за PID-файлов за счёт использования cgroups. Плюс возможность легко задействовать фишки ядра типа пространств имён, ограничений системных вызовов и проч. — и всё это в едином формате, не вынуждая писать императивный код. С которым, опять же, зачастую не справляются даже опытные разработчики — примеры есть выше, но могу добавить и ещё один: мой багрепорт почти 10-летней давности.

Не говоря уже о том, что мне как разработчику гораздо удобнее один раз написать простой сервис-файл, который будет работать в подавляющем числе дистрибутивов, нежели делать отдельный скрипт для Slackware, отдельный для Debian, отдельный для RedHat, а уж openSUSE и их былых init-скриптов касаться вообще не хочется.

Ну блин, на sysv, bsd-init и runit завершение работы не встаёт раком на полчаса.

Ну anecdotal evidence же. Сколько было жалоб на зависание загрузки того же Debian при отсутствии сети в эпоху init-скриптов — забыли уже? (Да, это не завершение работы, но суть-то та же.)

Ну и у меня есть своя cool story: на моём прошлом ноуте бывали проблемы с PCIe, и потому порой глючил SSD. В один прекрасный день завис swapoff при завершении работы — так systemd к моему удивлению за несколько минут таки сумел мучительно продраться через все ошибки ввода-вывода и завершить работу системы, а что было бы в таком случае с sysvinit — см. пример выше.

И речь не о том, что systemd идеален или что это панацея от всех бед, но о том, что sysvinit говно. Не было бы systemd — пускай был бы upstart (хотя тот местами весьма костыльный), портировали бы launchd или ещё что-нибудь — вместо системы инициализации на языке для интерактивного использования да небольших скриптов, с кучей костылей и подводных камней.

Если вы не поставили свой обработчик сигнала, то выполнится дефолтный

Это какой ? Как он завершит работу моего процесса ? Он что, знает в чем работа моего процесса ?

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

В какой язык ?

Плюс расширяемость. Плюс отсутствие гонок из-за PID-файлов за счёт использования cgroups. Плюс возможность легко задействовать фишки ядра типа пространств имён, ограничений системных вызовов и проч.

Вот за это systemd и ненавидят. Он пытается делать то, что инит не просят, и делает он это криво.

не вынуждая писать императивный код

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

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

Ну да. Что в этом сложного, написать .sh-файл, в котором start будет запускать, stop слать sigterm, restart слать sigterm и запускать ?

отдельный скрипт для Slackware, отдельный для Debian, отдельный для RedHat, а уж openSUSE

Да, вот за это стоит сказать спасибо RedHatу: административными методами продавил свое багоподелие на все дистрибутивы.

Это какой ? Как он завершит работу моего процесса ?

man 7 signal

В какой язык ?

man systemd.syntax

Он пытается делать то, что инит не просят

Вы лично не просите ≠ никто не просит.

Ну да. Что в этом сложного, написать .sh-файл, в котором start будет запускать, stop слать sigterm, restart слать sigterm и запускать ?

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

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

В общем, раз в этом нет ничего сложного, то — пишите, Шура, пишите…

это непарсируемое нормальным способом

windows10 ★★★ (24.05.22 22:00:44)

Всегда подозревал что виндузятники это днище, но то, что распарсить тривиальный и отлично документированный формат для них проблема - эта прям новая грань некомпетентности. Что ты вообще на ЛОРе забыл? Вкладку с винфак перепутал?

С systemd система завершается нормально, с sysv, bsd-init и runit завершение может встать раком и не случиться вообще никогда (или пока watchdog не квакнет). Это, собственно, одна из причин почему systemd и сделали - получить стабильное предсказуемое поведение базовых компонентов системы.

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

man 7 signal

Такого сигнала нет.

man systemd.syntax

Я тебя спросил о языке, а не конфиге юнит-говна стыренного с виндового INI-формата.

Вы лично не просите ≠ никто не просит.

Никтонепрошение следует из самой концепции init'а - инициализации. Конечно, к чайнику можно приделать мясорубку, и оно даже кому-то понравится. А еще можно пропихнуть это в супермаркеты, выпустив телевизоры не работающие без чайнико-мясорубки. И потом заявить что фичей мясорубки пользуются, а значит ее ждали в чайнике, лол. И это нормально. Только нехер людям в глаза, и говорить что это чайник. systemd - это не чайник, а НЁХ, придуманная полупокером не осилившим sh, и взгроможденная в массы полу-авторитарным способом - через насаживание. Давно ли DE стало нуждаться в поддержке системы инициализации ? Да оно (Gnome) и сейчас не нуждается, иксы\вяленный вполне себе стартовали и раньше. Но нет, мы прибьем инит к ДЕ, потому что иначе ж мы не заставим людей пользоваться этим шлаком.

А PID, которому слать, он с потолка возьмёт? А осиротевшие дочерние процессы он не оставит? А не прибьёт ли он другой процесс, если исходный уже давно завершился, и его PID занял другой?

Раньше брали, не оставляли, не прибивали.

в основном потому, что он ещё ничего из им предлагаемого не пробовал воплотить в реальность

В реальности я страдаю когда у очередного клиента не запускается очередной elasticsearch или nginx, а я вместо удобного tail -f /var/log/syslog - дрчу пейджапами-пейдждаунами по красивым стрелочкам.

root@gideon:/etc/mysql/mariadb.conf.d# service mariadb start
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
root@gideon:/etc/mysql/mariadb.conf.d# systemctl status mariadb.service
● mariadb.service - MariaDB 10.3.34 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-05-25 02:46:14 EEST; 11s ago
       Docs: man:mysqld(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 398602 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 398603 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 398605 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    Process: 398667 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=7)
   Main PID: 398667 (code=exited, status=7)
     Status: "MariaDB server is down"

May 25 02:46:11 gideon systemd[1]: Starting MariaDB 10.3.34 database server...
May 25 02:46:11 gideon mysqld[398667]: 2022-05-25  2:46:11 0 [Warning] option 'max_allowed_packet': unsigned value 4294967296 adjusted to 1073741824
May 25 02:46:11 gideon mysqld[398667]: 2022-05-25  2:46:11 0 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
May 25 02:46:11 gideon mysqld[398667]: 2022-05-25  2:46:11 0 [Note] /usr/sbin/mysqld (mysqld 10.3.34-MariaDB-0ubuntu0.20.04.1) starting as process 398667 ...
May 25 02:46:14 gideon systemd[1]: mariadb.service: Main process exited, code=exited, status=7/NOTRUNNING
May 25 02:46:14 gideon systemd[1]: mariadb.service: Failed with result 'exit-code'.
May 25 02:46:14 gideon systemd[1]: Failed to start MariaDB 10.3.34 database server.
root@gideon:/etc/mysql/mariadb.conf.d# 

В общем, раз в этом нет ничего сложного, то — пишите, Шура, пишите…

Я и пишу. И писал бы, если бы мне нагло не всучивали это поделие.

Всегда подозревал что виндузятники это днище, но то, что распарсить тривиальный и отлично документированный формат для них проблема

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

Естественно - не говоря уже о том, что syslog и близко не поддерживает всех возможностей journal. Так - отдельные костыли от разных вендоров поверх формата, разумеется несовместимые друг с другом.

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

man 7 signal

Такого сигнала нет.

Какого, блин, сигнала нет? 🤦

Это называется «команда». Эти буквочки и циферки нужно ввести в терминал и нажать на кнопочку Enter.

Я тебя спросил о языке, а не конфиге юнит-говна стыренного с виндового INI-формата.

Это тоже язык, если вы не в курсе.

Давно ли DE стало нуждаться в поддержке системы инициализации ?

Вы сейчас, наверное, про logind, который не является частью системы инициализации?

Раньше брали, не оставляли, не прибивали.

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

а я вместо удобного tail -f /var/log/syslog - дрчу пейджапами-пейдждаунами по красивым стрелочкам.

…А могли бы удобно следить через journalctl -u mariadb.service -f, но вам захотелось приключений.

В общем, ваш уровень мне понятен. Хотел попросить показать ваши скрипты, которые вы пишете, но теперь что-то страшновато.

Задача логгирования - сернуть в лог. Если мне понадобится его красивенько посмотреть - я его открою в блокноте с подсветками. Если мне его понадобится отправить - я открою email-клиент. Если мне понадобится с ним сделать %action% - я открою %программу_для_action%.

Старые добрые юникс-тулзы нихрена тебе не найдут в файлах journal. Но ты лучше расскажи мотивацию, которой руководствовался идиот, сохраняя информацию которую нужно читать текстом - в бинарный формат. Это гораздо интереснее.

выпустив телевизоры не работающие без чайнико-мясорубки

Ты съехал на бессмысленные аналогии потому что на конкретный технический вопрос ответить не смог, а признаться в этом зассал?

и взгроможденная в массы полу-авторитарным способом - через насаживание

Сексуальные фантазии виндузятников это отдельный жанр кринжа конечно.

Какого, блин, сигнала нет?

Ну ты написал что man 7 signal корректно завершит работу моего процесса ;)

Это тоже язык, если вы не в курсе.

Нет, я не в курсе. Но уговорил, тогда и формат fstab'а - язык.

Вы сейчас, наверное, про logind, который не является частью системы инициализации?

Нет.

А могли бы удобно следить через journalctl -u mariadb.service -f

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

Хотел попросить показать ваши скрипты, которые вы пишете, но теперь что-то страшновато.

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

Ты съехал на бессмысленные аналогии потому что на конкретный технический вопрос ответить не смог, а признаться в этом зассал?

Я сьехал на бессмысленные аналогии по двум причинам. Во-первых, с фанатиками спорить бессмысленно, ты скорее признаешь баг не багом, нежели что объект твоего поклонения - шлак; во-вторых, ты как типичный красноглаз с узким кругозором, зачем-то героически ищешь решения одной маленькой задачи, искренне считая что тебя спрашивают именно решение задачи, а не целесообразность ее постановки.

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

Ну а мне нет смысла дискутировать с наивным (или дураком), считающим что в 2022 году только он изобрел чтение мануалок.

Ну ты написал что man 7 signal корректно завершит работу моего процесса ;)

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

Но уговорил, тогда и формат fstab’а - язык

Разумеется!

Нет.

А о чём тогда? В каком месте DE стали нуждаться в поддержке системы инициализации?

Только зачем, если на выхлопе я вижу то же самое, что и раньше, используя очевидные простые инструменты ?

Во-первых, не то же: вывод отфильтрован исключительно по выхлопу конкретного нужного вам сервиса.

Во-вторых, количество возможностей по фильтрации и формату показа содержимого несопоставимо, начиная от диапазона дат и заканчивая выводом в формате ключ=значение (или JSON) для удобной машинной обработки.

На мой взгляд, основной положительный момент journal — это разделение форматов хранения и представления информации. В журнале хранится значительно больше данных, нежели в стандартном syslog, и при этом можно выводить эту информацию в том виде, который удобен в данный момент. (Хотя была ли необходимость использовать именно двоичный формат хранения — вопрос дискуссионный.)

Если мне понадобится его красивенько посмотреть - я его открою в блокноте с подсветками.

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

Старые добрые юникс-тулзы нихрена тебе не найдут в файлах journal.

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

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

Чужая душа - потёмки, тем более душа виндузятника: понятия не имею что тобой движет и какого лешего ты забыл на ЛОРе.

с фанатиками спорить бессмысленно

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

искренне считая что тебя спрашивают именно решение задачи

Решение задачи спросили как раз тебя, когда ты необдуманно попробовал изобразить из себя дофига эксперта. Ты тут же съехал на какие-то левые аналогии наглядно показав что ты виндузятник, а не эксперт.

Реализация Х протокола одна, а реализаций Wayland, которыми пользуется большое количество человек, как минимум 3. А вообще этих композиторов десятки. Но именно wayland это про монополизацию. Что ж, очень логично.

реализаций Wayland, которыми пользуется большое количество человек, как минимум 3

Weston, Mir, а третья кто?

Ядро Linux, обвязка GNU-Systemd

Gnome (Mutter), KDE (KWin) и Sway+wlroots. Особенно монолитен, неповоротлив и раздут третий вариант.

я просто спросить: для каких профессионалов делали journal?
Если хранить логи не в памяти, то тормозит не только journalctl, но и systemctl. А иногда надо хранить столько логов, что памяти надо довольно много

с systemd завершение тоже может встать раком. Как-то оказалось, что процесс подвис, а в юните было прописано, что ждать завершения нужно вечно. (юнит из пакета, не я такое поставил)
И CtrlAltDelBurstAction=reboot-force не помогло, systemd написал, что намек понял и завершается вот прям сейчас, и повис дальше, но уже без счетчика ожидания

Как-то оказалось, что процесс подвис, а в юните было прописано, что ждать завершения нужно вечно. (юнит из пакета, не я такое поставил)

Что за пакет, если не секрет?

И CtrlAltDelBurstAction=reboot-force не помогло

Это значение по-умолчанию вообще-то.

systemd написал, что намек понял и завершается вот прям сейчас, и повис дальше

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

То есть ты либо не прочитал что тебе написали, либо не понял. И уж совершенно точно не пробовал читать документацию.

для каких профессионалов делали journal?

Для тех кто знает где должны храниться логи.

Если хранить логи не в памяти, то тормозит не только journalctl, но и systemctl

Брехня как обычно - всё просто летает, особенно по сравнению с сислогом соответствующего размера.

Поиск по условиям и опасность словить no space left on device, если что-то взбесится и начнёт тонны текста в логи писать.

воначе?! вы к славе линуса решили подмазаться... подпереть его костылем, что-бы не дай бог не упал :о)

Для тех кто знает где должны храниться логи.

ну так посвяти, в чем проблема? Если это ёлка или datadog какой, то от journald особой пользы нет.

Брехня как обычно - всё просто летает

поверю, когда закроют https://github.com/systemd/systemd/issues/2460

особенно по сравнению с сислогом соответствующего размера.

может ты еще и с пожатым сислогом соответствующего размера сравнивал?

если что-то взбесится и начнет тонны текста в логи писать, то journald этим текстом захлебнется и у тебя могут быть проблемы с ssh/sudo. Они когда пишут логи, то встают в общую очередь.

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

если что-то взбесится и начнет тонны текста в логи писать, то journald этим текстом захлебнется

нет

$ grep RateLimit /etc/systemd/journald.conf
RateLimitIntervalSec=30s
RateLimitBurst=10000

Кстати, там ротацию для каждого юнита в отдельности сделали

man 5 systemd.exec

Я в курсе, нам не особо помогло. journald старался как мог, грузил ядро в 100%, но тормоза были. Ну и плюс в этом случае у нас логи были не в памяти, а на диске, он их потиху ротировал.

LogNamespace — ок, но в мане на сервере такого нет :)

:)

Тупым детям админам локалхоста рекомендуется почитать документацию на SysV и посмотреть, что вообще умеет классический init и inittab. А умеет он, например:

• респавн запущенного инитом же процесса (то есть мониторинг выполнения);
• однократный запуск при переходе на нужный ранлевел;
• запуск только при загрузке и запуск с ожиданием завершения при загрузке;
• всякие специальные вещи вроде powerwait (управление питанием через инфу от ИБП) и перехват ctrl+alt+del.

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

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

ну так посвяти, в чем проблема?

У кого? У меня всё отлично работает - именно так как мне и хотелось.

поверю, когда закроют https://github.com/systemd/systemd/issues/2460

Ну да, для вот этого экзотического случая (hdd, огромные локальные логи) индекс не помешал бы в качестве оптимизации. Шли патч раз это твой случай.