Devuan Excalibur 6

Читай стандарт, там «architecture-dependent data». В каком месте 90+% юнитов архитектурно-зависимые?

Сам читай. Я тебя буквально в него носом тыкаю, но ты не отдупляешь. Юниты по своей природе могут быть архитектурно-зависимыми. Из-за этого факта их положили в /usr/lib, чтобы не создавать пересортицу. Ровно по этой же причине в /usr/lib лежат библиотеки для perl, являющиеся текстовыми файлами.

Видимо файлики попадают туда из астрала каким то вуду.

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

Патчами на код? Опциями компиляции, конечно. Правда, всё еще остается вопрос, зачем это может понадобится. Systemd стандартизирует размещение определенных файлов по определенным местам именно для унификации.

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

Что ты несешь, болезный? Разработчик пакета под конкретную систему не знает, где в этой системе что лежит? Нет, если этот «разработчик» - ты, тогда всё понятно. Но в мире грамотных и адекватных людей, ты сначала должен посмотреть, что и подо что ты собираешь, прежде чем рваться в бой.

И это не говоря уже о простом факте, что поскольку разработчики systemd требуют и документируют нахождение путей в определенных местах (и снежинки из твоего дистра не наконфигурили/напатчили какую-нибудь хрень) - то все линуксы будут иметь одинаковые пути юнитов. Это и есть унификация, ради которой всё затевалось.

энтерпрайз на ro-образах

Дружище, вот я именно что поддерживаю свою энтерпрайзную ro-ось для своих железок, сделанную из арча с systemd. Ирония в том, что именно из systemd это оказалось слепить проще всего, потому что костыли из debian времен sysv, до сих-пор зачем-то поддерживающиеся и замещающиеи стандартные компоненты systemd (подозреваю, что для альтернативных инитов), с ридонли работают кривио.

А работа в префиксах? А портабельный софт?

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

Ты так и не сказал а)с какого Х все юниты причислены к архитектурно-зависимым данным,

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

Я эту разницу уже тебе сам объяснил раньше

Ты определись, «нет разницы» или «сам её объяснил».

Здравый смысл.

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

Юниты по своей природе могут быть архитектурно-зависимыми

А могут не быть. 90-99% - нет. Вот давай про них, какого Х они там делают?

Все прочие рассуждения с захардкоживанием путей у тебя в итоге сводятся «мне не нужно значит никому не нужно». Просто факт - среди адекватных разработчиков такие вещи всегда делаются считываемой переменной даже если оно 100 лет нужно не было.

С того, что архитектурно-зависимые данные - это широкий термин, как про слово «данные», так и про слово «архитектура».

Тогда я не знаю, давай в широком смысле поместим fstab в /usr/lib... Достаточно широко?

Как давно классические иниты типа sysv стали иметь какие-то вариабельные пути для размещения rc-скриптов?

Они имели всего 1 путь. Не сложную систему взаимного замещения из 15-20 путей, а только 1. Причём совершенно не важно где скрипт лежал физически, главное чтобы симлинк ссылался на него из правильного места. Интересно (хотя на самом деле нет), глюканёт ли системд если вместо юнита подсунуть ему симлинк на него?

Ты определись, «нет разницы» или «сам её объяснил».

Ты больше одного факта в голове держать совсем не способен? Разница между /usr/local и /usr - что /usr/local не ставится из пакетов. При этом разницы в назначении внутри подкаталогов /usr/local и /usr (lib, всякое) для размещения - нет.

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

Ответ неверный. Стандарт говорит, что всё в порядке. Опенсорсные проекты говорят, что всё в порядке. Примеры вроде авторитетных проектов вида перла говорят, что всё в порядке. Одному клоуну с лора только не нравится.

А могут не быть. 90-99% - нет. Вот давай про них, какого Х они там делают?

Модули для перла могут быть архитектурно-независимыми и написанными на самом перле. Почему они в /usr/share не лежат, по твоей же логике?

Все прочие рассуждения с захардкоживанием путей у тебя в итоге сводятся «мне не нужно значит никому не нужно».

