У меня уже пару лет живёт в WSL на рабочем ноутбуке алиас, которым я пользуюсь практически каждый день. В нём нет ничего особенного, но может кому-то в голову не приходило такое сделать, поэтому делюсь.

Алиас этот делает одну простую вещь - выдаёт информацию об IP адресе. Я не знаю, как у остальных админов и девопсов проходит рабочий процесс, но мне постоянно приходится проверять те или иные адреса для различных целей.

В .bashrc алиас с простой функцией:

function ipa {
  curl -s https://ifconfig.co/json?ip=$1 | jq 'del(.user_agent)'
  }

Работает это так:

# ipa 104.21.80.1
{
 "ip": "104.21.80.1",
 "ip_decimal": 1746227201,
 "country": "United States",
 "country_iso": "US",
 "country_eu": false,
 "asn": "AS13335",
 "asn_org": "CLOUDFLARENET"
}

В выводе обрезается информация об user_agent, так как мне она не нужна, только внимание отвлекает. Если не указывать IP, а просто ввести ipa, то выводится информация о моём внешнем IP адресе.

Сервис ifconfig.co полностью бесплатен, не нужны ни регистрация, ни что-либо ещё. Просто берёшь и пользуешься.

При поиске информации об IP адресах и домене обычно приходится оперировать следующими командами. Проверка DNS записей:

# dig +short example.com A

Потом можно сразу же проверить эти IP адреса:

# ipa 23.215.0.138

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

# host 23.215.0.138

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #wsl

Какое-то дёрганное лето получается. Новые проблемы сыпятся, как из рога изобилия. Жара что ли на сервера так влияет? Расскажу историю очередной проблемы, с которой столкнулся. Там есть несколько поучительных моментов.

На одном проекте ночью упал Redis, сайт начал 500-ю ошибку отдавать. Нечасто такое случается. Редис если и упадёт, то обычно быстро поднимается, потому что используют его в основном под кэш в оперативной памяти, данные можно не сохранять.

Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.

У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.

В настройках systemd юнита Redis указан параметр Restart=always. Подробно на эту тему я делал отдельную заметку. Рекомендую ознакомиться, если не знаете. Данный параметр означает, что при любой причине завершения работы службы будет попытка поднять её. Я упоминал в той заметке, что не всегда это бывает полезно. И это как раз мой случай.

Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.

В общем случае с параметром Restart=always служба должна подняться автоматически. Я потестировал немного на отдельной виртуалке. Если Редису дать команду SIGSEGV, то он так же, как у меня вышло, скидывает свой трейс в лог, завершает работу и запускается заново. Проверить можно так:

# kill -SIGSEGV $(pidof redis-server)

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

# systemctl stop redis-server
# systemctl start redis-server

Так что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.

Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром Restart.

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

#linux #systemd #ошибка

Заметил неожиданное различие между системой Ubuntu и Debian, хотя казалось бы в этом контексте его быть не должно. Для замены шлюза по умолчанию в Ubuntu можно сделать так:

# ip route add default via 172.31.112.5
# ip route del default via 172.31.112.1

Сначала добавили новый, потом удалили старый. Команды нормально отработают. Заменяют шлюз 172.31.112.1 на 172.31.112.5. Та же самая последовательность команд на Debian не сработает:

# ip route add default via 172.31.112.5
RTNETLINK answers: File exists

Там сработает другая и более правильная, которую имеет смысл использовать в обеих системах.

# ip route replace default via 172.31.112.5

И дело тут не в версии утилиты ip. Специально проверил на Debian 12, где iproute2-6.1.0 и более старой Ubuntu 22, где версия старее - iproute2-5.15.0. Различия судя по всему системные.

А вообще в Ubuntu такое удобно делать через netplan. Меняем шлюз, потом на всякий случай проверяем конфигурацию и применяем её.

# netplan try

Если что-то не так, и связь потеряна, настройки откатятся обратно. Я хоть и не особо люблю Ubuntu за её частые изменения, которые не всегда нужны, но конкретно netplan удобен именно вот в этом try. В Debian никаких проверок нет. Если ошибся в конфигурации сети, то узнаешь об этом уже по факту, когда перезагрузишься или перезапустишь сеть через:

# systemctl restart networking

Лично мне формат конфигурационного файла /etc/network/interfaces в Debian максимально удобен и понятен. Не знаю, зачем тут нужен yaml или что-то ещё. Открыл, посмотрел, поправил. Не надо никакие пробелы и отступы ловить. Все интерфейсы в одном месте.

Не хватает проверки изменений перед их применением. Когда настраиваешь сеть на арендованных дедиках с Proxmox, почти всегда приходится менять этот файл с сетевыми настройками. И ошибка в них зачастую фатальна. Можно потерять доступ к серверу, если, к примеру, арендуешь подсеть внешних IP адресов и делаешь на них бридж, чтобы прокидывать реальные адреса виртуалкам. Поэтому я всегда эти вещи делаю сразу после установки системы и потом стараюсь настройки сети вообще не трогать. Чаще всего это и не нужно, если уже настроил и проверил.

