Команды Linux для работы с сервером

Начните с наблюдения

Команда полезна, когда понятно, на какой вопрос она отвечает. «Сайт медленный» — повод посмотреть факты, а не сразу чистить весь кэш. В примерах ниже пути и имя службы нужно сопоставить со своим сервером; подставлять их наугад не следует.

Первая проверка без изменения данных
Вопрос	Команда	На что смотреть
Какая файловая система заполнена?	`df -h`	Точка монтирования и доля занятого места, а не только общая строка диска.
Сколько занимает текущий каталог?	`du -sh ./`	Размер именно выбранного каталога. На большом дереве обход может занять время.
Где я нахожусь?	`pwd`	Полный путь перед любым действием с относительным именем.
Кому принадлежит каталог?	`ls -ld ./`	Владелец, группа и права самого каталога.
Нужный файл вообще существует?	`find ./ -type f -name 'install.php' -print`	Список путей без удаления. Начинайте с узкого каталога, не со всего сервера.

Логи одного сайта вместо всех сразу

В старой серверной раскладке логи лежали в /var/www/httpd-logs/. Это не обязательный путь для любой системы. Найдите путь в конфигурации своего сайта и начните с конкретного файла:

tail -n 100 /path/to/site-access.log
tail -f /path/to/site-access.log

Первая команда показывает последние строки; вторая продолжает показывать новые. Для выхода из наблюдения нажмите Ctrl+C. Не публикуйте логи целиком: в них могут быть адреса клиентов, токены в query-параметрах и персональные данные. Лучше сохранить короткий фрагмент вокруг времени воспроизводимой ошибки.

Процессы и служба

htop — интерактивный просмотрщик процессов, если он уже установлен. Не нужно брать команду установки для одной версии CentOS и переносить её в любую ОС. Сначала определите систему и её менеджер пакетов.

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

systemctl status nginx --no-pager
journalctl -u nginx --since "30 minutes ago" --no-pager

Имя nginx — пример. Если сервис называется иначе или запущен в контейнере без systemd, нужен его реальный способ просмотра состояния. Чтение части журнала может требовать дополнительных прав.

Конфигурация nginx: проверить до применения

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

nginx -t

Проверка должна относиться к той же установке и тому же конфигурационному файлу, которые обслуживают сайт. Она проверяет синтаксис и возможность открыть указанные файлы; успешный результат ещё не подтверждает нужное поведение HTTP-запроса. Если конфигурацию генерирует панель, используйте поддерживаемый ею способ изменения.

Права без рекурсивного исправления всего дерева

Не начинайте диагностику с chown -R на каталоге всех сайтов. Сначала выясните, какому пользователю должен принадлежать конкретный файл и кто его читает или создаёт. Массовая смена владельца способна скрыть исходную проблему и сломать соседние процессы.

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

chmod u+x ./start.sh

Здесь меняется разрешение выполнения для владельца одного файла. Команда не проверяет содержимое скрипта и не делает неизвестный скачанный код безопасным.

Почему очистка — отдельная задача

Перед удалением файлов нужен просмотр списка кандидатов и понятный способ восстановления. Удаление nginx-кэша по цепочке grep | awk | rm не заменяет настройки кэша: оно зависит от внутреннего формата и может выбрать не те файлы. SQL-запрос на удаление строк тем более требует понимания схемы и резервной копии. Ни нехватка места, ни совпадение строки с доменом сами по себе не дают основания для массового удаления.

Справка: ключи nginx, systemctl, journalctl, htop.