Нет, клоун. Мои рассуждения сводятся к тому, что это объективно не нужно, потому что это базовый системный компонент, на который опираются все остальные. Его пути стандартизированы. Еще раз: СТАНДАРТИЗИРОВАНЫ. Стандартизированные пути не должны меняться.

Тогда я не знаю, давай в широком смысле поместим fstab в /usr/lib… Достаточно широко?

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

Они имели всего 1 путь. Не сложную систему взаимного замещения из 15-20 путей, а только 1.

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

У тебя абсолютная каша в голове.

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

Каша как раз в таких «настраиваемых» путях. 1 путь – все знают, куда лОжить и где смотреть. В твоей любимой систем-дэ как узнать, где лежат те юниты, что реально запускаются на конкретном компе?

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

При этом задача читать и понимать шелл-портянки, баш-портянки, питон-портянки, sed/awk-портянки, а то и perl-портянки никуда не делась.

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

Странный вопрос, никогда не поверю, что ты ни разу не запускал systemctl status unit.service

Каша как раз в таких «настраиваемых» путях.

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

1 путь – все знают, куда лОжить и где смотреть.

А что, остальные пути сложно найти? У кабинетных теоретиков проблемы с обучаемостью?

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

Очень легко. systemd-analyze и systemctl status. Документацию я тебе уже скидывал.

Претензии вида «нужно читать шелл-портянки, чтобы понять, что как запускается» ничтожны

Нет.

необходимости читать много-много мануалов по систем-дэ требуемой версии

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

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

И опять враньё. На архитектурном уровне всё работает очень просто. Необходимость читать исходники у админа не возникает. Как часто ты осмысляешь схему работы ядра?

Он ничего и никогда не запускал. Он просто сидит и теоретизирует, как и остальные хейтеры в этом треде. Раз за разом задаются вопросы «а как в systemd сделать X», на них даются ответы из первой строчки в гугле или документации, а потом придумываются всё новые и новые вопросы от других мамкиных админов локалхоста

Эти люди не только с systemd не работали, они вообще никогда с системой ниже DE не сталкивались. Но мнение имеют, да.

Я случайно узнал второй, более короткий вариант systemctl show -p FragmentPath unit.service

Каша как раз в таких «настраиваемых» путях.

Каши нет. Ты же не называешь (надеюсь) кашей бинари в /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin и /opt? Вот и тут та же картина.

Я, например, системные юниты в /lib/systemd/system/ не трогаю, а свои в пакетах кладу в /etc/systemd/system/.

Делаю кое-где также (в команде, естественно) системы, которые деплоятся заказчикам (в т.ч. в закрытые контуры, куда у нас доступа может и не быть), там разливаются кроме софта ещё несколько-строчные конфиги в UNIT.conf.d и UNIT.service.d, которые оверрайдят системные (например, для систем на ro корне, надо для отказоустойчивых по питанию вещей кое-где), поддерживается зоопарк дистрибутивов (deb/rpm/arch). Это просто чудо как хорошо, унифицированно и снимает ну просто невероятную кучу гемора с if/else в деплоилке.

Нет, я согласен, всегда можно взять и работать неделями от забора до обеда, написать 100500 bash-скриптов для всего вот этого (что и было в начале-середине 2000х, можно взять и посмотреть в ту же IBM Tivoli, например) Но я сначала предпочитаю хорошо подумать (даже может быть несколько дней), чтобы потом хорошо сделать.

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

systemctl status unit.service

ВСЕ юниты, не каждый вписывать.

Нууу туда еще надо -p DropInPaths или как там его, иначе нещитово, и в совокупности заклинание получится прям длинное. Проще всего, имхо systemctl cat глазами отгрепать.

ВСЕ юниты

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

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

Тут ситуация такая: ты щас можешь сказать, например, «затем, что я хочу видеть, какие юниты валяются в /etc», на что я меланхолично посоветую тебе пойти прям в /etc/systemd и увидеть, как вот они лежат.

А еще зачем?

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

И покласть их в подкаталоги одного каталога не судьба?

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

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

