Факты

😎 PyLinux | #memes

🔐 Проверка выхода из строя systemd-сервисов в Linux

Многие фоновые службы в Linux (nginx, sshd, docker и др.) управляются через systemd. Если какая-либо из них падает или перезапускается слишком часто — это повод для внимания. Этот скрипт проверяет логи на сбои systemd-сервисов и логирует их.

⚙️ Исходный код

#!/bin/bash

LOG_FILE="/var/log/systemd_failed_services.log"
echo "🧭 Проверка systemd-сервисов... $(date)" | tee -a "$LOG_FILE"

# Получаем список сервисов со статусом failed
FAILED=$(systemctl --failed --no-legend --plain)

if [ -n "$FAILED" ]; then
    echo "❌ Обнаружены сбои в systemd-сервисах:" | tee -a "$LOG_FILE"
    echo "$FAILED" | tee -a "$LOG_FILE"
else
    echo "✅ Все сервисы в норме." | tee -a "$LOG_FILE"
fi

echo "🔚 Проверка завершена." | tee -a "$LOG_FILE"

🟢 systemctl --failed показывает службы с ошибками
🟢 Удобно логировать и подключить в cron для регулярной проверки
🟢 Можно дополнить email/TG-уведомлениями для быстрого реагирования

➡️ Добавьте в crontab:

*/30 * * * * /path/to/systemd_check.sh

🗣 Подходит для серверов, рабочих станций, CI-сред — чтобы быть в курсе, если что-то важное перестало работать (например, ssh, cron, nginx, docker, postgres и др.).

😎 PyLinux | #scripts

🔜 Как я разработал скрипт для загрузки данных и разгрузил ИТ-отдел

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

🖥 Перейти к статье

😎 PyLinux | #articles

➡️ Нашел идеальный Линукс! CachyOS: Оптимизированный Arch для Всех! Мнение и Опыт

В этом видео я делаю обзор дистрибутива CachyOS — Arch-ориентированной системы, разработанной с упором на производительность и оптимизацию под современные ПК.

📱 Ссылка на источник

😎 PyLinux | #videos

Других причин не вижу... 🌚

😎 PyLinux | #memes

🔒 Управление и отладка заданий cron в Linux

Cron — это мощный планировщик задач. Но отладка и правильная настройка crontab требует точности. Ниже — практичные команды для контроля, диагностики и логирования.

📌 Полезные команды

# Открыть crontab текущего пользователя
crontab -e

# Просмотреть текущие задания cron
crontab -l

# Просмотреть cron-доступность пользователя
cat /etc/cron.allow
cat /etc/cron.deny

# Проверить системные задания (cron root)
sudo cat /etc/crontab

# Проверить cron'ы в отдельных директориях
ls /etc/cron.hourly/
ls /etc/cron.daily/
ls /etc/cron.weekly/
ls /etc/cron.d/

# Проверка, исполняются ли задания cron
grep CRON /var/log/syslog     # Debian/Ubuntu
grep CRON /var/log/cron       # RHEL/CentOS

# Лог всех ошибок cron
grep -i error /var/log/syslog | grep CRON

# Протестировать команду как cron бы её выполнил
SHELL=/bin/bash PATH=/usr/bin:/bin /your/command.sh

# Проверить переменные окружения cron
crontab -l | grep -E '^(SHELL|PATH|MAILTO|HOME)'

# Подсказка: cron по умолчанию шлёт stdout/stderr на email (MAILTO)

🟢 crontab -e редактирует задачи без sudo
🟢 grep CRON — полезно для логирования и дебага
🟢 Проверка $PATH особенно важна — cron запускается с минимальным окружением

🗣 Эти команды помогут быстрее находить, устранять и автоматизировать задачи cron, не оставляя их "тихо неработающими".

😎 PyLinux | #linux

🔜 Вглубь Synology NAS: метаданные, Btrfs и скрытые механизмы высокой производительности

Разбираюсь, как Synology ускоряет NAS: от кеша inode и фрагментации Docker до предсказаний IO и трюков с Btrfs. Это не просто коробка для бэкапов. Это инженерный тетрис.

🖥 Перейти к статье

😎 PyLinux | #articles

👩‍💻 Библиотека Python: jaxtyping

jaxtyping — это библиотека для декларативного описания размерностей и типов массивов (numpy, torch, jax) прямо в type hints. Она усиливает проверку типов при работе с тензорами, помогая ловить ошибки ещё до выполнения кода.

Идеальна для научных вычислений, ML/AI, CV — когда важна строгая типизация массивов и предсказуемость размерностей.

