SysVinit 3.16

…написание shell-портянок…

…удовольствие…написал и кайфанул…

Вы – тот мусье, который знает толк.

Связи не видите? Штош, тогда что-то доказывать вам бесполезно.

XFCE жива и активно ведёт переезд на Wayland, есть Wayland-оконники без зависимости от systemd, есть XLibre и Xorg на худой конец. И что вы хотите доказать?

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

Это вообще ужасная российская специфика.

внедрению проверки возраста пользователя прямо в systemd

Ужас-то какой... А почему у меня этого нет?? :))

Блин, он уже не идёт на диалог. Что же он хотел доказать-то…

извлечь тоже не получится, всё зашито намертво

Я так и не понял, почему нельзя, если можно заменить systemd-userdbd на какой-нибудь альтернативный сервис. В Гугле находятся: SSSD, NSS, AccountsService, NSCD, LDAP, nslcd. А для systemd-logind предлагает elogind, Seatd.

А даже если нельзя, то есть OpenRC и прочее. Если systemd способствует тому, что на Линукс приходит большей пользователей, и как следствие пилят больше прикладного софта, который в том числе можно использовать и на non-systemd системах, то в чём проблема его существования.

Если разработчики хотят делать софт под Wayland (и то пока большая часть лентяев типа VSCode/Discrod/DaVinci и прочих не сделали нормальные порты, всё идёт через XWayland) и systemd (в случае с более базовым софтом вроде GNOME/KDE), то это не их проблема, что никто из людей в сообществе, которые ненавидят systemd и Wayland, так и не сделали ничего годного для поддержки совместимости, а хотят заставить других делать софт под них.

Когда сам попробовал Mint после Windows 10, у меня глаза офигели от того, как желейно оно работает в связке с дровами NVIDIA (которые поддерживают оба варианта) и Xorg. И лет 5 назад подобное было с GNOME. Сколько ещё лет надо ждать-то, пока Microsoft борзеют прямо на глазах, а их систему поменять значительно труднее, чем славный Linux и софт под GPL…

По части закона и взгляда на блокировки/ограничения я вашу точку зрения уважаю, спасибо, но по части софта есть разногласия. Спасибо за диалог

Блин, он уже не идёт на диалог.

Кто не идёт? Куда не идёт?? Да и идёт он!.. :)

Что же он хотел доказать-то…

я так и не понял, кто это «он» и о ком речь, вообще... :)

Он в смысле - @PPP328

преобразования unit-файлов systemd в sysv-скрипты

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

Я когда-то «демона» написал на PHP… ;P ;))

Я тоже делал. Его задачей было обрабатывать поток данных с датчиков. Просто надо было прослушивать UDP порт. Сначала я делал ответвление от основного процесса, чтобы он в фоне видел. И всё даже работало. Но отладка была - сущий ад. А потом оказалось, что можно просто сделать скрипт, который обрабатывает данные и обернуть его в Unit. Systemd сам следит, чтобы процесс был активным, перезапускает при падениях, да и много ещё чего разного полезного может делать для демона. А отладка проста. Никаких форков процессов. Просто запускаешь скрипт и смотришь от чего он падает в процессе работы или просто логи изучаешь сервиса.

перезапускает при падениях

while true; do echo `date` starting ; /path/to/daemon args ; echo `date` stopped ; sleep 10 ; done

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

while true; do echo date starting ; /path/to/daemon args ; echo date stopped ; sleep 10 ; done

Угу. А теперь надо ещё как-то позаботиться о сохранении в логах того, что сервис выдаёт при своей работе, сделать так, чтобы это всё запустилось в фоне, обеспечить автозапуск, да так, чтобы сервис стартанул не сразу, а только после того, как заработает сеть и появится подключение к интернету… и т.д.

Я точно знаю, что со всем этим systemd отлично справится. Для примера, интересно было бы глянуть как можно запустить некоторый абстрактный сервис в виде скрипта mija2http.php с небольшим количеством зависимостей, которые подключены через composer (должен быть рабочий каталог). Суть его простая: прослушивать UDP порт, обрабатывать полученные данные и отправлять http запросы на определённый сервер. Никаких соединений с БД и прочего, чтобы было попроще. У меня подобный сервис месяцами крутился. Были падения, о которых вся информация в логах journald была. После падения сервис перезапускался спустя некоторое время, а если слишком часто падал, то уходил в отключку. Будет интересно глянуть как такое можно запустить через другие системы инициализации. И это не ради того, чтобы сказать, что systemd крутой, а остальные нет. Скорее для того, чтобы посмотреть. а вдруг реально есть что-то намного круче и удобнее.

