Шпаргалка по ufw для базовой настройки фаервола

Сетевой безопасностью часто пренебрегают при создании своих проектов на своем сервере. Но даже базовая настройка фаервола уже существенно снижает риски.

ufw (Uncomplicated Firewall) - простой способ настроить фаервол на Linux. Работает как обёртка над iptables, но не требует глубоких знаний сетевого стека.

Зачем вообще нужен фаервол?

Когда ты поднимаешь сервер (особенно публичный), он сразу становится видимым всему интернету. И даже если ты не настраиваешь ничего «опасного», какие-то сервисы по умолчанию могут слушать порты.

ufw помогает ограничить доступ: только те порты, которые ты явно разрешил - будут открыты. Если ты только поднял VPS и хочешь защитить сервер - это именно то, что нужно. Если по какой-то причине у тебя ufw не установлен:

$ sudo apt install ufw

Перед включением стоит задать основные правила, иначе можно случайно отрезать себя от SSH-доступа (особенно на VPS). Начнем с самого важного:

$ sudo ufw allow ssh

Теперь можно активировать фаервол:

$ sudo ufw enable

Просмотр статуса и активных правил:

$ sudo ufw status verbose

Отключение при необходимости:

$ sudo ufw disable

Базовые правила, которые стоить задать

Одно правило по разрешению ssh-доступа мы уже добавили, также будет правильно разрешить веб-траффик (http/https):

$ sudo ufw allow 80,443/tcp

Полезно запретить весь входящий трафик по умолчанию и разрешить только нужное. Также оставить открытым все на выход:

$ sudo ufw default deny incoming

$ sudo ufw default allow outgoing

Полезные команды:

Удалить правило:

$ sudo ufw delete allow 80/tcp

Разрешить доступ по конкретному IP:

$ sudo ufw allow from 192.168.1.10

Это может понадобиться, например, чтобы открыть порты для веб-траффика только Cloudflare или ServicePipe и закрыть для всего остального:

$ ufw default deny incoming
$ ufw default allow outgoing

# пердположим что 192.168.1.10 - IP нашего ServicePipe
$ sudo ufw allow from 192.168.1.10 to any port 22

Сбросить все правила и начать с нуля:

$ sudo ufw reset

После настройки рекомендую протестировать сервер из другого устройства или использовать онлайн-сервисы вроде portquiz или nmap для сканирования портов. Также полезно мониторить логи:

$ sudo less /var/log/ufw.log

Если ufw работает - ты увидишь записи о заблокированных соединениях, особенно на нестандартные порты. Даже минимальные настройки ufw — это уже огромный шаг вперёд в безопасности. Он не требует глубокого понимания iptables и легко вписывается в ежедневный рабочий процесс. Один раз настроил — и забыл.

LinuxCamp | #utils #devops

Почему docker compose logs -f спасает на проде

Когда что-то ломается в проде — время идёт на секунды. Не всегда есть доступ к графическому лог-серверу, и не всегда хочется копаться в docker exec, чтобы что-то вытащить. В таких случаях спасает простая команда:

docker compose logs -f

Она показывает живые логи сразу всех сервисов которые описаны в docker-compose.yml в данной директории.

В какой ситуации это может быть мастхев? Допустим что-то не стартует. Можно сделать быстрый дебаг ошибок конкретного сервиса:

docker compose logs -f backend

И ты моментально видишь stack trace, ошибку подключения к БД или криво прокинутую переменную. Кроме этого можно следить за цепочкой событий. Если сервисы завязаны друг на друге удобно запускать:

docker compose logs -f

И ты видишь весь «разговор» между фронтом, беком и базой, в одном терминале. Полезный флаг для просмотра логов:

docker compose logs -n 50 -f

"-n" - помогает просмотреть только последние N строк. Нужная и простая команда в арсенале, может спасти в самый ответственный момент.

LinuxCamp | #utils

ncdu — лучший способ быстро очистить место на сервере

Когда на сервере внезапно заканчивается место, первое, что хочется — понять, что его съело. Вместо того, чтобы долго ковыряться в du и find, просто поставь ncdu.

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

