Запускаем команды от имени другого пользователя через sudo -u — без входа в его интерактивную сессию через su!

Это удобно при разработке и администрировании, когда нужно проверить права приложения, выполнить миграцию от имени сервисного пользователя или воспроизвести ошибку, связанную с доступом.

Обычный запуск команды от имени другого пользователя:

sudo -u www-data id

Команда выполнится с UID и GID пользователя www-data, но текущий терминал останется вашим.

Например, можно проверить, имеет ли веб-приложение доступ к нужной директории:

sudo -u www-data ls -la /var/www/app

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

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

sudo -u postgres bash

Все команды внутри этого shell будут выполняться от имени postgres. Однако это не полноценный login shell: текущая директория и часть окружения могут сохраниться от исходного пользователя.

Если нужен shell с окружением, близким к обычному входу пользователя, используйте:

sudo -iu postgres

При отладке важно учитывать, что sudo -u не всегда воспроизводит реальное окружение работающего сервиса.

Например:

sudo -u node env

Эта команда покажет окружение, сформированное sudo, но оно может отличаться от окружения процесса, запущенного через systemd, Docker, Kubernetes, PM2 или другой менеджер процессов.

Также можно передать временную переменную окружения только для одного запуска:

sudo -u www-data env APP_ENV=testing ./deploy.sh

Переменная APP_ENV будет доступна только этому процессу и его дочерним процессам. Глобальные настройки системы при этом не изменятся. Также важно: возможности sudo -u зависят от правил в sudoers. Разрешение на запуск shell, интерпретатора или произвольного скрипта может дать пользователю широкий доступ от имени целевой учётной записи.

🔥 sudo -u — удобный инструмент для проверки прав, отладки сервисов и запуска отдельных команд от имени системных пользователей без полноценного переключения сессии.

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

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

В Linux почти всё взаимодействие построено вокруг файловых дескрипторов. Поэтому стандартный ввод, вывод и ошибки тоже доступны через специальные файлы в /dev.

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

$ cat /dev/stdin

cat читает текущий stdin процесса. Это может быть терминал, pipe или перенаправленный поток.

Например, можно сравнить файл с данными, которые приходят напрямую:

$ generate_config | diff config.old /dev/stdin

Без создания временных файлов:

$ echo "new_value=true" | diff config.old /dev/stdin

Также доступны стандартный вывод и ошибки:

$ echo "hello" > /dev/stdout
$ echo "error" > /dev/stderr

Это удобно в shell-автоматизации, когда программа умеет работать с потоками, но ожидает путь к файлу.

🔥 /dev/stdin, /dev/stdout и /dev/stderr — это удобные ссылки на файловые дескрипторы текущего процесса, которые помогают соединять программы без лишних временных файлов.

🚪 Linux Ready | #совет

📂 Напоминалка по особым правам в Linux!

Например, SUID позволяет запускать файл с правами его владельца, SGID помогает управлять наследованием групповых прав, а Sticky Bit защищает файлы в общих директориях вроде /tmp от удаления другими пользователями.

На картинке — основные отличия между SUID, SGID и Sticky Bit, примеры их использования и команды chmod для настройки специальных прав доступа.

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

🚪 Linux Ready | #ресурс

Практически любую команду можно запустить в отдельной cgroup!

Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения.

Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run:

systemd-run --user --scope \
  -p MemoryHigh=1536M \
  -p MemoryMax=2G \
  make -j32

Теперь ограничения действуют только на эту команду и всё её дерево процессов. После завершения временная cgroup автоматически исчезнет.

Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу):

systemd-run --user --scope \
  -p CPUQuota=200% \
  npm test

Или собрать сразу несколько политик для ресурсоёмкой задачи:

systemd-run --user --scope \
  -p MemoryMax=4G \
  -p CPUQuota=300% \
  -p IOWeight=100 \
  cargo build --release

Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2).

🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с VLAN в Linux: Access vs Trunk!

Например, Access Port используется для подключения устройств в один VLAN без дополнительной настройки на стороне клиента, а Trunk Port позволяет передавать несколько VLAN через один сетевой интерфейс с использованием стандарта 802.1Q.

На картинке — разница между Access и Trunk портами, структура тегированного и нетегированного Ethernet-кадра, а также пример связи нескольких VLAN через trunk-соединение.

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

🚪 Linux Ready | #ресурс

Разбираем диагностику OOM Killer в Linux через systemd, kernel logs и cgroup!

