Что происходит при вызове sync и зачем используются drop_caches?

Во время диагностики производительности или тестирования файловой системы нередко встречаются рекомендации выполнить:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Эти команды часто используют вместе, однако они решают разные задачи. Чтобы понимать, когда их действительно стоит применять, важно разобраться, что происходит внутри ядра Linux.

Когда приложение записывает данные в файл, они обычно не сразу попадают на устройство хранения. Ядро сначала размещает их в page cache, помечая соответствующие страницы как dirty. Это позволяет объединять множество небольших операций записи в более крупные и снижать количество обращений к диску.

Проверить объём таких страниц можно командой:

grep -E "Dirty|Writeback" /proc/meminfo

Пример:

Dirty:             18432 kB
Writeback:             0 kB

Значение Dirty показывает объём данных, ожидающих записи, а Writeback — объём страниц, которые в данный момент уже записываются фоновыми потоками ядра.

Команда:

sync

не очищает page cache и не освобождает память. Она инициирует запись всех изменённых страниц и метаданных файловой системы в нижележащее хранилище и завершается после окончания этих операций. Итоговые гарантии сохранности данных зависят от файловой системы, устройства хранения и его политики кэширования.

Если в системе в этот момент нет новых операций записи, после выполнения sync значение Dirty обычно становится близким к нулю.

Команда:

echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

работает иначе. Она освобождает объекты, которые ядро может безопасно восстановить при необходимости. Значение 1 очищает page cache, 2 — кэш dentry и inode, а 3 очищает оба типа кэша одновременно.

Поэтому на практике сначала выполняют:

sync

а затем:

echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Без предварительного sync часть страниц может оставаться изменённой (dirty), и ядро не сможет освободить их до завершения записи.

Проверить эффект можно с помощью:

grep -E "Cached|Buffers|SReclaimable|MemAvailable" /proc/meminfo

или:

free -h

При этом важно понимать, что уменьшение значения Cached не означает сопоставимого увеличения MemAvailable. Page cache и без принудительной очистки автоматически освобождается ядром при возникновении нехватки памяти и является частью нормальной работы Linux.

На практике drop_caches используют в основном перед сравнительным тестированием производительности файловой системы, чтобы исключить влияние уже закэшированных данных. Для «очистки памяти» на рабочих серверах эта команда обычно не применяется, поскольку после удаления кэша системе потребуется заново считывать данные с устройства хранения, что зачастую приводит к временному снижению производительности.

🔥 sync обеспечивает синхронизацию накопленных изменений с устройством хранения, а drop_caches освобождает восстанавливаемые структуры памяти. Эти механизмы предназначены для диагностики и тестирования, а не для регулярной оптимизации работы системы.

🚪 Linux Ready | #практика

🐱 Вышла интересная статья на Хабре: «Что такое LiteLLM и для чего его едят»!

В этой статье:
• Разбирается, как с помощью LiteLLM объединить работу со 100+ LLM-провайдерами через единый OpenAI-совместимый API;
• Показывается настройка LiteLLM в Docker, подключение разных моделей, fallback-механизмы, кэширование запросов и встроенный веб-интерфейс;
• Объясняется, как упростить интеграцию ИИ в проекты, избежать привязки к одному провайдеру и снизить расходы на использование моделей.

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

🚪 Linux Ready | #статья

📂 Напоминалка для работы с Logical Volume Manager!

Например, lsblk помогает посмотреть структуру дисков, pvs, vgs и lvs показывают информацию о физических, групповых и логических томах, а lvextend позволяет расширить хранилище без переразметки диска.

На картинке — основные компоненты LVM: Physical Volume, Volume Group и Logical Volume, а также команды для создания, просмотра, изменения и управления дисковым пространством.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Отслеживаем действия пользователей в Linux через auditd!

Обычная история команд в Linux не всегда помогает понять, что произошло на сервере. Файл history можно очистить, команды могут выполняться через скрипты, а некоторые действия вообще выполняются не через shell.

