Різниця між 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

Всі вищезазначені команди працюють.

1. Чи варто віддати перевагу одній команді над іншою?
2. Якщо так, то чому?
3. Чи є якісь інші команди, про які мені потрібно знати?

Використання init.d в Моніті спричинило проблеми, коли я хотів скористатися параметром статусу (статус буде таким, що служба в автономному режимі, коли вона фактично була в Інтернеті - перезапущена 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:~$

Хочу заздалегідь подякувати усім, хто знайшов час для читання та відповіді на це запитання.

Для початку існує ціла історія та боротьба між переходом від SysVInitдо SystemD. Замість того, щоб намагатися розбити все це однією відповіддю, я посилаюсь на якийсь google, який шукає детальнішу інформацію про історію, а також одну статтю з цієї теми:

http://www.tecmint.com/systemd-replaces-init-in-linux/

Підсумовуючи це, це був повільний і важкий перехід. Деякі застарілі функції зберігалися недоторканими (наприклад, init.dпевною мірою). Якщо у вас є можливість використовувати systemctlдля управління послугою, я рекомендую використовувати його. Це в найближчому майбутньому для Linux, і згодом старі SysVInitметоди будуть вважатися повністю застарілими та видалені.

Щоб висвітлити кожен із зазначених вами конкретно:

1. sudo systemctl status apache2.service

Це новий SystemDпідхід до обслуговування послуг. Просуваючись вперед, програми в Linux призначені для використання методу systemd, а не будь-якого іншого.

2. sudo /bin/systemctl status apache2.service

Це те саме, що і попередня команда. Єдина відмінність у цьому випадку полягає в тому, що $PATHзнайти команду не залежно від змінної середовища оболонки , вона чітко перераховує команду, включаючи шлях до команди.

3. sudo /etc/init.d/apache2 status

Це оригінальний SysVInitметод виклику послуги. Сценарії Init будуть написані для послуги та розміщені в цьому каталозі. Хоча цей метод все ще використовується багатьма, serviceбула команда, яка замінила цей метод виклику служб у SysVInit. Для новіших систем із цим є деякі застарілі функціональні можливості SystemD, але більшість нових програм це не включає, і не всі старі сценарії програми init працюють з ним.

4. sudo service apache2 status

Це був основний інструмент, що використовується в SysVInitсистемах для сервісів. У деяких випадках він просто пов'язаний зі /etc/init.d/сценаріями, але в інших випадках він перейшов до сценарію init, який зберігається в іншому місці. Він мав на меті забезпечити більш плавний перехід до обслуговування залежних від служби.

Нарешті, ви згадуєте, що хочете знати, як отримати більше інформації з команд, оскільки деякі надають більше інформації, ніж інші. Це майже завжди визначається програмою та тим, як вони розробили свій файл init чи службу. Як правило, якщо це тихо завершилося, це було успішним. Однак, щоб перевірити a start, stopабо restart, ви можете використовувати statusпідкоманду, щоб побачити, як це робиться. Ви згадали, що statusкоманда невірна в старому сценарії init. Це помилка, яку розробникам додатків доведеться подивитися. Однак, оскільки скрипти init стають застарілим методом обробки послуг, вони можуть просто ігнорувати помилку, поки повністю не видалять параметр сценарію init. Thesystemctl status завжди працювати правильно, інакше помилка повинна реєструватися у розробників додатків.