Работа с systemctl edit — переопределение systemd unit без изменения оригинального файла!

Многие администраторы и разработчики до сих пор изменяют unit-файлы напрямую в:

/usr/lib/systemd/system/

или:

/lib/systemd/system/

Но это vendor unit-файлы, устанавливаемые пакетным менеджером. После обновления пакета изменения могут быть перезаписаны.

Правильный способ настройки сервисов в systemd — использовать override-конфигурации через:

systemctl edit

Например, добавим переменные окружения для nginx:

sudo systemctl edit nginx.service

После сохранения systemd создаст файл:

/etc/systemd/system/nginx.service.d/override.conf

Это безопасный способ переопределения параметров сервиса без изменения оригинального unit-файла.

Пример добавления переменных окружения:

[Service]
Environment="APP_ENV=production"
Environment="WORKERS=4"

После сохранения systemctl edit обычно автоматически выполняет daemon-reload, поэтому достаточно просто перезапустить сервис:

sudo systemctl restart nginx

Если unit-файлы или override-конфигурации изменялись вручную в /etc/systemd/system/, тогда дополнительно выполняют:

sudo systemctl daemon-reload

Проверить итоговую конфигурацию сервиса можно так:

systemctl cat nginx.service

Команда покажет: оригинальный unit-файл, все override-конфигурации, порядок применения настроек.

А для просмотра итоговых параметров сервиса полезно использовать:

systemctl show nginx.service

Это особенно полезно при диагностике сложных production-конфигураций.

Переопределение ExecStart, один из важных нюансов systemd — перед новым ExecStart старое значение нужно очистить. Пример:

sudo systemctl edit app.service

Override:

[Service]
ExecStart=
ExecStart=/usr/local/bin/app --port 8080

Пустой ExecStart= сбрасывает предыдущее значение из исходного unit-файла. Без очистки systemd может выдать ошибку, поскольку для сервисов с типом, отличным от Type=oneshot, допускается только один ExecStart.

Автоматический перезапуск сервиса. Для production-сервисов часто настраивают автоматический перезапуск:

[Service]
Restart=on-failure
RestartSec=5

Так systemd будет автоматически перезапускать сервис только при ошибках, а не после штатной остановки.

Systemd умеет ограничивать ресурсы процессов через cgroup. Пример ограничения памяти:

[Service]
MemoryMax=1G

Это особенно полезно для Node.js, Python, Java и других серверных приложений с непредсказуемым потреблением памяти.

Иногда требуется изменить почти весь unit-файл. Для этого используется:

sudo systemctl edit --full app.service

В этом режиме systemd создаёт полный локальный unit-файл в:

/etc/systemd/system/

который заменяет оригинальный unit из пакета.

Но использовать --full стоит осторожно — после этого вы фактически берёте поддержку unit-файла на себя и можете пропустить изменения из новых версий пакета.

Практический пример настройки сервиса:

[Service]
Environment="NODE_ENV=production"
WorkingDirectory=/srv/app
ExecStart=
ExecStart=/usr/bin/node /srv/app/server.js
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
MemoryMax=1G

Так часто настраивают production-сервисы для Node.js, Go, Python, Java и других серверных приложений.

Дополнительно полезно знать:

systemctl show app.service -p FragmentPath -p DropInPaths

Команда покажет: путь к основному unit-файлу, все подключённые override-конфигурации.

🔥 Это стандартный и рекомендуемый способ настройки systemd без риска потерять изменения после обновления системы.

🚪 Linux Ready | #практика

🐱 Awesome Sysadmin — огромная база инструментов для Linux и DevOps!

В этом репозитории собраны open-source инструменты для системного администрирования: мониторинг, логирование, backup, docker, kubernetes, безопасность, networking, автоматизация и всё, что нужно для работы с серверами и инфраструктурой. По сути это готовая база полезного софта для сисадминов, DevOps и backend-разработчиков.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Слышали, что Bash умеет выводить set -x не в терминал, а в отдельный log-файл?

Обычно при debugging shell-скриптов используют set -x, но весь trace смешивается с обычным stdout/stderr и быстро делает вывод неудобным для чтения.

В Bash существует специальная переменная BASH_XTRACEFD, которая перенаправляет xtrace в отдельный файловый дескриптор:

$ exec {FD}>>debug.log
$ export BASH_XTRACEFD=$FD

Теперь debugging не ломает основной вывод программы:

$ bash -x ./deploy.sh

Все trace-команды уходят только в debug.log, а stdout/stderr продолжают работать как обычно.

Это особенно полезно в автоматизации, CI/CD, deploy-скриптах, где важно сохранить чистый вывод программы, но при этом иметь полную трассировку выполнения для отладки.