Для контроля изменений файлов и действий пользователей используется auditd. Он работает на уровне системного аудита и позволяет увидеть, какой процесс выполнил операцию и какой пользователь был связан с этим действием.

Проверяем состояние службы аудита:

systemctl status auditd

Добавим правило для отслеживания изменений файла конфигурации SSH:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

Параметр -w указывает файл или каталог, за которым нужно следить. Опция -p wa означает отслеживание записи в файл (w) и изменения его атрибутов (a). Ключ -k добавляет идентификатор правила, по которому потом удобно искать связанные события.

Теперь изменим файл:

vim /etc/ssh/sshd_config

И найдём связанные события аудита:

sudo ausearch -k ssh_config -i

В выводе можно увидеть информацию о процессе и пользователе:

type=SYSCALL
comm="vim"
exe="/usr/bin/vim"
uid=1000
auid=1000
success=yes

Поле exe показывает, какой процесс выполнял действие. uid показывает пользователя, от имени которого выполнялся процесс, а auid — пользователя, который изначально вошёл в систему. Это важно, потому что при использовании sudo процесс может выполняться от имени root, но исходный пользователь будет сохранён в auid.

Например:

ivan -> sudo vim /etc/ssh/sshd_config

uid=0
auid=1000

Теперь видно, что действие выполнялось с правами root, но инициировал его пользователь ivan.

Например, нужно понять, кто изменил или удалил файл приложения:

sudo auditctl -w /opt/app/config.yml -p wa -k app_config

После удаления файла:

rm /opt/app/config.yml

Проверяем событие:

sudo ausearch -k app_config -i

В результате можно увидеть процесс, который выполнил операцию, и пользователя, от которого она была выполнена:

uid=deploy
auid=deploy
exe=/usr/bin/rm
success=yes

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

Также можно отслеживать изменения целых каталогов. Например, контроль изменений файлов systemd:

sudo auditctl -w /etc/systemd/system -p wa -k systemd_changes

После изменения unit-файлов ищем события:

sudo ausearch -k systemd_changes -i

Для постоянного хранения правил их добавляют в конфигурацию audit:

/etc/audit/rules.d/custom.rules

Например:

-w /etc/nginx/nginx.conf -p wa -k nginx_change

После изменения правил необходимо загрузить новую конфигурацию:

sudo augenrules --load

Правила, созданные через auditctl, являются временными и исчезнут после перезагрузки. Файлы в /etc/audit/rules.d/ позволяют сохранить настройки постоянно.

Для современных систем также стоит учитывать, что правила через -w являются старым форматом. Более гибкий вариант — использовать syscall-based правила, например:

-a always,exit -F path=/etc/nginx/nginx.conf -F perm=wa -k nginx_change

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

🔥 auditd помогает разобраться, что произошло в Linux: какой пользователь изменил файл, какой процесс выполнил действие и было ли оно успешным.

🚪 Linux Ready | #практика

📂 Напоминалка для работы с MAC-адресами в Linux!

Например, MAC-адрес 6C:54:63:E2:31:76 состоит из 48 бит (6 байт): первые 3 байта (OUI) определяют производителя устройства, а последние 3 байта (NIC) — уникальный идентификатор сетевого интерфейса.

На картинке — структура MAC-адреса, формат записи, а также служебные биты U/L и I/G, которые определяют тип адреса и способ его назначения.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

✍️ linuxfullroadmap — пошаговый roadmap по изучению Linux!

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

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

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

📂 Напоминалка по работе почтовых серверов!

Например, SMTP отвечает за передачу писем между серверами, а IMAP позволяет почтовым клиентам получать доступ к сообщениям через сервер.

На картинке — полный путь электронного письма: от поиска MX-записи в DNS, обработки сообщения на почтовом сервере, постановки в очередь до доставки получателю.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