Кстати, netplan можно установить в Debian, если очень хочется. Например, если в инфраструктуре используются обе системы, и Debian, и Ubuntu.

# apt install netplan.io openvswitch-switch
# systemctl enable --now systemd-networkd
# apt remove ifupdown

Дальше рисуем конфигурацию для netplan и применяем:

# netplan generate
# netplan try

Заметил, что если у вас в системе используется динамический IP адрес от DHCP сервера, то netplan try будет работать некорректно. Он будет получать новый IP адрес, если на DHCP сервере нет привязки этой системы на выдачу одного и того же IP адреса, и в итоге вас будет отключать от системы. Но откатить обратно сетевые настройки уже не получится. Система получит новый IP адрес и он применится. Вам придётся вручную к ней подключаться. Так что в любом случае надо аккуратно к изменениям сетевых настроек подходить.

❓Вам какой формат сетевых настроек больше нравится?
◽️Как в Debian /etc/network/interfaces
◽️Как в Ubuntu /etc/netplan/*.yaml
◽️Как в RHEL и форках в /etc/sysconfig/network-scripts/ifcfg-*

Не знаю, как сейчас в RHEL сеть настраивается. Не смотрел свежие версии. В старых всегда network-scripts использовал. А удобнее всего мне формат interfaces. Люблю, когда всё в одном файле, а не по нескольким раскидано.

#linux

В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.

Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.

Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.

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

Допустим, у нас работает виртуальная машина с диском в виде файла vm-109-disk-0.qcow2 и этот файл по какой-то причине был удалён в момент работы VM. То есть машина работает, а файла уже нет. Поверяем, реально ли файл удалён, но всё ещё открыт его дескриптор:

# lsof | grep '(deleted)'
kvm    402083            root  14u   REG        0,39 21478375424     17 /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)

Вы должны увидеть строки с упоминанием файла /var/lib/vz/images/109/vm-109-disk-0.qcow2. Значит, он реально ещё не удалён. Его держит процесс с пидом 402083. Проверяем это:

# ls -l /proc/402083/fd | grep deleted
lrwx------ 1 root root 64 Aug 3 21:16 14 -> /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)

Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:

# cp /proc/402083/fd/14 /var/lib/vz/images/109/vm-109-disk-0.qcow2

Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.

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

❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.

#restore #linux #terminal

Вспомнил про одну необычную утилиту из мира консоли Linux. Сначала даже не был уверен, что не писал о ней ранее. Оказалось, что реально не писал, только пару упоминаний мельком сделал. Речь пойдёт о faketime. Вспомнил, когда скрипты пересматривал к утренней публикации. Искал что-то для примера в прикреплённой картинке.

Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться faketime. Причём сделать это очень просто, потому что утилита с незапамятных времён живёт в базовых репах:

# apt install faketime

Приложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:

# faketime '2025-12-31 23:59:59' date
Wed Dec 31 23:59:59 MSK 2025

Передали утилите date указанное время, и она его вывела.

Я чаще всего утилиту использую, когда с помощью find удаляю что-то по меткам времени. Удобно запустить через faketime без удаления, просто чтобы проверить, как отработает поиск. Вообще всё, что связано с удалением, предварительно проверяю и только потом ставлю на исполнение. Иногда в скриптах комментирую строки с удалением, чтобы дождаться полного наполнения данными, чтобы потом прийти, вручную всё отладить и только потом включить ключ с удалением. Иначе рано или поздно из-за ошибки или невнимательности можно наделать дел.

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

# find . -type f -mtime +1

◽️mtime – время последнего изменения файла
◽️+1 - n*24 часа, в данном случае n=1, то есть 24 часа

Это информация из man find. Ты ожидаешь, что будут найдены все файлы с датой модификации более суток назад. Проверяем:

# touch filename.tar
# ls -l
-rw-r--r-- 1 root root 0 Aug 28 14:39 filename.tar

# faketime '2025-08-29 14:40:00' find . -type f -mtime +1

Создали файл 28 августа в 14:39, а в 29 августа в 14:40 ничего не находит, хотя мы взяли время более 24 часов вперёд.

# faketime '2025-08-30 14:40:00' find . -type f -mtime +1
./filename.tar

Уехали на 48 часов и 1 минуту вперёд и нашли файл. У find есть особенность, и в данном случае +1 это не 24 часа, а 48. А чтобы было именно 24 часа, надо использовать +0:

# faketime '2025-08-29 14:40:00' find . -type f -mtime +0
./filename.tar

Faketime позволяет проверить работу своих скриптов, заглянув в будущее.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal

☝️ Всё новое – хорошо забытое старое.

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

В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.

Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач

Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске

Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения

Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)

Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#подборка #linux #perfomance

Я делал заметку про небольшой набор полезных для меня алиасов в консоли bash, которые я использую в повседневной работе в WLS2 на базе Ubuntu в своей рабочей Windows 11. Также я отдельно и подробно описывал один из них, который выводит информацию об IP адресах.

Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:

$ dinfo yandex.ru
{
 "Checking the domain 'yandex.ru', please wait...": "",
 "Domain": "yandex.ru",
 "IP Address": "77.88.44.55 5.255.255.77 77.88.55.88",
 "Name Server": "Found 2 NS record",
 "Name Server 1": "ns1.yandex.ru (213.180.193.1)",
 "Name Server 2": "ns1.yandex.ru (213.180.193.1)",
 "Name Server 3": "ns2.yandex.ru (93.158.134.1)",
 "Name Server 4": "ns2.yandex.ru (93.158.134.1)",
 "Mail Server": "Found 1 MX record",
 "Mail Server 1": "mx.yandex.ru (77.88.21.249)"
}

Передаём на вход имя домена и на выходе получаем краткую информацию по нему:
◽️IP адреса на основе А записей
◽️NS записи
◽️MX записи

За основу взял вот этот скрипт. Он относительно простой. Парсится вывод утилиты host, про которую я отдельно писал ранее. Рекомендую взять на вооружение, регулярно пользуюсь.

Единственное, что я изменил - сделал вывод вместо обычного табличного в json. Мне почему-то так удобнее. Привык уже, возможно из-за подсветки. В общем, вывод сделал такой же, как у других алиасов.

Кстати, попросил ИИ помочь перевести изначальный вывод скрипта в json, напридумывали оба очень длинные потянки. Пришлось самому сделать, потратил 5 минут. Конкретно бесплатный ChatGPT и платный Perplexity AI нагенерировали мне простыню баша с sed и awk. Возможно надо было как-то промпт оформлять, чтобы получить то, что хотелось. Я просто взял две маленькие утилиты, про которые я тут раньше тоже уже писал - jc и jq:

$ view-domain-info.sh -d yandex.ru | jc --kv | jq .

А сам алиас, а точнее функция, выглядит вот так:

function dinfo {
  bash ~/alias_scripts/view-domain-info.sh -d $1 | jc --kv | jq .
  }

Эту строку надо добавить в файл ~/.bashrc и потом перечитать: source ~/.bashrc.

Хорошо, что я учился ещё в доИИшные времени. Честно говоря, даже не представляю, во что это всё в итоге выльется. Развитие ИИ сумасшедшее. Сам сейчас активно осваиваю и экспериментирую.

Ниже на картинке изначальный вывод и мой обработанный. Второй вариант можно использовать в задачах мониторинга, если каким-то образом наблюдаете за выводимы данными.

#linux #terminal

Я не так давно рассказывал про очень простую и наглядную интерпретацию метрики LA (Load Average). Данную тему будет уместно дополнить более современными метриками – PSI (Pressure Stall Information). Это подсистема ядра Linux, которая отслеживает три наиболее важных ресурса:

▪️CPU
▪️Memory
▪️I/O

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

PSI имеет 3 периода измерений: avg10, avg60, avg300. Это время в секундах, то есть 10 секунд, 1 минута и 5 минут. К периодам прилагаются два типа метрик:

🔹some - процент времени, когда хотя бы один процесс ждёт освобождение ресурсов (line indicates the share of time in which at least some tasks are stalled on a given resource)
🔹full - процент времени, когда все активные процессы находятся в ожидании освобождения ресурсов (line indicates the share of time in which all non-idle tasks are stalled on a given resource simultaneously)

Эти метрики можно и нужно использовать в повседневной работе, наравне с привычными LA, disk r/w, iops. В версии htop, начиная с 3.0.0, можно включить их отображение. По умолчанию они не отображаются. Включаются так:

Открываем htop ⇨ F2 ⇨ Meters ⇨ Aviable Meters ⇨ Выбираем нужные метрики, нажатием Enter ⇨ F10 выйти с сохранением.

В недавнем обновлении Proxmox эти метрики появились на стандартном дашборде.

PSI активно используется в systemd-oomd – современной замене OOM Killer. А точнее помощнике. На основе метрик PSI он более избирательно останавливает процессы, а не ждёт, как OOM Killer, когда закончится память, чтобы прибить самого жирного потребителя при прочих равных условиях.

На практике метрики PSI могут быстро помочь определить узкое место в системе. Например, у вас начала тормозить СУБД. Заходите на сервер и видите высокий LA. Но сама по себе эта метрика не даёт никакой конкретики. Может быть чрезмерно нагружен как процессор, так и диск. Рядом метрики cpu some и io some сразу ответят на вопрос, где у вас узкое место. Если оно реально в CPU, то не придётся лезть в дисковую подсистему и смотреть, что там происходит.

Изменение метрик в режиме реального времени позволяют сразу же оценить какие-то свои изменения и посмотреть, как они повлияли на нагрузку. В общем, это полезные метрики, которые имеет смысл по умолчанию выводить в htop. Не знаю, есть ли они в обычном top. Я на все свои сервера без исключения ставлю htop. Очень к нему привык. Там и PSI, и вкладка I/O с активностью диска, и lsof для просмотра открытых файлов, и strace. В общем, очень удобно.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #perfomance