systemd 249

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

Ну ходи, бей челом к chmod’у…

Ну ходи, бей челом к chmod’у…

Ага. Предпочту это. Потому что он делает свою скромную работу, не претендуя на большее, – а не захватил контроль над системой, чтобы «атоматически» (хомяки ликуют!) решать те проблемы, которые сам же и породил.

Коммент и аватара совпали 1000%

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

А я, как и большинство работодателей, которым не пофиг,

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

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

Кокой ужос! Атрибуты меняют! А может гнать их за то что вообще root доступ получают? Вот же негодяи!

Я думаю логично гнать тех лентяев, которые экономят время для порнухи на чтении конфигов и мануалов, надеясь при этом на черный ящик, непрозрачно и избыточно усложняющий систему, а значит в плинус загоняющей ее надежность. Тем более что этим лентяям таки приходится в итоге учиться в гораздо больших объемах – учиться тому тому, как общаться с этой автоматикой, как уговаривать ее, с должным уважением и убедительностью.. – Хотя они могли бы сами себе делать хорошо, и гораздо проще. Тот случай когда «хочешь сделать хорошо – сделай сам».

И да, в соседнем треде я говорил, повторюсь здесь особо: одна из главных задач systemd это сделать в глазах пользователя Линукс на столько сложным, на сколько это в принципе возможно – чтобы пользователь тем охотнее доверял – все и как можно больше – автоматике, и не пытался понять как что работает. И уже после этого systemd в новых обновлениях делает все, чтобы пользователь действительно ничего не понял, будь он даже академик. Это называется привитие и закрепление психологической импотенции root’a, с перетеканием ее в физическую.

Это увеличивает контроль над системой со стороны RedHat – уже в долгоиграющей перспективе. Ибо уже выросло поколение «Линуксоидов», которые только и умеют что уговаривать systemd, но понятия не имеют как что в нем и в ОС вообще работает. А следующие поколения будут еще более systemd-зависимыми.

Вот где она – главная зависимость в Linux. Собствено это и была изначально цель редхатов. О чем я – и не только – говорил уже давно. Тогда апологеты systemd много смеялись. Теперь смеются меньше, в основном тролят просто от беспомощности и безысходности: им ничего уже не осталось кроме как безропотно накатывать обновления systmd и внутренне смирившись со своей психологической импотенцией просто по случаю рофлить с оппонентов, не вдаваясь в вопрос, кто здесь на самом деле смешен; и не ведая о том, что психологическая импотенция постепенно перетекает в необратимую, физическую. Ибо система реально избыточно усложняется, а не только делает вид, что нереально сложна.

У меня в жизни было два момента когда я почувствовал что меня крупно обманули, поимели: это когда я после виндовса увидел линукс. Особенно когда услышал звук – я чуть не расплакался, честно. Уже потом я вкурил техническую разницу между ALSA и directsound, но качественная меня пробила навылет и сразу.

А второй случай это когда я после systemd/linux увидел gnu/linux. Я ожидал что Slackware будет в разы сложнее всего, с чем я до сих пор имел дело – в Debian и OpenSuse – каково мне сулили стереотипы изложенные в этих ваших интернетах. Но нет. Все оказалось наоборот: практически все нагромождения сложностей в предыдущих «автоматизированных» дистрах были чисто искуственными, и существовали они только чтобы придать вид практической (с точки зрения интересов пользователя) осмысленности существованию systemd. А «ручное» управление (на самом деле в слаквари существует необходимое количество скриптовых костылей для узких тривиальных задач; но они – альтернатива ручному управлению, а не его полная и безальтернативная замена) оказалось гораздо более простым чем «автоматическое». Это не преувеличение: управление одним только systemd со всеми его приблудами вспоминается мне как что-то кошмарное, – в разы более сложнее и запутанное - чем в целом управление свободным от systemd-скверны Slackwar’oм

Говорят что

«кто изучает Debian тот изучает Debian, а кто изучает Slackware, тот изучает Linux».

