❤️ Oh My BackEnd — дорожная карта для backend-разработчиков!

В репозитории собраны ключевые навыки, необходимые для разработки веб-приложений: от Linux, Docker, сетей и баз данных до HTTP, безопасности, мониторинга и проектирования систем. Удобно, что темы расположены в рекомендуемом порядке изучения, разделены по уровням сложности и дополнены пояснениями о том, где и зачем эти знания применяются.

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

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

В util-linux есть инструмент lsfd, который позволяет фильтровать открытые файловые дескрипторы по их свойствам!

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

Вместо ручного поиска по /proc можно использовать lsfd:

sudo lsfd -Q 'DELETED'

Фильтр -Q позволяет выбирать дескрипторы по выражению, а DELETED — находить открытые файлы, которые уже удалены из файловой системы.

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

sudo lsfd -Q 'DELETED' \
  -o PID,COMMAND,NAME

Так становится видно, какой процесс удерживает файл и к какому пути тот относился.

А самое интересное — lsfd умеет не просто показывать список, а выполнять выборки по свойствам дескрипторов:

# Дескрипторы конкретного процесса
sudo lsfd -Q 'PID == 1234'

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

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

🚪 Linux Ready | #совет

👨‍💻 На Хабре лежит годная статья: «Всё, что вы настроили в Linux, можно было не настраивать»!

В этой статье:
• Узнаете, почему автор после 15 лет использования Linux отказался от сложных конфигураций в пользу Fedora с GNOME;
• Разберёте, когда i3, кастомные панели, dotfiles и скрипты действительно полезны, а когда лишь усложняют работу;
• Задумаетесь, почему постоянная настройка окружения часто создаёт иллюзию продуктивности, не ускоряя решение реальных задач.

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

🚪 Linux Ready | #статья

Как принудительно ограничить аппетит прожорливого процесса, чтобы он не использовал весь процессор и не вешал сервер?

Когда тяжелый скрипт, бэкап или процесс компиляции внезапно забивает CPU под 100%, сервер перестает отвечать, а соседние сервисы начинают падать. Вместо радикального убийства процесса через kill можно использовать утилиту cpulimit, которая динамически контролирует его работу, отправляя сигналы остановки и возобновления, удерживая нагрузку в жестких рамках.

Ограничение уже запущенного процесса по его идентификатору (PID) до заданного процента мощности:

$ cpulimit -p 1234 -l 40

Утилита перехватит управление процессом 1234 и не позволит ему занять более 40% от одного ядра CPU.

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

$ cpulimit -l 25 -- tar -czf backup.tar.gz /var/www

Архивация начнется в фоне, но процесс гарантированно будет использовать не более четверти процессорного времени.

Важно: cpulimit высчитывает проценты от общего числа ядер (на 4-ядерном процессоре лимит 200% означает полную загрузку двух ядер), и для работы с чужими процессами понадобятся права sudo.

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

🚪 Linux Ready | #совет

GNU Make умеет специально ломать привычный порядок сборки, чтобы находить ошибки в зависимостях Makefile!

Бывает, что make -j работает нормально, а затем сборка случайно падает на CI или новой машине. Частая причина — одна цель неявно рассчитывает, что другая успеет выполниться раньше, хотя эта зависимость нигде не объявлена.

В GNU Make 4.4 для поиска таких проблем появился --shuffle:

make -j8 --shuffle

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

Полезно прогнать сборку несколько раз:

for i in {1..20}; do
  make clean
  make -j8 --shuffle || break
done

Если сборка упала, Make сообщает seed перемешивания. Его можно передать повторно и воспроизвести тот же порядок:

make -j8 --shuffle=123456789

Интересно, что --shuffle полезен даже без параллельной сборки:

make -j1 --shuffle

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

🔥 make --shuffle превращает порядок сборки в fuzz-тест: отличный способ найти отсутствующие зависимости в Makefile до того, как они проявятся случайным падением на CI.

🚪 Linux Ready | #совет