Різниця між командами systemctl і службами

systemdнадає нам systemctlнабір команд, який в основному використовується для включення служб до запуску під час завантаження. Ми також можемо запустити, зупинити, перезавантажити, перезапустити та перевірити стан послуг за допомогою systemctl.

Ми можемо зробити це, наприклад sudo systemctl enable service_name, і service_nameавтоматично запуститься під час завантаження. Ми також можемо відключити послуги, які не запускаються під час завантаження.

Чи є єдиною різницею між командами serviceта systemctlкомандами, які systemctlможна використовувати для включення запуску послуг під час виконання? Чи можемо ми користуватися systemctlбудь-якою послугою? Які ще суттєві відмінності є?

serviceКоманда є обгорткою скрипт , який дозволяє системним адміністраторам запускати, зупиняти і перевіряти стан послуг , не надто переймаючись тим , використовується поточна система ініціалізації. До впровадження systemd це було обгорткою для /etc/init.dскриптів та initctlкоманд Upstart , а тепер це оболонка для цих двох, а systemctl також.

Користуйся джерелом, Лука!

Він перевіряє наявність Upstart:

# 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

Якщо це не працює, він шукає 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

І якщо це також не вдається, воно повертається до /etc/init.dсценаріїв System 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

Оскільки serviceкоманда є досить простою обгорткою, вона підтримує лише обмежений набір дій у порівнянні з тим, що може надати фактична система init.

Для портативності в різних версіях Ubuntu користувачі можуть надійно використовувати serviceкоманду для запуску, зупинки, перезавантаження або вивчення стану послуги. Однак для більш складних завдань може використовуватися фактична команда, будь то initctlта systemctlабо /etc/init.dсценарій, безпосередньо.

Крім того, будучи обгорткою, serviceсценарій в деяких випадках також робить більше, ніж може зробити команда прямого еквівалента. Наприклад:

• Він завжди виконує /etc/init.dсценарії в чистому середовищі. (Зверніть увагу на довге env виклик команди у run_via_sysvinitфункції вище.)
• Він відображає restartв системах Upstart комбінацію stop/ start, оскільки звичайна initctl restartпомилка вимикається, якщо служба вже не працює.

• Він зупиняє розетки при зупинці системних служб, які мають асоційовані сокети:

  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.

Служби Upstart були включені безпосередньо у файлі конфігурації служби (або відключені через переопределення), а сценарії System V були включені або відключені update-rc.dкомандою (яка керувала символьними посиланнями в /etc/rc*каталогах), тому serviceкоманда ніколи не брала участь у ввімкненні та відключенні послуг під час завантаження. .

• systemd назад сумісний з SysV.
• завантажує послуги паралельно при запуску
• він забезпечує активацію послуги за запитом
• це засноване на залежності
• і багато іншого я здогадуюсь ...

Є набагато більше, ніж ви згадали, на що systemctlздатні.

systemd працює з підрозділами, є різні типи одиниць: цілі, служби, розетки тощо. Цілі - це те саме поняття, що і рівні пробігу, вони є купою одиниць разом.

Ви можете використовувати systemctlдля встановлення або отримання системної цілі за замовчуванням.

systemctl get-default

Ви можете перейти до інших цілей:

systemctl isolate multiuser.target

Інші цілі: багатокористувацька, графічна, рятувальна, надзвичайна ситуація, перезавантаження, потужність.

Як ви вже говорили, ви можете використовувати systemctlдля управління службами, деякі інші команди, пов'язані з управлінням сервісом, про які я знаю:

# 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

Ви можете використовувати його, щоб дізнатися про стан послуги:

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

Ви можете замаскувати або розблокувати послугу:

systemctl mask name.service
systemctl unmask name.service

Якщо ви маскуєте послугу, з якою вона буде пов’язана /dev/null, тому вручну або автоматично інші служби не можуть її активувати / вмикати. (спершу слід його розкрити).

Ще одним використанням systemctl є перелік одиниць:

systemctl list-units

У якому перелічені всі типи підрозділів, завантажені та активні.

Список службових підрозділів:

systemctl list-units --type=service

Або перелічити всі доступні одиниці не тільки завантажених та активованих:

systemctl list-unit-files

Ви можете створювати псевдоніми або навіть керувати віддаленими машинами

systemctl --host ravexina@192.168.56.4 list-units

З іншого боку, serviceробить те, що йому потрібно робити, керуючи послугами і не маючи нічого спільного з бізнесом інших народів;)