Разница между systemctl init.d и сервисом
Я новичок в Linux, и я тестировал себя, используя экземпляр Amazon Lightsail (Ubuntu 16.04 LTS).
Просматривая множество руководств, с которыми я сталкивался, я вижу людей, использующих разные команды для запуска / остановки / перезапуска / перезагрузки / проверки состояния службы. В частности это;
sudo systemctl status apache2.service
sudo /bin/systemctl status apache2.service
sudo /etc/init.d/apache2 status
sudo service apache2 status
Все вышеперечисленные команды работают.
- Стоит ли мне отдавать предпочтение одной команде над другой?
- Если да, то почему?
- Есть ли какие-либо другие команды, о которых мне нужно знать?
Использование init.d в Monit вызывало проблемы, когда я хотел использовать опцию состояния (статус будет состоять в том, что служба была отключена, когда она была на самом деле - перезапущена Monit). Измените код в Monit с inid.d на / bin / systemctl и исправьте его.
Кажется, что использование init.d предоставляет больше информации о том, что случилось с другими. Если мне нужно использовать одну из других команд, возможно ли, чтобы они отображали больше информации о том, что было сделано?
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:~$
Я хотел бы заранее поблагодарить всех, кто нашел время для чтения и ответ на этот вопрос.
1 ответ
Для начала, существует целая история и борьба между переходом от SysVInit к SystemD. Вместо того, чтобы пытаться разбить все это в одном ответе, я отсылаю вас к некоторой авантюре Google для более подробной информации об истории, а также к одной конкретной статье на эту тему:
http: / /www.tecmint.com/systemd-replaces-init-in-linux/
В общем, это был медленный и трудный переход. Некоторые унаследованные особенности были сохранены (например, init.d в некоторой степени). Если у вас есть возможность использовать systemctl для управления сервисом, я рекомендую использовать его. Это обозримое будущее для Linux, и в конечном итоге старые методы SysVInit будут считаться устаревшими и полностью удалены.
Чтобы охватить каждого, кого вы перечислили специально:
-
sudo systemctl status apache2.service
Это новый SystemD подход к обработке услуг. В дальнейшем приложения в Linux предназначены для использования метода systemd, а не любого другого.
-
sudo /bin/systemctl status apache2.service
Это то же самое, что и предыдущая команда. Единственное отличие в этом случае заключается в том, что поиск команды не зависит от переменной среды оболочки $PATH, а выводит ее в явном виде, включая путь к команде.
-
sudo /etc/init.d/apache2 status
Это оригинальный метод вызова службы SysVInit. Сценарии инициализации будут написаны для службы и помещены в этот каталог. Хотя этот метод до сих пор используется многими, команда service заменила этот метод вызова сервисов в SysVInit. Для этого в более новых системах с SystemD существует некоторая устаревшая функциональность, но большинство новых программ не включают это, и не все более старые сценарии инициализации приложения работают с ним.
-
sudo service apache2 status
Это был основной инструмент, используемый в SysVInit системах для служб. В некоторых случаях он просто связывался со скриптами /etc/init.d/, но в других случаях он переходил к скрипту инициализации, хранящемуся в другом месте. Он должен был обеспечить более плавный переход к обработке зависимостей службы.
Наконец, вы упомянули, что хотите знать, как получить больше информации из команд, поскольку некоторые предоставляют больше информации, чем другие. Это почти всегда определяется приложением и тем, как они разработали свой файл инициализации или службы. Как правило, хотя, если он завершен в молчании, он был успешным. Однако, чтобы проверить start, stop или restart, вы можете использовать подкоманду status, чтобы увидеть, как она работает. Вы упомянули неправильную команду status в старом скрипте инициализации. Это ошибка, на которую должны были бы обратить внимание разработчики приложений. Однако, поскольку сценарии инициализации становятся устаревшим методом обработки служб, они могут просто игнорировать ошибку, пока полностью не удалят параметр сценария инициализации. systemctl status всегда должен работать правильно, иначе ошибка должна регистрироваться разработчиками приложения.