W moim systemie (16.04) są pliki /lib/systemd/system/network-manager.servicei /etc/init.d/network-managerna przykład.
Nie rozumiem, jak (i dlaczego) to działa. Zawsze ponownie uruchamiam Network Managera przez sudo service network-manager restart. Czy ten system nie powinien jakoś popsuć? Nadal wydaje się działać.
Dlaczego service --status-alllista wszystkich rodzajów usług? Czy 16.04 nie powinno używać systemd zamiast Upstart?
Ktoś proszę wyjaśnić, jak działa to współistnienie.
Odpowiedzi:
Jednocześnie może być aktywny tylko jeden system inicjujący. W dniu 16.04 to systemd.
Wiele pakietów jest dostarczanych z plikami dla wielu systemów inicjujących, dzięki czemu można nimi zarządzać za pomocą wielu systemów inicjujących w różnych systemach operacyjnych. Na Ubuntu czasami instalowane są skrypty dla wielu systemów inicjujących, nawet jeśli nie wszystkie są używane jednocześnie.
Nowsze systemy init starają się zachować zgodność ze starszymi. W szczególności systemd stara się zachować zgodność ze skryptami inicjującymi Upstart i SysV.
W przypadku wspomnianego skryptu „init.d” jest to skrypt inicjujący „SysV”, a nie skrypt Upstart. Ponadto skrypty inicjujące „SysV” byłyby uruchamiane przy rozruchu tylko wtedy, gdyby były dowiązane symbolicznie do katalogu takiego jak „/etc/rc5.d”. Przekonasz się, że Network Manager nie ma tam zainstalowanego dowiązania symbolicznego.
Aby zrozumieć, w jaki sposób systemdzarządza starymi skryptami inicjującymi „SysV”, zobacz Jak systemd używa skryptów /etc/init.d? .
Teraz, aby odpowiedzieć na pytanie, dlaczego to działa, aby zrestartować Network Managera za pomocą „service restart menedżera sieci”. servicePolecenie służy zarówno skrypty dorobkiewicz i skryptów startowych sysv, preferując tych pierwszych. Network Manager ma również skrypt Upstart zainstalowany 16.04 o /etc/init/network-manager.conf.
Jeśli przejrzysz wyniki sudo strace service network-manager restart, możesz zorientować się, co się dzieje. Po pierwsze, wynik pokazuje, że systemctljest wywoływany, co wskazuje, że polecenie jest przekierowywane do systemd. Po pierwsze, wkrótce po otwarciu /usr/bin/service, możesz zobaczyć, jak zaczyna czytać w pliku jako skrypt powłoki:
open("/usr/sbin/service", O_RDONLY) = 3
...
read(10, "#!/bin/sh\n\n#####################"..., 8192) = 8192
Teraz, gdy wiemy, że servicejest to skrypt powłoki, możemy sprawdzić jego kod źródłowy. W kodzie źródłowym stwierdzamy, że is_systemdjest wykrywany i ustawiany. W przypadku systemd widać, że polecenie zostało przepisane systemctl restart network-manager.
Tak więc chociaż trzy systemy inicjujące współistnieją i mają pewną kompatybilność, istnieją warstwy złożoności. Aby zminimalizować złożoność tego, co dzieje się w przyszłości, najlepiej używać systemowych plików jednostek i systemctlnarzędzia do zarządzania usługami.