Сколько раз вы задавались «простым» вопросом: а почему же этот сервис снова не стартует при перезагрузке? Или ловили top, уверенный, что процесс-пожиратель памяти вот-вот появится в списке — а он словно включает плащ-невидимку? Давайте разберёмся, как взять под контроль службы и процессы так, чтобы серверы работали, а нервы оставались целыми.
Зачем вообще заботиться о службах и процессах?
Службы (они же «units» или «демоны») и процессы — это моторы операционной системы. Если моторы глохнут, корабль не плывёт. А если они без спроса крутятся на холостых, — съедают топливо и расчёты бюджета на хостинг. Управлять ими — значит управлять ресурсами, безопасностью и отказоустойчивостью своего проекта.
- Снижение расхода CPU и RAM (экономия денег в облаке).
- Повышение безопасности: меньше работающих служб — меньше атакуемая поверхность.
- Чёткая картина, что происходит на сервере: проще искать «утечки».
systemd и systemctl: ваш персональный пульт управления службами
systemd — это не просто «тот самый процесс с PID 1», а целая экосистема, которая стартует всё остальное, ведёт логи, следит за зависимостями и перезапускает упавшее. А systemctl — своёобразный пульт ДУ. Давайте жать кнопки.
Запуск и остановка
Запустить службу в ручном режиме проще простого:
systemctl start nginx.
Остановить? Аналогично: systemctl stop nginx.
По сути, вы отдаёте приказ systemd «двинуть рычаг питания» для указанного unit-файла.
Автозагрузка: включаем и выключаем
Чтобы сервис стартовал при каждой перезагрузке, дайте команду systemctl enable nginx. Для полного отключения автозапуска — systemctl disable nginx. Кстати, enable не запускает сервис прямо сейчас, а лишь создаёт символическую ссылку в каталоге /etc/systemd/system/.
Перезапуск без паники
Когда вы обновили конфиг и нужно перезагрузить службу без долгого «шатауна», используйте systemctl reload nginx. Не помогло — systemctl restart nginx, что равносильно «выключили-включили». Перезапуск — это Ctrl+Alt+Del, но для одного демона.
Что внутри unit-файла?
Unit-файл — простой текст в .ini-стиле. Пример:
- [Unit] — описание и зависимости.
- [Service] — что запускать, как рестартовать, где логировать.
- [Install] — в каких «runlevel» активировать.
Открыть можно привычным cat /lib/systemd/system/nginx.service. Не бойтесь — чтение unit-файлов не вызывает головной боли, в отличие от JSON-конфигов с фигурными скобками на пол-экрана.
ps: моментальный снимок процесса в его естественной среде
Иногда нужен «скриншот» списка процессов здесь и сейчас — без анимации и подмигивания. Встречайте ps.
Классический приём: ps aux
Команда ps aux выводит абсолютно всё: процессы любого пользователя (а — all), u — детальный формат, x — включая фоновые без терминала. Получается длинная простыня, но зато полная. Лайфхак: добавьте | grep nginx, чтобы не искать глазами.
Полезные фильтры
- ps -ef — альтернативный BSD-формату вывод: чуть больше полей, ключ SSID (Session ID), тот же | grep.
- ps -eo pid,cmd,%mem,%cpu — строим свой кастомный «отчёт».
- ps --sort=-%mem -eo pid,cmd,%mem | head — топ «пожирателей» памяти за одну строку.
top и друзья: реальный тайм-трекер загрузки сервера
top — как кардиомонитор: моргает строчками, показывает, что живо, что притворяется. Запускаете простым top и сразу видите проценты CPU, нагрузку на ядра, swap, любителей OOM-киллера.
Навигация без мыши
- h — подсказка; можно не гуглить каждый раз.
- k — «убить» процесс, указав PID и сигнал (по умолчанию 15).
- r — изменить nice, если процесс ведёт себя нагло.
- M — сортировка по памяти, P — по CPU.
- q — выход, когда нагляделись.
Почему все хвалят htop?
htop — тот же top, но с повышенным UX: цветные полоски, мышиный щелчок, горизонтальное дерево процессов. Установить в Debian-based можно командой apt install htop. Мораль: визуальные плюшки мотивируют мониторить чаще.
Комбо-техники: системный детектив в действии
Допустим, сервис myapp внезапно падает. План действий:
- systemctl status myapp — смотрим последний код возврата.
- journalctl -u myapp — читаем лог. journalctl — библиотека сплетен systemd.
- Видим PID, проверяем ps -p PID -o pid,cmd,%cpu,%mem.
- Если память улетела, открываем top, сортируем M, наблюдаем пиковые значения.
- Меняем конфиг (лимиты, worker-processes), сохраняем, перезапускаем: systemctl restart myapp.
В 90 % случаев связка systemctl + journalctl + top находит корень зла быстрее, чем детальный strace. А в оставшиеся 10 % — да, придётся доставать тяжелую артиллерию ( bpftrace и друзья).
Автоматизация: скрипты, таймеры и немного магии
Каждый админ хотя бы раз писал «гробовый» cron-скрипт check_nginx.sh, который раз в минуту вызывает ps и запускает Nginx, если тот умер. Современный способ — systemd timer. Создаёте myapp.service плюс myapp.timer — и получаете регулярный запуск без костылей. Официальный вики-гайд расскажет все подробности.
Советы по безопасности и здоровью системы
- Не спешите посылать kill -9. Сначала попытайтесь SIGTERM = 15. systemd автоматом отправит SIGKILL, если приложение игнорирует вежливую просьбу.
- Ограничьте ресурсы Unit-файлом: MemoryLimit=512M, CPUShares=1024. Так вы заранее ставите «потолок».
- Используйте ProtectSystem=strict и PrivateTmp=true — это минимизирует ущерб, если сервис скомпрометируют.
- По возможности запускайте сетевые демоны под отдельным пользователем (параметр User= в unit-файле).
Выводы: меньше паники — больше контроля
Управление службами и процессами — не таинственная алхимия, а набор привычек: проверяйте статус systemctl, делайте «снимки» ps, наблюдайте сердечный ритм top. Вскоре логика всех этих утилит складывается как пазл — и вы без труда объясните коллеге, почему «сервер медлит», вместо того чтобы нервно перезапускать его целиком.
Берегите uptime и не бойтесь экспериментировать: Linux простит, а опыт обязательно пригодится.
