Как да стартирате автоматично услуги при стартиране в RHEL / CentOS 7?

Чудите се как да управлявате услуги във фонов режим или при зареждане?


Механизмът за управление и стартиране на процеси при зареждане е променен. До RHEL / CentOS 6.x, вие щяхте да създадете скрипт в /etc/init.d/ и да го активирате с помощта на chkconfig, но нещата са различни по RHEL 7.

Той е заменен с systemd и тъй като е повече или по-малко мениджърът на процеси по подразбиране за основните версии на Linux, System Admin, запознат с други вкусове, ще се чувства като у дома си. В тази статия ще разгледаме какво е systemd, какви са причините за превключването и как да използваме systemd за настройка, изпълнение и управление на фонови процеси с него.

Какво е систематизирано?

Тъй като всеки процес в Linux е видимо видим, нека видим къде дебне systemd. В моята система получавам следното:

~ $ ps -ef | grep systemd
корен 1 0 0 ноември11? 00:01:02 / lib / systemd / systemd – система – десериализирайте 22
съобщение + 768 1 0 Nov11? 00:05:46 / usr / bin / dbus-daemon – система – адрес = systemd: –nofork –nopidfile – системно активиране – само за syslog
корен 805 1 0 ноември11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 Nov11? 00:00:00 / lib / systemd / systemd –user
ankush 1176 1132 0 Nov11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-activation –syslog-only
ankush 9772 20029 0 21:11 pts / 6 00:00:00 grep –color = auto systemd
systemd + 17298 1 0 Nov19? 00:00:12 / lib / systemd / systemd-разрешен
systemd + 17303 1 0 Nov19? 00:00:00 / lib / systemd / systemd-timesyncd
корен 17307 1 0 Nov19? 00:00:02 / lib / systemd / systemd-journald
корен 18182 1 0 Nov19? 00:00:00 / lib / systemd / systemd-udevd

Обзалагам се, че сте го забелязали моментално. първият процес в списъка е стартиран като потребителски корен и има pid 1.

Със сигурност, това беше първият процес, който системата стартира при стартиране. Кажете здравей на systemd. ��

Така че, просто, systemd е процесът “майка”, който стартира, управлява и прекратява други процеси в системата, освен че предоставя информация за тяхното регистриране, състояния на файловата система и т.н..

Бележка за името обаче. Името наистина е системно, а не System D или нещо друго. „D“ означава демон, стандартен Linux процес, който работи (дебне?) На заден план и не е прикачен към никоя терминална сесия.

Защо RHEL премина към systemd?

Както вече обсъдихме, systemd е система и мениджър на процеси, а в RHEL 7 замества добре познатата програма Upstart. Защо RHEL (Oracle?) Взе това решение? Е, има много добри причини за това, така че нека да разгледаме бързо.

Инициализация на паралелна услуга

Не харесва програмата SysV init, systemd е способен да стартира услуги паралелно. Противоположната програма init ги стартира едно по едно. В епоха, в която дори мобилните устройства имат многоядрени процесори, липсата на паралелна инициализация е голямо изключване.

Динамично (горещо) управление на услуги

Ако сте забелязали, че USB устройствата трябва да бъдат изрично монтирани в по-ранни системи Fedora, докато те автоматично ще се отворят в Ubuntu и подобни дистрибуции, причината е системна. Той е в състояние да открие живи промени в хардуера и да прекрати / стартира услуги, ако е необходимо. Някои могат да твърдят, че е ненужно, но за мнозина всичко, което намалява когнитивната тежест, е най-добре дошло.

Отложено стартиране на услугата

systemd прави пъти за стартиране на стартирането, тъй като е в състояние да отложи стартирането на услугата, когато това действително е необходимо. Прост пример са услугите, свързани с мрежовата файлова система. Ако няма наличен мрежов диск, няма смисъл да стартирате и стартирате услуга.

По-бърза комуникация на процеса

Паралелните възможности на systemd се пренасят към междупроцесовата комуникация. systemd е в състояние да предложи паралелен достъп до сокети и системна шина, като значително намалява времето за изчакване на процеса за комуникационни ресурси.

Автоматичен рестарт

Ако дадена услуга се срине, systemd може да открие това и да се опита да го рестартира. В повечето случаи, просто рестартиране е всичко, което е необходимо, за да може едно приложение да започне да функционира отново, освен ако няма по-фундаментални проблеми.

Както и да е, systemd улеснява живота на sysadmin тук.

systemd в RHEL7 – Какви промени за Sysadmins?

Ако имате заяждащо чувство, че systemd няма да са всички камбани и свирки, вие сте прав. Има няколко значителни несъвместимости, които могат да изравнят RHEL sysadmin от изненада. Нека да разгледаме бързо.

Ограничена поддръжка на ниво

systemd има доста изтъркано разпознаване и поддръжка за нивата на движение. Не всички нива на въртене се поддържат, а за някои цели може дори да няма такива. В такива случаи systemd връща „N“ като отговор на командите от runlevel, което означава, че няма съответно ниво на изпълнение към тази цел. Като цяло, Red Hat ни съветва да не използваме (!) Командите runlevel.

Няма персонализирани команди

Това ще навреди. Един голям плюс при SysV беше възможността да се определят персонализирани команди, за да се осигури по-добра функционалност за управление на процесите. При systemd няма такава опция и сте заседнали със старт, стоп, състояние, рестартиране и т.н..

Само за семейство и неинтерактивен