Я это исправлю, согласно актуальной конъюнктуре. Сегодня ситуация такова, что

кто изучает Debian – а так же ворох прочих зараженных systemd дистрибутивов – изучает systemd

Аминь.

Только теоретически.

И практически тоже

[Unit]
Description=Foo

[Service]
ExecStart=/usr/sbin/foo-daemon

[Install]
WantedBy=multi-user.target
[/code]

А теперь возьми аналог на bash скриптах. Там будет сотня строк нередактируемой лапши, а если какие-нибудь watchdog’и подключаются, то и того больше.

Освятил тред светом истины. Могу спать спокойно.

Ты расписался в собственном невежестве.

Хреновый ты работодатель, если лезешь в работу админов:

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

если ты сам с усами, зачем тебе админы?

Затем, чтобы заняться другими задачами.

приведу пример для runit: http://smarden.org/runit/runscripts.html

#!/bin/sh
exec klogd -n

Ибо уже выросло поколение «Линуксоидов», которые только и умеют что уговаривать systemd, но понятия не имеют как что в нем и в ОС вообще работает. А следующие поколения будут еще более systemd-зависимыми.

Ты очень узко мыслишь. Насрать всем на systemd и систему инициализации. Никто уже лет 10 не настраивает руками ОС, задача админа – описать конфигурацию сервиса в каком-нибудь terraform и раскатать на сотню виртуалок и/или контейнеров.

А watchdog и логирование как настроить ?

Первое - зло, а второе - https://docs.voidlinux.org/config/services/logging.html

Первое - зло

С чего это? Сегфолтнулся сервис в выходные. Кто его будет передпонимать? Очевидно – никто.

а второе

Что за хрень? Сервис пишет что-то в stdout/stderr. Как из этого собрать логи? По ссылке не вижу ответа на вопрос.

Ты очень узко мыслишь.

Да ну?

Насрать всем на systemd и систему инициализации.

Вот это – по твоему значит «широко мыслить»? ?то значит, по твоему, срать на «системный менеджер» который контолирует в ствоем сервере буквально все? Может с такой широтой мышления возвращайся на любимую винду, нэ? Помнится ты здесь много лет вприсядку на нее рукоблудил. Уже бросил или балуешься втихоря? Ты балуйся, но зачем ты аппологируешь в пользу такой же скверны когда она пробралась на линукс?

Никто уже лет 10 не настраивает руками ОС

Почему ты так уверенно говоришь за всех? – Это раз.

Во-вторых,

задача админа – описать конфигурацию сервиса … и раскатать

Я думал эта задача подходит для специально обученнной для этого обезьяны. А админ должен знать что у него где и как работает, максимально полно и глубоко. Это и есть работа админа – знать (а не срать). Ситуация такова, что в системе без systemd «знать все» – задача для админа на порядок более близкая к реальности чем в системе с systemd. Я повторюсь, для аффективно влюбленных в виндоподобные черные ящики: задача systemd это сделать админа таким как ты специалистом по сранью на все, просто из отчаяния разобраться во всем. Он с этой задачей справляется на ура, и уже лет 10 как, – верно?

А watchdog и логирование как настроить ?

ты здесь экзамен решил устраивать? Ты спросил, тебе ответили, и вышло то, что ты продемонстрировал «нередактируемую лапшу» как таз таки в юнитах. Ибо юнит ссылается на другие юниты, – места нахождения которых тебе надо гуглить и текста которых ты не видишь, – а те юниты ссылаются на другие, и те на другие – и тд и тп: и получается в итоге самая «лапша конфигов» как в конфигах, только мелко-мелко порезанная и разбросанная, совершенно не документированная на месте, а потому реально не редактируемая вручную.

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

Никто уже лет 10 не настраивает руками ОС