👍 Полезная статья на Хабре: «Как я искал себе читалку и придумал новый формат электронных книг для изучающих язык»!

В этой статье:
• Автор рассказывает, почему обычные EPUB/FB2 и существующие приложения оказались неудобны для чтения книг на иностранном языке;
• Показывает идею собственного открытого формата двуязычных книг, где перевод нужного фрагмента можно получить прямо во время чтения;
• Разбирает, как с помощью LLM создавать переводы для книг и превратить обычное чтение в инструмент постоянной языковой практики.

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

🚪 Linux Ready | #статья

Как записать терминальную сессию Linux для последующего анализа с помощью script?

Во время диагностики проблемы или разбора инцидента часто нужно сохранить не только команды, но и весь процесс работы в терминале. История оболочки показывает только введённые команды, а > или tee не сохраняют полноценную интерактивную работу приложений. Для таких задач используется утилита script из пакета util-linux.

Она создаёт псевдотерминал (PTY) и записывает вывод терминальной сессии: результаты выполнения команд, вывод программ, работу интерактивных приложений и управляющие последовательности терминала. При необходимости отдельно можно сохранить и поток ввода пользователя. Начать запись:

script session.log

После запуска открывается новая интерактивная shell-сессия через PTY, а происходящее в терминале сохраняется в файл session.log. Завершить запись:

exit

или:

Ctrl+D

Если нужно сохранить интервалы времени между действиями для последующего воспроизведения:

script --log-timing=session.time session.log

Воспроизведение:

scriptreplay --timing=session.time session.log

Это удобно для разбора ошибок, демонстрации диагностики или анализа длительных операций.

Можно отдельно сохранить ввод пользователя, вывод терминала и временные интервалы:

script \
  --log-in=input.log \
  --log-out=output.log \
  --log-timing=timing.log

Будут созданы три файла: input.log — поток ввода пользователя, output.log — вывод терминала и timing.log — временные интервалы между событиями.

Важно: --log-in сохраняет именно ввод пользователя, поэтому туда могут попасть пароли, токены и другие чувствительные данные. Если нужен только вывод терминала:

script --log-out=session.log

Проверить журнал:

less session.log

Поиск ошибок:

grep "ERROR" session.log

Если лог содержит ANSI escape sequences или управляющие символы терминала, отображение может выглядеть некорректно. Так как script работает через PTY, это запись терминальной сессии, а не полноценный аудит действий пользователя. Для безопасности и контроля действий обычно используют специализированные инструменты, например auditd или системы session recording.

🔥 script — простой способ сохранить интерактивную терминальную сессию Linux без изменения привычного рабочего процесса. PTY позволяет получить один из самых полных вариантов сохранения контекста для анализа и разбора инцидентов.

🚪 Linux Ready | #практика

📂 Напоминалка по командам сетевой диагностики!

Например, mtr объединяет возможности ping и traceroute, позволяя анализировать маршрут и потери пакетов в реальном времени.

На картинке — основные утилиты для диагностики сети в Linux и их аналоги в Windows: назначение каждой команды, примеры использования и основные сценарии применения.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

📂 Напоминалка по инструментам для парсинга логов!

Например, grep используется для поиска по шаблонам, awk — для обработки структурированных данных, sed — для потокового редактирования текста, а jq — для анализа JSON.

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

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Как namei помогает быстро найти причину Permission denied!

Наверняка у вас была такая ситуация: файл существует, права на него вроде бы выставлены правильно, но вместо доступа получаете:

Permission denied

Смотришь на права файла — всё нормально. Меняешь владельца, проверяешь chmod — ничего не помогает. Во многих случаях проблема находится не в самом файле, а в одном из каталогов на пути к нему.

Чтобы обратиться к файлу, процесс должен иметь право прохода (x) через каждый каталог в цепочке. Именно поэтому проверка только ls -l у файла нередко ничего не показывает — проблема может быть на несколько уровней выше.