После завершения debugging дескриптор корректно закрывается:

$ set +x
$ exec {FD}>&-

🔥 Механизм работает внутри Bash и использует обычные файловые дескрипторы оболочки без внешних утилит.

🚪 Linux Ready | #совет

❤️ Крутая статья попалась на Хабре: Разбираем хаос в Linux-логах: journald, rsyslog и файлы!

В этой статье:
• Объясняется, как устроена система логирования в Linux;
• Разбираются различия между journald, rsyslog, syslog и классическими файлами логов;
• Показывается, как правильно настраивать логирование для PostgreSQL, Redis, Nginx, Kafka, HAProxy и др.;
• Объясняется, откуда появляются дубли логов, лишняя нагрузка на диск и проблемы с ротацией;

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

✍️ CommandLineFu — полезные команды для Linux и Unix!

Удобный каталог команд для Linux, Unix и macOS, где собраны готовые решения на Bash для самых разных задач: работа с файлами, сетью, процессами, логами, безопасностью и администрированием серверов. Каждая команда сопровождается пояснением.

📌 Оставляю ссылочку: commandlinefu.com

🚪 Linux Ready | #сайт

В Linux можно безопасно перезаписывать файл результатом команды, которая этот же файл читает!

Многие хотя бы раз пытались сделать что-то вроде:

$ sort users.txt > users.txt

И получали пустой файл.

Проблема в том, что shell открывает файл на запись ещё до запуска sort, поэтому содержимое уничтожается раньше, чем команда успевает его прочитать.

Для таких случаев существует sponge из пакета moreutils:

$ sort users.txt | sponge users.txt

Сначала sponge полностью считывает входной поток в память, а затем открывает файл и записывает результат.

Точно так же можно фильтровать логи или конфигурации без временных файлов:

$ grep -v debug app.log | sponge app.log

Или выполнять цепочки преобразований над одним и тем же файлом:

$ sed 's/localhost/db.local/' config.ini | sponge config.ini

🔥 Это позволяет безопасно изменять файл, не создавая временные копии и не рискуя случайно потерять данные.

🚪 Linux Ready | #совет

📂 Напоминалка по Bash-скриптам!

Например, set -euo pipefail помогает избежать многих ошибок в скриптах, а trap позволяет корректно обрабатывать сигналы и выполнять очистку перед завершением программы.

На картинке — основные конструкции Bash: переменные, условия, циклы, функции, массивы, работа с файлами, аргументы командной строки, перенаправление потоков, обработка сигналов и другое.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Работа с ss — замена netstat для диагностики сетевых подключений!

Во многих руководствах до сих пор встречается:

netstat

Но в большинстве современных Linux-дистрибутивов рекомендуется использовать:

ss

Утилита входит в пакет iproute2, работает быстрее и получает информацию через интерфейсы ядра Linux без необходимости парсинга большого объёма данных из /proc.

Посмотреть TCP-сокеты:

ss -t

Посмотреть все TCP-соединения в числовом виде:

ss -tan

Посмотреть прослушивающие TCP-сокеты и UDP-сокеты:

ss -tuln

Если нужно увидеть процессы, которым принадлежат сокеты:

ss -tulpn

Вывод покажет адреса прослушивания, порты, PID и имя процесса.

Частая задача — выяснить, кто занимает конкретный порт. Например, проверить порт 8080:

ss -ltnp '( sport = :8080 )'

Либо отфильтровать сокеты, прослушивающие порт 443:

ss -ltnp '( sport = :443 )'

При диагностике веб-серверов полезно смотреть количество установленных соединений. Например:

ss -tan

Состояния соединений отображаются в первом столбце, например:

LISTEN
ESTAB
TIME-WAIT
CLOSE-WAIT
SYN-RECV

Подсчитать количество активных соединений:

ss -Htan state established | wc -l

Это помогает быстро оценить текущую нагрузку на сервис.

Для анализа SSH-подключений:

ss -tn '( sport = :22 )'

Либо так:

ss -tn '( dport = :22 )'

В зависимости от того, анализируется сервер или клиент.

Посмотреть только сокеты в состоянии LISTEN:

ss -ltn

Так можно быстро проверить, действительно ли приложение слушает нужный порт.

Например, после запуска сервиса:

ss -ltnp | grep 3000

Для диагностики проблем с соединениями полезно смотреть сокеты в ожидании закрытия:

ss -tan state close-wait

Большое количество CLOSE-WAIT часто указывает на ошибки в приложении, которое некорректно закрывает соединения.

Показать общую статистику по протоколам:

ss -s

Например:

TCP: 523 established
UDP: 42
INET: 610

Конкретные значения будут зависеть от текущего состояния системы. Команда позволяет быстро оценить сетевую активность системы.

