🧩 Редкий, но очень полезный Linux совет, о котором знают далеко не все
Если хочешь понять, кто именно удерживает файл открытым и почему диск «занят», даже когда файл уже удалён, используй команду:
Это покажет процессы, которые держат открытые дескрипторы на удалённые файлы. Да, в Linux файл может продолжать занимать место на диске, даже если его стёрли, пока процесс не завершит работу.
Зачем это нужно
• помогает найти утечки логов
• решает проблему «диск заполнен, но где именно»
• спасает от внезапного out of space на проде
• позволяет не перезапускать весь сервер, а убить только нужный процесс
Масштабировать свой Linux скилл проще, когда понимаешь такие скрытые механики.
@linux_read
Если хочешь понять, кто именно удерживает файл открытым и почему диск «занят», даже когда файл уже удалён, используй команду:
lsof -a +L1Это покажет процессы, которые держат открытые дескрипторы на удалённые файлы. Да, в Linux файл может продолжать занимать место на диске, даже если его стёрли, пока процесс не завершит работу.
Зачем это нужно
• помогает найти утечки логов
• решает проблему «диск заполнен, но где именно»
• спасает от внезапного out of space на проде
• позволяет не перезапускать весь сервер, а убить только нужный процесс
Масштабировать свой Linux скилл проще, когда понимаешь такие скрытые механики.
@linux_read
👍17❤1
💡 Продвинутый и редко используемый Linux совет - работа с PID-неймспейсами прямо из терминала
Если нужно отлаживать процессы в полностью изолированном пространстве процессов (почти как в контейнере), можно запустить команду в отдельном PID-namespace. Это позволяет:
- видеть процессы только внутри пространства
- запускать init-процесс PID 1
- безопасно тестировать сервисы, сигналы, демонизацию
- воспроизводить поведение контейнеров без Docker
Команда:
Что происходит:
Теперь внутри вы увидите:
и получите полностью изолированное дерево процессов.
Это идеальный инструмент, если нужно отлаживать демоны, изучать сигналы, тестировать systemd-поведение или понимать, как контейнеры управляют процессами под капотом.
@linux_read
Если нужно отлаживать процессы в полностью изолированном пространстве процессов (почти как в контейнере), можно запустить команду в отдельном PID-namespace. Это позволяет:
- видеть процессы только внутри пространства
- запускать init-процесс PID 1
- безопасно тестировать сервисы, сигналы, демонизацию
- воспроизводить поведение контейнеров без Docker
Команда:
sudo unshare --pid --fork --mount-proc bash
Что происходит:
- `--pid` создаёт новый PID-namespace
- `--fork` запускает новый процесс как PID 1 внутри пространства
- `--mount-proc` подменяет `/proc`, чтобы видеть только локальные процессы
Теперь внутри вы увидите:
ps aux
и получите полностью изолированное дерево процессов.
Это идеальный инструмент, если нужно отлаживать демоны, изучать сигналы, тестировать systemd-поведение или понимать, как контейнеры управляют процессами под капотом.
@linux_read
👍7❤3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 BASH СОВЕТ
Если тебе нужно быстро найти, какие команды ты запускал для конкретного проекта, но не хочешь листать весь history - используй историю по директории.
Bash сохраняет путь вместе с командой, и можно фильтровать только то, что выполнялось в текущем каталоге.
Если тебе нужно быстро найти, какие команды ты запускал для конкретного проекта, но не хочешь листать весь history - используй историю по директории.
Bash сохраняет путь вместе с командой, и можно фильтровать только то, что выполнялось в текущем каталоге.
grep "$(pwd)" ~/.bash_history \
| sed "s|$(pwd)||" \
| sed 's/^.*: //' \
| sort -u \
| less
# Показывает только те команды,
# которые запускались в текущей директории.
# Можно искать по проектам, не засоряя историю.
👍8❤4🔥1🤔1
Forwarded from Devops / Bash / Linux
Linux совет дня💡
Нужно быстро найти исполняемые файлы в каталоге?
Используй
Пример:
В отличие от проверки прав через
Bash советы
Нужно быстро найти исполняемые файлы в каталоге?
Используй
find с флагом -executable — он покажет только те файлы, которые действительно можно запускать.Пример:
find . -type f -executable
В отличие от проверки прав через
-perm, этот вариант учитывает реальные разрешения и ACL, поэтому результат точнее — вывод включает только те файлы, которые доступны для выполнения текущим пользователем.Bash советы
👍5❤3
🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты?
Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом.
Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям.
Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт.
🎁 48 часов действует скидка в 40% процентов
👉 Начать учиться на Stepik
Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом.
Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям.
Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт.
🎁 48 часов действует скидка в 40% процентов
👉 Начать учиться на Stepik
❤5👎2👍1
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Совет по Linux безопасности
Если ты настраиваешь сервер или рабочую Linux-машину, начинай защиту не с сложных IDS и фаерволов, а с базовой, но правильной минимизации поверхности атаки.
Главная ошибка
Оставлять активными сервисы и доступы "на всякий случай". Именно они чаще всего становятся точкой входа.
Правильный подход
- Закрыть всё по умолчанию
- Разрешать только необходимое
- Логировать и ограничивать попытки доступа
- Делать защиту простой и проверяемой
Минимальный must-have
- Отключение root-доступа по SSH
- Доступ по ключам вместо паролей
- Ограничение попыток входа
- Базовый firewall с allow-list подходом
Это даёт 80% реальной защиты без оверхеда и лишней магии.
https://www.youtube.com/shorts/GQ13RqAPu80
Если ты настраиваешь сервер или рабочую Linux-машину, начинай защиту не с сложных IDS и фаерволов, а с базовой, но правильной минимизации поверхности атаки.
Главная ошибка
Оставлять активными сервисы и доступы "на всякий случай". Именно они чаще всего становятся точкой входа.
Правильный подход
- Закрыть всё по умолчанию
- Разрешать только необходимое
- Логировать и ограничивать попытки доступа
- Делать защиту простой и проверяемой
Минимальный must-have
- Отключение root-доступа по SSH
- Доступ по ключам вместо паролей
- Ограничение попыток входа
- Базовый firewall с allow-list подходом
Это даёт 80% реальной защиты без оверхеда и лишней магии.
Отключаем root-логин и пароли по SSH
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh
Ограничиваем вход по SSH только нужному пользователю
sudo sed -i 's/^#\?AllowUsers.*/AllowUsers youruser/' /etc/ssh/sshd_config
sudo systemctl restart ssh
Включаем простой firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable
Защита от brute-force
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
https://www.youtube.com/shorts/GQ13RqAPu80
👍8❤3🔥2😡1