Управление на процеси и услуги
(systemd)

1. Как мисля за процесите

В началото, когато за първи път видях ps aux, ми се струваше, че гледам безмислен списък. Днес знам, че това е картата на живота на системата. Процесите са като влаковете в гарата – някои идват, други си отиват, но винаги има такива, които трябва да работят безспирно.

systemd е мениджърът на тази гара в повечето съвременни дистрибуции. Той не просто стартира и спира услуги – той следи зависимостите, управлява логовете и може да рестартира паднал процес. Ако не разбираш systemd, не разбираш как сървърът ти оцелява.

2. Команди, които използвам всеки ден

Няма да ти давам списък с всички опции на systemctl. Ще ти покажа тези, които наистина ми трябват в практиката.

# Проверка на състоянието на услуга
systemctl status nginx

# Стартиране на услуга
sudo systemctl start nginx

# Спиране на услуга
sudo systemctl stop nginx

# Рестартиране на услуга
sudo systemctl restart nginx

# Зареждане на конфигурацията без рестарт
sudo systemctl reload nginx

# Включване на услугата при старт
sudo systemctl enable nginx

# Изключване на услугата при старт
sudo systemctl disable nginx

3. Логове с journalctl

Преди systemd логовете бяха разпръснати из /var/log в различни файлове. Сега всичко е събрано в journal – и това ми спестява часове. journalctl е най-добрият ми приятел, когато нещо се обърка.

# Всички логове на системата
journalctl

# Логове на конкретна услуга
journalctl -u nginx

# Логове от последния час
journalctl --since "1 hour ago"

# Следене на логове в реално време
journalctl -u nginx -f

# Логове с приоритет "error"
journalctl -p err

4. Създаване на собствена услуга

Когато трябва да стартирам свой скрипт или приложение като услуга, не го пускам просто в cron или в screen. Пиша unit файл за systemd. Това ми дава контрол, логове и възможност за автоматично рестартиране.

[Unit]
Description=Моето приложение
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/python3 app.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

5. Анализ на зависимости и таймери

Едно от най-ценните неща в systemd е възможността да дефинираш зависимости. Можеш да кажеш: "Стартирай услугата X, но само след като Y е стартирана". Това избягва хаоса при стартиране на сървъра.

[Unit]
Description=Услуга, която зависи от мрежата и базата
After=network.target postgresql.service
Requires=postgresql.service

[Service]
ExecStart=/usr/local/bin/myapp
Restart=always

[Install]
WantedBy=multi-user.target

Освен това, systemd може да замести cron с таймери. Те са по-гъвкави и логовете им са интегрирани в journal-а.

[Unit]
Description=Ежедневен бекъп

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

6. Какво да правя, когато услугата не стартира

Най-честата причина услуга да не стартира е грешка в конфигурацията, липсващ файл или зает порт. Моят подход е систематичен.

1. Проверявам статуса: systemctl status myapp – там често пише каква е грешката.
2. Гледам логовете: journalctl -u myapp -n 50 – последните 50 реда.
3. Проверявам дали портът е свободен: ss -tulpn | grep 8080.
4. Проверявам правата на файловете: ls -la /var/www/myapp.
5. Опитвам да стартирам ръчно ExecStart-а: за да видя грешката в терминала.

7. Изолация на процеси с Control Groups (cgroups)

Модерните systemd услуги могат да бъдат ограничавани по ресурси – памет, CPU, I/O. Това е особено полезно, когато имаш уеб приложение, което може да изяде всички ресурси на сървъра.

[Service]
MemoryMax=512M
CPUQuota=50%
TasksMax=20

С тези настройки услугата няма да може да използва повече от 512 MB RAM или повече от 50% от процесорното време. Това защитава останалите процеси на сървъра.

8. Маскиране на услуги – когато не искаш да стартират

Понякога искаш да предотвратиш стартирането на услуга – например, когато вече не я използваш, но някой друг пакет я изисква. mask прави услугата напълно неактивна – дори ръчен start няма да работи.

# Маскиране на услуга
sudo systemctl mask cups

# Връщане на услугата
sudo systemctl unmask cups

9. Моят план при авария с услуга

Когато услуга на продукционен сървър спре, нямам време за експерименти. Следвам си стъпките, които съм изградил с години.

1. Проверявам дали услугата работи: systemctl status service.
2. Гледам логовете: journalctl -u service -n 100.
3. Проверявам ресурсите: top, df -h, free -h.
4. Проверявам мрежата и портовете: ss -tulpn.
5. Ако е нужно, рестартирам услугата: systemctl restart service.
6. Ако не помогне, проверявам конфигурацията и правата.

10. Съвети от моята практика

• Пиши собствени unit файлове – те дават контрол и преносимост.
• Използвай systemctl edit – този инструмент създава отделен файл с промените, без да променя оригиналния unit файл. Това улеснява ъпдейтите.
• Проверявай зависимостите – systemctl list-dependencies ти показва какво ще бъде стартирано заедно с услугата.
• Не спирай услуги с kill -9 – използвай systemctl stop, за да дадеш шанс на приложението да освободи ресурсите си.

Заключение

systemd е повече от инструмент – той е основата на модерното Linux управление. Разбирането му не е опция, а необходимост за всеки, който поддържа сървъри. В тази статия споделих моята практическа гледна точка – как използвам systemd в реални ситуации, а не само по учебник.

В следващата част ще се потопим в мрежовите конфигурации – от статични IP-та до мостове и VLAN-и. Там също има много капани, които съм учил на практика.