У моїй системі (16.04) є файли /lib/systemd/system/network-manager.serviceі /etc/init.d/network-manager, наприклад.
Я не розумію, як (і чому) це працює. Я завжди перезапускаю Менеджер мережі за допомогою sudo service network-manager restart. Чи не повинно це заплутатися якось? Це все одно, здається, працює.
Чому service --status-allперелік усіх видів послуг? Чи не повинен 16.04 використовувати systemd замість Upstart?
Хтось, будь ласка, поясніть, як працює це співіснування.
Відповіді:
Одразу може бути активна лише одна система init. 16.04, це систематизовано.
Ряд пакетів постачається з файлами для декількох систем init, тому ними можна керувати за допомогою декількох систем init на різних ОС. В Ubuntu інколи встановлюються сценарії для декількох систем init, хоча вони не використовуються одночасно.
Новіші системи init намагаються підтримувати сумісність зі старими. Зокрема, systemd намагається підтримувати сумісність із сценаріями Instart та SysV init.
У випадку зі згаданим вами сценарієм "init.d" це сценарій init "SysV", а не сценарій Upstart. Крім того, "SysV" сценаріїв init буде запущено під час завантаження лише у тому випадку, якщо вони були би пов'язані з каталогом типу "/etc/rc5.d". Ви побачите, що в Менеджері мережі не встановлено симпосилання.
Щоб зрозуміти, як systemdкерує старими сценаріями "SysV" init, див. Як система використовує /etc/init.d scirpts? .
Тепер, щоб відповісти на питання про те, чому працює перезапуск Менеджера мереж за допомогою "перезавантаження сервісної мережі менеджера". serviceКоманда використовується з обох сценаріїв вискочка і скриптах SysV, віддаючи перевагу першій. Менеджер мережі також має встановлений сценарій Upstart 16.04 о /etc/init/network-manager.conf.
Переглянувши результат роботи sudo strace service network-manager restart, ви можете зрозуміти, що відбувається. По-перше, результат показує, systemctlщо викликається, вказуючи на те, що команда перенаправляється на systemd. По-перше, незабаром після його відкриття/usr/bin/service ви побачите, як він починає читати у файлі як сценарій оболонки:
open("/usr/sbin/service", O_RDONLY) = 3
...
read(10, "#!/bin/sh\n\n#####################"..., 8192) = 8192
Тепер, коли ми знаємо, що serviceце скрипт оболонки, ми можемо перевірити його вихідний код. У вихідному коді ми знаходимо цеis_systemd виявлено та встановлено. У системному випадку ви бачите, що команда переписується у формат systemctl restart network-manager.
Тож, коли три системи init співіснують і мають певну сумісність, існують шари складності. Щоб мінімізувати складність того, що відбувається вперед, найкраще використовувати файли системного блоку та systemctlінструмент для управління службами.