$ sudo apt install ncdu

Для сканирования нужно просто ввести команду и передать целевой каталог. Чтобы промониторить корень:

$ sudo ncdu /

Нужные кнопочки:

Навигация - стрелками вверх/вниз.
Удаление - клавиша d.
Обновить - g.
Выйти - q.

В отличие от "du -sh *", ncdu не только показывает вес директорий, но и позволяет разобраться в них быстрее. Особенно полезно, если забит логами /var/log, кто-то накатил 100500 .tar.gz или забыли почистить кэш в home. Утилита очень выручает, когда каждая секунда важна. Установил - посмотрел - удалил - освободил.

LinuxCamp | #utils

Базовая настройка Nginx и подключение домена: как я это сделал

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

Шаг 1: Покупка домена

Я купил домен на reg.ru - обычная регистрация, ничего необычного, правда с верификацией по паспорту. После покупки нужно было настроить DNS-записи, чтобы домен знал, на какой сервер ему "смотреть".

Шаг 2: Настройка DNS

В панели управления reg.ru я прописал A-записи для поддоменов. Примерно через 5–10 минут домен уже начал резолвиться (хотя может и сильно дольше):

@ → IP моего сервера
www → тот же IP

Шаг 3: Установка Nginx

На сервере я поставил Nginx:

$ sudo apt install nginx -y

Шаг 4: Bash-скрипт для настройки проксирования

Чтобы не ковыряться руками в /etc/nginx/sites-available, я написал простой скрипт, который:

1) Создаёт конфиг для твоего домена
2) Проксирует запросы на нужный порт
3) Автоматически подключает SSL через certbot (сертификат безопасности, то самое "s" в https)

Запрашиваем данные, вводим домен и порт приложения, на который будет проксироваться nginx:

#!/bin/bash
read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

Задаем стандартные директории для конфигов и логов Nginx:

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

Создаём папку для логов:

$ sudo mkdir -p "$LOGS_DIR"

Генерируем конфиг:

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
    listen 80;
    server_name $DOMAIN;
    location / {
        proxy_pass http://127.0.0.1:$PORT;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
    }
    error_log $LOGS_DIR/error.log;
    access_log $LOGS_DIR/access.log;
}
EOF

Включаем сайт

$ sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

Проверка и перезапуск:

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

Получаем SSL-сертификаты:

$ sudo certbot --nginx -d "$DOMAIN"

Финальная проверка и reload

if sudo nginx -t; then
    sudo systemctl reload nginx
else
    exit 1
fi

SSL-сертификаты от Let's Encrypt. Certbot сам всё сделал: прописал listen 443 ssl и нужные директивы, плюс настроил редирект с HTTP на HTTPS. Если хочешь, можешь вручную добавить в конфиг ssl_protocols, ssl_ciphers, HSTS и другие фишки безопасности, но базовая настройка уже работает.

В итоге после запуска скрипта твой сайт по HTTPS работает на нужном порту, все логи идут в /var/log/nginx/имя_домена/, и весь трафик проксируется на нужное приложение. Готовый скрипт:

#!/bin/bash

read -p "Домен: (например, example.ru)" DOMAIN
read -p "Порт (например, 9003): " PORT

SITES_AVAILABLE="/etc/nginx/sites-available"
SITES_ENABLED="/etc/nginx/sites-enabled"
CONF_FILE="$SITES_AVAILABLE/$DOMAIN"
LOGS_DIR="/var/log/nginx/$DOMAIN"

sudo mkdir -p "$LOGS_DIR"

sudo tee "$CONF_FILE" > /dev/null <<EOF
server {
listen 80;
server_name $DOMAIN;
location / {
proxy_pass http://127.0.0.1:$PORT;
proxy_set_header Host \$host;
proxy_set_header X-Real-IP \$remote_addr;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto \$scheme;
}
error_log $LOGS_DIR/error.log;
access_log $LOGS_DIR/access.log;
}
EOF

sudo ln -s "$CONF_FILE" "$SITES_ENABLED/$DOMAIN" 2>/dev/null

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

