LinuxCamp | DevOps
Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование. Админ (реклама): @XoDefender Чат: @linuxcamp_chat Менеджер: @Spiral_Yuri Биржа: https://telega.in/c/linuxcamp_tg РКН: https://clck.ru/3RWA3C
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام LinuxCamp | DevOps
تُعد قناة LinuxCamp | DevOps (@linuxcamp_tg) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 13 960 مشتركاً، محتلاً المرتبة 9 131 في فئة التكنولوجيات والتطبيقات والمرتبة 47 183 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 13 960 مشتركاً.
بحسب آخر البيانات بتاريخ 06 يوليو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -98، وفي آخر 24 ساعة بمقدار -3، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 27.85%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 10.66% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 3 888 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 489 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 23.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل linuxcamp, ядро, linux, диск, docker.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Обо мне: C/C++/Linux эксперт. Говорим про разработку, Linux, DevOps, сети и администрирование.
Админ (реклама): @XoDefender
Чат: @linuxcamp_chat
Менеджер: @Spiral_Yuri
Биржа: https://telega.in/c/linuxcamp_tg
РКН: https://clck.ru/3RWA3C”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 07 يوليو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
Скачал вирус для Linux. Распаковал. Запустил от root - не сработало. Оказалось, что вместо /usr/local/bin вирус распаковался в /usr/bin, куда у malware нет прав на запись, поэтому вирус не смог создать файл процесса. Нашел пропатченный configure и makе - не хватало библиотеки, которой в Ubuntu нет. Собрал вручную. Запустился и упал с core dump. Разобрал логи - вирус предполагал, что работает на ext4, и обращался к API шифрования диска. Под btrfs этот API уже давно депрекейтнут и ядро просто перевело раздел в read-only. Открыл исходники, нашёл Bitcoin-кошелёк и скинул туда $5 из жалости.LinuxCamp | #memes
ls -li
Почему место может закончиться при свободных гигабайтах
Свободное место и количество inode это разные вещи. Ext2/3/4 создают inode один раз при форматировании. Один файл -> один inode.
Проверка:
df -h # место
df -i # inode
Типичная ситуация:
df -h → свободно 20G
df -i → 0 свободных inode
Свободные блоки есть, а inode закончились, получается новый файл создать нельзя.
Что делать
Понять, что именно упёрлось: место или inode. Если упёрлось в inode, вариантов немного. На ext увеличить их нельзя. Только удалить мелкие файлы или переделать файловую систему.
Резервные блоки ext
Ext по умолчанию скрывает около 5% места под root. Иногда это десятки гигабайт.
Посмотреть:
tune2fs -l /dev/sdX1 | grep 'Reserved block'
Временно отключить:
sudo tune2fs -m 0 /dev/sdX1
Вывод
Если прод внезапно перестал писать, а df -h показывает свободное место — сразу смотри df -i. Чаще всего именно inode закончились первыми. В xfs и btrfs такая ситуация почти не встречается, потому что inode там создаются динамически, а не заранее.
LinuxCamp | #storage
swapon --show
или просто:
free -h
Если swap выключен
Когда физическая память закончится, ядро запустит OOM Killer (Out Of Memory Killer) - это специальный механизм, который выбирает и убивает процессы, чтобы высвободить память. Умрёт не обязательно твой сервис, система решает сама, кого "пожертвовать", ориентируясь на приоритет oom_score.
Посмотреть, как она видит твоё приложение:
cat /proc/<pid>/oom_score
Как OOM выбирает жертву
Он не смотрит на виртуальную память, а только на реально используемую (resident set size, RSS). Именно физическая память решает, кому жить, а кому нет.
Вывод
Если память утекает Linux не спасёт, он просто решит, кого первым застрелить. Swap продлит агонию, OOM поставит точку.
LinuxCamp | #storage #ram
sudo rm -rf /
"Это уже шестой раз, когда я переустанавливаю систему... Прощай, suicide linux!"
sudo atp remove suicide-linux "О нет, опять"LinuxCamp | #resources
«У 87% систем с таким CPU-профилем помогло отключение intel_pstate=passive»Доступно с версий RHEL 9.4+ Что будет? Вот так будет выглядеть пример взаимодействия с ОС, к которому мы идем:
$ ai-troubleshoot nginx
— ИИ анализирует "journalctl, nginx -t, ss -tulpn, df -h" и выводит:
«Порт 80 занят apache2... Остановить apache и перезапустить nginx?»LinuxCamp | #news
Вы узнаете: — с какими вызовами сталкиваются инфраструктуры хранения данных; — как решения от Deckhouse и YADRO помогают управлять большими данными, снижают операционные затраты и повышают отказоустойчивость; — каким образом вы сможете создать гибкую среду для управления данными; — как возможна интеграция технологий хранения данных в контейнерные среды без необходимости изменять архитектуру существующих приложений.Приходите, мы покажем рабочие инструменты для решения ключевых задач вашей цифровой-инфраструктуры! Зарегистрироваться 11 ноября в 12:00 🎁 Среди участников вебинара разыграем наборы памятного мерча от YADRO, а также подарим промокод на обучение в Deckhouse Академии.
Too many open filesВиноват ulimit Каждый процесс в Linux живёт в рамках ограничений ядра - ulimits. Одно из них nofile, максимум открытых файловых дескрипторов. Файл, сокет, pipe - всё это дескрипторы. Посмотреть текущие лимиты:
ulimit -n
увидишь, например:
1024Это значит, что твой процесс не может держать больше 1024 открытых файлов и соединений. Как увеличить Иногда это нужно для высоконагруженных сервисов, например, база данных, reverse-proxy или API, который держит тысячи открытых соединений. Если лимит слишком маленький, то приложение начнёт падать на пике трафика. Временно (для текущей сессии):
ulimit -n 65535
Навсегда — в /etc/security/limits.conf или /etc/systemd/system.conf:
* soft nofile 65535 * hard nofile 65535Если сервис под systemd, добавь в unit-файл:
[Service]
LimitNOFILE=65535
и перезапусти:
systemctl daemon-reexec
systemctl restart <service>
Осторожно с лимитами
Увеличивать можно, но без фанатизма. Слишком высокий nofile при множестве активных процессов может съесть память и дескрипторы ядра, Особенно если приложение не закрывает файлы корректно. Поэтому лучше провести ревизию приложения вначале.
Вывод
Too many open files - это не баг, а защита ядра. Если приложение задыхается, то можно увеличить лимиты. Главное понимать почему в приложении появляется данная проблема
متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