– При чем здесь ты под «OS» очевидно имел в виду systemd. Зараженные им линуксы - да, никто руками (тоесть мимо systemd) не настраивает. Именно потому что юниты – на практике – не редактируемы руками. Они созданы такими, чтобы система не поддавалась ручному управлению. Сама их организация заточена исключительно на это.

А админ должен знать что у него где и как работает

Он знает, но шаловливыми руками никуда не лезет. Все через terraform и аналоги.

Ситуация такова, что в системе без systemd «знать все»

«Всё» даже Торвальдс не знает, поэтому не надо утрировать.

что ты продемонстрировал «нередактируемую лапшу» как таз таки в юнитах.

Зачем ты врешь? Где я лапшу продемонстрировал? Адепты скриптов пока ничего не продемонстрировали вообще, так как стыдно им.

Именно потому что юниты – на практике – не редактируемы руками.

Можно эту мантру еще 100500 раз повторить для больше убедительности. У фанатиков никаких доказательств кроме повторения бреда over 9000 раз как обычно нет.

По ссылке не вижу ответа на вопрос.

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

Ты вообще не в теме похоже. У меня есть сервис, в котором логирование сделано максимально просто и топорно – вызовом функции printf. Что и где мне надо вкрутить чтобы собрать из этого лог? В нормальных системах инициализации это делается одной строчкой.

Зачем ты врешь? Где я лапшу продемонстрировал?

Для особо одаренных мне может быть некоторые фразы повторять по два-три раза?

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

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

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

ПО ФАКТУ в моем примере лапши нет, что бы не думали упоротые фанатики скриптов.

А ты и читать не умеешь? Ну ок. Убедил. Я всегда против тупости.

Сегфолтнулся сервис в выходные.

Вот и выросло поколение. Ты ещё пропиши в свой любимый unit restart каждые сутки. Охрененная практика, ага.

Охрененная практика, ага.

Я пока не услышал лучшего решения. «Писать без багов» по очевидным причинам решением не является.

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

Ну да не в том суть. А в том, то systemd уже чёрный ящик. И правильно выше пишут, что ты завернул-развернул, и? Это любая обезьяна с сертификатом могёт. А если не получается? Тут у обезьяны что? Разрыв шаблона? Или ждём патча от Шапочки? Ну-ну…

В нормальных системах инициализации

Ты че, серьезно? Ты все еще называешь systemd «системой инициализации»? – Он ведь уже даже официально называется «системным менеджером». Уже не скромничает. Кстати, мне так и не ответили на один вопрос… Я смотрю ты грамотный очень, так что изволь ответить ты.

Как в двух словах называется программа, которая

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

– напоминаю вопрос: к какому типу программ относится такая? Есть еще пара нетипичных свойств у рассматриваемой гипотетической типовой программы

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

А то ты баш наизусть знаешь.

Да ни в жЫсть!

напоминаю вопрос: к какому типу программ относится такая?

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

Предпочитаю сделать один раз и дальше пить свой смузи. Или ещё чем полезным или интересным заниматься.

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

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

Я тебе привёл конкретный пример. А ты лишь трындишь и сути ноль. Конкретные аргументы будут или как ?

К тем, которые неплохо решают очень много МОИХ задач.

Эдвинг? Поттеринг?Чего стесняешься залогиниться. Не боись, здесь на снайпера для тебя скидываться не будут. Модер не благославит.

По делу есть что сказать или как? Ты предлагаешь в каждом сервисе свой вотчдог пилить или как?

Я тебе привёл конкретный пример.

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

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

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

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

По делу есть что сказать или как?

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

Как я и думал. Слив засчитан !

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

Я вот даже не знаю, хочу ли я просить тебя поделиться тем, на на чем сидишь… Боюсь, настолько крепкое я не потяну😞

Мы с этим персонажем спорили много лет назад. Тогда он признавался что сидит на тяжелых веществах и видит чертей. Правда ник был без суффикса 64, но сути это не меняет.

Это завершённый пример.

