При использование популярной в Linux утилиты ps чаще всего оперируешь PID процесса или грепаешь вывод по строке в имени процесса:

# ps -p 524 -o %mem,%cpu,cmd
# ps ax | grep prometheus

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

# ps -T -C prometheus
  PID  SPID TTY     TIME CMD
  525   525 ?    00:55:34 prometheus
  525   803 ?    00:03:10 prometheus
  525   808 ?    00:09:22 prometheus
  525  1054 ?    00:08:44 prometheus
  525  1113 ?    00:12:03 prometheus
  525  1129 ?    00:10:42 prometheus
  525  58983 ?    00:11:30 prometheus

Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:

# ps -T -C zabbix_server | wc -l
82

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

# ps ax | grep zabbix_server | wc -l
59

Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.

# ps -L -o spid,%mem,%cpu,cmd 508
SPID %MEM %CPU CMD
  1070 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1071 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1072 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1074 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1075 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1077 0.6 0.3 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:

# cat /proc/508/task/1077/stat
1077 (f2b/f.wp-login) ...................................

Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет status:

# cat /proc/508/task/1077/status

Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:

# strace -p 1077

Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ -o:

# strace -p 1077 -o ~/strace.out

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

# strace -p 1077 -e trace=openat,read

А для каких-то процессов будет иметь смысл следить за записью:

# strace -p 1077 -e trace=write

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

Трейсы в режиме реального времени можно посмотреть и в htop. Выбираете нужный процесс или поток и нажимайте s. Если strace установлена в системе, то увидите её работу.

Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.

📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools

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

#linux #terminal #perfomance

Одним из самых популярных репозиториев на github (21-е место по кол-ву звёзд) является репозиторий с ohmyzsh. Это фреймворк для создания конфигураций оболочки zsh. Для тех, кто не понимает, что это такое, скажу просто. Это сильно прокачанный по функциональности bash.

Никогда не понимал страсти и большой народной любви к zsh и ohmyzsh в частности. Хотя несколько раз пробовал. У меня и на рабочей станции, и на серверах всегда обычный bash. Мне кажется такое единообразие удобнее.

Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:

# apt install zsh
# wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
# sh install.sh

Дальше поверх этого делаются различные настройки

Основные возможности ohmyzsh:

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

◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.

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

С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.

А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.

#terminal #linux

В стандартном репозитории Debian живёт неприметная и не особо популярная программа sosreport. Создана она была, судя по названию, для служб технической поддержки. Тем не менее, полезна может быть не только им. Она создаёт архив со слепком состояния системы. Этот архив включает в себя практически всю информацию о системе:

◽️Настройки Grub
◽️Все конфигурационные файлы из раздела /etc
◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из /var/log и journalctl
◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно

По сути собрана вся доступная подробная информация о системе. Ставится так:

# apt install sosreport

Использовать удобнее всего так:

# sos report --batch --all-logs

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

Архив будет иметь имя вида sosreport-337737-2025-04-15-acgbmpx.tar.xz. Его можно распаковать и смотреть прямо тут, либо передать куда-то в другое место, распаковать и запустить сгенерированную html страничку sos.html, которая лежит в директории sos_reports.

Довольно удобная штука, чтобы быстро снять слепок состояния системы и потом спокойно его изучать, не боясь, что пока ты что-то ищешь или смотришь, состояние изменится. Так же предполагаю, что может быть полезно, например, раз в сутки делать такой слепок и складывать куда-то на некоторое время, просто на всякий случай. Архив получается маленький, проблем его хранить нет. Но в случае внештатной ситуации может помочь.

Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.

# /usr/bin/sosreport --batch -o process

Sosreport выполнит и сохранит вывод следующих команд:

# ps auxwww
# lsof -b +M -n -l -c ''
# ps auxwwwm
# ps alxwww
# ps -elfL
# ps axo pid,ppid,user,group,lwp,nlwp,start_time,comm,cgroup
# ps axo flags,state,uid,pid,ppid,pgid,sid,cls,pri,addr,sz,wchan:20,lstart,tty,time,cmd

Можно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей --upload, --upload-url, --upload-user, --upload-pass.

Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:

⇨ Мониторинг списка запущенных процессов в Zabbix

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

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

#linux #мониторинг

В Debian есть интересная библиотека libeatmydata, которая подменяет системные вызовы fsync, fdatasync, sync и некоторые другие на пустышки. Эти команды сразу выдают положительный результат, ничего не делая. То есть не работает подтверждение записи на диск.

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

Работает это примерно так:

int fsync(int fd) {
    return 0;
}

Реально там ещё пару проверок с if, но по сути всё так и есть для всех системных вызовов, что она она перехватывает.

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

# apt install eatmydata

Запускаем через него любую команду. Я протестировал на старой виртуалке, которую давно не обновляли. Сделал запуск обновления без eatmydata и с ней. Разница получилась заметной.