При эксплуатации Linux-сервисов периодически встречается ситуация: процесс завершается, но в логах приложения нет явной причины ошибки.
Первое, что обычно проверяем — состояние сервиса через systemd:

systemctl status api.service

Например, в выводе можно увидеть:

Active: failed (Result: signal)

Этот статус показывает только факт завершения процесса, но не объясняет, что именно произошло. Чтобы найти причину, нужно посмотреть сообщения ядра Linux. Одна из распространённых причин внезапного завершения процессов — срабатывание OOM Killer.

OOM Killer — это механизм ядра, который включается при критической нехватке памяти и завершает выбранные процессы, чтобы система продолжила работу. При этом важно понимать: причина может быть не только в полном исчерпании памяти сервера, но и в ограничениях, заданных через cgroup.

Проверяем события OOM в логах ядра:

journalctl -k | grep -Ei "out of memory|killed process|oom"

Также можно использовать:

dmesg -T | grep -Ei "killed process|out of memory|oom"

Например:

Out of memory: Killed process 4210 (java)
anon-rss:16000000kB

Из этого видно, что ядро завершило процесс Java из-за проблем с памятью. Следующий вопрос при расследовании — почему именно этот процесс был выбран.

Для работающего процесса можно проверить значение:

cat /proc/<PID>/oom_score

oom_score показывает относительную вероятность выбора процесса механизмом OOM Killer. Чем выше значение, тем выше вероятность завершения процесса при нехватке памяти.

Также существует параметр:

cat /proc/<PID>/oom_score_adj

Он позволяет изменить приоритет процесса. Значения находятся в диапазоне от -1000 до 1000. Чем ниже значение, тем меньше вероятность завершения процесса. Значение -1000 полностью исключает процесс из выбора OOM Killer.

Для сервисов под systemd такие настройки корректнее задавать через unit-файл:

[Service]
MemoryMax=4G
OOMScoreAdjust=-500

После изменения конфигурации:

systemctl daemon-reload
systemctl restart api.service

При работе с контейнерами важно учитывать ещё один сценарий: проблема может быть не в памяти хоста, а в ограничении cgroup.
Например, сервер может иметь свободную память, но контейнер ограничен параметром memory limit. После превышения этого значения процесс внутри контейнера будет завершён.

Проверяем ограничение памяти Docker:

docker inspect -f '{{.HostConfig.Memory}}' container_name

Текущее потребление:

docker stats

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

memory.events

В Kubernetes аналогичная ситуация отображается через:

kubectl describe pod api

В выводе будет:

Reason: OOMKilled

Это означает, что контейнер превысил установленный limits.memory. При диагностике OOM важно определить, где именно возникло ограничение: на уровне памяти хоста, systemd/cgroup, Docker или Kubernetes.

🔥 Основная задача при расследовании — определить, какой процесс был завершён, какой механизм инициировал завершение и какое ограничение памяти стало причиной события.

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

☕️ Полезная статья недавно вышла на Хабре: Как я написал свой клиент Miracast для шаринга экрана под Linux в 2026 году и погряз в войне за проприетарные байты!

В этой статье:
• Разбирается, как автор на Python собрал собственную Linux-утилиту FluxCast для трансляции экрана на Smart TV без HDMI-кабеля;
• Показываются реальные проблемы Miracast, DLNA, RTSP/RTP, GStreamer, Wayland, Wi-Fi Direct и совместимости с разными телевизорами;
• Рассказывается, как open-source проект вырос из CLI-скрипта в AppImage, AUR-пакет и утилиту, попавшую в ArchWiki.

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

🚪 Linux Ready | #статья

📂 Напоминалка по типам файлов в Linux!

Например, символические ссылки (symlink) позволяют обращаться к файлам без их дублирования, а FIFO и сокеты используются для обмена данными между процессами.

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

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

🚪 Linux Ready | #ресурс

Проверяем задержки сети в Linux через mtr!

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

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

Для таких случаев удобно использовать mtr — инструмент, который объединяет возможности ping и traceroute и позволяет увидеть, где именно начинается деградация. Запуск:

mtr api.example.com

MTR показывает маршрут до узла и статистику по каждому промежуточному хопу: задержку, количество отправленных пакетов и возможные потери ответов.

Для длительного тестирования удобно использовать:

mtr -rwbc 100 api.example.com