Это даже не начатый пример, и тот в вакууме. Где должен лежать этот юнит? Какой юнит должен на него ссылаться? Какие юниты должны ссылаться на тот, где все это должно лежать, чтобы все работало как надо?

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

Ну вот посмотри у Slackware например: все файлы пуска всех сервисов лежат в одном директории. Нежданчик, дыа? – никаких перекрестных ссылков в тысячах файлов. Тупо свалено все лежит в одном месте. Если лежит здесь, значит должно запускаться. Если нет атрибута x то не должно.

Вместо кучи всяких «target» и «wantedby» в сотнях файлов есть шесть скриптов с последовательностью запусков для каждого уровня запуска. Что может быть проще, легче в обслуживании и отслеживании? И не надо никаких «автоматизированных» свистелок и палок. Ты пример хотел? Да нету никаких аналогов «настройки сервисов» с уровнем сложности и паофосности подобным systemd. Файловая структура и есть настройка. linux-way помноженный на KISS https://ibb.co/x11rPnn вот и вся настройка запуска демонов. Если что init.d и директории вида rc0.d это для мебели и совместимости с редахтом.

Вот например конфиг запуска сети. Сравни уровень документированности и общей понятности документа со своими «юнитами».

# /etc/rc.d/rc.inet1.conf
#
# This file contains the configuration settings for network interfaces.
# If USE_DHCP[interface] is set to "yes", this overrides any other settings.
# If you don't have an interface, leave the settings null ("").

# You can configure network interfaces other than eth0,eth1... by setting
# IFNAME[interface] to the interface's name. If IFNAME[interface] is unset
# or empty, it is assumed you're configuring eth<interface>.

# Several other parameters are available, the end of this file contains a
# comprehensive set of examples.

# =============================================================================

# Config information for eth0:
IPADDR[0]="192.168.1.3"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""

# Config information for eth2:
IPADDR[2]=""
NETMASK[2]=""
USE_DHCP[2]=""
DHCP_HOSTNAME[2]=""

# Config information for eth3:
IPADDR[3]=""
NETMASK[3]=""
USE_DHCP[3]=""
DHCP_HOSTNAME[3]=""

# Default gateway IP address:
GATEWAY="192.168.1.1"

# Change this to "yes" for debugging output to stdout.  Unfortunately,
# /sbin/hotplug seems to disable stdout so you'll only see debugging output
# when rc.inet1 is called directly.
DEBUG_ETH_UP="no"

# Example of how to configure a bridge:
# Note the added "BRNICS" variable which contains a space-separated list
# of the physical network interfaces you want to add to the bridge.
#IFNAME[0]="br0"
#BRNICS[0]="eth0"
#IPADDR[0]="192.168.0.1"
#NETMASK[0]="255.255.255.0"
#USE_DHCP[0]=""
#DHCP_HOSTNAME[0]=""

## Example config information for wlan0.  Uncomment the lines you need and fill
## in your info.  (You may not need all of these for your wireless network)
#IFNAME[4]="wlan0"
#IPADDR[4]=""
#NETMASK[4]=""
#USE_DHCP[4]="yes"
#DHCP_HOSTNAME[4]="icculus-wireless"
#DHCP_KEEPRESOLV[4]="yes"
#DHCP_KEEPNTP[4]="yes"
#DHCP_KEEPGW[4]="yes"
#DHCP_IPADDR[4]=""
#WLAN_ESSID[4]=BARRIER05
#WLAN_MODE[4]=Managed
##WLAN_RATE[4]="54M auto"
##WLAN_CHANNEL[4]="auto"
##WLAN_KEY[4]="D5AD1F04ACF048EC2D0B1C80C7"
##WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=96389dc66eaf7e6efd5b5523ae43c7925ff4df2f8b7099495192d44a774fda16"
#WLAN_WPA[4]="wpa_supplicant"
#WLAN_WPADRIVER[4]="ndiswrapper"

## Some examples of additional network parameters that you can use.
## Config information for wlan0:
#IFNAME[4]="wlan0"              # Use a different interface name instead of
                                # the default 'eth4'