Напомню, что реальной установкой пакетов занимается утилита dpkg, а не apt. Dpkg для надёжности выполняет все действия с подтверждением записи. Так что если запустить её через eatmydata, она отработает гораздо быстрее.

Я выполнил полное обновление пакетов в два этапа, откатив первое обновление на изначальный снепшот:

# time apt upgrade -y
Fetched 249 MB in 30s (8,183 kB/s)
real 1m 43.690s

# time eatmydata apt upgrade -y
Fetched 249 MB in 33s (7,671 kB/s)
real 1m 36.984s

Работа dpkg занимает где-то треть всего времени, ещё треть загрузка пакетов, и треть пересборка initramfs. Без eatmydata dpkg работала примерно 30 секунд, с ней – 20.

Или вот ещё более наглядный тест. Запускаем создание файла в режиме синхронизации и подтверждения записи каждого блока:

# dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync
536870912 bytes (537 MB, 512 MiB) copied, 1.95211 s, 275 MB/s

И то же самое через eatmydata:

# eatmydata dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync
536870912 bytes (537 MB, 512 MiB) copied, 0.343773 s, 1.6 GB/s

Эта возможность может пригодиться при сборке контейнеров, образов, раскатки тестовых сред. Можно запускать тестовую СУБД через eatmydata. Да всё, что угодно на тестовом сервере.

Если у вас есть какие-то скрипты, которые не хочется переделывать, добавляя в начало каждой команды eatmydata, можете просто задать переменную окружения, в том числе глобальную в /etc/environment:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so

И все процессы будут писать без подтверждения записи в кэш.

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

#linux

Настраивал на днях арендованный сервер без прямого доступа к консоли. Ещё и конфигурация была нестандартная, так что техподдержка вручную установила туда ОС и отдала мне с доступом по SSH. Нужно было настроить дополнительные диски и добавить их в fstab. Несмотря на то, что в современных ОС реально монтирует диски systemd, я по старинке предпочитаю добавлять новые точки монтирования в fstab.

В этом деле самое главное – не ошибиться и сразу после изменения файла проверить, что там всё в порядке. Иначе после перезагрузки можно получить проблемы. Без прямого доступа к консоли это может быть фатально.

Я обычно добавляю новые диски в систему следующим образом. Смотрю список дисков через fstab:

# fdisk -l | grep /dev/

Сразу видно диски без разметки. Добавлять разделы предпочитаю в cfdisk, а не напрямую в консоли через fstab. В TUI как-то нагляднее, меньше шансов ошибиться.

# cfdisk /dev/sdb

Создаю раздел, выбираю тип раздела, сохраняю. После этого можно создавать файловую систему.

# mkfs -t ext4 /dev/sdb1

Монтирую в систему:

# mkdir /mnt/disk1
# mount /dev/sdb1 /mnt/disk1

Теперь нам надо добавить эту точку монтирования в fstab. По имени диска категорически нельзя добавлять. Диски могут менять свои имена. Причём это стало актуально в какой-то момент с очередным обновлением железа. Когда я только начинал изучать Linux, спокойно монтировал по именам дисков и проблем не было. В какой-то момент они начались. И сейчас я сам часто наблюдаю, что диски, как и сетевые интерфейсы, могут изменить свои имена после перезагрузки. Если используете LVM, то можно добавлять точки монтирования по имени LV.

Смотрим UUID раздела:

# blkid | grep /dev/sdb1

Добавляем его в fstab отдельной строкой:

UUID=eaf5c153-08b7-4ea8-8037-e6baad4cac0d /mnt/disk1 ext4 errors=remount-ro 1 0

А теперь проверяем, всё ли мы правильно добавили.

# findmnt --verify --verbose

Findmnt проверил все монтирования. В моём случае я получил предупреждение на /media/cdrom0.

[W] unreachable source: /dev/sr0: No such file or directory

Судя по всему систему ставили с какого-то диска, локального или сетевого, не знаю, но он остался в fstab. Делать ему там больше нечего, можно закомментировать строку с ним.

Более кратко можно получить информацию только об ошибках:

# findmnt -x

☝️Отдельно обращаю внимание на такой момент. До перехода управления к systemd было критически важно оставлять в fstab в конце файла переход на новую строку. Сейчас даже если этого не сделать, то проблем не будет. Всё нормально загрузится. Насколько я понимаю, это тянется из далёкого прошлого и POSIX-совместимой практики, когда файлы конфигурации заканчивались переходом на новую строку. Я лично до сих пор на всякий случай везде этой практики придерживаюсь.

Ещё один способ проверить корректность записей в fstab – использовать mount. Можно не монтировать вручную новый диск, а сразу добавить его в fstab. Потом запустить:

# mount -a -v

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

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

Сразу понял, в чём дело, зашёл в режим обслуживания и поправил fstab. Так что внимательно относитесь к его настройке. Этой проблемы можно избежать, если использовать nofail в параметрах монтирования. Но с ним могут быть нюансы. Иногда лучше не загрузиться, если с разделом проблемы.

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

#linux