Różnica między poleceniami systemctl a service

systemddaje nam systemctlzestaw poleceń, który jest używany głównie do umożliwienia uruchamiania usług w czasie rozruchu. Możemy również uruchamiać, zatrzymywać, przeładowywać, restartować i sprawdzać status usług za pomocą systemctl.

Możemy to zrobić na przykład sudo systemctl enable service_namei service_namerozpocznie się automatycznie w czasie uruchamiania. Możemy również wyłączyć usługi, aby nie uruchamiały się podczas rozruchu.

Czy jedyną różnicą między poleceniami servicei systemctl, których systemctlmożna użyć, aby umożliwić uruchomienie usług w czasie wykonywania? Czy możemy korzystać systemctlz dowolnej usługi? Jakie są inne istotne różnice?

serviceKomenda jest skrypt wrapper, który pozwala administratorom na start, stop, i sprawdzić stan usługi, nie martwiąc się zbytnio używany rzeczywisty system init. Przed wprowadzeniem systemd było to opakowanie dla /etc/init.dskryptów i initctlpolecenia Upstart , a teraz jest to opakowanie dla tych dwóch, a systemctl także.

Użyj źródła, Luke!

Sprawdza poprawność:

# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version 2>/dev/null | grep -q upstart \
   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
   # Upstart configuration exists for this job and we're running on upstart

Jeśli to nie działa, szuka systemd:

if [ -d /run/systemd/system ]; then
   is_systemd=1
fi

...

# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then

A jeśli to też się nie powiedzie, wraca do /etc/init.dskryptów Systemu V :

run_via_sysvinit() {
   # Otherwise, use the traditional sysvinit
   if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
      exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
   else
      echo "${SERVICE}: unrecognized service" >&2
      exit 1
   fi
}

...
run_via_sysvinit

Ponieważ servicepolecenie jest dość prostym opakowaniem, obsługuje tylko ograniczony podzbiór działań w porównaniu z tym, co może zapewnić rzeczywisty system init.

Aby zapewnić przenośność w różnych wersjach systemu Ubuntu, użytkownicy mogą niezawodnie używać servicepolecenia do uruchamiania, zatrzymywania, ponownego uruchamiania lub sprawdzania stanu usługi. Dla bardziej złożonych zadań, jednak używana rzeczywista komenda, możliwe, że initctlalbo systemctlczy /etc/init.dskrypt może być stosowany bezpośrednio.

Ponadto, będąc opakowaniem, servicew niektórych przypadkach skrypt robi więcej, niż może zrobić bezpośrednie równoważne polecenie. Na przykład:

• Zawsze wykonuje /etc/init.dskrypty w czystym środowisku. (Zwróć uwagę na długie env wywołanie polecenia w run_via_sysvinitpowyższej funkcji).
• Odwzorowuje on restartna systemach dorobkiewicz do kombinacji stop/ start, ponieważ zwykły initctl restartbędzie błędu, jeśli usługa nie jest już uruchomiony.

• Zatrzymuje gniazda podczas zatrzymywania usług systemowych, które mają powiązane gniazda:

  case "${ACTION}" in
    restart|status)
       exec systemctl $sctl_args ${ACTION} ${UNIT}
    ;;
    start|stop)
       # Follow the principle of least surprise for SysV people:
       # When running "service foo stop" and foo happens to be a service that
       # has one or more .socket files, we also stop the .socket units.
       # Users who need more control will use systemctl directly.

Usługi upstart zostały włączone bezpośrednio w pliku konfiguracyjnym usługi (lub wyłączone przez przesłonięcia), a skrypty Systemu V zostały włączone lub wyłączone za pomocą update-rc.dpolecenia (które zarządzało dowiązaniami symbolicznymi w /etc/rc*katalogach), więc servicepolecenie nigdy nie było zaangażowane w włączanie lub wyłączanie usług podczas rozruchu .

• systemd jest wstecznie kompatybilny z SysV.
• ładuje usługi równolegle przy starcie
• zapewnia aktywację usługi na żądanie
• jest oparty na zależności
• i wiele innych, jak sądzę ...

Jest o wiele więcej niż to, o czym wspomniałeś, że systemctljest w stanie.

systemd współpracuje z jednostkami, istnieją różne typy jednostek: cele, usługi, gniazda itp. Cele są takie same jak poziomy pracy, są grupą jednostek.

Możesz użyć, systemctlaby ustawić lub uzyskać domyślny systemowy cel.

systemctl get-default

Możesz przejść do innych celów:

systemctl isolate multiuser.target

Inne cele to: wiele użytkowników, grafika, odzyskiwanie, awaryjne, ponowne uruchomienie, wyłączenie.

Jak już powiedziałeś, możesz używać systemctldo zarządzania usługami, a niektóre inne polecenia związane z zarządzaniem usługami, o których wiem, to:

# Restarts a service only if it is running.
systemctl try-restart name.service

# Reloads configuration if it's possible.
systemctl reload name.service

# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service

Możesz go użyć, aby dowiedzieć się o statusie usługi:

systemctl status name.service

systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load

Możesz zamaskować lub zdemaskować usługę:

systemctl mask name.service
systemctl unmask name.service

Jeśli zamaskujesz usługę, z którą zostanie ona połączona /dev/null, więc ręcznie lub automatycznie inne usługi nie będą mogły jej aktywować / włączyć. (najpierw należy zdemaskować).

Innym zastosowaniem systemctl jest lista jednostek:

systemctl list-units

Które wyświetlają listę wszystkich rodzajów jednostek, załadowanych i aktywnych.

Lista jednostek usług:

systemctl list-units --type=service

Lub, aby wyświetlić listę wszystkich dostępnych, nie tylko załadowanych i aktywowanych urządzeń:

systemctl list-unit-files

Możesz tworzyć aliasy, a nawet kontrolować zdalne maszyny

systemctl --host ravexina@192.168.56.4 list-units

Z drugiej strony servicerobi to, co musi robić, zarządzając usługami i nie mając nic wspólnego z biznesem innych ludzi;)