#HWADDR[4]="00:01:23:45:67:89"  # Overrule the card's hardware MAC address
#MTU[4]=""                      # The default MTU is 1500, but you might need
                                # 1360 when you use NAT'ed IPSec traffic.
#DHCP_KEEPRESOLV[4]="yes"       # If you don't want /etc/resolv.conf overwritten
#DHCP_KEEPNTP[4]="yes"          # If you don't want ntp.conf overwritten
#DHCP_KEEPGW[4]="yes"           # If you don't want the DHCP server to change
                                # your default gateway
#DHCP_IPADDR[4]=""              # Request a specific IP address from the DHCP
                                # server
#WLAN_ESSID[4]=DARKSTAR         # Here, you can override _any_ parameter
                                # defined in rc.wireless.conf, by prepending
                                # 'WLAN_' to the parameter's name. Useful for
                                # those with multiple wireless interfaces.
#WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=thekey"
                                # Some drivers require a private ioctl to be
                                # set through the iwpriv command. If more than
                                # one is required, you can place them in the
                                # IWPRIV parameter (separated with the pipe (|)
                                # character, see the example).

Зачем было все эти «юниты» и «таргеты» городить, если без них все проще и понятней, и в одном месте собрано? Я слыхал, systemd обещал следить за «очередностю запусков»? Дык ведь гораздо проще и логичнее когда очередность запусков скриптов контролируется тупо материнским процессом.

Вот например скрипт определенного ранлевела. Заметь, вся архисложная система запуска умещается в одном файле, контролируется полностью до деталей не одходя от кассы – и не надо гор «юнитов», и не надо километров текста с запросами к systemd чтобы сформулировать чего ты хочешь запускать и как. И уж тем более проще чем вручную ковыряться в десятках «юнитов», по которым рассыпана каждая в целом несложная инструкция запуска.

#!/bin/sh
#
# rc.M		This file is executed by init(8) when the system is being
#		initialized for one of the "multi user" run levels (i.e.
#		levels 1 through 6).  It usually does mounting of file
#		systems et al.
#
# Version:	@(#)/etc/rc.d/rc.M	2.23	Wed Feb 26 19:20:58 PST 2003
#
# Author:	Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
#		Heavily modified by Patrick Volkerding <volkerdi@slackware.com>
#

# Tell the viewers what's going to happen.
echo "Going multiuser..."

# Update all the shared library links:
if [ -x /sbin/ldconfig ]; then
  echo "Updating shared library links:  /sbin/ldconfig &"
  /sbin/ldconfig &
fi

# Screen blanks after 15 minutes idle time, and powers down in one hour
# if the kernel supports APM or ACPI power management:
/bin/setterm -blank 15 -powersave powerdown -powerdown 60

# Set the hostname.
if [ -r /etc/HOSTNAME ]; then
  /bin/hostname $(cat /etc/HOSTNAME | cut -f1 -d .)
else
  # fall back on this old default:
  echo "darkstar.example.net" > /etc/HOSTNAME
  /bin/hostname darkstar
fi

# Set the permissions on /var/log/dmesg according to whether the kernel
# permits non-root users to access kernel dmesg information:
if [ -r /proc/sys/kernel/dmesg_restrict ]; then
  if [ $(cat /proc/sys/kernel/dmesg_restrict) = 1 ]; then
    touch /var/log/dmesg
    chmod 640 /var/log/dmesg
  fi
else
  touch /var/log/dmesg
  chmod 644 /var/log/dmesg
fi
# Save the contents of 'dmesg':
/bin/dmesg -s 65536 > /var/log/dmesg

