Как диагностировать рассинхронизацию времени!

Некорректное системное время приводит к сбоям TLS, аутентификации, логирования и распределённых систем. Ниже — компактный чек-лист диагностики.

Общее состояние времени:

timedatectl

Показывает текущее время, статус синхронизации и RTC.
RTC in local TZ = yes на серверах — плохая практика; рекомендуется UTC.

Кто управляет временем:

systemctl is-active systemd-timesyncd chronyd chrony ntp ntpd 2>/dev/null || true
systemctl status    systemd-timesyncd chronyd chrony ntp ntpd 2>/dev/null || true

Важно, чтобы реально корректировал время только один механизм.

Качество синхронизации:

timedatectl timesync-status
timedatectl show -p NTPSynchronized -p NTP
chronyc sources -v

timesync-status актуален только для systemd-timesyncd; для chrony используйте chronyc.

Резкие коррекции времени:

journalctl -u systemd-timesyncd -u chronyd -u ntp -u ntpd | \
grep -iE "step|jump|offset|slew|clock"

Помогает выявить скачки и принудительные корректировки.

RTC и перезагрузки:

hwclock --show

Большое расхождение между RTC и system clock проявляется после ребута, особенно если NTP не стартует сразу.

Виртуализация:

systemd-detect-virt
dmesg | grep -iE "kvm|hyper-v|vmware|xen|clock|timesync|ptp"

Guest-tools и гипервизор могут конфликтовать с NTP внутри гостя.

Базовая настройка:

timedatectl set-ntp true        # systemd-timesyncd
systemctl enable --now chronyd # chrony
timedatectl set-local-rtc 0    # RTC в UTC

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

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

Нагружаем приложение и смотрим, как оно себя ведёт!

Сегодня прогоняем тестовое веб‑приложение через обычную нагрузку и простейшую «атаку», чтобы увидеть разницу по метрикам и логам. Всё через терминал и пару утилит: hey/ab для нагрузки и curl для имитации агрессивного клиента.

Сначала замерим «здоровое» состояние с равномерной нагрузкой:

hey -z 30s -c 20 http://localhost:8080/

За 30 секунд получим средний RPS, latency и процент ошибок. Это будет базовый уровень, с которым будем сравнивать.

Теперь устроим «атаку» с одного IP — резкий всплеск запросов:

hey -z 30s -c 200 http://localhost:8080/login

Следим в это время за приложением:

tail -f app.log
htop

В логах увидишь частые обращения к одному эндпоинту и рост 5xx/4xx, а по ресурсам — скачок CPU/памяти.

Можно вынести это в простой скрипт:

load_test() {
  hey -z 20s -c 30 "$1"
  hey -z 20s -c 200 "$1"
}
load_test "http://localhost:8080/login"

🔥 Так удобно быстро смотреть, где приложение начинает «сыпаться» под нагрузкой: код, база или сеть.

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

FIFO в Linux: именованные пайпы для связи процессов без файлов!

Если нужно связать разные процессы, скрипты или shell’ы — используй FIFO (именованный канал).

Создаём канал:

mkfifo /tmp/myfifo

Чтение из канала (блокируется, пока нет данных):

cat /tmp/myfifo

Запись в канал — из другого процесса или терминала (может блокироваться, если нет читателя):

echo "hello world" > /tmp/myfifo

🔥 Данные передаются напрямую через ядро, без сохранения в файл на диске (буферизация — в памяти ядра).

🚪 Linux Ready | #совет

☕️ Kernel Newbies — сообщество и база знаний по Linux!

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

📌 Оставляю ссылочку: kernelnewbies.org

🚪 Linux Ready | #сайт

Низкоуровневый аудит процесса в Linux!

Когда top и htop уже не дают ответов, вся реальная картина состояния процесса находится в /proc.

Аргументы запуска процесса (argv):

cat /proc/PID/cmdline | tr '\0' ' '

Показывает текущие аргументы процесса. Полезно для диагностики, но argv может быть изменён самим процессом и не всегда отражает исходную команду запуска.

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

/usr/bin/python3 worker.py --queue=emails --env=prod

Память процесса:

cat /proc/PID/status | grep -E 'VmRSS|VmSize|VmSwap'

VmRSS — реально занятая RAM

VmSize — виртуальное адресное пространство процесса

VmSwap — объём, вытесненный в swap

Пример:

VmRSS:   412384 kB
VmSwap:   65536 kB

Детальная карта памяти процесса:

cat /proc/PID/smaps

Позволяет понять, где именно расходуется память: private, shared, file-backed. На больших процессах может быть тяжёлым.

Открытые файлы и сокеты процесса:

ls -l /proc/PID/fd

Здесь видны логи, сокеты, pipes и удалённые файлы, которые всё ещё удерживаются процессом (доступ зависит от прав).

Количество потоков внутри процесса:

ls /proc/PID/task | wc -l

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

Реальный исполняемый файл процесса:

readlink /proc/PID/exe

Права и capabilities процесса:

cat /proc/PID/status | grep Cap

🔥 Короткая практическая выжимка для анализа процессов на уровне procfs/ядра.

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

Как гарантировать, что скрипт или команда не запустится дважды?

Часто cron запускается повторно, деплой стартует дважды, скрипт пересекается сам с собой.

PID-файлы — ненадёжны.
Проверки через ps — гонки.

В Linux есть решение — flock.
Запустить команду, только если она ещё не выполняется:

flock -n /tmp/deploy.lock deploy.sh

Если блокировка занят, flock завершится с ошибкой, команда не стартует.

