Admin Guides | Сисадмин
Обучающий канал по ОС Linux & Windows для начинающих и действующих администраторов. Админ, реклама: @Ak_Mihail Биржа: https://telega.in/c/admguides РКН: https://kurl.ru/nQejS
Показати більше📈 Аналітичний огляд Telegram-каналу Admin Guides | Сисадмин
Канал Admin Guides | Сисадмин (@admguides) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 11 777 підписників, посідаючи 10 520 місце в категорії Технології та додатки та 55 309 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 11 777 підписників.
За останніми даними від 29 липня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 125, а за останні 24 години на 1, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 12.46%. Протягом перших 24 годин після публікації контент зазвичай збирає 6.97% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 1 468 переглядів. Протягом першої доби публікація в середньому набирає 821 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 10.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як ядро, /proc, grep, latency, linux.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Обучающий канал по ОС Linux & Windows для начинающих и действующих администраторов.
Админ, реклама: @Ak_Mihail
Биржа: https://telega.in/c/admguides
РКН: https://kurl.ru/nQejS”
Завдяки високій частоті оновлень (останні дані отримано 30 липня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
inotifywait -e close_write /etc/nginx/nginx.conf && nginx -t && systemctl reload nginx
Но это одноразово. Для постоянного мониторинга нужен цикл:
inotifywait -m -e close_write /etc/nginx/nginx.conf | while read -r; do
nginx -t && systemctl reload nginx
done
Проблема без debounce
Редактор вроде vim делает несколько операций при сохранении: создаёт временный файл, переименовывает, удаляет старый. inotifywait срабатывает несколько раз подряд на одно логическое сохранение. Reload запускается три раза вместо одного.
Debounce через sleep и проверку времени последнего события:
#!/bin/bash
CONFIG="/etc/nginx/nginx.conf"
LAST_RUN=0
DEBOUNCE=2
inotifywait -m -e close_write,moved_to "$CONFIG" 2>/dev/null | while read -r; do
NOW=$(date +%s)
if (( NOW - LAST_RUN > DEBOUNCE )); then
LAST_RUN=$NOW
nginx -t && systemctl reload nginx \
&& echo "$(date) reloaded" >> /var/log/nginx_autoreload.log
fi
done
Запускаем как systemd-сервис чтобы не умирал:
[Unit]
Description=Nginx config watcher
[Service]
ExecStart=/usr/local/bin/nginx_watcher.sh
Restart=always
[Install]
WantedBy=multi-user.target
⚡️inotifywait не видит изменения через bind mount или NFS, ядро не генерирует события для удалённых файловых систем. Если конфиг приезжает через ConfigMap в Kubernetes или NFS-шару, inotifywait не сработает, нужен polling или механизм самого оркестратора.find /usr/bin /usr/sbin -type f | while read -r bin; do
dpkg -S "$bin" &>/dev/null || echo "NOT IN PACKAGES: $bin"
done
На RHEL/CentOS:
find /usr/bin /usr/sbin -type f | while read -r bin; do
rpm -qf "$bin" &>/dev/null || echo "NOT IN PACKAGES: $bin"
done
Медленно на большом количестве файлов. Ускоряем через массовый запрос:
find /usr/bin /usr/sbin -type f -print0 \
| xargs -0 dpkg -S 2>&1 \
| grep "no path found" \
| awk -F': ' '{print $2}'
Добавляем проверку времени создания, свежие файлы подозрительнее:
find /usr/bin /usr/sbin -type f -newer /var/lib/dpkg/info -print0 \
| xargs -0 dpkg -S 2>&1 \
| grep "no path found" \
| awk -F': ' '{print $2}'
-newer /var/lib/dpkg/info фильтрует файлы появившиеся после последнего apt действия.
В cron для периодического аудита:
0 3 * * * /usr/local/bin/check_unknown_bins.sh >> /var/log/unknown_bins.logТакже поддерживается чтение данных S.M.A.R.T., встроенных датчиков процессора и температуры видеокарт.Что изменилось в HWMonitor 1.66: • улучшен отчёт о температуре в зонах перегрева видеокарт AMD Radeon RX 9000; • окно графика стало прозрачным.
ps aux | awk '$8 == "Z" {print $2, $11}'
Для каждого зомби находим родителя:
ps aux | awk '$8 == "Z" {print $2}' | while read -r pid; do
ppid=$(cat /proc/$pid/status 2>/dev/null | awk '/PPid/ {print $2}')
parent=$(ps -p "$ppid" -o comm= 2>/dev/null)
echo "zombie PID=$pid родитель PID=$ppid ($parent)"
done
Скрипт мониторинга с алертом
#!/bin/bash
THRESHOLD=5
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
LOG="/var/log/zombie_check.log"
zombies=$(awk '$8 == "Z" {count++} END {print count+0}' /proc/[0-9]*/status 2>/dev/null)
echo "$(date '+%Y-%m-%d %H:%M:%S') zombies: $zombies" >> "$LOG"
if [ "$zombies" -ge "$THRESHOLD" ]; then
details=$(ps aux | awk '$8 == "Z" {print $2, $11}' | head -10)
curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" \
-d text="⚠️ $zombies zombie-процессов на $(hostname)\n${details}"
fi
В cron каждые 5 минут:
*/5 * * * * /usr/local/bin/zombie_check.shСмотрим тренд:
grep zombies /var/log/zombie_check.log | tail -20
👀 Убить зомби через kill нельзя, он уже мёртв. Единственный способ: отправить SIGCHLD родителю чтобы он забрал exit code, или убить самого родителя. Если родитель это системный демон который плодит зомби, это баг в приложении который нужно фиксить, а не обходить.Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.❓Вопрос: Что такое epoll и почему он эффективнее select() и poll()? ✅Ответ: epoll — это механизм мультиплексирования ввода-вывода в Linux, предназначенный для эффективной работы с большим количеством сетевых соединений. Именно на нём построены современные веб-серверы, прокси и балансировщики нагрузки. Как это работает: • Приложение один раз регистрирует файловые дескрипторы в epoll через
epoll_ctl(). • Ядро самостоятельно отслеживает события на этих дескрипторах. • При вызове epoll_wait() возвращаются только те сокеты, на которых действительно произошло событие.realm join example.com -U AdministratorОн автоматически настроит SSSD, Kerberos и разрешения. Если без realmd — делаем вручную. 2️⃣ Настраиваем /etc/sssd/sssd.conf Пример минимального конфига:
[sssd]
domains = example.com
config_file_version = 2
services = nss, pam
[domain/example.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
fallback_homedir = /home/%u@%d
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
3️⃣ Права на файл конфигурации
chmod 600 /etc/sssd/sssd.conf
4️⃣ Запускаем и добавляем в автозагрузку
systemctl enable --now sssd
5️⃣ Настраиваем PAM
Обновляем /etc/pam.d/common-auth и common-session для вызова pam_sss.so и автоматического создания домашней директории.
Пример для common-session:
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
Сервис отвечает, CPU и I/O в порядке, но часть запросов периодически «подвисает». Задержка возникает не внутри приложения, а на этапе резолва - до установления соединения.Каждый getaddrinfo() может блокироваться: ожидание ответа от DNS, попытки по нескольким nameserver’ам, fallback с IPv6 на IPv4, поиск по search-доменам. При сетевых сбоях или медленных резолверах это превращается в десятки–сотни миллисекунд на каждый запрос. В асинхронных сервисах это особенно заметно: потоков много, а блокировка происходит в libc. Проверить, где теряется время:
strace -tt -e trace=network,connect,recvfrom,sendto -p <pid>
Если видны паузы на recvfrom/sendto к DNS-серверам - задержка вне приложения.
Посмотреть, какие резолверы используются:
cat /etc/resolv.conf
Порядок nameserver, наличие search и options напрямую влияет на количество попыток и время ожидания.
Проверить реальное время резолва:
dig +stats example.comЕсли время скачет или есть retries - проблема в DNS-инфраструктуре или сетевом пути. Дополнительно:
ss -u -a | grep :53
Позволяет увидеть активность UDP-запросов к DNS.#!/bin/bash
IFACES=("eth0" "eth1")
SNAPSHOT_DIR="/var/lib/iface_stats"
LOG="/var/log/iface_errors.log"
THRESHOLD=100
ERROR_KEYS="rx_errors tx_errors rx_missed_errors rx_fifo_errors
rx_crc_errors rx_frame_errors tx_aborted_errors
rx_length_errors rx_over_errors"
mkdir -p "$SNAPSHOT_DIR"
for iface in "${IFACES[@]}"; do
SNAP="$SNAPSHOT_DIR/${iface}.snap"
CURRENT=$(mktemp)
ethtool -S "$iface" 2>/dev/null | awk '{gsub(/:/,"",$1); print $1, $2}' \
| sort > "$CURRENT"
if [ ! -f "$SNAP" ]; then
cp "$CURRENT" "$SNAP"
rm "$CURRENT"
continue
fi
join "$SNAP" "$CURRENT" | while read -r key prev curr; do
for ekey in $ERROR_KEYS; do
if [ "$key" = "$ekey" ]; then
delta=$(( curr - prev ))
if [ "$delta" -ge "$THRESHOLD" ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') $iface $key +$delta" >> "$LOG"
fi
fi
done
done
cp "$CURRENT" "$SNAP"
rm "$CURRENT"
done
В cron каждые 5 минут:
*/5 * * * * /usr/local/bin/iface_stats.shСмотрим лог за сегодня:
grep "$(date '+%Y-%m-%d')" /var/log/iface_errors.log
Если конкретный счётчик растёт стабильно, смотрим подробнее:
ethtool -S eth0 | grep -E "crc|missed|fifo|frame"Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.❓Вопрос: Что такое S.M.A.R.T. и почему одного статуса PASSED недостаточно для оценки состояния диска? ✅Ответ: S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) - это система самодиагностики HDD и SSD, которая отслеживает десятки параметров, связанных с состоянием накопителя. Однако статус PASSED означает лишь то, что производитель не считает диск критически неисправным, а не то, что он полностью исправен. На что обращать внимание: • Reallocated_Sector_Ct - количество переназначенных секторов. • Current_Pending_Sector - нестабильные сектора, ожидающие повторной проверки. • Offline_Uncorrectable - сектора, которые не удалось прочитать. • Для SSD - Percentage Used, Media_Wearout_Indicator, объём записанных данных (TBW).
ip neigh show ip neigh show nud stale ip neigh show nud failednud stale - это записи, которые не подтверждались давно, но ещё не признаны мёртвыми. nud failed - это записи, где ARP-запрос не получил ответа. Скрипт проверки живости каждой записи
#!/bin/bash
IFACE=${1:-eth0}
STALE_LOG="/var/log/arp_check.log"
echo "=== ARP check $(date) ===" >> "$STALE_LOG"
ip neigh show dev "$IFACE" | while read -r ip _ _ _ mac state; do
[ "$ip" = "" ] && continue
[ "$mac" = "FAILED" ] && {
echo "FAILED: $ip" >> "$STALE_LOG"
continue
}
if ping -c 1 -W 1 -I "$IFACE" "$ip" &>/dev/null; then
status="OK"
else
status="UNREACHABLE"
echo "UNREACHABLE: $ip (mac: $mac, state: $state)" >> "$STALE_LOG"
fi
echo "$ip $mac $state -> $status"
done
Принудительное обновление устаревших записей
Если запись stale, ядро обновит её при следующем трафике. Но если нужно прямо сейчас:
ip neigh show nud stale | awk '{print $1}' | while read -r ip; do
ip neigh change "$ip" dev eth0 nud reachable 2>/dev/null || \
arping -c 1 -I eth0 "$ip" &>/dev/null
echo "Refreshed: $ip"
done
Удаляем записи которые не ответили на ping несколько раз подряд:
ip neigh show nud failed | awk '{print $1, $3}' | while read -r ip iface; do
ip neigh del "$ip" dev "$iface"
echo "Removed failed entry: $ip"
done
В cron раз в 15 минут:
*/15 * * * * /usr/local/bin/arp_check.sh eth0ss -tn state established '( dport = :443 or dport = :80 )'Скобки и пробелы обязательны, без них парсер не поймёт выражение. Фильтрация по состоянию и порту одновременно Все установленные соединения кроме SSH и loopback:
ss -tn state established \
'( not dport = :22 and not src 127.0.0.0/8 )'
Только соединения в TIME_WAIT старше определённого порога, полезно для детекта проблем с закрытием сокетов:
ss -tn state time-wait
ss -tn state time-wait | wc -l
Фильтрация по подсети источника или назначения
Все соединения от конкретной подсети, например найти кто из внутренней сети ломится на внешние адреса:
ss -tn state established 'src 10.0.0.0/8 and not dst 10.0.0.0/8'Или наоборот, внешние соединения к нашим портам:
ss -tn state established 'dst 10.0.0.0/8 and not src 10.0.0.0/8'Комбинируем с watch для живого мониторинга
watch -n 2 "ss -tn state established '( dport = :443 )' | wc -l"
Счётчик активных HTTPS-соединений в реальном времени без внешних инструментов.
Фильтрация UDP
ss -un 'dport = :53'Все UDP-сокеты которые отправляют DNS-запросы, полезно для детекта процессов которые ходят мимо локального резолвера. Смотрим с процессами:
ss -tunp state established \
'( not dst 10.0.0.0/8 and not dst 127.0.0.0/8 )' | \
awk '{print $NF}' | sort | uniq -c | sort -rn
Покажет какие процессы держат больше всего внешних соединений.Главными нововведениями стали экспериментальная поддержка именованных параметров в сигнатурах функций, алиасы в foreach, а также новый режим /xx для регулярных выражений, позволяющий разбивать классы символов на несколько строк и добавлять комментарии.Кроме того, Perl 5.44 получил поддержку Unicode 17.0, более безопасную генерацию случайных чисел через getentropy(), исправления нескольких уязвимостей и оптимизации производительности арифметических операций, сигнатур функций и работы с хэшами.
cat /proc/net/dev_snmp6/eth0
Вывод это пары ключ-значение: имя счётчика и его значение. Счётчики группируются по RFC: Ip6InReceives, Ip6OutForwDatagrams, Ip6InDiscards и так далее.
Ключевые счётчики на которые смотрим:
grep -E "InReceives|OutRequests|InDiscards|OutDiscards|InHdrErrors|InAddrErrors" \
/proc/net/dev_snmp6/eth0
InDiscards и OutDiscards это дропы на сетевом уровне, ненулевые значения требуют внимания. InHdrErrors говорят о битых пакетах или несовместимости реализаций.
Скрипт мониторинга с дельтами
Абсолютные значения бесполезны, нужна динамика:
#!/bin/bash
IFACE=${1:-eth0}
INTERVAL=60
FILE="/proc/net/dev_snmp6/$IFACE"
METRICS="Ip6InReceives Ip6OutRequests Ip6InDiscards Ip6OutDiscards"
declare -A prev
while IFS=" " read -r key val; do
prev[$key]=$val
done < "$FILE"
sleep $INTERVAL
echo "=== IPv6 stats delta for $IFACE ==="
while IFS=" " read -r key val; do
for m in $METRICS; do
if [ "$key" = "$m" ]; then
delta=$(( val - ${prev[$key]:-0} ))
echo "$key: +$delta"
fi
done
done < "$FILE"
Запускаем с указанием интерфейса:
./ipv6_monitor.sh eth0
Сравниваем несколько интерфейсов разом
for iface in /proc/net/dev_snmp6/*; do
name=$(basename $iface)
discards=$(grep "Ip6InDiscards" $iface | awk '{print $2}')
[ "$discards" -gt 0 ] && echo "$name: InDiscards=$discards"
done
Покажет только интерфейсы где есть дропы, остальные не шумят.