а пару страниц документации прочитать - табу?

Мне не платят за такое чтение. Паскаль, шеллы, sed/awk, Питон имеют много более широкое применение, нежели знания систем-дэ.

systemctl status

Это выдаёт ВСЕ запущенные процессы, что на работающей системе та ещё портянка. Выдаёт пути к исполняемым файлам, запускаемым юнитами, а где пути К ЮНИТАМ?

systemd-analyze

С какими ключами?

Необходимость читать исходники у админа не возникает.

Когда документация исчерпывающая. С примерами, разбором неочевидных коллизий и пр.

Ты же не называешь (надеюсь) кашей бинари в /usr/bin

Не, там просто свалка. Понятно, что иначе никак, но всё равно свалка.

можно положить хитрый файл в /run/systemd и сервер перестанет реагировать на команду reboot, в рантайме причём.

Имея права, можно переименовать reboot.

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

Чтобы, мля, посмотреть, что в них написано, в тех юнитах, что запускаются!

боженька дал нам ls и find,

Угу, т.е. систем-дэ не даёт нам удобный и универсальные механизмы управления самим собой. Знания баша и команд остаётся обязательным. Но ещё надо потратиться на овладение систем-дэ.

Чтобы, мля, посмотреть, что в них написано, в тех юнитах, что запускаются!

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

систем-дэ не даёт нам удобный и универсальные механизмы управления самим собой

УПРАВЛЕНИЯ, о боже мой.

хочешь вывод всего содержимого всех юнитов на экран разом

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

Дерево загрузки с инфой, какой юнит какой вызывает, какой после какого загружается ЛОГИЧЕСКИ, а не по времени.

УПРАВЛЕНИЯ, о боже мой.

Естественно, иначе нахрена нам этот монстр?! Чем он лучше стандартных команд типа ps, top, cat, less, tee, упомянутые ls, find, остальных coreutils, та хоть пресловутого mc?!

Я хочу прочесть лишь те юниты, что реально работают в моём компе.

Не скажу за пацанов, но лично я не против.

Т.е. получить список файлов юнитов с путями к ним

Зачем. Тебе. Пути. В. Списке. Юнитов?

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

И покласть их в подкаталоги одного каталога не судьба?

Нет, потому что это не соответствует FHS. По FHS это должно быть расположенно именно так, как сделано сейчас.

Паскаль для начального ознакомления с программированием прост и прозрачен.

Нет.

Мне не платят за такое чтение.

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

С какими ключами?

Я давал тебе документацию и отвечал на все твои вопросы. Ты даже не удосужился открыть эти ссылки. Теперь всё, надо - открывай мануалы и ищи.

Имея права, можно переименовать reboot.

Костыли-костылища, м-м-м! И shutdown не забудь тоже переименовать, ага.

Имея права, можно переименовать reboot.

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

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

Мне нужно ЛОГИЧЕСКОЕ дерево «запуска юнитов», а путь к ним, чтобы я не тратил время на поиск файла этого юнита, да и не нарвался на одноимённый, но по другому пути.

Как по мне, именно откуда и в какой последовательности запускается – это первое, что должен знать и понимать «владелец компа», решивший порыться в системе. Почему уже которую страницу защитники систем-дэ скрывают это сакральное знание, ведь в момент загрузки систем-дэ таки строит такое дерево?

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

Нет, потому что это не соответствует FHS. По FHS это должно быть расположенно именно так, как сделано сейчас.

Тогда целый /etc нам зачем?

Нет.

Да, поскольку доступен даже для филологинь.

Тогда какого рожна ты лезешь туда, где ни бельмеса не смыслишь?

Вот и я спрашиваю, зачем этот неудаляемый монстр на моём компе?! Вопрос ведь не в том, нужен или нет систем-дэ как ПРОФЕССИОНАЛЬНЫЙ инструмент для ПРОФЕССИОНАЛОВ… в некоторых ситуациях. Вопрос в том, пошто его засовывают столь беспардонно туда, где ему совсем не место?

Я давал тебе документацию и отвечал на все твои вопросы.