⚙️ Пример использования

from jaxtyping import Float, Int64
import torch
from typing import Callable

# Функция принимает Float32 тензор размером (batch, 3)
def normalize(x: Float[torch.Tensor, "batch 3"]) -> Float[torch.Tensor, "batch 3"]:
    return x / x.norm(dim=1, keepdim=True)

# Пример с проверкой
x = torch.randn(32, 3)
normalize(x)  # ✅

➕ Преимущества:

🟢 Проверка shape и dtype прямо в аннотациях
🟢 Поддержка PyTorch, NumPy, JAX
🟢 Совместима с mypy и runtime type checking
🟢 Обнаруживает ошибки в размере входных данных при разработке моделей

✔️ Установка

pip install jaxtyping

➡️ Ссылка на документацию

😎 PyLinux | #python_libs

Тот самый тим лид

😎 PyLinux | #memes

🔐 Анализ повторных перезапусков systemd-сервисов в Linux

Службы, которые часто перезапускаются, могут перегружать систему или указывать на скрытые проблемы (утечки памяти, падения, ошибки конфигурации). Этот скрипт ищет systemd-сервисы, перезапускавшиеся более X раз, и логирует их.

⚙️ Исходный код

#!/bin/bash

LOG_FILE="/var/log/systemd_restart_watch.log"
RESTART_THRESHOLD=3

echo "🔄 Анализ перезапусков systemd-сервисов... $(date)" | tee -a "$LOG_FILE"

# Получаем список активных сервисов
for svc in $(systemctl list-units --type=service --no-pager --no-legend | awk '{print $1}'); do
    # Извлекаем число рестартов
    RESTARTS=$(journalctl -u "$svc" --since "1 hour ago" | grep -c "Starting")
    if [ "$RESTARTS" -gt "$RESTART_THRESHOLD" ]; then
        echo "⚠️ Сервис $svc перезапущен $RESTARTS раз(а) за последний час" | tee -a "$LOG_FILE"
    fi
done

echo "✅ Проверка завершена." | tee -a "$LOG_FILE"

🟢 systemctl list-units — список всех активных сервисов
🟢 journalctl — журнал перезапусков
🟢 Скрипт выводит сервисы, которые ведут себя нестабильно
🟢 Порог (RESTART_THRESHOLD) можно адаптировать под систему

➡️ Добавьте в crontab:

*/20 * * * * /path/to/systemd_restart_watch.sh

🗣 Особенно полезно для DevOps-инженеров, системных админов, SRE-команд — когда важно не просто знать, что сервис упал, а выявить нестабильные процессы до сбоя

😎 PyLinux | #scripts

🔜 SonarQube: базовая настройка и анализ качества кода с помощью FastAPI

Показываю, как прикрутить SonarQube к FastAPI, настроить анализ через Docker и CI, чтобы ловить баги до запуска. Автоматизируем проверку, избавляемся от «запахов».

🖥 Перейти к статье

😎 PyLinux | #articles

➡️ Роадмап Python разработчика — Что учить [2025]

30 минут отговариваю учить ненужные темы по Python.

📱 Ссылка на источник

😎 PyLinux | #videos

😎 PyLinux | #memes

🔒 Диагностика и мониторинг systemd timers в Linux

Системные таймеры на основе systemd — современная альтернатива cron.

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

📌 Полезные команды

# Показать все активные и неактивные таймеры
systemctl list-timers --all

# Показать только активные таймеры с временем запуска
systemctl list-timers

# Узнать подробности о конкретном таймере
systemctl status myjob.timer

# Посмотреть привязанный unit (например, сервис, который запускает таймер)
systemctl cat myjob.timer

# Немедленно запустить задачу вручную (для теста)
systemctl start myjob.service

# Проверить последние запуски и логи таймера
journalctl -u myjob.service

# Проверить системные таймеры и их состояние
systemctl list-timers | grep -v "0 loaded units listed"

# Пример создания таймера и сервиса:
# 1. /etc/systemd/system/myjob.service
[Unit]
Description=Custom job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/myscript.sh

# 2. /etc/systemd/system/myjob.timer
[Unit]
Description=Run custom job every hour

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

# 3. Активировать таймер
sudo systemctl daemon-reexec
sudo systemctl enable --now myjob.timer

🟢 systemctl list-timers — как crontab -l, только лучше
🟢 Таймеры можно запускать от любого пользователя
🟢 Persistent=true гарантирует запуск после пропуска (например, при выключенном ПК)
🟢 Логи идут в journalctl — удобно отлаживать

