Phenquestions
Със своите услуги, systemd прави всичко това по-лесно, наистина по-лесно. Веднага щом искате нещо, което следи вашето приложение и лесен контрол върху него, systemd е пътят, и това е, което ще обясня тук!
Къде са Systemd Services
За да добавите нова услуга, трябва да отговорите на този въпрос. Както винаги в systemd, зависи дали услугата е само за вашия потребител или за цялата система. Ще се съсредоточим върху това как systemd работи за цели системни услуги.
Точното местоположение зависи от това защо и как е инсталирана услугата. Ако услугата е инсталирана от мениджър на пакети, тя обикновено ще бъде в / usr / lib / systemd / system. За софтуер, който разработвате или за този, който не поддържа systemd сам по себе си, ще поставите файла на услугата в / usr / local / lib / systemd / system. Моля, имайте предвид, че някои дистрибуции не поддържат тази папка в / usr / local. И накрая, ако искате да конфигурирате съществуваща systemd услуга, / etc / systemd / system е пътят.
В тези папки можете да намерите множество файлови разширения като *.гнездо, *.цел или *.обслужване. Очевидно ще се фокусираме върху последното. systemd използва името на файла като име на услугата при стартиране или спиране и т.н. Така че обикновено имената на файлове в услугата съдържат само буквено-цифрови знаци, заедно с тирета и долни черти. По време на разработката препоръчвам да го създадете във вашите документи и след това да го копирате на системно място, когато сте готови, което ще ви избегне проблеми, ако запазите в средата на редактиране.
Добре, така че, моля, създайте вашия сервизен файл във вашите документи. Сега сме готови да прегледаме как да напишем този файл.
[Забележка: Вижте потенциален доклад за грешки в раздела за коментари на този блог]
Описание = HTTP сървър на уеб приложение Penguins (работи в порт 8080)
WantedBy = многопотребителски.мишена
[Обслужване]
Тип = просто
ExecStart = / usr / bin / python3 / usr / local / bin / penguin-web-app / main.py
Рестартиране = винаги
Файловият формат всъщност е близък до ini. Знам, че може да е странно, тъй като ini файловете често се намират в Windows, но така работи. Файлът за услуга първо е разделен на 2 раздела: [Unit] и [Service]. Всеки раздел конфигурира специфичен аспект на systemd: [Unit] съдържа елементи, споделени от всички файлове на systemd unit, докато [Service] е само за конфигурация, специфична за настройване на нова услуга.
Тогава секцията се конфигурира със свойства като Description = или ExecStart =. Стойността се отделя от името на свойството със знака за равенство = без интервал.
Да се върнем към файла, показан по-горе. Той описва услуга, предназначена за стартиране на уеб приложение, написано на Python за пингвини. systemd ще го рестартира всеки път, когато процесът излезе и стартира сървъра при стартиране на сървъра, ако го активирате с командата systemctl enable. Готино а?
Но вие може би следващото ви уеб приложение не е свързано с пингвини - и това е жалко - и не е написано на Python. В този случай ще искате да научите повече за възможните конфигурации.
Свойства на Systemd Services
Нека първо се съсредоточим върху свойствата в [Unit]:
Описание = е просто да се даде ясно описание на това, което услугата прави. Показва се в списъка с услуги, регистрационните файлове на услугата, така че искате да е описателен, но трябва да остане в един ред и едно изречение.
WantedBy = позволява да се каже на systemd: когато това нещо се стартира, стартира и мен. Обикновено ще поставите името на целта. Примери за общи цели:
- многопотребителски.target: когато сървърът е наред и е готов за стартиране на приложения от командния ред
- графичен.target: когато GNOME или KDE са готови
- мрежова връзка.цел: когато сървърът е свързан правилно към мрежа
ОК за началото тези свойства на [Unit] са достатъчни. Нека да разгледаме [Service] сега.
Type = помага на systemd да разбере дали услугата работи. Ето често срещани типове:
- simple е може би най-често използваният: systemd счита процеса, който стартирате, като този, който извършва услугата. Ако процесът спре, той счита, че услугата също е спряна и т.н.
- forking се предпочита за приложения, които са написани като сървър, но без помощта на система за управление на услуги. По принцип той очаква стартираният процес да се форкира и този форк се счита за финален процес за услугата. За да бъдете по-точни, можете също да помогнете на systemd с PID файл, където PID на процеса за проследяване се записва от стартиралото приложение.
ExecStart = е може би най-важният за дадена услуга: той уточнява какво приложение да стартира при стартиране на услугата. Както можете да видите в услугата Penguin, използвах / usr / bin / python3, а не python3 веднага. Това е така, защото системната документация изрично препоръчва да се използват абсолютни пътеки, за да се избегнат изненади.
Но това е и по друга причина. Системата за управление на други услуги обикновено се основава на скриптове на Shell. Въпреки това systemd, поради причини за производителност, не изпълнява черупка по подразбиране. Така че не можете да предоставите директно команда на черупката в ExecStart =. Все пак можете да използвате скрипт на обвивка, като направите:
ExecStart = / usr / bin / bash / usr / local / bin / launch-penguin-server.шНе е толкова трудно, нали? Имайте предвид, че ако трябва да стартирате някакъв процес, за да сигнализирате, че вашата услуга спира чисто, ExecStop = съществува, както и ExecReload = за презареждане на услуги.
Restart = ви позволява изрично да кажете кога услугата трябва да бъде рестартирана. Това е една от важните характеристики на systemd: тя гарантира, че услугата ви остава постоянна, докато желаете, така че обръщайте голямо внимание на тази опция.
| Рестартиране = | Значение |
| винаги | systemd ще продължи да го рестартира, когато прекрати или се срине. Е, докато не направите systemctl спрете име на услуга.обслужване. Той е идеален за сървъри и онлайн услуги, тъй като предпочитате няколко безполезни рестартирания, отколкото ръчно рестартиране на услугата без никаква причина. |
| на-ненормално | Когато процесът на услугата се срине, рестартирайте услугата. Ако обаче приложението излезе чисто, не го рестартирайте. Това е по-полезно за cron-работни места като услуги, които трябва да изпълняват задача надеждно, но не трябва да се изпълняват през цялото време. |
| при неуспех | Подобно на on-abnormal, но също така рестартира услугата, когато приложението излезе чисто, но с ненулев код за изход. Ненулевите кодове за изход обикновено означават грешка. |
| не | systemd няма да рестартира услугата автоматично. Обикновено полезно за получаване на достъп до други системни функции, като регистриране без функцията за рестартиране. |
WorkingDirectory = може да наложи работеща директория при стартиране на вашето приложение. Стойността трябва да е абсолютен път на директорията. Работната директория се използва, когато използвате относителни пътища в кода на вашето приложение. За нашата услуга за пингвини това може да бъде:
WorkingDirectory = / srv / penguin-web-app /Тогава сигурността е важна, така че обикновено искате да не стартирате услугата си с root права. User = и Group = ви позволява да зададете името на потребителя или групата или UID / GID, под които вашето приложение ще бъде стартирано. Например:
Потребител = пингвин-мрежаГрупа = пингвин-мрежа
EnvironmentFile = е мощен вариант. Приложенията, изпълнявани като услуги, често се нуждаят от конфигурация и файловете на околната среда позволяват да зададете тази конфигурация по два начина:
- Приложението може да чете директно променливата на околната среда.
- Но също така можете да зададете различни аргументи на командния ред на вашето приложение, без да променяте файла на услугата.
Синтаксисът на този файл е прост: въвеждате името на променливата на средата, знакът за равенство = и след това нейната стойност. След това поставяте абсолютния път на файла на вашата среда в свойството EnvironmentFile.
Така че пример:
EnvironmentFile = / etc / penguin-web-app / environmentИ файлът / etc / penguin-web-app / environment съдържа:
LISTEN_PORT = 8080Тогава нашето уеб приложение за пингвини ще има достъп до променливата на средата LISTEN_PORT и ще слуша очаквания порт.
Запазете и стартирайте новосъздадената Systemd услуга
Така че, ако последвахте съвета ми, редактирахте вашия файл с услуги в домашната си директория. След като сте доволни, копирайте този файл в / usr / local / lib / systemd / system, като приемете, че вашата дистрибуция поддържа този път. Името на файла на вашия сервизен файл ще бъде неговото име на услуга. Това име на файл трябва да завършва с .обслужване. Например за нашия сървър за пингвини това би било приложението за пингвини в мрежата.обслужване.
След това трябва да кажете на systemd, че сте добавили нова услуга, така че трябва да въведете тази команда:
$ sudo systemctl daemon-reloadДобре сега, systemd е наясно с новата ви услуга, ако приемем, че файлът ви не съдържа синтаксисна грешка. В крайна сметка това е първият ви файл, така че вероятно ще направите грешки. Трябва да изпълните тази команда по-горе при всяка актуализация във вашия сервизен файл.
Сега е време да стартирате услугата:
$ sudo systemctl стартирайте приложението за пингвини.обслужванеАко не успее с грешка Unit not found като тази:
$ sudo systemctl стартирайте приложението за пингвини.обслужванеСтартирането на уеб приложението на пингвин не бе успешно.услуга: Единицата не е намерена.
Това означава, че вашата дистрибуция не поддържа директорията или не сте посочили правилно вашия файл с услуги. Не забравяйте да проверите.
Ако настроите услугата си с WantedBy = и искате услугата ви да стартира автоматично, трябва да я активирате с тази команда:
$ sudo systemctl активира приложението на пингвин-уеб.обслужванеГотиното с услугата е, че тя работи във фонов режим. Проблемът: как да разберете дали тя работи правилно и дали тя работи във фонов режим? Не се притеснявайте, системният екип помисли и за това и предостави команда, за да види дали работи правилно, от колко време и т.н.:
$ systemctl статус penguin-web-app.обслужванеЗаключение
поздравления! Вече можете да управлявате приложенията си, без да се грижите всеки път да го рестартирате ръчно. Сега ви препоръчвам да прочетете другата ни статия за системните регистрационни файлове: Master journalctl: разбирайте системните регистрационни файлове. С това можете да използвате мощната система за регистриране на новата си услуга и да изградите по-надеждни сървъри!