Первое – да, втрое – нет. Простой вопрос не получил ответа уже много страниц. Так кто должен читать документацию?

Ты даже не удосужился открыть эти ссылки.

Открывал. Одну, вторую надо было vpn включать, мне было лень. Вывод тот же, что и был, завместо чтения портянок на шелл для систем-дэ надо читать портянки разрозненных описаний, а по ним составлять структурированное руководство.

Преимуществ systemctl status перед ps -eLf, ps -efH или ps -ejH я не увидел, причём ключи ps выдаёт man, никакие ссылки искать не надо.

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

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

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

Мне нужно ЛОГИЧЕСКОЕ дерево «запуска юнитов»

Так вот, путь к файлу конфига не является частью ЛОГИЧЕСКОГО дерева юнитов. Потому что путь к файлу - это часть дерева файловой системы, хоба!

Как по мне, именно откуда и в какой последовательности запускается – это первое

Теперь СКАЖИ УЖЕ НАКОНЕЦ, нахера тебе видеть путь к конфигу юнита в выхлопе, например systemctl list-dependencies или systemctl status. В том самом логическом дереве, ага.

Тогда целый /etc нам зачем?

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

Да, поскольку доступен даже для филологинь.

Всё ещё нет.

Вот и я спрашиваю, зачем этот неудаляемый монстр на моём компе?!

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

Вывод тот же

Вывод неверный.

Преимуществ systemctl status перед ps -eLf, ps -efH или ps -ejH я не увидел

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

При этом разницы в назначении внутри подкаталогов /usr/local и /usr (lib, всякое) для размещения - нет.

Если бы разницы не было - это был бы один каталог.

Его пути стандартизированы. Еще раз: СТАНДАРТИЗИРОВАНЫ

Где?! Ты мне показал официальную пародию на документацию, вся суть которой сводится к многозначительному "...". Т.е. буквально, «Хз, мы не знаем, может быть ещё где нибудь». Это нельзя понять как либо иначе и не требует перевода.

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

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

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

           │   │ ├─app.slice 
           │   │ │ ├─gvfs-daemon.service

...

rrr@raspberrypi:/tmp $ systemctl status gvfs-daemon.service
Unit gvfs-daemon.service could not be found.

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

Бывает как то так… юнит есть, но его нет. Напрягает уже сама возможность такой ситуации

Почему сейчас то напрягает, непонятно? Это могло напрягать лет 5-7 назад, сейчас уже всем понятно, что после изменения юнит-файла надо daemon-reload делать?

А никто ничего не изменял. Он вообще может быть динамически создаваемым или спрятанным в недокументированные пути. Собственно за запуск gvfs вообще не должен отвечать системд.

Каши нет. Ты же не называешь (надеюсь) кашей бинари в /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin и /opt? Вот и тут та же картина.

Нет никаких «/usr/sbin, /usr/local/bin, /usr/local/sbin», есть переменная $PATH и туда при определённых условиях может вообще не входить /usr/bin.

Нет никаких «/usr/sbin, /usr/local/bin, /usr/local/sbin»

Да ладно! :))

или спрятанным в недокументированные пути.

Извини, это вообще бурда написана. Нет никаких недокументированных путей. Devuan Excalibur 6 (комментарий)

Собственно за запуск gvfs вообще не должен отвечать системд.

А кто должен отвечать за запуск сервиса вместо него, Пушкин А.С.?

Подожди, так надо что то с чем то смешивать

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

Это должно быть делом 15 секунд и 1 запроса в гугл

Для быстрого поиска это так и есть. Проблема в том, что если ты не понимаешь, чем ты управляешь - тебе никакой гугл не поможет. То же самое справедливо для SysV. Например, я даю тебе FHS и буквально разжевываю его смысл, но ты, из-за своей тупости, упираешься рогом.

Не, это мы с тобой выяснили

Это тебе так кажется.

отстаёт от актуальной версии

Любой продукт содержит баги.

У них только 1 мануал.

Ложь. Подними глаза в правый верхний угол страницы: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

Ложь.