Параметры:
-r — вывести итоговый отчёт и завершить выполнение; -w — расширенный формат вывода; -b — показывать IP-адреса вместе с именами узлов; -c 100 — отправить 100 пакетов.

Для больших маршрутов иногда удобнее отключить DNS-резолвинг:

mtr -n api.example.com

Сохранить результат для дальнейшего анализа:

mtr -rwbc 100 api.example.com > mtr-report.txt

Важный момент: потери на промежуточном узле не всегда означают реальную проблему. Многие маршрутизаторы ограничивают обработку ICMP или имеют низкий приоритет для таких ответов. Один из хопов может показывать высокий процент потерь, а конечный сервер при этом работать нормально.

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

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

mtr -T -P 443 api.example.com

В этом режиме MTR использует TCP SYN probes вместо ICMP, что ближе к проверке реального пути для сервисов вроде HTTPS, SSH или API. Примеры:

# HTTPS
mtr -T -P 443 api.example.com

# SSH
mtr -T -P 22 server.example.com

Но важно понимать: TCP MTR проверяет сетевую доступность и транспортный уровень. Он не покажет проблемы внутри TLS, HTTP или самого приложения. Полезно сравнивать разные направления:

mtr -T -P 443 server-a.example.com
mtr -T -P 443 server-b.example.com

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

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

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

📂 Напоминалка по типам IPv6-адресов!

Например, Global Unicast используется для глобальной маршрутизации, Link-Local — для связи внутри локального сегмента, а Multicast заменяет broadcast и позволяет отправлять данные группе устройств.

На картинке — основные типы IPv6-адресов, их префиксы, назначение и примеры использования.

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

🚪 Linux Ready | #ресурс

Управляем ресурсами процессов через cgroups v2!

При эксплуатации серверов снижение производительности нередко связано с постепенным ростом потребления ресурсов одним из сервисов. В результате уменьшается объём доступного процессорного времени и памяти для остальных процессов, что отрицательно влияет на стабильность всей системы.

Для управления ресурсами в Linux используется механизм control groups (cgroups). Он позволяет ядру учитывать и ограничивать потребление CPU, памяти, дискового ввода-вывода и количество задач, включая процессы и потоки.

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

findmnt -t cgroup2

или:

stat -fc %T /sys/fs/cgroup

Если используется cgroups v2, в последнем случае будет получен вывод:

cgroup2fs

В системах с systemd процессы сервисов автоматически размещаются в отдельных cgroups, поэтому ограничения ресурсов обычно задаются средствами systemd.

Например, ограничить объём памяти для сервиса можно следующим образом:

systemctl set-property nginx.service MemoryMax=1G

После применения параметра systemd устанавливает соответствующее ограничение для cgroup сервиса. При достижении лимита ядро сначала пытается освободить память, а если это невозможно, OOM-механизм memory cgroup может завершить один или несколько процессов.

Следует учитывать, что MemoryMax ограничивает не только анонимную память приложения, но и учитываемый page cache. Проверить текущие значения можно командой:

systemctl show nginx.service -p MemoryCurrent -p MemoryMax

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

systemd-cgtop

Утилита отображает активные cgroups, текущее использование CPU и памяти, объём ввода-вывода и количество задач, что позволяет быстро определить сервис, создающий основную нагрузку.

Ограничение использования процессора задаётся аналогичным образом:

systemctl set-property worker.service CPUQuota=50%

Значение CPUQuota=50% соответствует половине времени одного логического процессора, а CPUQuota=200% позволяет использовать до двух логических процессоров. Ограничение распространяется на суммарное использование CPU всеми процессами, входящими в cgroup сервиса.

Количество процессов и потоков можно ограничить следующим параметром:

systemctl set-property worker.service TasksMax=200

Это предотвращает неконтролируемое создание задач и снижает риск исчерпания системных ресурсов.

Постоянные ограничения удобно задавать через override-конфигурацию:

systemctl edit worker.service

Например:

[Service]
MemoryMax=2G
CPUQuota=200%
TasksMax=500

После изменения конфигурации сервис необходимо перезапустить:

systemctl restart worker.service

🔥 Механизм cgroups работает на уровне ядра и применяет ограничения к группе процессов независимо от языка программирования или способа запуска приложения. На основе cgroups v2 реализованы механизмы управления ресурсами в systemd и большинстве современных контейнерных платформ.

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