# Initialize PCMCIA devices:
#
# NOTE: This used to be started near the top of rc.S so that PCMCIA devices
# could be fsck'ed along with the other drives.  This had some unfortunate
# side effects, however, since root isn't yet read-write, and /var might not
# even be mounted the .pid files can't be correctly written in /var/run and
# the pcmcia system can't be correctly shut down.  If you want some PCMCIA
# partition to be mounted at boot (or when the card is inserted) then add
# the appropriate lines to /etc/pcmcia/scsi.opts.
#
# Note that the stuff in /etc/pcmcia/ is only for 2.4.x kernels using
# 16-bit PCMCIA cards (not 32-bit Cardbus cards!).  For example, with a
# wireless card you might need to set options in /etc/pcmcia OR in
# /etc/rc.d/rc.wireless.conf, or even in /etc/rc.d/rc.inet1.conf (with
# extra options if needed for the encryption key, ESSID, etc.)
#
# Hopefully this situation will be unified in the future, but for now
# that's how it is...
#
if [ -x /etc/rc.d/rc.pcmcia ]; then
  . /etc/rc.d/rc.pcmcia start
  # The cards might need a little extra time here to initialize.
  sleep 5
fi

# Start the system logger.
if [ -x /etc/rc.d/rc.syslog -a -x /usr/sbin/syslogd -a -d /var/log ]; then
  . /etc/rc.d/rc.syslog start
fi

# Update the X font indexes:
if [ -x /usr/bin/fc-cache ]; then
  echo "Updating X font indexes:  /usr/bin/fc-cache -f &"
  /usr/bin/fc-cache -f &
fi

# Run rc.udev again.  This will start udev if it is not already running
# (for example, upon return from runlevel 1), otherwise it will trigger it
# to look for device changes and to generate persistent rules if needed.
if grep -wq sysfs /proc/mounts && grep -q devtmpfs /proc/filesystems ; then
  if ! grep -wq nohotplug /proc/cmdline ; then
    if [ -x /etc/rc.d/rc.udev ]; then
      /bin/sh /etc/rc.d/rc.udev start
    fi
  fi
fi

# Initialize the networking hardware.
if [ -x /etc/rc.d/rc.inet1 ]; then
  . /etc/rc.d/rc.inet1
fi

# Start D-Bus:
if [ -x /etc/rc.d/rc.messagebus ]; then
  sh /etc/rc.d/rc.messagebus start
fi

# Start Bluetooth:
if [ -x /etc/rc.d/rc.bluetooth ]; then
  sh /etc/rc.d/rc.bluetooth start
fi

# Start wicd or networkmanager:
if [ -x /etc/rc.d/rc.wicd -a -x /usr/sbin/wicd ]; then
  sh /etc/rc.d/rc.wicd start
elif [ -x /etc/rc.d/rc.networkmanager ]; then
  sh /etc/rc.d/rc.networkmanager start
fi

# Start networking daemons:
if [ -x /etc/rc.d/rc.inet2 ]; then
  . /etc/rc.d/rc.inet2
fi

# Look for additional USB/SCSI/IEEE1394/etc devices on multiple LUNs:
if [ -x /etc/rc.d/rc.scanluns ]; then
  . /etc/rc.d/rc.scanluns
fi

# Mount any additional filesystem types that haven't already been mounted:
mount -a -v 2> /dev/null | grep -v -e "already mounted" -e "ignored" | cut -f 1 -d : | tr -d ' ' | while read dev ; do mount | grep "${dev} " ; done

# Start the Control Script for automounter:
if [ -x /etc/rc.d/rc.autofs ]; then
  sh /etc/rc.d/rc.autofs start
fi

# Start the Network Time Protocol daemon:
if [ -x /etc/rc.d/rc.ntpd ]; then
  sh /etc/rc.d/rc.ntpd start
fi

