Różnica między systememctl init.d a usługą

Jestem nowy w Linuksie i testowałem się przy użyciu instancji Amazon Lightsail (Ubuntu 16.04 LTS).

Przeglądając wiele przewodników, z którymi się zetknąłem, widzę ludzi używających różnych poleceń do uruchamiania / zatrzymywania / restartu / przeładowywania / sprawdzania statusu usługi. W szczególności te;

sudo systemctl status apache2.service
sudo /bin/systemctl status apache2.service
sudo /etc/init.d/apache2 status
sudo service apache2 status

Wszystkie powyższe polecenia działają.

1. Czy wolę jedno polecenie od drugiego?
2. Jeśli tak, to dlaczego?
3. Czy są jeszcze jakieś polecenia, o których muszę wiedzieć?

Użycie init.d w Monit spowodowało problemy, gdy chciałem użyć opcji statusu (status będzie taki, że usługa jest offline, kiedy była w trybie online - ponownie uruchomiona przez Monit). Zmień kod w Monit z inid.d na / bin / systemctl naprawił go.

Wygląda na to, że użycie init.d dostarcza więcej informacji o tym, co się stało, że inni. Jeśli powinienem używać jednego z innych poleceń, czy jest możliwe, aby wyświetlały więcej informacji o tym, co zostało zrobione?

ubuntu@ip-172-26-12-245:~$ sudo systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /bin/systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /etc/init.d/pure-ftpd restart
[ ok ] Restarting pure-ftpd (via systemctl): pure-ftpd.service.
ubuntu@ip-172-26-12-245:~$ sudo service pure-ftpd restart
ubuntu@ip-172-26-12-245:~$

Chciałbym z góry podziękować wszystkim, którzy poświęcili czas na przeczytanie i odpowiedź na to pytanie.

Na początek jest cała historia i walka między przejściem od SysVInitdo SystemD. Zamiast próbować wyjaśnić to wszystko w jednej odpowiedzi, odsyłam cię do jakiegoś przedsięwzięcia google, aby uzyskać więcej szczegółów na temat historii, a także jeden konkretny artykuł na ten temat:

http://www.tecmint.com/systemd-replaces-init-in-linux/

Podsumowując, było to powolne i uciążliwe przejście. Niektóre starsze funkcje pozostały nienaruszone (np. init.dDo pewnego stopnia). Jeśli masz opcję użycia systemctldo kontroli usług, zalecam użycie tej. To przewidywalna przyszłość dla Linuksa i ostatecznie starsze SysVInitmetody zostaną uznane za całkowicie przestarzałe i usunięte.

Aby szczegółowo opisać każdą z wymienionych:

1. sudo systemctl status apache2.service

To nowe SystemDpodejście do obsługi usług. Idąc dalej, aplikacje w systemie Linux są zaprojektowane tak, aby używały metody systemowej, a nie żadnej innej.

2. sudo /bin/systemctl status apache2.service

To jest to samo, co poprzednie polecenie. Jedyną różnicą w tym przypadku jest to, że $PATHznalezienie polecenia nie zależy od zmiennej środowiskowej powłoki , ale jawnie wyświetla listę polecenia, włączając ścieżkę do polecenia.

3. sudo /etc/init.d/apache2 status

Jest to oryginalna SysVInitmetoda wywoływania usługi. Skrypty inicjujące zostałyby napisane dla usługi i umieszczone w tym katalogu. Chociaż ta metoda jest wciąż używana przez wielu, servicebyło to polecenie, które zastąpiło tę metodę wywoływania usług w SysVInit. W nowszych systemach dostępna jest pewna starsza funkcjonalność SystemD, ale większość nowszych programów tego nie zawiera i nie wszystkie starsze skrypty inicjujące aplikację z tym współpracują.

4. sudo service apache2 status

Było to podstawowe narzędzie używane w SysVInitsystemach usług. W niektórych przypadkach po prostu łączył się ze /etc/init.d/skryptami, ale w innych przypadkach przechodził do skryptu init przechowywanego gdzie indziej. Jego celem było płynniejsze przejście do obsługi zależności usług.

Na koniec wspominasz, że chcesz wiedzieć, jak uzyskać więcej informacji z poleceń, ponieważ niektóre zawierają więcej informacji niż inne. Jest to prawie zawsze określane przez aplikację i sposób zaprojektowania pliku init lub pliku usługi. Zasadniczo jednak, jeśli zakończyło się po cichu, zakończyło się powodzeniem. Aby jednak zweryfikować a start, stoplub restart, możesz użyć polecenia statuspodrzędnego, aby zobaczyć, jak to działa. Wspomniałeś, że statuspolecenie jest niepoprawne w starym skrypcie inicjującym. Jest to błąd, na który musieliby spojrzeć twórcy aplikacji. Ponieważ jednak skrypty init stają się przestarzałą metodą obsługi usług, mogą po prostu zignorować błąd do momentu całkowitego usunięcia opcji skryptu init. Thesystemctl status powinien zawsze działać poprawnie, w przeciwnym razie błąd powinien zostać zarejestrowany z twórcami aplikacji.