Практический пример диагностики недоступного веб-приложения. Сначала проверяем, слушает ли процесс порт:

ss -ltnp '( sport = :8080 )'

Затем смотрим активные подключения:

ss -tan '( sport = :8080 )'

Если подключений нет — проблема может быть в балансировщике, firewall или DNS.

Если подключения есть, но много соединений находится в состоянии:

SYN-RECV

Стоит проверить сетевую доступность, настройки фильтрации трафика и работу балансировщика.

Дополнительно полезно знать:

ss -i

Команда выводит расширенную информацию о TCP-соединениях: RTT, размер окна, retransmits и другие параметры, которые часто используются при анализе сетевых проблем.

🔥 ss — один из основных инструментов диагностики сети в современных Linux-системах и в большинстве случаев является предпочтительной заменой netstat благодаря более высокой скорости работы и расширенным возможностям фильтрации.

🚪 Linux Ready | #практика

😍 Linux Cheat — полезнейший репозиторий для изучения Linux!

В этом репозитории подробно разбирается внутреннее устройство Linux: процессы, память, системные вызовы, ELF и работа системы на низком уровне. Материал построен на практических примерах за счёт чего сложные темы намного проще понять. Хорошо подойдёт разработчикам, DevOps и тем, кто хочет лучше понимать, как Linux работает под капотом.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Знали, что Bash умеет генерировать десятки путей и аргументов ещё до запуска команды?

Большинство используют циклы или копируют похожие команды несколько раз, хотя Bash умеет делать это самостоятельно.

Например, нужно быстро создать структуру нового проекта:

$ mkdir -p project/{src,tests,docs}

Shell автоматически развернёт команду в несколько аргументов ещё до запуска mkdir.

Точно так же удобно создавать резервные копии:

$ cp app.{conf,conf.bak}

Фактически Bash выполнит:

$ cp app.conf app.conf.bak

Можно работать сразу с несколькими каталогами:

$ echo /var/log/{nginx,apache2,redis}/*.log

Команда мгновенно превратится в набор путей для всех указанных директорий.

Поддерживаются и диапазоны:

$ touch file{1..10}.txt

В результате будут созданы файлы от file1.txt до file10.txt без единого цикла.

🔥 Brace expansion выполняется внутри Bash ещё до запуска программы, поэтому работает быстрее и чище, чем дополнительные shell-конструкции.

🚪 Linux Ready | #совет

❤️ Шпаргалка по Linux-командам — быстрый справочник для работы в терминале!

Удобная шпаргалка, в которой собраны команды для повседневной работы. Здесь можно быстро найти команды для навигации по файловой системе, управления файлами и каталогами, работы с процессами, пользователями, сетью и правами доступа. Материал отлично подойдёт как новичкам, которые только знакомятся с Linux, так и разработчикам, которым нужен быстрый справочник.

📌 Оставляю ссылочку: unlix.ru

🚪 Linux Ready | #сайт

Большинство задач на удалённом сервере можно выполнять без входа по SSH!

Многие подключаются к серверу, выполняют одну команду, выходят, затем подключаются снова.

На самом деле SSH умеет запускать команды напрямую:

$ ssh user@server 'journalctl -n 1000'

Результат сразу приходит в локальный терминал без интерактивной сессии.

Можно передавать данные через обычные каналы Linux:

$ ssh user@server 'mysqldump db' > dump.sql

Дамп базы окажется на локальной машине, при этом временный файл на сервере не создаётся.

Можно копировать целые каталоги потоково:

$ ssh user@server 'tar czf - /var/log' | tar xzf -

Архив никогда не записывается на диск сервера и сразу распаковывается локально.

🔥 Такой подход удобно использовать в скриптах, автоматизации, резервном копировании и диагностике. Часто оказывается, что для выполнения задачи полноценная SSH-сессия вообще не нужна.

🚪 Linux Ready | #совет

📂 Напоминалка по Pipes в Linux!

Pipes позволяют процессам обмениваться данными напрямую: вывод одной программы становится входом для другой. Именно благодаря этому работают привычные конвейеры команд через символ |.

На картинке показаны анонимные и именованные каналы (FIFO), схема их работы, примеры создания и основные команды для использования.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

✍️ Шпаргалка по Linux-командам — полезный справочник для работы с Linux!

На сайте собрана удобная шпаргалка по основным Linux-командам, которая помогает быстро находить нужные команды для повседневной работы. Здесь есть всё необходимое: навигация по файловой системе, управление файлами и каталогами, работа с процессами, сетью, пользователями и правами доступа.

📌 Оставляю ссылочку: wiki.planetahost.ru

🚪 Linux Ready | #сайт