Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

Admin Guides | Сисадмин: post #3087 — TG.ME

Admin Guides | Сисадмин@admguides · 11.9K subscribers Open in TelegramOpen

t.me/admguides/3087

15

4

2

August 31, 2026 1.1K 3

More from this channel

lsblk -o +UUID,PARTUUID: когда UUID и PARTUUID ведут к разным объектам У диска и его раздела могут быть сразу несколько идентификаторов, и они не взаимозаменяемы Посмотрим их вместе: lsblk -o NAME,SIZE,FSTYPE,UUID,PARTUUID,MOUNTPOINTS Например: nvme0n1 ├─nvme0n1p1 vfat 7A3C-91F2 4f8a... /boot/efi └─nvme0n1p2 ext4 91c2... 8e21... / UUID относится к файловой системе PARTUUID относится к самому разделу в partition table Это принципиальная разница. Если выполнить: blkid /dev/nvme0n1p2 можно получить: UUID="91c2..." PARTUUID="8e21..." UUID меняется вместе с filesystem Например, для ext4 можно создать новую файловую систему: mkfs.ext4 /dev/nvme0n1p2 Раздел останется тем же, но filesystem UUID будет новым. Поэтому /etc/fstab, где используется: UUID=91c2... / ext4 defaults 0 1 после пересоздания filesystem перестанет находить старую файловую систему PARTUUID принадлежит разделу Если файловую систему внутри раздела пересоздать, PARTUUID обычно останется прежним. Но если удалить раздел и создать его заново, partition entry уже может получить другой идентификатор Посмотреть таблицу непосредственно можно: lsblk -o NAME,PARTUUID или: blkid -p /dev/nvme0n1p2 Где это становится особенно важным В Linux можно встретить: root=UUID=... в параметрах kernel command line А в некоторых конфигурациях используется: root=PARTUUID=... В первом случае kernel/initramfs ищет filesystem с определённым UUID Во втором - конкретный partition entry Поэтому после клонирования диска можно получить очень неприятную ситуацию: структура разделов и их PARTUUID скопированы, а UUID файловых систем тоже совпали В результате система или initramfs может обнаружить не тот экземпляр filesystem ⚡️Практическое правило: UUID отвечает на вопрос «какую файловую систему найти», а PARTUUID - «какой раздел найти» При диагностике загрузки, клонирования дисков и проблем с /etc/fstab важно сначала определить, какой именно идентификатор используется и к какому уровню устройства он относится 499·Sep 2

💬 Вопрос на собеседовании для сисадмина Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое split-brain в кластере и почему он опасен? ✅Ответ: Split-brain - это состояние кластера, при котором его узлы теряют связь между собой, но несколько частей кластера продолжают считать себя активными и пытаются одновременно управлять одними и теми же ресурсами. Как это происходит: • Кластер из нескольких узлов теряет сетевую связь между ними. • Каждый узел видит, что остальные недоступны, и может решить, что именно он должен продолжать обслуживать ресурс. • Два узла начинают одновременно работать с общим хранилищем, виртуальной машиной или IP-адресом. • В результате возникают конфликты, повреждение данных или двойная запись. 815·Sep 2