Ложь. Ты просто не обладаешь нужными компетенциями.

Нет никаких «/usr/sbin, /usr/local/bin, /usr/local/sbin»

И снова очередной безграмотный бред.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html

кроме того что действительно нужно

Денег, удачи и здоровья, ага.

Обнули переменную и удивись что будет! Причём есть возможность реально встретиться с этой ситуацией при использовании новых версий su.

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

Нет никаких недокументированных путей.

А давай просто посмотрим что там по факту! Открываю документаци. делаю find по всем документированным путям (оказывается что в моём дистрибутиве 6/12 отсутствуют, но это мелочи...), смотрю на список юнитов в systemctl status (там как известно не все юниты, как минимум замаскированных нет, возможно ещё каких то)(Кстати, а где список замаскированных юнитов?) и со второй строчки вижу, что .device-юниты не находятся в документированных путях!

Читаю документацию... На странице https://www.freedesktop.org/software/systemd/man/latest/systemd.device.html где должно быть всё про device.device нет ничего про то где их искать. Но зато сказано что у юнитов есть такие же зависимости и некоторые опции, как и у других юнитов. А значит они где то должны лежать!

Ладно, документация как всегда бесполезна. Ищем методом тыка. Например юнит sys-devices-platform-emmc2bus-fe340000.mmc-mmc_host-mmc0-mmc0:5048-block-mmcblk0-mmcblk0p1.device. status говорит что по адресу /sys/devices/platform/emmc2bus/fe340000.mmc/mmc_host/mmc0/mmc0:5048/block/mmcblk0/mmcblk0p1 но разумеется никакого юнита там нету. А где?

Или .mount-юниты. Аналогично, они существуют, но куда то спрятаны! А ведь их править надо...

Для юнитов .scope в документации по крайней мере соизволили указать что они не имеют файлов. Так что нет смысла разбираться зачем эта хрень нужна - она очевидно не нужна раз её нельзя конфигурировать.

Чешу юниты дальше. Вот например raspi-config.service, стрнная штука с путём /etc/init.d/raspi-config и по сути не являющаяся юнитом. И всё бы ничего, но инит-скрипты не импортируются автоматически в виде виртуальных юнитов. Где то есть конфиг... Ладно, хрен с ними, кажется на эту тему где то что то было написано.

dev-disk-by\x2did-usb\x2dSATA_SSD_Best_USB_Device_235678C218CA\x2d0:0\x2dpart1.swap вообще could not be found. Своп есть. Юнит есть. Отмонитровать надо. Но его нету.

Так, давай к сути: объясни мне в каком месте $PATH является захардкоженной детерминированной константой, обязательно содержащей в себе /usr/bin и обязательно не содержащей /home/rrr/.skript? Или ты вообще не видишь разницу между путями юнитов в системд и путями для поиска исполняемых файлов в юникс? Вот прям одна и та же логика, одни и те же методы?

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

У тебя для этого есть пакетный менеджер если что. Функция «не смешивать» осталась в 80-х, когда программы собирались из сорцев и вручную копировались куда то там, куда прав копировать дали. Особенно странно слышать это от арчевода, который тянет в свой дистр каждую какшку от каждого проекта при каждом обновлении.

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

Твои заявления противоречат тому, что там буквально чёрным по белому написано.

Это тебе так кажется.

Ты в итоге сам признал что косяки там есть.

Любой продукт содержит баги.

В «любом проекте» наткнуться на баг несколько сложнее чем попасть с 3 метров из дробовика в стену. Или ты думаешь я гениальный аналитик, приложивший для этого значительные усилия и больше 15 минут?

Покажи мне где /usr/bin захардкожен в $PATH и является константой?

Так, давай к сути: объясни мне в каком месте $PATH является захардкоженной детерминированной константой, обязательно содержащей в себе /usr/bin и обязательно не содержащей /home/rrr/.skript?

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

Ну-ка объясни мне, почему PATH в Solaris 2.4 не содержит в себе /u01/app/oracle/bin?

Кстати, а где список замаскированных юнитов?

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