systemd (разбира се) следи процесите, които е стартирал и съхранява техните PID. Предизвикателството обаче е, че systemd не може да се справи с не стартирани от него процеси. Освен това не е възможно потребителят да взаимодейства с процес, стартиран от systemd. Целият изход отива в / dev / null, ефективно спирайки всички надежди, които бихте имали за заснемане на продукцията.

Без контекст

За разлика от услугите на init, тези, стартирани от systemd, не наследяват никаква среда от никой от потребителите в системата. С други думи, информация като PATH и други системни променливи не е налична и всеки нов процес се стартира в празен контекст.

Ако този списък с ограничения ви накара да плачете, отново не сте сами. systemd е поляризираща сила в света на Linux и Googling на „systemd sucks“ ще открие много материали за четене. ��

Как да стартирате услугата автоматично, когато надолу?

Ето един доста често срещан случай на използване при внедряването. Трябва да демонизираме програма на език, който няма продължителни процеси: PHP! Да допуснем, че пиша PHP скрипт за обработка на входящи връзки в уеб сокет (в края на краищата изградихме приложение за чат!) И скриптът се поставя на /home/ankush/chat_server/index.php.

Тъй като връзките на уебсайтове могат да ударят сървъра по всяко време, този процес трябва да бъде непрекъснат и да следи входящите връзки. Тук не можем да имаме традиционния жизнен цикъл на PHP, защото WebSockets са връзки в състояние и ако скриптът умре, връзката е списък. Както и да е, достатъчно на уебсайтове; нека да видим как ще продължим да демонстрираме този скрипт чрез systemd.

Всички системни услуги пребивават в / etc / systemd / system, така че нека създадем файл там, за да опишем скрипта на нашия уебсакет. Ако приемем, че сте влезли като потребител на root.

# vi /etc/systemd/system/chat_server.service

и тогава е необходимо следното.

[Мерна единица]
Описание = Услуга за чат сървър
След = network.target

[Обслужване]
Тип = прост
Потребителят = Ankush
ExecStart = php /home/ankush/chat_server/index.php
Рестартиране = на прекъсване

[Инсталирай]
WantedBy = multi-user.target

Запишете файла и следващата стъпка е да презаредите системния демон

# systemctl презареждане на демон

и да стартираме услугата, която току-що създадохме:

# systemctl стартира chat_server

Ако не виждате грешки, това беше!

Нека също да разгледаме бързо какво означават различните директиви във файла:

  • Частта [Unit] дефинира нов сервизен блок за systemd. На езика на системата всички услуги са известни като сервизни единици.
  • Директивата After (предвидимо) казва на systemd да стартира тази услуга само след стартиране на мрежовите услуги (в противен случай, кой ще извърши по-ниското ниво на обработка на сокетните връзки ?!).
  • Типът = прост казва systemd, че тази услуга не трябва да се разклонява. С други думи, само един екземпляр ще се изпълнява в даден момент.
  • User = ankush означава, че тази услуга ще се изпълнява като потребителя „ankush“. Можем да променим това на „root“, но това е крайно не препоръчително от гледна точка на сигурността.
  • ExecStart, както можете да кажете, е действителната команда за изпълнение.
  • Restart = on-abort означава, че услугата трябва да бъде рестартирана, когато прекъсне. В PHP продължителните процеси пропускат памет и в крайна сметка се взривяват, така че това е необходимо.
  • Директивата WantedBy = казва systemd към коя цел (помислете за групи) тази услуга е част. Това води до създаване на символни връзки вътре в тази цел, за да се посочи услугата.

По принцип това е достатъчно за изпълнение на фонови процеси, използващи systemd в RHEL 7.

Още опция за логика за рестартиране

В горния пример конфигурирах Restart = on-abort, но това не е единствената опция. Има повече и изберете въз основа на изискването.

  • по-недостатъчност – ще се рестартира при нечист код за изход или сигнал
  • винаги – рестартирайте при открит, чист или нечист сигнал
  • по-анормален – нечист сигнал, пазач или изчакване
  • по-успех – само когато е спрян от чист сигнал или код за излизане

Конфигуриране на услугата да стартира при зареждане

След като сте доволни от скрипта и се уверите, че той работи, след това искате да конфигурирате, така че да се задейства при стартиране и да стартирате.

Отидете на / etc / systemd / system и изпълнете командата за активиране по-долу (не забравяйте да промените името на .service файла с това, което имате)

# systemctl активирайте chat_server.service

Ще видите потвърждение, че той е създал символна връзка.

Създадена символна връзка от /etc/systemd/system/multi-user.target.wants/chat_server.service към /etc/systemd/system/chat_server.service.

Рестартирайте вашия сървър и трябва да видите, че услугата започва при зареждане.

Това беше лесно! Не е ли така?

Помогне! Масово инвестирам в Upstart. ��

Разбрах, че ми се доверявате, вашият случай е по-скоро норма, а не изключение. RHEL използва Upstart толкова дълго, че превключвателят почти се чувства като предателство. Но ей, системите продължават да се променят и не бива да се караме за дреболии. Red Hat признава, че много хора са останали с по-стари версии и са създали a ръководство за миграция към които определено трябва да се обърнете.

Една от благодатта за спестяване във всичко това е, че systemd е съвместим със SysV init скриптове, така че в по-голямата си част просто ще трябва да преместите файловете си и да стартирате същите услуги.

Интересувате се да научите повече за администрацията и отстраняването на неизправности в Linux? Вижте това онлайн курс.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map