opensnoop: кто постоянно открывает файлы Бывает приложение начинает тормозить из-за огромного количества файловых операций, хотя CPU и диск выглядят нормально Например, процесс может тысячи раз в секунду проверять один и тот же отсутствующий файл, конфигурацию или каталог opensnoop позволяет увидеть эти обращения непосредственно на уровне syscall open, openat и openat2 ⏺Смотрим, кто открывает файлы opensnoop В выводе будут PID, процесс, результат операции и путь PID COMM FD ERR PATH 4217 app 12 0 /etc/app/config.json 4217 app -1 2 /etc/app/cache.db 4217 app -1 2 /tmp/app.lock FD=-1 означает, что открыть файл не удалось, а ERR=2 соответствует ENOENT - файла не существует ⏺Почему ошибки открытия особенно интересны Допустим, приложение постоянно делает: openat("/etc/app/cache.db") → ENOENT openat("/etc/app/cache.db") → ENOENT openat("/etc/app/cache.db") → ENOENT Файл отсутствует, поэтому I/O данных практически нет, но приложение продолжает выполнять системные вызовы и проходить путь поиска BCC прямо отмечает такой сценарий как возможную причину проблем с производительностью. Можно оставить только неудачные открытия: opensnoop -x Или ограничиться конкретным процессом: opensnoop -p 4217 ⏺А если обращений слишком много Для приложения, которое делает тысячи операций в секунду, вывод каждой строки сам становится неудобным. Можно вместо этого агрегировать события через bpftrace bpftrace -e ' tracepoint:syscalls:sys_enter_openat { @[comm, str(args.filename)] = count(); }' После остановки получим не тысячи одинаковых строк, а статистику @[app, "/etc/app/config.json"]: 18432 @[app, "/tmp/app.lock"]: 9217 @[app, "/proc/self/status"]: 4081 bpftrace использует kernel tracepoint для openat() и позволяет собирать статистику непосредственно в ядре, а не просто печатать каждое событие ⏺Что искать в результате Особенно подозрительны огромные количества обращений к одному и тому же несуществующему файлу, постоянное чтение конфигурации вместо её кэширования, бесконечный поиск библиотек или конфигов по нескольким каталогам и приложения, которые постоянно открывают /proc и /sys Важно и то, что opensnoop показывает именно попытки открытия, а не только успешные операции - поэтому через него можно увидеть ошибки, которые обычный мониторинг диска вообще не заметит ⚡️Это хороший пример ситуации, когда проблема выглядит как «приложение просто тормозит», хотя причина находится намного ниже - в тысячах повторяющихся системных вызовов openat() и неудачных поисках файлов 705·Sep 1

Только 2% запросов к git.kernel.org приходят от людей Инфраструктура kernel.org обрабатывает около 6 млн запросов в день, но лишь 2% из них считаются запросами реальных пользователей. Остальные создают боты и скрапперы. Они перебирают старые коммиты и ветки, отправляя миллиарды запросов вместо обычного git clone. При этом используют миллионы случайных IP из домашних и мобильных сетей, поэтому блокировка по IP почти не работает. Даже Anubis, который заставляет клиентов выполнять вычислительную задачу, боты научились обходить. В результате на пяти серверах 14–16 из 90 CPU-ядер постоянно уходят на обслуживание скрапперов. Команде приходится ограничивать анонимный доступ и отключать ресурсоёмкие функции. Простого решения пока нет: ИИ-компаниям нужны данные, а боты продолжают адаптироваться. 920·Sep 1

lsof +L1: почему удалённый файл продолжает занимать место Бывает, что файл уже удалили, а df продолжает показывать занятое место Причина в том, что процесс всё ещё держит файл открытым Находим такие файлы lsof +L1 Например: java 4217 app 12w REG 8,1 21474836480 /var/log/app.log (deleted) Файл больше не виден в каталоге, но его inode и блоки всё ещё принадлежат процессу java Почему rm не освобождает место При удалении файл сначала теряет имя в файловой системе Но данные остаются доступны через уже открытый файловый дескриптор Условно: /var/log/app.log ↓ rm inode ─────→ процесс Пока процесс не закроет FD, ядро не сможет освободить занятые блоки Можно увидеть сам дескриптор ls -l /proc/4217/fd/12 Получим: /var/log/app.log (deleted) А иногда нужно срочно освободить место, но перезапускать процесс нельзя Тогда содержимое открытого файла можно обнулить через /proc : > /proc/4217/fd/12 Размер файла станет нулевым, при этом процесс продолжит использовать тот же FD ⚡️ Поэтому ситуация df показывает занято, а du не находит часто объясняется именно deleted-open файлами du уже не видит файл в каталоге, а ядро продолжает учитывать его блоки до закрытия последнего дескриптора 937·Aug 31

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 09/02/2026 · v0.2.0 · 8721010

Privacy Terms DMCA & complaints Report a violation

Similar channels

Network Admin12.4K subscribers

BashMaster8.9K subscribers

ServerAdmin.ru32.5K subscribers

Linux / Линукс13.5K subscribers

Серверная Админа | Компьютерные сети26.7K subscribers

Типичный Сисадмин37.9K subscribers

Bash Days | Linux | DevOps23.7K subscribers

Лига сисадминов13.1K subscribers