sudo certbot --nginx -d "$DOMAIN"

if sudo nginx -t; then
sudo systemctl reload nginx
else
exit 1
fi

echo "Готово."

LinuxCamp | #devops #nginx #bymaga

Как очистить сервер от мусора

Со временем сервер обрастает мусором: логи, временные файлы, старые кэши. Разберем команды по удалению всего этого добра. Бонусом в конце будет готовый файл для запуска скрипта с логированием, который будет каждый день удалять все ненужное 🙂

Команда для удаления .log-файлов старше 7 дней:

$ find /var/log -type f -name "*.log" -mtime +7 -delete

find - команда поиска файлов
/var/log - папка, где хранятся логи
"-type f" - ищем только файлы
-name "*.log" - по шаблону *.log
"-mtime +7" - старше 7 дней
-delete - сразу удалять

Очистить systemd-журналы:

$ journalctl --vacuum-time=7d

Эта команда удаляет внутренние журналы системы, которым больше 7 дней. Такие журналы хранят события: старты, ошибки, перезагрузки, службы — всё, что происходило в системе. Обычно занимают много места, особенно если сервер работает давно.

Очистить временные файлы:

$ rm -rf /tmp/* /var/tmp/*

Удаляет всё из временных директорий. Будь осторожен, если на сервере кто-то работает прямо сейчас.

Очистить кэш и мусор после установки пакетов:

$ apt clean && apt autoremove -y

"apt clean" - очищает кэш установленных .deb файлов
"apt autoremove" - удаляет больше не нужные зависимости
"-y" - выполнять без лишних вопросов

Ниже прикладываю готовый файл. Его нужно будет сделать исполняемым и можно добавить в crontab с запуском в каждое воскресенье в 0:00. Все результаты будут сохраняться в файл "/var/log/server-cleanup.log":

#!/bin/bash

LOG_FILE="/var/log/server-cleanup.log"
echo "[$(date)] Очистка начата" >> "$LOG_FILE"

find /var/log -type f -name "*.log" -mtime +7 -delete >> "$LOG_FILE" 2>&1
journalctl --vacuum-time=7d >> "$LOG_FILE" 2>&1
rm -rf /tmp/* /var/tmp/* >> "$LOG_FILE" 2>&1
apt clean && apt autoremove -y >> "$LOG_FILE" 2>&1

echo "[$(date)] Очистка завершена" >> "$LOG_FILE"

$ sudo chmod +x /usr/local/bin/clean-server.sh

$ sudo crontab -e

0 0 * * 0 /usr/local/bin/clean-server.sh

LinuxCamp | #devops #utils

Systemd Timer - альтернатива cron

Если ты используешь cron для запуска скриптов по расписанию - пора бы взглянуть в сторону systemd timer. Это часть системы systemd - более новый и с фишками, которых нет в cron. Разберёмся, зачем он нужен и как с ним работать.

Что умеет systemd timer

systemd timer позволяет запускать задачи по расписанию вместо или в дополнение к cron. Отличается он несколькими вещами:

1) Привязан к сервису systemd (можно логировать, отслеживать статус, перезапускать);
2) Логирует всё через journalctl (никаких потерянных логов). Можно быстро проверить, когда скрипт реально запускался и с каким результатом;
3) Флаг "Persistent=true" позволяет выполнить задачу после включения сервера, если она была пропущена во время выключения;
4) Можно задавать зависимости, например, чтобы очистка выполнялась только после поднятия сети, или после других сервисов;
5) Более гибкое расписание такого вида "OnCalendar=Wed 09:44";

Пример запуска скрипта.

Возьмём тот, что был в прошлом посте. Создадим юнит для сервиса:

$ nano /etc/systemd/system/clean-server.service

[Unit]
Denoscription=Автоматическая еженедельная очистка сервера

[Service]
Type=oneshot
ExecStart=/usr/local/bin/clean-server.sh

Создаем таймер:

nano /etc/systemd/system/clean-server.timer

[Unit]
Denoscription=Таймер для еженедельной очистки сервера

[Timer]
OnCalendar=Sun 02:00
Persistent=true

[Install]
WantedBy=timers.target

Активируем:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable --now clean-server.timer

Можем проверить статус:

systemctl list-timers | grep clean-server

И посмотреть те самые автоматические логи:

systemctl status cleanup-server.timer
# или
journalctl -u clean-server.timer 

Короч, systemd timer - более современный способ управлять задачами по расписанию. Он не заменяет cron полностью, но стоит внимания в большом количестве случаев.

LinuxCamp | #utils #cron

Пацаны, биг дроп на канале!

Видео про мифы, которые мешают стать программистом. Посыл в том, что многие новички очень часто переживают из-за всяких мелочей и формируют ошибочные установки:

1) без английского у меня ничего не получится;
2) обязательно нужно высшее образование;
3) я не потяну эту науку;
4) смысл мне начинать, если AI через пару лет всех заместит;

И это на самом деле может демотивировать. Человек, вместо того, чтобы репу чесать и сомневаться, способен заспидранить обучение и через год выйти на первую работу)

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

В ролике я по фактам разбираю каждый миф. Есть, с чем согласиться и что опровергнуть.

Смотреть на YouTube

Что такое Ansible - и как обновить пакеты сразу на 10 серверах

Ansible - это инструмент для автоматизации. Он позволяет управлять сотнями серверов как одним: обновлять, настраивать, перезапускать сервисы - всё с помощью простого playbook (набор команд в YAML-файле).

Для начала нужно скачать Ansible:

sudo apt install ansible -y

Вот минимальный пример update.yml:

- name: Обновление пакетов
  hosts: all
  become: yes  # получаем root-доступ
  tasks:
    - name: apt update && upgrade
      apt:
        update_cache: yes
        upgrade: dist

Как это работает:

hosts: all - применяем ко всем серверам из инвентаря
become: yes - выполняем от имени root
apt: - встроенный модуль Ansible для Debian/Ubuntu

Запуск:

ansible-playbook -i inventory update.yml

Для подробностей можно добавить -v или -vvv:

ansible-playbook update.yml -vvv

А если хочешь сначала посмотреть, что бы изменилось, но не выполнять, используй режим dry run:

ansible-playbook update.yml --check

LinuxCamp | #utils

Caddy - замена Nginx с авто-TLS и минимальной настройкой

Ты наверняка используешь Nginx как прокси-сервер или для выдачи статики. Но есть более свежий и удивительно простой веб-сервер - Caddy. Он сам получит HTTPS, сам перезапустится при изменении конфига и вообще просит к себе минимум внимания. Разбираемся, чем он крут.

Caddy — это современный веб-сервер, написанный на Go. Его главная фишка — всё работает из коробки:

1) Автоматический HTTPS от Let's Encrypt
2) Перезапуск при изменении конфига
3) Встроенный reverse proxy
4) Простая конфигурация (Caddyfile)

Установка:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy.gpg

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

sudo apt update
sudo apt install caddy

Минимальный пример Caddyfile:

example.com {
  reverse_proxy localhost:3000
}

- Заменяешь "example.com" на свой домен
- localhost:3000 (твой сервис);

Запуск сервера

Caddy работает как systemd-сервис. Чтобы запустить или перезапустить:

sudo systemctl restart caddy

После этого caddy сам проверит домен, получит HTTPS-сертификат от Let's Encrypt, настроит прокси и всё заработает)

Почему это удобно

- Не нужно возиться с SSL — HTTPS работает из коробки
- Конфигурация проще, чем у Nginx
- Отлично подходит для pet-проектов, демо, VPS-серверов

Когда лучше остаться с Nginx

1) Если у тебя уже сложная конфигурация с множеством rewrite, map, ssl_params
2) Если нужна кастомная сборка модулей
3) Если используешь stream (TCP/UDP proxy)

LinuxCamp | #utils #devops

Что такое logrotate и как он спасает ваши диски

Системные логи могут незаметно занять весь диск, особенно если ты держишь nginx, docker, или пишешь логи вручную. Если ты ещё не настроил logrotate — однажды тебя очень удивит "df -h". Разберёмся, что это и как работает.

Что делает logrotate

logrotate — это системная утилита, которая:

- архивирует старые логи (обычно в .gz)
- удаляет логи старше N дней/версий
- переименовывает файлы (access.log → access.log.1, и т.д.)
- может перезапускать сервис после ротации (чтобы лог снова появился)

Где живёт конфиг

Ubuntu и Debian по умолчанию кладут правила в "/etc/logrotate.d/*" - здесь обычно уже лежат готовые правила для nginx, apt, docker и т.д. Но конфиги — это ещё не запуск.

Даже если правила лежат в logrotate.d, они не будут применяться, если logrotate либо не установлен, либо не запускается ни через cron, ни через systemd. Можно проверить работает ли logrotate у тебя уже. Посмотри, запланирован ли таймер:

systemctl list-timers | grep logrotate

Как всё включить

Установи, если не установлен:

sudo apt install logrotate

У тебя появится файл "/etc/logrotate.conf". Также появится автоматически сервис и таймер ротации логов. Можно запустить systemd‑таймер, если не запустился автоматически:

sudo systemctl enable --now logrotate.timer

Как добавить своё правило

Если у тебя, например, есть лог "/var/log/myapp.log". Создай конфиг, после чего файл будет ротироваться вместе с остальными:

/var/log/myapp.log {
    daily              # ротация каждый день
    rotate 7           # хранить 7 архивов
    compress           # архивировать .gz
    missingok          # не ругаться, если файла нет
    notifempty         # не трогать, если пустой
    copytruncate       # обрезать файл, не перезапуская процесс
}

sudo nano /etc/logrotate.d/myapp

Что с Docker?

Docker пишет логи в "/var/lib/docker/containers/.../*.log". Они не попадают под системный logrotate. Чтобы ограничить размер:

# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Затем:

sudo systemctl restart docker

Что с journalctl?

Если сервисы логируют в systemd‑журнал, ротация настраивается в "/etc/systemd/journald.conf".

Пример параметров:

SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=7day

Вывод

1) Конфиги в logrotate.d — это ещё не автомат
2) Сначала проверь, может уже всё работает
3) Самый надёжный способ — logrotate.timer
4) Docker и journalctl — отдельные истории

LinuxCamp | #utils #devops #bymaga

Оптимизация Dockerfile и образов

Общие принципы

- Каждая инструкция Dockerfile создаёт слой - по возможности объединяй команды RUN, чтобы минимизировать количество слоёв.
- Не используй latest: фиксируй версии образов и зависимостей для стабильности и воспроизводимости.
- Всегда указывай версии зависимостей:

flask==3.0.0
psycopg2==2.9.9
PyJWT==2.6.0

Правильная структура Dockerfile

FROM python:3.10

WORKDIR /app

# копируем только requirements для кэширования установки
COPY requirements.txt . 
RUN pip install --no-cache-dir -r requirements.txt && \
    rm -rf /root/.cache

# копируем остальной код
COPY . .

CMD ["python", "main.py"]

CMD vs ENTRYPOINT

CMD задаёт команду по умолчанию, которую можно переопределить при запуске контейнера. ENTRYPOINT фиксирует поведение и используется, когда контейнер должен всегда выполнять определённую задачу (например, CLI-инструмент). Обычно их комбинируют: ENTRYPOINT задаёт неизменяемую часть, CMD — параметры по умолчанию.

- CMD — удобно для простого запуска,
- ENTRYPOINT — для CLI-обёрток и скриптов, где логика жёстко зафиксирована.

Советы по чистке

- Используй "--no-cache-dir" при установке pip-зависимостей.
- Удаляй .cache, временные и сборочные файлы (pycache, .pytest_cache и т.д.). А лучше использовать ".dockerignore":

__pycache__/
*.pyc
.git
.venv
.pytest_cache

Оптимизация кэширования

Сначала копируй наименее изменяемые файлы (например, requirements.txt) — это позволяет использовать кэш при сборке.

Многоступенчатая сборка (multi-stage build)

Когда мы собираем Docker-образ, нам часто нужны временные инструменты — компиляторы, менеджеры зависимостей и прочее. Но в финальном образе они уже не нужны и только раздувают размер.

Multi-stage build позволяет:

1) сначала собрать проект во временном образе (build stage),
2) а затем в финальный образ перенести только то, что нужно для запуска (runtime stage),
3) не таща за собой мусор и сборочные инструменты.

Пример для python:

FROM python:3.10 as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.10-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages
COPY . .
CMD ["python", "main.py"]

Пример для Go:

FROM golang:1.21 as build
COPY . .
RUN go build ./src/main.go

FROM alpine:latest
COPY --from=build /go/main .
CMD ["./main"]

LinuxCamp | #utils #devops

Команда watch: живой взгляд на процессы и метрики

watch - утилита, которая повторно запускает любую команду через заданный интервал (по‑умолчанию 2 сек) и отображает её вывод полноэкранно. Подходит, когда:

1) нужно увидеть изменение метрики прямо сейчас;
2) нет времени поднимать полноценный мониторинг;
3) требуется «подкараулить» событие и выйти, как только оно случится;
4) работает везде: на Debian, BusyBox в Alpine, внутри Docker‑контейнера;

Базовый синтаксис

watch [-n <сек>] [-d] [-g] [-t] [-p] [-e] [-x] <команда>

Ключевые опции

"-n 5” — устанавливает интервал в 5 с. Хорош для медленных команд и экономии CPU;
-d — подсвечивает изменения относительно предыдущего вывода. Удобно отслеживать «скачки»;
-g — автоматически выходит, как только вывод изменится; полезно, когда ждёте окончания бэкапа;
-e — завершает работу при ненулевом exit‑коде команды. Превращает watch в health‑check;
-t — убирает заголовок watch. Идеален для чистых скриншотов;
-p — синхронизирует запуск с системными секундами. Это важно при очень частых опросах, например "-n 0.2";
-x — запускает команду без обёртки в shell. Это помогает, если команда содержит символы вроде $ или *, которые интерпретируются bash'ем;

Практические примеры

Топ прожорливых процессов

watch -n 1 -d 'ps -eo pid,cmd,%cpu --sort=-%cpu | head'

Ждём появления строки ERROR в логе и выходим

watch -g "grep -q ERROR /var/log/app.log"
echo 'Нашли ERROR!'

Мини‑график latency

watch -n 0.2 -p 'ping -c1 1.1.1.1 | awk -F"=" "/time=/{print $4}"'

Лайфхаки

"-d" подсвечивает изменения — удобно, когда хочешь быстро понять, что именно изменилось. Добавь "--differences=permanent", чтобы подсветка не исчезала между обновлениями.
"-t" убирает заголовок watch — идеально для чистых логов или скриншотов.
"-p" даёт ровный ритм (1 Hz и выше), полезно для прецизионного мониторинга.
"-g" или "-e" + немного shell'а — и у тебя мини-скрипт, который реагирует на событие.

LinuxCamp | #utils

lsof: что держит порт, файл или устройство занятым?

Если ловил ошибку "Address already in use" или не получалось размонтировать флешку - значит, уже сталкивался с ситуацией, когда что-то заняло ресурс. Команда lsof поможет быстро понять - кто именно.

Зачем использовать lsof:

- Узнать, кто держит порт (например, 80 или 5432).
- Посмотреть, кто пишет в лог или блокирует файл.
- Проверить, кто мешает размонтировать диск (umount).
- Увидеть, какие файлы открыты у процесса (отладки и утечки).

Примеры:

Кто занял порт 5432 (PostgreSQL):

lsof -i :5432

Какие процессы используют файл:

lsof /var/log/syslog

Какие процессы используют определённую директорию:

lsof +D /mnt/backup

Посмотреть открытые файлы у PID:

lsof -p 1234

Что мешает размонтировать:

lsof /mnt/usb

Лайфхаки:

Совмещай с grep, чтобы быстрее искать нужное:

lsof -i | grep LISTEN

Можно убить процесс, который держит порт:

kill -9 $(lsof -t -i :1234)

LinuxCamp | #utils #microhelp