Разница между Systemctl и сервисом
Я исправил это, добавив эти три строки в конец файла /etc/modprobe.d/blacklist.conf:
черный список intel_rapl черный список the_module черный список i2c_piix411 ответов
Команда service представляет собой сценарий оболочки, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не беспокоясь слишком сильно о фактической используемой системе init. До введения 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
И если это не так, , он возвращается к сценариям System 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 является довольно простой оболочкой, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может быть фактической системой инициализации
Для переносимости в различных версиях Ubuntu пользователи могут надежно использовать команду service для запуска, остановки, перезапуска или проверки состояния службы. Однако для более сложных задач используется фактическая команда, заключающаяся в том, что скрипт initctl или systemctl или /etc/init.d может быть использован напрямую.
Далее, будучи оберткой, [[ f15] в некоторых случаях также делает больше, чем может сделать команда прямого эквивалента. Например:
Он всегда выполняет скрипты /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 были включены или отключены с помощью [ f23] (которая управляла символическими ссылками в каталогах /etc/rc*), поэтому команда service никогда не участвовала в включении или отключении служб при загрузке.
-
1превосходное объяснение, спасибо. – Willa O Ng'wana 10 May 2018 в 00:49
Команда service представляет собой сценарий оболочки, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не беспокоясь слишком сильно о фактической используемой системе init. До введения 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
И если это не так, , он возвращается к сценариям System 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 является довольно простой оболочкой, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может быть фактической системой инициализации
Для переносимости в различных версиях 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 никогда не участвовала в включении или отключении служб при загрузке.
Команда service представляет собой сценарий оболочки, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не беспокоясь слишком сильно о фактической используемой системе init. До введения 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
И если это не так, , он возвращается к сценариям System 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 является довольно простой оболочкой, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может быть фактической системой инициализации
Для переносимости в различных версиях 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 никогда не участвовала в включении или отключении служб при загрузке.
Команда service представляет собой сценарий оболочки, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не беспокоясь слишком сильно о фактической используемой системе init. До введения 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
И если это не так, , он возвращается к сценариям System 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 является довольно простой оболочкой, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может быть фактической системой инициализации
Для переносимости в различных версиях 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 никогда не участвовала в включении или отключении служб при загрузке.
Команда service представляет собой сценарий оболочки, который позволяет системным администраторам запускать, останавливать и проверять состояние служб, не беспокоясь слишком сильно о фактической используемой системе init. До введения 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
И если это не так, , он возвращается к сценариям System 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 является довольно простой оболочкой, она поддерживает только ограниченное подмножество действий по сравнению с тем, что может быть фактической системой инициализации
Для переносимости в различных версиях 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 никогда не участвовала в включении или отключении служб при загрузке.
Есть намного больше, чем вы упомянули, что systemctl способен.
systemd работает с единицами, существуют разные типы единиц: цели, службы, сокеты и т. д. цели - это то же понятие, что и уровни запуска, они представляют собой совокупность единиц.
[d8 ] Вы можете использовать systemctl для установки или получения целевой системы по умолчанию.systemctl get-default
Вы можете перейти в другие цели:
systemctl isolate multiuser.target
Другие цели: многопользовательские, графические , выключение, аварийная ситуация, перезагрузка, выключение питания.
Как вы сказали, вы можете использовать systemctl для управления службами, некоторые из других команд, связанных с управлением сервисами, о которых я знаю: [!d11 ]
# 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
Wen mask сервис, который будет связан с /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)
-
1это был прекрасный ответ: есть ли что-нибудь, что service может сделать, но не systemctl? – luv.preet 11 April 2017 в 02:10
-
2Ничто из того, что я знаю об этом, я думаю, что было бы полезно посмотреть страницу service man . – Ravexina 11 April 2017 в 02:12
-
3Есть пара очевидных различий. Синтаксис - один. Другое, что системные скрипты никогда не занимались сокетами, насколько я знаю. Тот факт, что systemd пытается разобраться в сетевом типе вещей, является другим, и это частая точка критики. В целом, systemd пытается сделать больше, чем просто запуск сервисов – Sergiy Kolodyazhnyy 11 April 2017 в 04:28
-
4Я хотел бы подать жалобу здесь о системных скрытых сообщениях журнала из неудачных попыток service start. Pre-systemd, service start позволит мне сразу увидеть, почему мой сервис не запускается. Post-systemd, я должен посмотреть четыре или пять разных журналов, прежде чем я смогу его найти. Все, что сказал, мой комментарий, несомненно, не соответствует теме и, вероятно, будет удален. – Ross Presser 11 April 2017 в 05:23
-
5AFAICS Этот ответ, похоже, ничего не говорит о команде service, не была ли эта часть вопроса? – ilkkachu 11 April 2017 в 11:04
Есть намного больше, чем вы упомянули, что 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
Wen mask сервис, который будет связан с /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)
Есть намного больше, чем вы упомянули, что 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
Wen mask сервис, который будет связан с /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)
-
1это был прекрасный ответ: есть ли что-нибудь, что service может сделать, но не systemctl? – luv.preet 11 April 2017 в 02:10
-
2Ничто из того, что я знаю об этом, я думаю, что было бы полезно посмотреть страницу service man . – Ravexina 11 April 2017 в 02:12
-
3Есть пара очевидных различий. Синтаксис - один. Другое, что системные скрипты никогда не занимались сокетами, насколько я знаю. Тот факт, что systemd пытается разобраться в сетевом типе вещей, является другим, и это частая точка критики. В целом, systemd пытается сделать больше, чем просто запуск сервисов – Sergiy Kolodyazhnyy 11 April 2017 в 04:28
-
4Я хотел бы подать жалобу здесь о системных скрытых сообщениях журнала из неудачных попыток service start. Pre-systemd, service start позволит мне сразу увидеть, почему мой сервис не запускается. Post-systemd, я должен посмотреть четыре или пять разных журналов, прежде чем я смогу его найти. Все, что сказал, мой комментарий, несомненно, не соответствует теме и, вероятно, будет удален. – Ross Presser 11 April 2017 в 05:23
-
5AFAICS Этот ответ, похоже, ничего не говорит о команде service, не была ли эта часть вопроса? – ilkkachu 11 April 2017 в 11:04
Есть намного больше, чем вы упомянули, что 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
Wen mask сервис, который будет связан с /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)
-
1это был прекрасный ответ: есть ли что-нибудь, что service может сделать, но не systemctl? – luv.preet 11 April 2017 в 02:10
-
2Ничто из того, что я знаю об этом, я думаю, что было бы полезно посмотреть страницу service man . – Ravexina 11 April 2017 в 02:12
-
3Есть пара очевидных различий. Синтаксис - один. Другое, что системные скрипты никогда не занимались сокетами, насколько я знаю. Тот факт, что systemd пытается разобраться в сетевом типе вещей, является другим, и это частая точка критики. В целом, systemd пытается сделать больше, чем просто запуск сервисов – Sergiy Kolodyazhnyy 11 April 2017 в 04:28
-
4Я хотел бы подать жалобу здесь о системных скрытых сообщениях журнала из неудачных попыток service start. Pre-systemd, service start позволит мне сразу увидеть, почему мой сервис не запускается. Post-systemd, я должен посмотреть четыре или пять разных журналов, прежде чем я смогу его найти. Все, что сказал, мой комментарий, несомненно, не соответствует теме и, вероятно, будет удален. – Ross Presser 11 April 2017 в 05:23
-
5AFAICS Этот ответ, похоже, ничего не говорит о команде service, не была ли эта часть вопроса? – ilkkachu 11 April 2017 в 11:04
Есть намного больше, чем вы упомянули, что 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
Wen mask сервис, который будет связан с /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)
-
1это был прекрасный ответ: есть ли что-нибудь, что service может сделать, но не systemctl? – luv.preet 11 April 2017 в 02:10
-
2Ничто из того, что я знаю об этом, я думаю, что было бы полезно посмотреть страницу service man . – Ravexina 11 April 2017 в 02:12
-
3Есть пара очевидных различий. Синтаксис - один. Другое, что системные скрипты никогда не занимались сокетами, насколько я знаю. Тот факт, что systemd пытается разобраться в сетевом типе вещей, является другим, и это частая точка критики. В целом, systemd пытается сделать больше, чем просто запуск сервисов – Sergiy Kolodyazhnyy 11 April 2017 в 04:28
-
4Я хотел бы подать жалобу здесь о системных скрытых сообщениях журнала из неудачных попыток service start. Pre-systemd, service start позволит мне сразу увидеть, почему мой сервис не запускается. Post-systemd, я должен посмотреть четыре или пять разных журналов, прежде чем я смогу его найти. Все, что сказал, мой комментарий, несомненно, не соответствует теме и, вероятно, будет удален. – Ross Presser 11 April 2017 в 05:23
-
5AFAICS Этот ответ, похоже, ничего не говорит о команде service, не была ли эта часть вопроса? – ilkkachu 11 April 2017 в 11:04
- systemd обратно совместим с SysV.
- загружает службы параллельно при запуске
- , это обеспечивает активацию услуги по требованию
- , это зависимость на основе
- и намного больше, я думаю ...
Есть намного больше, чем вы упомянули, что systemctl способен.
systemd работает с единицами, существуют разные типы единиц: цели, службы, сокеты и т. д. цели - это то же понятие, что и уровни запуска, они представляют собой совокупность единиц.
Вы можете использовать systemctl, чтобы установить или получить целевую систему по умолчанию.
systemctl get-default
Вы можете перейти в другие цели:
systemctl isolate multiuser.target
Другие цели: многопользовательские, графические, reboot, poweroff.
Как вы сказали, вы можете использовать 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
В случае маскировки службы она будет ссылка ed до /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 делает то, что он должен делать, управляя услугами и не имеющими никакого отношения к бизнесу других народов;)