Разница между systemctl и сервисными командами

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

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

Является единственной разницей между service и systemctl команды, которые systemctl может быть использован для включения запуска служб во время выполнения? Можем ли мы использовать systemctl на какой-нибудь службе? Какие еще существенные различия существуют?

То service command - это сценарий-оболочка, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не слишком беспокоясь о фактической используемой системе инициализации. До появления systemd это была оболочка для /etc/init.d сценарии и выскочки initctl команда, и теперь это оболочка для этих двух и systemctl также.

Используй источник, Люк!

Он проверяет наличие выскочки:

# Operate against system upstart, not sessionunset UPSTART_SESSIONif [ -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/nullthen   # Upstart configuration exists for this job and we're running on upstart

Если это не сработает, он ищет systemd:

if [ -d /run/systemd/system ]; then   is_systemd=1fi...# When this machine is running systemd, standard service calls are turned into# systemctl calls.if [ -n "$is_systemd" ]then

И если это тоже не удастся, он вернется к системе V /etc/init.d скрипты:

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 command - это довольно простая оболочка, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может предоставить реальная система инициализации.

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

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

  • Он всегда выполняет /etc/init.d скрипты в чистой среде. (Обратите внимание на длинный env вызов команды в run_via_sysvinit функция выше.)
  • Он отображает restart на стартовых системах к сочетанию stop/start, поскольку простой initctl restart выдаст сообщение об ошибке, если служба еще не запущена.
  • Он останавливает сокеты при остановке служб systemd, которые имеют связанные сокеты:

    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 команда никогда не участвовала в включении или отключении служб при загрузке.

Есть гораздо больше, чем то, что вы упомянули, что systemctl способен на:

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

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 servicesystemctl reload-or-restart name.service

Вы можете использовать его, чтобы узнать о статусе обслуживания:

systemctl status name.servicesystemctl is-active name.service # runningsystemctl is-enabled name.service # will be activated when bootingsystemctl is-failed name.service # failed to load

Вы можете замаскировать или снять маску с службы:

systemctl mask name.servicesystemctl 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 делает то, что должен делать, управляя услугами и не имея ничего общего с бизнесом других людей ;)

Я сам думаю, что ты выбрал неправильный ответ.