🗣 Отлично подходит для DevOps, администраторов и всех, кто хочет более надёжное планирование задач, чем cron, с логами и гибкостью systemd.

😎 PyLinux | #linux

🔜 Livepatching для ядра Linux на x86 и RISC-V: как это работает

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

🖥 Перейти к статье

😎 PyLinux | #articles

👩‍💻 Библиотека Python: pyinstrument

pyinstrument — это минималистичный, но мощный профилировщик производительности. Он показывает, что именно замедляет выполнение Python-программы, и в каком участке кода тратится больше всего времени — в виде читаемого дерева вызовов.

Идеален для быстрого анализа "узких мест" в скриптах, API, CLI и любом CPU-bound коде.

⚙️ Пример использования

from pyinstrument import Profiler

profiler = Profiler()
profiler.start()

# код, который нужно проанализировать
total = 0
for i in range(1000000):
    total += i ** 0.5

profiler.stop()
profiler.print()


Timer started at: 15:20:42
Total time: 0.42s

Program:
0.420s  [self]  your_script.py:7
└─ 0.420s  your_script.py:10  total += i ** 0.5

➕ Преимущества:

🟢 Визуальное дерево вызовов прямо в терминале
🟢 Работает без модификации кода — можно обернуть main()
🟢 Поддерживает HTML-отчёты для браузера
🟢 Удобен для интеграции с CI и pytest

✔️ Установка

pip install pyinstrument

➡️ Ссылка на документацию

😎 PyLinux | #python_libs

😎 PyLinux | #memes

🧠 lsof — мощь, о которой все забывают

lsof — один из самых мощных инструментов в Linux для отладки, но его часто игнорируют. А зря: он показывает, какие файлы, сокеты, устройства открыты и кем.

🔍 Кто использует порт?

lsof -i :8000

Узнаешь, кто занял порт — особенно полезно, если server already running или address already in use.

🔐 Кто держит файл открытым?

lsof /var/log/syslog

Найдёт процессы, которые всё ещё используют файл — даже если ты его уже удалил (deleted).


💀 Убить процесс, держащий порт

kill -9 $(lsof -t -i :8000)

Комбо для CI/CD: освобождай порт автоматически перед перезапуском.

📦 Утечки в логах и tmp?

lsof +L1

Покажет файлы, которые удалены, но всё ещё заняты процессами — часто причина переполнения диска.

📁 Какие файлы открыл процесс?

lsof -p 1234

Прямой способ узнать, с чем работает любой процесс.

😎 PyLinux | #linux

🧩 Мониторинг зависших процессов в Linux (на основе времени выполнения)

В Linux процессы могут "зависнуть" — не завершаться, занимать ресурсы, но ничего не делать. Этот скрипт помогает находить такие задачи, работающие дольше заданного времени (например, 1 час), и логировать их для анализа.

⚙️ Исходный код

#!/bin/bash

LOG_FILE="/var/log/stuck_processes.log"
MAX_RUNTIME_MINUTES=60

echo "⏱️ Поиск процессов старше $MAX_RUNTIME_MINUTES минут... $(date)" | tee -a "$LOG_FILE"

# Получаем текущий timestamp
NOW=$(date +%s)

# Получаем список всех процессов с временем запуска
ps -eo pid,etimes,comm --no-headers | while read -r pid etimes comm; do
    if [ "$etimes" -gt $((MAX_RUNTIME_MINUTES * 60)) ]; then
        echo "⚠️ PID: $pid | Время: $((etimes / 60)) мин | Команда: $comm" | tee -a "$LOG_FILE"
    fi
done

echo "✅ Проверка завершена." | tee -a "$LOG_FILE"

🟢 ps -eo pid,etimes,comm — показывает PID, время жизни процесса (в секундах) и его команду
🟢 Сравниваем с порогом (по умолчанию 60 минут)
🟢 Скрипт удобен для поиска подвисших cron-задач, rsync, python-скриптов и др.
🟢 Можно доработать: исключить сервисы, логин-сессии, добавить автоубийство (kill)

➡️ Добавьте в crontab:

*/30 * * * * /path/to/stuck_process_monitor.sh

🗣 Полезно для CI/CD, серверов, рабочих станций и всех, где важна своевременная очистка висящих задач

😎 PyLinux | #scripts

🔜 Intel прикрыла Clear Linux: конец эпохи «самого быстрого» дистрибутива

Разбираюсь, зачем Intel прикрыла Clear Linux, что мы теряем вместе с его фишками и как это отразится на остальных. Немного грусти, немного аналитики и пара идей, куда теперь мигрировать.

🖥 Перейти к статье

😎 PyLinux | #articles