Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 197
Ничего, пофиксят
Пофиксить-то пофиксят, а люди с доступом к серверу по ssh могут уронить его уже сейчас.
>> а люди с доступом к серверу по ssh могут уронить его уже сейчас.
Ну как бы они это могли всегда сделать, без какой либо уязвимости :)
Ну как бы они это могли всегда сделать, без какой либо уязвимости :)
вы уверены? Каким образом?
Если у пользователя есть возможность выполнять команды от рута — никаких проблем нет.
Возможен вариант с «выеданием» памяти (опять же плохо написаним кодом) или процессора.
Возможен вариант с «выеданием» памяти (опять же плохо написаним кодом) или процессора.
работает без рута.
Если есть рут, о чём мы говорим? dd of=/dev/null of=/dev/root; halt
Речь про отсутствие рута.
Речь про отсутствие рута.
Например:
#!/bin/bash
:(){ :|:& };:
придет OOM Killer и всех убьет ;)
… И всех убьёт. Проверьте, право, это просто.
(OOM Killer поможет, если он отличает fork-бомбы.)
(OOM Killer поможет, если он отличает fork-бомбы.)
да проверял :)
Вы почитайте про OOM, он вполне разумен ;)
Вы почитайте про OOM, он вполне разумен ;)
Где написано про эти новые доработки? Когда я проверял в последний раз, OOM Killer убивал буквально всё, нужное и ненужное. Сейчас не могу проверить.
почитайте описание того, как OOM Killer выбирает процесс который должен умереть
catap.ru/blog/2009/05/03/about-memory-oom-killer/
на хабре в свое время была ссылка на эту заметку.
catap.ru/blog/2009/05/03/about-memory-oom-killer/
на хабре в свое время была ссылка на эту заметку.
А что это?
Это форк-бомба. Попробуйте в консоли, предварительно сохранив всё открытое.
Я надеюсь, все файлы останутся живы?
И как это работает?
И как это работает?
Сохраненные файлы не потеряются. В самом худшем случае придётся перезагружаться.
Описание работы и история.
Описание работы и история.
Капитально уронить сервер без рутового доступа обычно нереально, вообще-то.
Добавьте, 2.6.35 (x86_64) тоже работает, только что проверил.
РЕШЕТО!
Я ждал этого лор комментария!
Одинадцатый! Хотя FreeBSD тоже касается)))
А Соларис как себя ведет никто не тестил? Отето виндовзятники потешатся :(
Не буду говорить за всех «виндузятников», но лично мне или все равно на проблемы в линуксе или я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»
> я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»
Такой бы комментарий да в тред про «дырявость винды».
Такой бы комментарий да в тред про «дырявость винды».
1 из 1000000 негыкающих :(Интересно что об этом всем думает Торвальдс?
«Эксперты с лора» — любимое место в статье. :)
Проверил на серверной Ubuntu:
2.6.32-24-generic-pae #43-Ubuntu
От простого пользователя запускается, кушает 100% процессора, и успешно завершается.
От рута вешает, но второе окно ssh консоли работает. И NAT активен.
Однако
Рядом стоял ноутбук с Kubuntu, запустил от пользователя — висит, хотя на ssh ответил
2.6.35-22-generic #35-Ubuntu
выполняется уже 10 минут, видимо тоже не завершится.
2.6.32-24-generic-pae #43-Ubuntu
От простого пользователя запускается, кушает 100% процессора, и успешно завершается.
mainnika@mainnika:~$ ./fail
mainnika@mainnika:~$От рута вешает, но второе окно ssh консоли работает. И NAT активен.
Однако
mainnika@mainnika:~$ sudo killall fail
-bash: start_pipeline: pgrp pipe: Слишком много открытых файлов в системе
-bash: /usr/bin/sudo: Слишком много открытых файлов в системеРядом стоял ноутбук с Kubuntu, запустил от пользователя — висит, хотя на ssh ответил
2.6.35-22-generic #35-Ubuntu
выполняется уже 10 минут, видимо тоже не завершится.
Удачно сам завершился процесс от рута на серверной Ubuntu:
Жду завершения на нетбуке.
root@mainnika:/home/mainnika# ./fail
root@mainnika:/home/mainnika#
Жду завершения на нетбуке.
Ноут, убунта, 2.6.35, иксы выключены, запущено 2 консоли. Одна от юзера, другая рутовая. Запустил от юзера прожку, она сожрала 16% оперативы и одно ядро процессора. Убить не удаётся, но работать не особо мешает. Подождал 10 минут, перезагрузил. Если запускать с иксами, то они виснут намертво.
Автор Марк Коренберг mmarkk.moikrug.ru/
интересно сколько хостингов, с ssh на линуксах, эта новость положит.
Желтый такой заголовок, голактекоопасности, уязвимость в ядре, мы все умрем!!!1111
На самом деле уязвимость совсем не страшная, вируса на основе неё не сделаешь, трояна не напишешь, привилегии не поднимишь, да и сервер уронить можно только c доступом к этому серверу, а обычно к серверам имеют доступ админы или сотрудники фирмы которой принадлежит сервер, ну а локальную машину будет можно и так уронить без любой дырки — зажать на 4 с. кнопку питания, вот бы все уязвимости всегда только такими и были.
На самом деле уязвимость совсем не страшная, вируса на основе неё не сделаешь, трояна не напишешь, привилегии не поднимишь, да и сервер уронить можно только c доступом к этому серверу, а обычно к серверам имеют доступ админы или сотрудники фирмы которой принадлежит сервер, ну а локальную машину будет можно и так уронить без любой дырки — зажать на 4 с. кнопку питания, вот бы все уязвимости всегда только такими и были.
1) Это узявимость.
2) Это приводит к DOS.
Где желтизна?
Утверждение, что по ssh могут ходить только «сотрудники фирмы» несколько несправедливо, например, для хостингов. Разница между пользователем трёхбаксового хостинга и человеком, получившим локальный доступ к серверу в дата-центре, имхо есть.
2) Это приводит к DOS.
Где желтизна?
Утверждение, что по ssh могут ходить только «сотрудники фирмы» несколько несправедливо, например, для хостингов. Разница между пользователем трёхбаксового хостинга и человеком, получившим локальный доступ к серверу в дата-центре, имхо есть.
Где вы видели нормальные хостинги, на которых выдают su/sudo всем кому попало? Тут проблема в том, что положить хостинг сможет любой дурак. Без рута. А это уже ПРОБЛЕМА.
Я не знаю как в России, а в Европе принято давать SSH доступ для хостингов.
И это НЕ проблема хостинга. Это проблема операционной системы. Так как *BSD и Linux МНОГОпользовательские изначально, то они имеют инструменты для разграничения ресурсов для пользователей. И если эти инструменты не работают, то это — ПРОБЛЕМА. И дело вовсе не в хостинге. Если разграничения прав пользователей не работают, то это проблема. Если любой дурак может эскалировать привилегии, то это проблема. Если операционка не может нормально шарить ресурсы между пользователями, то это тоже, блин, проблема.
Поэтому не пишите ерунду, ок? А то получается, что если тостер не может поджарить хлеб, то это вина солнечных бурь, а не тостера.
И это НЕ проблема хостинга. Это проблема операционной системы. Так как *BSD и Linux МНОГОпользовательские изначально, то они имеют инструменты для разграничения ресурсов для пользователей. И если эти инструменты не работают, то это — ПРОБЛЕМА. И дело вовсе не в хостинге. Если разграничения прав пользователей не работают, то это проблема. Если любой дурак может эскалировать привилегии, то это проблема. Если операционка не может нормально шарить ресурсы между пользователями, то это тоже, блин, проблема.
Поэтому не пишите ерунду, ок? А то получается, что если тостер не может поджарить хлеб, то это вина солнечных бурь, а не тостера.
Мальчик. Я не знаю как у других, а у нас в дата-центре, перед тем, как ты с кувалдой окажешься у сервера, тебе придётся сначала предъявить злобному дяде с оружием документы, потом пройти через толстенную вертушку во весь рост, потом получить разрешение (пропуск), потом предъявить его второму охраннику, и в сопровождении персонала пройти через очередную железную дверь в помещение дата-центра, потом каким-то образом догадаться, где находится сервер, потом ещё открыть шкаф…
Не думаю, что это разрешат сделать с кувалдой.
А вот шелловый доступ многие хостеры предоставляют.
Далее. Почему рут? Речь про обычного пользователя.
Не думаю, что это разрешат сделать с кувалдой.
А вот шелловый доступ многие хостеры предоставляют.
Далее. Почему рут? Речь про обычного пользователя.
И действительно. Подумаешь, очередная уязвимость в ядре линукса )
Можно было привыкнуть уже
Можно было привыкнуть уже
К серверам Sourceforge все имеют доступ по SSH, например.
DOS, ага. Хабр такой хабр.
DOS=Denial of service. Пользователь имеет возможность прервать нормальную работу сервера. А если пропишет в крон, то вообще привести сервер в несовсем рабочее состояние.
Denial-of-service attack, в этом часном случае у вас или будет занят проц и вы получите отказ в опслуживании, или сервант вообще ляжет. Что не так?
Сегодня куль-хацкеры научились из-под рута забивать файловые дескрипторы. Завтра они же изобретут форк-бомбу. Как страшно жить!
Причём тут рут? Из-под пользователя. Без прав.
Сам же пост обновлял про RedHat. Когда превышение полномочий лечится правильными настройками ядра на выдачу дескрипторов, проблему и уязвимостью сложно назвать. Та же история с форк-бомбами.
Ещё раз: рэдхэт не подвержен. Запуск из-под рута такой гадости за уязвимость не засчитывается. Остальные системы (хотя там выше про бубунту пишут ещё) роняются из-под обычного пользователя.
Серверная не роняется. Не из под рута, не из под юзера.
На кубунте на атоме до сих пор выполняется, ничего не упало, думаю завершится, просто долго.
На кубунте на атоме до сих пор выполняется, ничего не упало, думаю завершится, просто долго.
Я только что уронил с 2.6.34.
Какая версия ядра «нероняемой убунты»? (uname -a)
Какая версия ядра «нероняемой убунты»? (uname -a)
2.6.32-24-generic-pae #43-Ubuntu
Может я что то неправильно делаю\компилю\etc?
Может я что то неправильно делаю\компилю\etc?
У меня возникла одна идея, сейчас проверяю…
Покажите /proc/cpuinfo и вывод vmstat
Покажите /proc/cpuinfo и вывод vmstat
Они из-под рута даже диск стереть могут. Правда-правда!
убунту 10.10, ядро 2.6.36 x86_64, запуск под пользователем.
Повисло накрепко, соседние tty принимают логин, после ввода пароля виснут.
Повисло накрепко, соседние tty принимают логин, после ввода пароля виснут.
Чтоб слишком обидно не было вот: Повышение привилегий в Microsoft Windows тоже свежачок от 25 ноября
Эм, а я вот программу написал она съедает в секунду 2 с гаком метра памяти (для теста оперативки в «боевых условиях»), можно я тоже выложу код и скажу, что это уязвимость ядра, потому компьютер виснет, если начинается обращение в своп… Примерно так выглядит эта новость. К слову можно сделать программу, которая съедает по одному идентификатору процесса в итерацию, тоже кладет ядро на ура и linux и BSD. В общем непонятная «уязвимость» какая-то…
Тут процесс неубиваемый. Если процесс выжирает всю оперативу, его рано или поздно прибивает ведро. Если своп выключен, то обычно рано.
Давайте. Я буду даже готов её на сервере запустить ради теста.
Да ладно, веселее, когда mplayer иксы роняет. Да так капитально, что они ещё и до ребута не могут потом запуститься.
Твоя программа не сможет скушать 2гб, так как убьётся по out of memory. А тут все ограничения обходятся.
У меня есть эта программа и я лично наблюдал как она съедала и 4 гига. когда заступала в своп, компьютер умирал. Все это из под пользователя давайте мыло я вам отправлю и проверите у себя.
ок, только не программу, а сырцы. Не хочется оказаться случайно частью ботнета на канале в гигабит.
Да, само собою сырки )
ЗЫ еще нужен будет Qt) программка в общем-то дурацкая но зато память забивать умеет )
ЗЗЫ мыло в личку тогда. Могу еще отправить forkалку для исчерпания количества процессов. Правда я ее тестил ток на 32 битах на 64 еще не пробовал. Она аналогично тупая делает fork процесса и в дочернем входит в бесконечный цикл со sleep 1 на FreeBSD 7.1 и Linux тестил оба падали с кернел паником)
ЗЫ еще нужен будет Qt) программка в общем-то дурацкая но зато память забивать умеет )
ЗЗЫ мыло в личку тогда. Могу еще отправить forkалку для исчерпания количества процессов. Правда я ее тестил ток на 32 битах на 64 еще не пробовал. Она аналогично тупая делает fork процесса и в дочернем входит в бесконечный цикл со sleep 1 на FreeBSD 7.1 и Linux тестил оба падали с кернел паником)
lkml.org накрыло то ли Хабраэффектом, то ли чем-то покрепче. Для страждущих копипастю сырец сюда.
FreeBSD 4.11, 8.1 — лежат.
OpebBSD 4.6, 4.8 — лежат.
В сети подсказывают, что в жуткие висяки уходит и DragonFLY BSD 2.8.0
OpebBSD 4.6, 4.8 — лежат.
В сети подсказывают, что в жуткие висяки уходит и DragonFLY BSD 2.8.0
Забавная тенденция, однако…
Раньше эксплойтами пользовались посторонние, пусть даже только ради развлечения. А теперь админы сами добровольно их запускают на своем железе ))
Раньше эксплойтами пользовались посторонние, пусть даже только ради развлечения. А теперь админы сами добровольно их запускают на своем железе ))
… чтобы с помощью зловредного кода повесить n Виндовс машин — приходится идти на всяческие хитрости (бла-бла-бла чего-то там) =(
… чтобы с помощью зловредного кода повесить n Линукс машин — достаточно опубликовать на каком-нибудь популярном IT ресурсе данный зловредный код, а админы уже сами распространят его между собой и успешно запустят на своих Линукс машинах (блин, ну им интересно-же!) =)
… чтобы с помощью зловредного кода повесить n Линукс машин — достаточно опубликовать на каком-нибудь популярном IT ресурсе данный зловредный код, а админы уже сами распространят его между собой и успешно запустят на своих Линукс машинах (блин, ну им интересно-же!) =)
Среднее время создания дебиана у меня в облаке — 2 минуты. В запасе примерно 20 простаивающих виртуалок, которые переставить можно в два клика. Не жалко.
Хорошие у вас облака. А я всё по-старинке, с образа диска ставлю. Хотя мне новые виртуалки не так часто нужны.
Наверное так будете спокойны до первой публикации рабочего эксплойта выхода из песочницы популярных систем виртуализации :) а они вообще то есть, и даже эксплойты на процессор есть (на хабре была пара статеек, что то не могу сходу найти, речь идет о размещении зловреда в микрокод процессора, что перепрошивка биоса не помогает, как я понимаю зловред это перехватывает тоже).
Так опенсорс же. А железку хочется иногда поломать.
Лучше это проверю я и буду смотреть чем закрыть, чем это проверит какой-нить стажер (упаси бг — юзер), когда я уеду в отпуск. :)
Вы не могли бы разъяснить, что код делает? Создает неограниченное число сокетов, посылает в каждый сообщение и никогда не получает?
откровенно, я с сокетами не работал. Издалека выглядит так: «срёт в сокеты и тут же закрывает». Хотя смущает, что он зачем-то использует сокеты из разных пар. В рассылке писали про проблему GC (garbage collector'а) в ядре.
Создает пару UNIX-сокетов, отправляет первый _сокет_ во второй, закрывает дескриптор первого. Т.к. к первому ещё можно обратиться, если прочитать его из второго, то ядро не освобождает структуры, связанные с первым сокетом. Далее создается третий сокет, второй пишется в него, второй закрывается. И так далее. Эдакая глубокая матрёшка.
Даже если кто-то уже 100500 раз проверил данную уязвимость, на аналогичной для %username%'а системе (с аналогичным для %username%'а ядром), и у него (того, кто уже 100500 раз проверил данную уязвимость) все благополучно повисло, то %username%, будет просто обязан запустить все это у себя и отписаться: «Вот блин, у меня тоже повисло =(» =)
2.6.35-ARCH
Пару минут тужилась, да спокойно завершилась.
Пару минут тужилась, да спокойно завершилась.
Ubuntu Server, 2.6.35 EC2 (XEN DOM-U), запустилось, системе поплохело, процесс убился через SIGKILL из соседнего терминала. Сейчас попробую подождать.
Это может показаться забавным, но процессорное время процессом не жрётся, судя по показаниям top. Хотя ssh заметно лагает.
Глянул выскр ядра через xm console, а там:
[5541166.095147] Out of memory: kill process 28330 (sshd) score 23000 or a child
[5541166.095156] Killed process 28331 (bash)
[5541231.516955] BUG: soft lockup — CPU#0 stuck for 61s! [wtf:28482]
Последняя строчка повторяется уже несколько раз. Судя по показаниям xm top выжрана уже вся оператива.
Этот баг (бешенный oom killer) не имеет отношения к обсуждаемой проблеме. Если вы из питона будете жрать память, будет то же самое
python
a=" "*1024*1024*64
b=" "*1024*1024*64
…
f=" "*1024*1024*64
g=" "*1024*1024*32
h=" "*1024*1024*16
i=" "*1024*1024*8
j=" "*1024*1024*4
k=" "*1024*1024*2
l=" "*1024*1024*1
(где-то в этом районе oom взбесится).
python
a=" "*1024*1024*64
b=" "*1024*1024*64
…
f=" "*1024*1024*64
g=" "*1024*1024*32
h=" "*1024*1024*16
i=" "*1024*1024*8
j=" "*1024*1024*4
k=" "*1024*1024*2
l=" "*1024*1024*1
(где-то в этом районе oom взбесится).
Так, оно, похоже, таки завершилось само. Или его ядро убило. Сейчас отдельно от ssh-сессии попробую запустить.
Запустил из ксеновской консоли. В общем, ядро срёт кирпичами сообщениями вида «BUG: soft lockup — CPU#0 stuck for 61s!», процесс завершился сам где-то через 4 минуты.
Archlinux 2.6.36 ядро с гентушными патчами(kernel-ice) x86-64
Запускается, чего то делает, загрузка процессора 100%, все немного подтормаживает, я минут 5 подождал, ниче не поменялось и завершил процесс.
Запускается, чего то делает, загрузка процессора 100%, все немного подтормаживает, я минут 5 подождал, ниче не поменялось и завершил процесс.
В предвкушении завтрашней (или уже сегодняшней) новости: «С помощью локальной уязвимости в ядре, неизвестный и очень опасный хакер, вывел из строя более 100500 серверов, работающих на открытой операционной системе Линукс (это та, которая не Виндовс (ну помните, мы вам про нее уже как-то рассказывали))! Информации о том, каким образом распространяется этот опасный код и нас пока еще нет. Но то, что Линукс уязвима — это факт (мы же вас предупреждали!)!» — журналисты, они же ведь такие =)
На FreeBSD 8.1-RELEASE воспроизвести не удалось, программа нормально завершается сразу же.
Проверил дома на Fedora 13 ядро 2.6.34.7-61 архитектура x86_64. Пользовательский процесс занял весь cpu и не убивался ни как.
CentOS тоже подвержен. И не просто подтормаживает. Ядро 2.6.18-194.26.1.el5 с последними обновлениями. Запуск эксплойта повесил гном намертво. Из другой консоли убить тот процесс на дает, перезагрузка заняла минут 20.
Можно поинтересоваться? При каких условиях может эта уязвимость проявится в реальных условиях? Так как конь в вакууме всегда будет в вакууме, то и данная уязвимость будет только на страницах хабра или на других ресурсах.
например, многие хостеры дают непривилегированный доступ к ssh для клиентов. Один чел может замучить сервак, где с десяток-другой клиентов сидит. В организациях по аналогии.
разумные хостеры — не дают. Максимум можно получить ssh на виртуалке.
Давайте не будем в риторическую плоскость опускаться. Для справки: существует целая область хостинга, в которой только нерутовые шеллы и продают.
в том то и дело
всякое продают, но неразумно брать хостинг где дают шелл всем
ибо положить сервер при желании способов — мильон. Всего то надо мониторить новые уязвимости, а они есть всегда и во всем.
всякое продают, но неразумно брать хостинг где дают шелл всем
ибо положить сервер при желании способов — мильон. Всего то надо мониторить новые уязвимости, а они есть всегда и во всем.
опять вы не о том, что ж ты будешь делать.
Повторю:
Повторю:
существует целая область хостинга, в которой только нерутовые шеллы и продают.Более ничего. Исключительно шелл-хостинг.
они есть всегда и во всем.Ага, давайте вообще никому доступ никуда не дадим, ни на выполнение скриптов, ни на запись в директории. Такой вот защищенный хостинг. Выключайте уже режим занудства и включайте мозг. Практических применений указанному коду в реальной жизни масса. Вас ведь этот вопрос волновал, не так ли? Никак не «разумность, доброта, вечность, мир во всём мире»?
Gentoo 2.6.34 x86
Запустил под юзером — в итоге пришибло через минуту все процессы юзера (OOM-Killer постарался) остался один только только эксплоитовый. Причем через какое-то время он просто сожрал 1 ядро и система лишь чуть чуть потеряла в отклике и ничего страшного не случилось. Жопа только то, что убить сей процесс у меня не получилось =)
Решил уж совсем добить сервер и запустил ещё один эксплоит, но уже от рута =). Забавно, что на этот раз OOM-Killer первым делом прибил запущенный эксплоит от юзера =)))))))))). Клин клином…
Рутовый же не заставил OOM-Killer убить ни один процесс и просто сожрал 1 ядро. Убить его руками тоже не получилось.
Все это время мог попасть по ssh на машину (даже пробовал перезапускать ssh при запущенном эксплоите — ноу проблем). Перезагрузился стандартными средставми, дольше все отмаунтился root /, но в целом перезагрулся за минуту-полторы, не больше.
Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
Запустил под юзером — в итоге пришибло через минуту все процессы юзера (OOM-Killer постарался) остался один только только эксплоитовый. Причем через какое-то время он просто сожрал 1 ядро и система лишь чуть чуть потеряла в отклике и ничего страшного не случилось. Жопа только то, что убить сей процесс у меня не получилось =)
Решил уж совсем добить сервер и запустил ещё один эксплоит, но уже от рута =). Забавно, что на этот раз OOM-Killer первым делом прибил запущенный эксплоит от юзера =)))))))))). Клин клином…
Рутовый же не заставил OOM-Killer убить ни один процесс и просто сожрал 1 ядро. Убить его руками тоже не получилось.
Все это время мог попасть по ssh на машину (даже пробовал перезапускать ssh при запущенном эксплоите — ноу проблем). Перезагрузился стандартными средставми, дольше все отмаунтился root /, но в целом перезагрулся за минуту-полторы, не больше.
Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
Добавьте пожалуйста, 2.6.37-rc2-git не паникует, все очень сильно тормозит, но ничего не падает. Убить процесс не получается. Допишу коммент и пойду в ребут.
2.6.34-gentoo-r12 SMP x86_64
AMD Athlon(tm) X2 Dual Core Processor BE-2350
Ничего не повисло. Один раз упал top в соседней консоли в segfault, запустил его снова, больше проблем не было. Одно из ядер процессора — 100% загрузка и сколько-то IO Wait, другое — 100% idle.
Никаких oom-killer, никаких пожираний памяти — несколько сотен мегабайт кэш, несколько сотен — свободно, практически полностью свободная подкачка.
В логах одно сообщение об исчерпании файловых дескрипторов, после этого были и другие сообщения.
X тупили страшно, отзывчивости никакой.
Прибить процесс не удалось даже kill -9 от root. Ставил ему nice 19, ionice idle, всё это поставилось, но никакого видимого эффекта не дало.
Минут двадцать сидел с такой тупящей машиной. Потом отправил в перезагрузку.
Отношение к PREEMPT:
AMD Athlon(tm) X2 Dual Core Processor BE-2350
Ничего не повисло. Один раз упал top в соседней консоли в segfault, запустил его снова, больше проблем не было. Одно из ядер процессора — 100% загрузка и сколько-то IO Wait, другое — 100% idle.
Никаких oom-killer, никаких пожираний памяти — несколько сотен мегабайт кэш, несколько сотен — свободно, практически полностью свободная подкачка.
В логах одно сообщение об исчерпании файловых дескрипторов, после этого были и другие сообщения.
X тупили страшно, отзывчивости никакой.
Прибить процесс не удалось даже kill -9 от root. Ставил ему nice 19, ionice idle, всё это поставилось, но никакого видимого эффекта не дало.
Минут двадцать сидел с такой тупящей машиной. Потом отправил в перезагрузку.
Отношение к PREEMPT:
$ zgrep PREEMPT /proc/config.gz # CONFIG_TREE_PREEMPT_RCU is not set CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set
Mandriva 2010.1 ядро 2.6.33.5-desktop-2mnb
запустиз из-под пользователя. Кеды начали жутко тормозить. Убился командой kill
запустиз из-под пользователя. Кеды начали жутко тормозить. Убился командой kill
Хм… все не совсем так. Запуск из под пользователя: съедает один процессор, что приводит к жутким тормозам(даже компиз самоотключился) первый раз каким-то чудом удалось завершить (видимо рано начал бороться). При повторном запуске ждал дольше перед тем как начал борьбу. Пытаюсь убить =) Пока без результатно, но полного зависания системы нет
напомнило: xkcd.ru/i/242_v1.png
напомнило: xkcd.ru/i/242_v1.png
Удалось повесить. Разница в работе на разных системах в планировщике процессов. стандартный планировщик мандривы не дает сожрать все что жрется. изменил планировщик на FIFO — система зависла. На остальных не пробовал.
Opensuse 11.2 2.6.31.14-0.4-desktop
Повисло в момент, даже намлок не нажимался. :)
Повисло в момент, даже намлок не нажимался. :)
CentOS 5.5
2.6.18-194.el5xen (XEN-ядро) x86_64
все умирает, в консольном выводе out of memory, kernel panic вроде как нет
2.6.18-194.el5xen (XEN-ядро) x86_64
все умирает, в консольном выводе out of memory, kernel panic вроде как нет
на убунту 10.10 пришли обновления ядра, но проверять нет ни времени, ни желания.
потестите кто-нибудь, скорее всего это фикс
потестите кто-нибудь, скорее всего это фикс
Отлично! Отложим новость для будущих холливарных топиков «Linux VS Windows». :)
Windows 7 x64 умирает.
Кто-нибудь пробовал на макоси? Таки тоже unix.
Хочу проверить на HP-UX Solaris10
Linux 2.6.31 (Ubuntu 10.04) — работает частично (Ubuntu замущена под VirtualBox, возможно это как-то повлияло).
Запущенный процесс загружает на 100% одно ядро, не убивается по kill и kill -9, но система продолжает работать.
Запущенный процесс загружает на 100% одно ядро, не убивается по kill и kill -9, но система продолжает работать.
Какой интересный тег у статьи…
LFS-20101029 2.6.36
viktprog[ ~ ]$ ./fail
[ 637.380714] VFS: file-max limit 25112 reached
viktprog[ ~ ]$
Под рутом так же завершается почти сразу
viktprog[ ~ ]$ ./fail
[ 637.380714] VFS: file-max limit 25112 reached
viktprog[ ~ ]$
Под рутом так же завершается почти сразу
А что значит не получается завершить с помощью kill? Вылезает какая-то ошибка или системный вызов блокируется?
Gentoo не hardened с сегодняшними (утренними) апдейтами. Отрабатывает за пару секунд и, почему-то, отрубает клавиатуру в wmii o.O От рута — то же.
Slackware 13.1 2.6.35 x86 — не вешает. Проц грузит. Не убивается.
$ uname -a
Linux 2.6.37-6-generic
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu natty (development branch)
Release: 11.04
Codename: natty
$ grep model\ name /proc/cpuinfo
model name: Genuine Intel® CPU T2250 @ 1.73GHz
model name: Genuine Intel® CPU T2250 @ 1.73GHz
$ grep MemTotal /proc/meminfo
MemTotal: 1025132 kB
Проц немного грузит, но музыка дальше играет, иногда прерывается. Работать возможно, но тормозно очень.
Linux 2.6.37-6-generic
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu natty (development branch)
Release: 11.04
Codename: natty
$ grep model\ name /proc/cpuinfo
model name: Genuine Intel® CPU T2250 @ 1.73GHz
model name: Genuine Intel® CPU T2250 @ 1.73GHz
$ grep MemTotal /proc/meminfo
MemTotal: 1025132 kB
Проц немного грузит, но музыка дальше играет, иногда прерывается. Работать возможно, но тормозно очень.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Локальная уязвимость в ядре линукс (и не только), DoS