С какими частыми ошибками в Linux сталкивался

Распространенные ошибки и проблемы в Linux системах

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

1. Ошибки управления правами и пользователями

Это одна из самых частых и потенциально опасных проблем.

• Случайное использование chmod 777 для решения проблем с доступом. Это грубейшая ошибка безопасности, открывающая доступ всем пользователям системы.

# Плохой подход
chmod 777 /var/www/html/

# Правильный подход — установка прав только для нужной группы (например, www-data)
chmod 750 /var/www/html/
chown www-data:www-data /var/www/html/

• Некорректная конфигурация sudo или su, приводящая к предоставлению чрезмерных прав обычным пользователям.
• Работа под root для обычных задач, вместо использования sudo для конкретных команд.

2. Проблемы с управлением дисковым пространством и файловой системой

• Недостаток мониторинга приводит к заполнению корневого раздела (/), что парализует систему. Частые причины:

    * Логи приложений (`/var/log/`), особенно без ротации.
    * Неуправляемые временные файлы или кэш.
    * "Остатки" от удаленных пакетов в `/var/cache/apt/`.

• Использование rm -rf / или rm -rf ./* без проверки текущей директории. Классическая катастрофическая ошибка.

# Категорически избегать! Предварительно всегда проверяем pwd
pwd
# Только после подтверждения директории выполняем удаление
rm -rf ./old_backups/

• Неправильное использование fdisk/mkfs для живых систем, приводящее к потере данных.

3. Ошибки сетевой конфигурации и безопасности

• Некорректные правила iptables/nftables или firewalld, блокирующие необходимые порты или оставляющие сервисы открытыми для всех.

# Частая ошибка — блокировка всего трафика без исключения для SSH
iptables -A INPUT -j DROP # Без предварительного разрешения для управляющих портов!

# Правильный подход: сначала разрешить управление, потом ограничить
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP

• Конфигурация sshd_config с разрешением парольной аутентификации и root-логина на производственных серверах.
• Открытие сервисов на всех интерфейсах (0.0.0.0), когда требуется только внутренний доступ.

4. Проблемы управления процессами и сервисами

• "Жесткое" убийство процессов kill -9 (SIGKILL) без попытки сначала использовать kill или kill -15 (SIGTERM) для корректного завершения. SIGKILL не позволяет процессу освободить ресурсы.

# Сначала пытаемся завершить процесс корректно
kill -15 <PID>
# Если не отвечает, тогда используем SIGKILL после анализа причины зависания
kill -9 <PID>

• Неправильная конфигурация systemd unit-файлов: отсутствие Restart=on-failure, некорректные User/Group, или блокировка из-за неверных зависимостей (Requires/After).
• Отсутствие лимитов ресурсов (cgroups) для сервисов, приводящее к их "пожиранию" памяти или CPU.

5. Ошибки в работе с пакетами и обновлениями

• Обновление всех пакетов (apt upgrade/yum update) без тестирования на staging-окружении, особенно на производственных серверах. Это может привести к конфликтам зависимостей или несовместимости версий.
• Смешение репозиториев (например, Ubuntu и Debian) или использование неофициальных источников без проверки.
• Удаление "казалось бы ненужных" пакетов, которые являются критическими зависимостями для других компонентов системы.

6. Логические и скриптовые ошибки

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

#!/bin/bash
# Плохой скрипт
cd /some/directory/
rm -rf *.log # Если cd не удался, удаление произойдет в текущей директории!

# Правильный скрипт с проверкой
cd /some/directory/ || { echo "Directory change failed"; exit 1; }
rm -rf *.log

• Использование > вместо >> в скриптах, когда необходимо дописывать файл, что приводит к его перезаписи.
• Отсутствие -e (exit on error) в bash-скриптах для критических операций.

7. Проблемы производительности и диагностики

• Непонимание вывода команд top, htop, free -m, df -h. Например, интерпретация "used memory" в free без учёта кэша и буферов.
• Игнорирование swappiness при работе с памятью, приводящее к чрезмерному использованию swap на высоконагруженных серверах.
• Отсутствие анализа iostat, netstat, ss при проблемах с IO или сетью.

Основные принципы предотвращения ошибок:

• Всегда проверять команды, особенно с ключами -rf или модификацией системных файлов.
• Использовать staging-окружение для тестирования изменений.
• Внедрять мониторинг (Prometheus, Grafana) для диска, памяти, сети.
• Автоматизировать конфигурацию с помощью Ansible, Terraform для снижения "human error".
• Вести документацию всех изменений на production.
• Применять принцип наименьших прав (least privilege) для пользователей и процессов.

Большинство этих ошибок устраняется накоплением опыта, строгими процедурами и культурой "не делать на живом сразу". В DevOps мы часто создаем защитные механизмы через CI/CD, проверки конфигурации (например, linters для Ansible), и автоматическое тестирование инфраструктуры.