Какие основные команды Linux для навигации и просмотра файлов
Что проверяют
Уверенно ли вы работаете на сервере, где нет графического интерфейса, а есть только ssh и авария. Базовые cd и ls интервьюеру неинтересны, следом идёт практическая задача: «диск заполнен, найдите, что съело место» или «покажите ошибки сервиса за последние десять минут».
Как отвечать
Покажите команды через рабочие сценарии:
- навигация и метаданные:
ls -lah,stat(права, владелец, время изменения, inode),fileдля типа файла,readlink -fчтобы раскрыть симлинк,tree -L 2если установлен. Полезно знать FHS: конфиги в/etc, логи в/var/log, данные сервисов в/var/lib, состояние ядра и процессов в/proc; - просмотр:
lessс поиском по/и режимом слежения+F,headиtail -n,tail -Fдля логов с ротацией; - логи сервисов:
journalctl -u nginx --since "10 min ago" -p err,journalctl -f, для контейнеровdocker logs --tail 100 -f, в Kuberneteskubectl logsс--previousдля перезапущенного контейнера; - поиск:
grep -rnс-Eдля регулярок,find / -xdev -type f -size +1Gдля крупных файлов,findс-mtimeдля старых; - место на диске:
df -hпо файловым системам,df -iпо inode,du -sh /var/* | sort -hчтобы найти тяжёлый каталог; - права:
namei -l /путь/к/файлупоказывает права на каждом уровне пути, когда сервис ловит Permission denied.
Разбор сильнее, если вы собираете команды в цепочку: journalctl нашёл ошибку записи, df -h показал 100%, du сузил поиск до каталога, find нашёл конкретный файл.
Где спотыкаются
Удаляют через rm огромный лог, который пишет живой процесс, и удивляются, что df место не вернул. Файл удалён, но дескриптор открыт. Такие файлы видно в lsof +L1, а живой лог безопаснее обнулить через truncate -s 0.
Смотрят только df -h и не проверяют df -i. Когда inode кончаются из-за миллиона мелких файлов, запись падает при свободных гигабайтах.
Запускают find / без -xdev и без 2>/dev/null: поиск уходит в /proc и сетевые монтирования, а вывод тонет в ошибках доступа. Заодно ищут логи в /var/log, хотя сервис пишет в journald или в stdout контейнера.