Я только что переключился на Debian Jessie, и большинство вещей работает нормально, включая мой менеджер графического отображения wdm.

Дело в том, что я просто не понимаю, как это работает. Очевидно, что мой /etc/init.d/wdmсценарий называется, потому что, когда я вставил туда раннее exit, wdm не запускается. Но когда я альтернативно переименую каталог /etc/rc3.d (мой уровень запуска по умолчанию был 3), тогда wdm все еще запускается.

Я не мог выяснить, как systemd находит этот скрипт, и я не понимаю, что он делает со всеми другими скриптами init.d.

• Когда и как systemd запускает init.d scrips?
• В конечном счете, я должен избавиться от всех сценариев init.d?

Ответ хаоса - это то, что говорится в какой-то документации. Но это не то, что на самом деле делает systemd. (Это не то, что rcсделал ван Смуренбург , так же. Ван Смуренбургrc определенно не игнорировал заголовки LSB, которые insservиспользовались для вычисления статических порядков, для начинающих.) Документация Freedesktop, такая как страница "Несовместимость", на самом деле неверна, на эти и другие моменты. (The HOMEпеременная окружения на самом деле это часто устанавливается, например. Это продолжалось полностью документированы в любом месте в течение длительного времени. Это сейчас описано в руководстве, по крайней мере, но Freedesktop WWW страницы до сих пор не исправлена.)

Нативный формат службы для systemd - это единица службы . Правильное управление службами systemd работает исключительно в терминах тех, которые он читает из одного из девяти каталогов, в которых .serviceмогут храниться (общесистемные) файлы. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, И /usr/lib/systemd/systemчетыре из этих каталогов.

Совместимость со rcсценариями Ван Смуренбурга достигается с помощью программы преобразования с именем systemd-sysv-generator. Эта программа приведена в /usr/lib/systemd/system-generators/каталоге и, таким образом , автоматически запускается Systemd в начале процесса начальной загрузки при каждой загрузке, и снова каждый раз, когда Systemd проинструктирован повторно загрузить свою конфигурацию позже.

Эта программа является генератором , типом вспомогательной утилиты, задачей которой является создание файлов сервисных модулей на лету, в tmpfs, где находятся еще три из этих девяти каталогов (которые предназначены для использования только генераторами). systemd-sysv-generatorгенерирует сервисные модули, из которых выполняются rcсценарии van Smoorenburg /etc/init.d, если он не находит собственный системный сервисный модуль с таким именем, уже существующий в других шести местах.

Управление сервисом systemd знает только о сервисных блоках. Эти автоматически (повторно) сгенерированные сервисные единицы пишутся для вызова rcсценариев ван Смуренбурга . Они имеют среди прочего:

[Единица измерения]
SourcePath = / и т.д. / init.d / Wibble
[Обслуживание]
ExecStart = / etc / init.d / wibble start
ExecStop = / etc / init.d / wibble stop

Мудрость заключается в том, что rcсценарии Ван Смуренбурга должны иметь LSB-заголовок и выполняться параллельно без учета приоритетов, навязанных /etc/rc?.d/системой. Это неверно по всем пунктам.

На самом деле, они не должны иметь LSB заголовка, и если они не systemd-sysv-generatorмогут признать более ограниченную старую RedHat комментарий заголовки ( description:, pidfile:и так далее). Более того, в отсутствие заголовка LSB он будет возвращаться к содержимому /etc/rc?.dферм символьных ссылок, считывая приоритеты, закодированные в именах ссылок, и создавая из них порядок до / после, сериализовывая сервисы. Заголовки LSB не только не являются обязательным требованием, и они не только сами кодируют до / после упорядочений, которые до некоторой степени сериализуют вещи, но и резервное поведение при их полном отсутствии фактически является непараллельной операцией.

Причина, по которой /etc/rc3.dэто не имеет значения, заключается в том, что вы, вероятно, включили этот сценарий через другой /etc/rc?.d/каталог. systemd-sysv-generatorпереводит перечисленные в любой из /etc/rc2.d/, /etc/rc3.d/и /etc/rc4.d/в родные Wanted-Byотношения с systemd multi-user.target. Уровни выполнения «устарели» в мире systemd, и вы можете забыть о них.

дальнейшее чтение

• systemd-sysv-генератор . Системные справочные страницы. Freedesktop.org.
• «Переменные среды в порожденных процессах» . systemd.exec, Системные справочные страницы. Freedesktop.org.
• https://unix.stackexchange.com/a/394191/5132
• https://unix.stackexchange.com/a/204075/5132
• https://unix.stackexchange.com/a/196014/5132
• https://unix.stackexchange.com/a/332797/5132

Systemd обратно совместим со сценариями инициализации SysV. Согласно LSB 3.1, сценарий инициализации должен иметь информационные условные обозначения для комментариев , определяющие, когда сценарий должен запускаться / останавливаться и что требуется для запуска / остановки сценария. Это пример:

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO

Это закомментированный раздел, который игнорируется SysV. С другой стороны, systemd читает эту информацию о зависимости и запускает эти сценарии в зависимости от этого.

Но есть один момент, когда systemd и SysV различаются по сценариям инициализации. SysV выполняет сценарии в последовательном порядке, основываясь на их количестве в имени файла. Systemd нет. Если встречаются зависимости, systemd запускает сценарии немедленно, без учета нумерации имен сценариев. Некоторые из них, скорее всего, потерпят неудачу из-за заказа. Есть много других несовместимостей, которые следует учитывать.

Если для одной и той же службы существуют сценарии инициализации и файлы .service, systemd выполнит обе функции, как только будут найдены зависимости (в случае сценария инициализации они определены в заголовке LSB).