# Remove stale locks and junk files (must be done after mount -a!)
/bin/rm -f /var/lock/* /var/spool/uucp/LCK..* /tmp/.X*lock /tmp/core /core 2> /dev/null
/bin/rm -rf /var/spool/cron/cron.?????? 2> /dev/null

# Remove stale hunt sockets so the game can start.
if [ -r /tmp/hunt -o -r /tmp/hunt.stats ]; then
  echo "Removing your stale hunt sockets from /tmp."
  /bin/rm -f /tmp/hunt*
fi

# Ensure basic filesystem permissions sanity.
chmod 755 / 2> /dev/null
chmod 1777 /tmp /var/tmp

# Start ACPI daemon.
if [ -x /etc/rc.d/rc.acpid ]; then
  . /etc/rc.d/rc.acpid start
fi

# Enable CPU frequency scaling:
if [ -x /etc/rc.d/rc.cpufreq ]; then
  . /etc/rc.d/rc.cpufreq start
fi

# Update any existing icon cache files:
if find /usr/share/icons -maxdepth 2 2> /dev/null | grep -q icon-theme.cache ; then
  for theme_dir in /usr/share/icons/* ; do
    if [ -r ${theme_dir}/icon-theme.cache ]; then
      echo "Updating icon-theme.cache in ${theme_dir}..."
      /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null &
    fi
  done
  # This would be a large file and probably shouldn't be there.
  if [ -r /usr/share/icons/icon-theme.cache ]; then
    echo "Deleting icon-theme.cache in /usr/share/icons..."
    #/usr/bin/gtk-update-icon-cache -t -f /usr/share/icons 1> /dev/null 2> /dev/null &
    rm -f /usr/share/icons/icon-theme.cache
  fi
fi

# Update mime database:
if [ -x /usr/bin/update-mime-database -a -d /usr/share/mime ]; then
  echo "Updating MIME database:  /usr/bin/update-mime-database /usr/share/mime &"
  /usr/bin/update-mime-database /usr/share/mime 1> /dev/null 2> /dev/null &
fi

# Start console-kit-daemon:
if [ -x /etc/rc.d/rc.consolekit ]; then
  sh /etc/rc.d/rc.consolekit start
fi

# Все не влезло но для примера хватит

Зачем мне эта лапша? Юнит кладётся в директорию указанную в документации потом systemctl enable, systemctl start. Юнит из моего примера законченный.

Тогда он признавался что сидит на тяжелых веществах

Ну ты же клевещешь

и видит чертей.

С другой стороны, если бы не клевета и лживость, явное видение давалось бы мне хуже.

Ты уже забыл, ну ок, может вылечили тебя.

Зачем мне эта лапша?

– Тебе эта «лапша» не надо, тебе же срать на все, ты же широко мыслишь, не так ли. А серьезным сознательным админам надо – чтобы полностью контролировать происходящее в системе, тем более без «помощи» непрозрачного сколоченного гвоздями черного ящика, который с каждым годом все более "благожелателен" и «альтруистичен». Пассионарность уже этой приблуды уже покойную мать Терезу в гробу шевелит.

Юнит кладётся в директорию указанную в документации

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

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

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

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

Этот твой «контроль» не более чем гипертрофированное ЧСВ. По факту ты все равно ничего не контролируешь, а для запуска реальных сервисов в реальном продакшене на таких убогих «системах инициализации» надо писать тонны boilerplate кода. Но диванным админам, якобы контролирующим все, это не понять .

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

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

Дык ведь гораздо проще и логичнее когда очередность запусков скриптов контролируется тупо материнским процессом.

Проще? Может быть. Только никто не обещал, что система инициализации должна быть простой.

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

Дык ведь гораздо проще и логичнее когда очередность запусков скриптов контролируется тупо материнским процессом.

Товарищ настолько загнался, что сам того не ведая придумал systemd 🤭

Что, если

Что, если

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

Простая и надежная как лом система запуска, которая возможно подребует допила если что-то там пойдет не так – таких вопросов оставляет очень ораниченное количество, и они очевидны, если что – что ты сам и продемонстрировал, сразу заметив потенциальную проблему, а это значит что она считай решена, буде она иметь место. Что важно: в BSD-подобной системе slackware есть простой ответ на любое «если что» и таки ты прав: даже юзер в состоянии допилить все что ему нужно. И перепилить, – как угодно вообще – если необходимо. Ибо это «портянка», – как ты выразился – понятная любому юзеру и редактируемая даже без chroot.

А в systemd есть вообще хоть какие-то простые ответы? Если systemd уронится в мертвую петлю, не давая системе запуститься, по кругу гоняя механизм загрузки (риалстори), то ЧЕМ и КАК и ЧТО ты будешь исправлять? – Ведь без systemd ты уже как без рук. Его не настроить пока система не стартанет. А она не стартанет потому что он фейлит. Что дальше? – Переустановка? Здравствуй винда на линукс-ядре?

– А ты ведь даже не сможешь узнать в чем дело и что нетак: журнал не посмотреть, без отчаянных плясок с бубном, chroot и теми вот матерями, ибо journald тоже не работает на неработающей системе, а лог-файл давно не текстовый. Он двоичный. Зато #censured c подсветской синтаксиса – но правда читается в принципе только когда система работает и он обычно не нужон.

В моем случае, о котором я упомянул (встречался в сюзе), понадобилось просто исправить fstab – это от одной ошибки в нем система стала небутабельной – и это без каких-либо объяснений, и без возможности диагностики, ибо journald и вызывал цикличный перезапуск. Но ведь не это важно. Важно то, что этот гребаный черный ящик сходит с ума и роняет систему наглухо от очень простых вещей.

Чего держать systemd? Чтобы он решал «проблемы», которые можешь решить и ты, но при этом порождал такие проблемы, которые не может решить ни он ни ты?

Видишь – ты просто посмотрел в скрипт и уже видишь даже потенциальную проблему. Значит считай она решена, буде она иметь место. А что с systemd? А ЧТО ЕСЛИ...

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

А читающему значит не дано понимать зависимости? Я считаю что тот кто не знает о них ничего – туда и лезть не станет. А кто туда в лезет – не обломается поинтересоваться темой. Это раз. Во-вторых запускаемы дочерние скрипты вполне в состоянии сами проверять существование необходимых кондиций и возвращать в материнский процесс результат проверки. Или в ваших благодродных компилируемых языках еще не завезли такое, и вы не в курсе?

Так это мои файлы, а не системные. Оформляешь в пакет, ставишь пакет.

Даже круче: systemctl status показывает, какие оверрайды и откуда он загрузил. Офигенно удобно, когда надо вспомнить, чего и где я подковыривал.

Пакет особо не нужен. Вообще сейчас же уходят от правки файлов в пользу дропов в каталог.

Только никто не обещал, что система инициализации должна быть простой.

Оккам говорил, что самое простое решение всегда самое верное. Ибо простота равна надежности, при всех прочих равных. Так что любая программа таки ДОЛЖНА быть предельно простой. Если только ты не Поттеринг, которому поставлена задача создать троян тысячелетия и привить «админам» линукса выученную беспомощность, чтобы они полностью полагались на твоего трояна.

Эти зависимости знает сам сервис,

А значит «тупому админу» не дано знать зависимости сервиса, если уж он берется писать скрипт его запуска? Ты че, серьезно? Ты хочешь огородить стартовую систему BSD от вмешательства бабушек и дедушек с лавки у подъезда? Я тоже «за», но разве для этого нужно нагружать систему трояном? По моему достаточно не давать бабушкам рута.

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

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

А значит «тупому админу» не дано знать зависимости сервиса, если уж он берется писать скрипт его запуска?

Как раз наоборот: systemd очень хорошо может нарисовать зависимости между сервисами в красивую картинку с графом. Может в виде гант диаграммы выдать как сервисы стартовали и кто сколько кого ждал, чтобы оптимизировать процесс загрузки (если кому это важно).

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

Видишь – ты просто посмотрел в скрипт и уже видишь даже потенциальную проблему.

Ага, само наличие скрипта - это уже даже не потенциальная проблема. 😭

Значит считай она решена,

Нормальной системой инициализации 😂