А теперь надо ещё как-то позаботиться о сохранении в логах того, что сервис выдаёт при своей работе,

 >> /path/to/xxx.log 2>&1

чтобы это всё запустилось в фоне

&

обеспечить автозапуск

mcedit /etc/rc.local

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

Тут самое сложное, и в целом это костыль. Но можно с помощью пингов выявлять появление интернета.

А можно было еще проще. Прописать нужный порт/протокол на суперсервере xinetd. И он отдавал бы твоей программе трафик на STDIN.

Тут самое сложное, и в целом это костыль. Но можно с помощью пингов выявлять появление интернета.

О чём, собственно, и речь. В systemd я пишу один .service файл и в нём описываю что запускать, от какого пользователя, после чего запускать, куда складывать вывод приложения (обычный поток и поток ошибок), нужно ли следить, чтобы процесс работал и что делать, если процесс остановился. И это не создание костылей, а использование параметров в файле конфигурации сервиса. Параметры описаны в документации и можно использовать не только для этого сервиса, но и в любом другом.

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

А можно было еще проще. Прописать нужный порт/протокол на суперсервере xinetd. И он отдавал бы твоей программе трафик на STDIN.

Для моего примера, возможно, так и есть. Это скорее абстрактный сервис, хотя у меня есть и реальный. Но я делал это ещё в 2018 году, когда никаких ИИ не было, которые могли что-то подсказать. А я сделал, как сделал. С другой стороны, это может быть какой-то другой сервис, который лучше запускать в виде отдельного процесса.

Решил посмотреть как это можно реализовать без демона. Гугл предложил сделать 2 файла для systemd:

[Unit]
Description=Multicast UDP Receiver Socket

[Socket]
ListenDatagram=9898
Broadcast=true
BindToDevice=eth0
Accept=yes

[Install]
WantedBy=sockets.target

и сам сервис:

[Unit]
Description=Forward Multicast Packet to PHP Web Server

[Service]
ExecStart=/usr/bin/curl -s -X POST --data-binary @- http://127.0.0.1/upd/receiver
StandardInput=socket
Type=oneshot

[Install]
WantedBy=multi-user.target

Так что, да. Мой сервис больше не нужен. Вся обработка уже будет идти на веб-сервере на любом языке программирования. С systemd оказывается можно сделать ещё проще, чем делал я :-D

Алё, оригинал вообще-то принадлежит немецкому пастору.

скрипта sysd2v, предназначенного для преобразования unit-файлов systemd в sysv-скрипты

А можно такое же, чтобы на выходе были конфиги для openRC? :)

можно - сделай :)

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

Эм, оригинал чего? И что ещё за немецкий пастор?

пастор Шлаг

https://www.youtube.com/watch?v=-MwY0TcbWz8&t=17s

Удивительно. Но, казалось бы, древняя SysVinit пользуется большей популярностью на ЛОРе, чем runit, которая пользуется популярностью в качестве инита по умолчанию в некоторых дистрибутивах (antiX, Void, Dragora).

Какую систему инициализации вы используете дома?

Гугли «когда они пришли за»

А, это понятно, слышал, знаю. Но автор комментария-то адаптировал эту фразу под блокировки и ограничения со стороны РКП

Офигеть, оно шевелится.

А зачем? Вот уж эту часть юникса точно стоит закопать без сожалений. Она изначально была спроектирована всрато.

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

В настоящее время SysVinit продолжает использоваться в таких дистрибутивах как Devuan, Slackware, Debian GNU/Hurd и antiX.

Всё ненужное перечислено. Гармонично.

А при чем тут systemd? Это государственная инициатива. Если компания хочет поставлять ОС в соответствующие страны, то приходится соответствовать.

Её нельзя форкнуть, никто не потянет

Нахера его форкать?

И этот модуль с возрастом извлечь тоже не получится, всё зашито

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

А уж как это будет соответствовать законам - это к юристам вопрос, а не к программистам.

Вот уж эту часть юникса точно стоит закопать без сожалений. Она изначально была спроектирована всрато.

О, мамины иксеперды на боевых диванах подтянулись.

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

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

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

Речь в обсуждении шла про возраст. Эту функцию патчи как хочешь.

Нахрена трогать системные интерфейсы, непонятно. Да, DE зависит от API уровня ОС.

Задача или цель в чём?

А sysvinit так не коммерсы делали. Иксы не коммерсы делали. Qt не коммерсы делали.

Вам сколько лет, 16? Вряд ли. Откуда такой.. Максимализм.

Так гном и не нужен. Пусть делают что хотят, пофиг.

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