Для скриптов ещё надёжнее:

exec 9>>/tmp/job.lock
flock -n 9 || exit 1

С этого момента гарантированно: только один экземпляр, блокировка снимается автоматически при exit.

🔥 flock — это advisory-блокировка ядра с атомарной установкой, а не договорённость скриптов. Используйте её для cron, деплоя, миграций, бэкапов и CI-шагов.

🚪 Linux Ready | #совет

Как быстро и безопасно работать с большими файлами в Linux!

Большие логи, дампы, CSV, JSON, бэкапы — с ними сталкиваются почти все. Неправильная работа с такими файлами часто приводит к зависаниям терминала, высокой нагрузке и потере времени.

Быстрый просмотр начала файла:

head -n 50 huge.log

Просмотр конца файла (самый частый кейс для логов):

tail -n 50 huge.log

Постраничный просмотр без загрузки файла в память:

less huge.log

Полезные режимы:

-F — выход, если файл помещается на экран
-S — без переноса строк
+F — режим tail -f (follow)

Поиск по огромному файлу с ограничением результатов:

grep -n -m 10 "ERROR" huge.log

Подсчёт количества строк:

wc -l huge.log

Читает файл последовательно и обычно быстрее любых текстовых редакторов.

Быстрое извлечение диапазона строк:

sed -n '100000,100200p' huge.log

Разделение большого файла на части:

split -l 500000 huge.log part_

Полезно для передачи, обработки или параллельного анализа.

Обработка с индикатором прогресса:

pv huge.log | grep "ERROR" > errors.log

pv показывает скорость и объём обработки (утилита может быть не установлена по умолчанию).

Безопасное массовое изменение содержимого:

sed 's/old_value/new_value/g' huge.log > huge.log.new && mv huge.log.new huge.log

Изменение через временный файл — надёжнее, чем sed -i, особенно для больших файлов.

🔥 Эти приёмы позволяют уверенно работать с файлами любого размера даже на слабых серверах и ноутбуках.

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

🧐 На Хабре вышла интересная статья про автоматизацию tmux-окружения с помощью скриптов.

В этой статье:
• Научитесь запускать tmux-сессии в фоне и управлять ими из bash-скрипта;
• Автоматически поднимете несколько окон и панелей с нужными командами;
• Разберётесь с new-session, new-window, split-window и send-keys для сценариев «всё готово за один запуск»;
• Соберёте удобный шаблон, который можно адаптировать под разработку, мониторинг или отладку.

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

🚪 Linux Ready | #статья

Проверка активных DNS-серверов!

Определим, какие DNS-резолверы использует система, проверим их доступность и сравним задержку ответов при разрешении домена.

Показать текущие DNS-серверы в systemd-resolved (основной современный способ):

resolvectl status

Вывод показывает DNS-серверы по интерфейсам, текущий активный резолвер (Current DNS Server) и список upstream DNS (DNS Servers).

Посмотреть, что указано в resolv.conf:

grep -E "^nameserver" /etc/resolv.conf

Важно: в системах с systemd-resolved файл часто содержит локальный stub-адрес 127.0.0.53, поэтому не отражает настоящие upstream DNS.

Замерить задержку ответа конкретного DNS-сервера при резолве домена:

dig @1.1.1.1 example.com +stats | grep "Query time"
dig @8.8.8.8 example.com +stats | grep "Query time"

Формат результата:

;; Query time: XX msec

Задержка зависит от сети, маршрута и кэша. Для объективной оценки рекомендуется выполнять серию запросов и учитывать влияние кэширования, DNSSEC, VPN/Split-DNS и search-доменов.

Проверка базовой работоспособности резолвинга:

nslookup example.com

Если возвращается IP-адрес — в целом разрешение имён работает.

🔥 Понимание активных DNS-серверов — базовый шаг диагностики сети, особенно когда доступ по IP есть, но доменные имена не разрешаются.

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

Знали, что «битый» YAML-файл может уронить весь CI/CD пайплайн еще до того, как начнется деплой?

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

Самый быстрый способ проверить файл без установки лишнего софта — встроенные возможности Python:

python3 -c 'import yaml, sys; yaml.safe_load(sys.stdin)' < deployment.yaml

Если файл валиден, команда ничего не выведет, если есть ошибка, то ты получишь точную строку и номер символа.

Для продвинутой проверки с учетом лучших практик используй специализированный линтер:

yamllint -d relaxed config.yaml

Это подсветит не только ошибки синтаксиса, но и нарушение стилистики (слишком длинные строки, лишние пробелы в конце).

Добавь проверку в pre-commit хук своего репозитория, чтобы ошибки вообще не попадали в Git:

- repo: https://github.com/adrienverge/yamllint.git
  rev: v1.33.0
  hooks:
    - id: yamllint

🔥 Маленькая проверка на входе экономит десятки минут ожидания «красного» пайплайна в GitLab или GitHub.

🚪 Linux Ready | #совет

Как мгновенно откатить ошибочную команду в shell!

Запустил команду и сомневаешься, что она делает? Повтори последнюю команду без выполнения, просто выведи её:

!!:p

!! — последняя команда из истории, :p — print only.

Хочешь, чтобы при повторе команда сначала появлялась в терминале для проверки, а не исполнялась сразу?

shopt -s histverify

Теперь при вводе:

!!

🔥 Команда вставится в строку, но не выполнится, пока не нажмёшь Enter. Если увидел, что это не то — просто редактируй или отменяй.

🚪 Linux Ready | #совет