✍️ Крайне информативная статья вышла на Хабре: «Ваш docker-compose.yml сломается: 5 настроек, которые все забывают»!

В этой статье:
• Разбираются пять важных настроек Docker Compose, которые стоит использовать в продакшене;
• Показывается, как правильно настроить лимиты ресурсов, restart policy, ротацию логов и healthcheck;
• Объясняется, почему резервное копирование volumes помогает избежать потери данных при сбоях и ошибках.

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

🚪 Linux Ready | #статья

В Linux можно запустить программу в изолированной среде без Docker и виртуальной машины!

Для тестирования скриптов, сборки проектов или проверки поведения программ часто создают контейнеры. Но иногда полноценный контейнерный стек просто не нужен.

Bubblewrap (bwrap) использует Linux namespaces и позволяет создавать минимальное sandbox-окружение одной командой. Во многих системах это работает без root (если разрешены user namespaces):

$ bwrap \
  --ro-bind /usr /usr \
  --ro-bind /bin /bin \
  --dev /dev \
  --proc /proc \
  --tmpfs /tmp \
  bash

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

Например, можно дать программе доступ только к конкретному каталогу:

$ bwrap \
  --bind ./project /app \
  --chdir /app \
  bash

Теперь работа идёт внутри отдельного пространства, а изменения можно ограничить указанными каталогами.

Можно запускать тестовые скрипты или проверять сборку без изменения основной системы:

$ bwrap \
  --ro-bind /usr /usr \
  --bind ./test-env /tmp \
  ./test.sh

Например, Flatpak использует Bubblewrap для изоляции приложений.

🔥 bwrap — это минимальный контейнерный инструмент без Docker: быстрый способ проверить программу в отдельном окружении и не засорять основную систему.

🚪 Linux Ready | #совет

📂 Напоминалка по Git для разработчиков!

Например, git add подготавливает изменения к коммиту, git commit фиксирует состояние проекта в истории, а git branch и git merge позволяют управлять ветками разработки.

На картинке — базовый набор Git-команд, необходимых для ежедневной работы в команде.

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

🚪 Linux Ready | #ресурс

Анализ времени загрузки через systemd-analyze!

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

Первый этап анализа — общее время загрузки:

systemd-analyze

Пример вывода:

Startup finished in 4.2s (kernel) + 35.8s (userspace) = 40.0s

kernel показывает время загрузки ядра, а userspace — время запуска systemd, сервисов и пользовательского пространства. На некоторых системах дополнительно отображаются этапы firmware, loader и initrd.

Если основная задержка находится в userspace, дальнейший анализ выполняется через systemd юниты и их зависимости. Для поиска юнитов с длительной активацией используется:

systemd-analyze blame

Пример:

45.231s docker.service
32.814s NetworkManager-wait-online.service
18.502s nginx.service

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

Для анализа реальной цепочки зависимостей используется:

systemd-analyze critical-chain

Пример:

multi-user.target @40.012s
└─docker.service @35.421s +4.580s
  └─network-online.target @35.400s
    └─NetworkManager-wait-online.service @2.561s +32.814s

Символ @ показывает момент активации юнита, а + — продолжительность его запуска. Такой вывод позволяет определить, какой компонент находится в критической цепочке и задерживает достижение target.

Один из частых случаев — NetworkManager-wait-online.service, который ожидает готовности сети перед продолжением загрузки. На серверах без необходимости ждать полного поднятия сети он может увеличивать время старта, однако отключение этого сервиса требует проверки зависимостей от network-online.target.

Для визуального анализа процесса загрузки:

systemd-analyze plot > boot.svg

Файл boot.svg содержит временную диаграмму запуска юнитов и позволяет увидеть параллельные процессы, последовательные зависимости и точки задержек.

Для проверки конкретного сервиса:

systemctl status docker.service

Время запуска основного процесса можно получить командой:

systemctl show docker.service -p ExecMainStartTimestamp

А причины ошибок и тайм-аутов анализируются через журнал systemd:

journalctl -b -u docker.service

Для предыдущей загрузки:

journalctl -b -1 -u docker.service

Отключать сервисы только на основании systemd-analyze blame некорректно. Перед изменением конфигурации необходимо проверить назначение юнита, наличие зависимостей и сообщения в журнале.

🔥 systemd-analyze позволяет определить проблемный этап загрузки, найти критические зависимости и локализовать причину задержки без ручного просмотра большого количества конфигурационных файлов.

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