Быстро найти проблемное место помогает утилита namei. Например:

namei -l /var/www/app/storage/logs/app.log

Пример вывода:

f: /var/www/app/storage/logs/app.log
drwxr-xr-x root root     /
drwxr-xr-x root root     var
drwxr-x--- root www-data www
drwxr-xr-x app  app      app
drwx------ app  app      storage
drwxr-xr-x app  app      logs
-rw-r--r-- app  app      app.log

namei разбивает путь на отдельные компоненты и показывает права, владельца и группу для каждого каталога и самого файла. Благодаря этому не нужно вручную выполнять ls -ld для каждого каталога на пути — вся цепочка сразу перед глазами.

Но стоит помнить, что для каталогов право x означает возможность пройти через каталог и обратиться к объекту по известному имени, а не выполнить его. Поэтому даже если файл имеет права 644, процесс всё равно получит Permission denied, если хотя бы на одном из родительских каталогов отсутствует право x. Например, каталог:

drwx------ app app storage

доступен только владельцу. Поэтому процесс, запущенный от имени www-data, не сможет открыть файл внутри этого каталога, даже если сам файл доступен на чтение.

Чтобы убедиться, что проблема действительно в правах доступа, попробуйте открыть файл от имени пользователя, под которым фактически работает приложение:

sudo -u www-data cat /var/www/app/storage/logs/app.log

И не забудьте проверить, от какого пользователя действительно запущен процесс, который обращается к файлу. Например, для nginx:

ps -o user,group,pid,cmd -C nginx

Если права выглядят корректными, проверьте ACL. Желательно не только у файла, но и у каталогов на пути к нему:

getfacl /var/www/app/storage
getfacl /var/www/app/storage/logs
getfacl /var/www/app/storage/logs/app.log

Если и здесь всё в порядке, обратите внимание на SELinux или AppArmor — они тоже нередко становятся причиной Permission denied.

🔥 namei -l — одна из тех команд, которые экономят много времени при поиске причин Permission denied. Вместо проверки каждого каталога вручную вы сразу видите весь путь и права доступа на каждом уровне.

🚪 Linux Ready | #практика

📂 Напоминалка по AWK для Linux!

Например, awk '{print $1}' file.txt выводит нужное поле из строки, а awk -F ":" '{print $1}' /etc/passwd позволяет работать с данными, разделёнными специальными символами.

На картинке — основные возможности AWK: встроенные переменные, операторы, функции, регулярные выражения, массивы и конструкции для обработки текста, логов и автоматизации.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Можно открыть упавшее приложение в GDB спустя несколько дней, даже если вы не запускали его под отладчиком!

Многие воспроизводят падение заново, чтобы получить стек вызовов. Но если система использует systemd-coredump и core dump сохранился, вся необходимая информация для анализа может уже быть в системе.

Достаточно выполнить:

coredumpctl debug myapp

или указать PID:

coredumpctl debug 18432

coredumpctl найдёт нужный core dump, запустит GDB и подключит соответствующий исполняемый файл. Если доступны подходящие отладочные символы, вы сможете сразу приступить к анализу.

Можно посмотреть историю падений:

coredumpctl list

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

🔥 Если на машине используется systemd-coredump, возможно, всё необходимое для отладки уже сохранено в системе.

🚪 Linux Ready | #совет

😍 Linux Roadmap — большая подборка материалов для изучения Linux и DevOps!

Здесь собраны книги, курсы и практические руководства по Linux, Bash, командной строке, обработке текста, Docker, systemd, Kubernetes, Python, Vim и Git. Поможет разобраться не только с базовыми командами, но и с инструментами, которые используются в реальной работе разработчиков, DevOps-инженеров и системных администраторов.

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

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

📂 Напоминалка по JWT-токенам и API-ключам!

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

На картинке — сравнение двух популярных способов доступа к API: JWT-токены для управления сессиями и API-ключи для взаимодействия между сервисами.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс