Pull to refresh

Comments 197

Пофиксить-то пофиксят, а люди с доступом к серверу по ssh могут уронить его уже сейчас.
>> а люди с доступом к серверу по ssh могут уронить его уже сейчас.
Ну как бы они это могли всегда сделать, без какой либо уязвимости :)
вы уверены? Каким образом?
Если у пользователя есть возможность выполнять команды от рута — никаких проблем нет.
Возможен вариант с «выеданием» памяти (опять же плохо написаним кодом) или процессора.
Если есть рут, о чём мы говорим? dd of=/dev/null of=/dev/root; halt

Речь про отсутствие рута.
>>Пофиксить-то пофиксят, а люди с доступом к серверу по ssh могут уронить его уже сейчас.
Извините, тогда я пропустил root в этой фразе.
человек, имеющий рута, имеет возможность всё сломать. Вне зависимости от наличия уязвимостей.
UFO just landed and posted this here
Неверно, если — 1) рут ограничен чем-то вроде SELinux'а.
2) Сама система является OpenVZ-контейнером.

Обе песочницы предполагают, что в ядре нет уязвимостей, дающих выбраться из песочницы, либо получить ресурсы, больше предопределённых.
Как вы пропустили тут рета, если это даже не вы говорили?
Например:
#!/bin/bash
:(){ :|:& };:

придет OOM Killer и всех убьет ;)
… И всех убьёт. Проверьте, право, это просто.
(OOM Killer поможет, если он отличает fork-бомбы.)
да проверял :)
Вы почитайте про OOM, он вполне разумен ;)
Где написано про эти новые доработки? Когда я проверял в последний раз, OOM Killer убивал буквально всё, нужное и ненужное. Сейчас не могу проверить.
Это форк-бомба. Попробуйте в консоли, предварительно сохранив всё открытое.
Я надеюсь, все файлы останутся живы?

И как это работает?
Да, уже нашел, спасибо
но у меня не работает почему-то
Видимо, или лимиты стоят, или какая-то другая защита. Это нормально.
заработало, когда запустил не в качестве скрипта, а тупо
forkobomb(){forkobomb:forkobomb&};forkobomb
лимиты на количество процессов?
UFO just landed and posted this here
Капитально уронить сервер без рутового доступа обычно нереально, вообще-то.
Попробуйте от пользователя:
#!/bin/bash
:(){ :|:& };:
UFO just landed and posted this here
Добавьте, 2.6.35 (x86_64) тоже работает, только что проверил.
Из-под пользователя?
Я ждал этого лор комментария!
Mac OSX Snow Leopard, не работает :)
мож собрать надо как-то по-особенному?
FreeBSD 8.2-PRERELEASE
не подтверждается ни SOCK_SEQPACKET ни SOCK_DGRAM
s/SOCK_SEQPACKET/SOCK_STREAM/g
UFO just landed and posted this here
А Соларис как себя ведет никто не тестил? Отето виндовзятники потешатся :(
UFO just landed and posted this here
Не буду говорить за всех «виндузятников», но лично мне или все равно на проблемы в линуксе или я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»
> я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»

Такой бы комментарий да в тред про «дырявость винды».
1 из 1000000 негыкающих :(Интересно что об этом всем думает Торвальдс?
«Эксперты с лора» — любимое место в статье. :)
ага, как увидел задался мыслью «почему я там их не видел?» =)
«Анонимные аналитики» было бы точнее и атмосфернее.
Проверил на серверной Ubuntu:
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#


Жду завершения на нетбуке.
У меня в тестах (не разбирался пока почему) оно нормально отрабатывает только из /usr/bin/
Ноут, убунта, 2.6.35, иксы выключены, запущено 2 консоли. Одна от юзера, другая рутовая. Запустил от юзера прожку, она сожрала 16% оперативы и одно ядро процессора. Убить не удаётся, но работать не особо мешает. Подождал 10 минут, перезагрузил. Если запускать с иксами, то они виснут намертво.
У меня включены иксы, ноут на atom n270 с кедами и 2.6.35-22-generic, иксы отвечают с очень большой задержкой, а ssh с небольшой задержкой отвечает.
интересно сколько хостингов, с ssh на линуксах, эта новость положит.
Желтый такой заголовок, голактекоопасности, уязвимость в ядре, мы все умрем!!!1111
На самом деле уязвимость совсем не страшная, вируса на основе неё не сделаешь, трояна не напишешь, привилегии не поднимишь, да и сервер уронить можно только c доступом к этому серверу, а обычно к серверам имеют доступ админы или сотрудники фирмы которой принадлежит сервер, ну а локальную машину будет можно и так уронить без любой дырки — зажать на 4 с. кнопку питания, вот бы все уязвимости всегда только такими и были.
1) Это узявимость.
2) Это приводит к DOS.

Где желтизна?

Утверждение, что по ssh могут ходить только «сотрудники фирмы» несколько несправедливо, например, для хостингов. Разница между пользователем трёхбаксового хостинга и человеком, получившим локальный доступ к серверу в дата-центре, имхо есть.
UFO just landed and posted this here
Где вы видели нормальные хостинги, на которых выдают su/sudo всем кому попало? Тут проблема в том, что положить хостинг сможет любой дурак. Без рута. А это уже ПРОБЛЕМА.
UFO just landed and posted this here
Я не знаю как в России, а в Европе принято давать SSH доступ для хостингов.

И это НЕ проблема хостинга. Это проблема операционной системы. Так как *BSD и Linux МНОГОпользовательские изначально, то они имеют инструменты для разграничения ресурсов для пользователей. И если эти инструменты не работают, то это — ПРОБЛЕМА. И дело вовсе не в хостинге. Если разграничения прав пользователей не работают, то это проблема. Если любой дурак может эскалировать привилегии, то это проблема. Если операционка не может нормально шарить ресурсы между пользователями, то это тоже, блин, проблема.

Поэтому не пишите ерунду, ок? А то получается, что если тостер не может поджарить хлеб, то это вина солнечных бурь, а не тостера.
UFO just landed and posted this here
Мальчик. Я не знаю как у других, а у нас в дата-центре, перед тем, как ты с кувалдой окажешься у сервера, тебе придётся сначала предъявить злобному дяде с оружием документы, потом пройти через толстенную вертушку во весь рост, потом получить разрешение (пропуск), потом предъявить его второму охраннику, и в сопровождении персонала пройти через очередную железную дверь в помещение дата-центра, потом каким-то образом догадаться, где находится сервер, потом ещё открыть шкаф…

Не думаю, что это разрешат сделать с кувалдой.

А вот шелловый доступ многие хостеры предоставляют.

Далее. Почему рут? Речь про обычного пользователя.
UFO just landed and posted this here
И действительно. Подумаешь, очередная уязвимость в ядре линукса )
Можно было привыкнуть уже
Ну да. А первого человека, по различным источникам, убили то ли 50к лет назад, то ли 6.5к лет назад. Чего мы на убийства всё ещё реагируем?
извините, инерция чтения сверху вниз.
К серверам Sourceforge все имеют доступ по SSH, например.
DOS=Denial of service. Пользователь имеет возможность прервать нормальную работу сервера. А если пропишет в крон, то вообще привести сервер в несовсем рабочее состояние.
Лучше уж DoS, все-таки и правильнее, и вызывает меньше ассоциаций с операционкой DOS
Denial-of-service attack, в этом часном случае у вас или будет занят проц и вы получите отказ в опслуживании, или сервант вообще ляжет. Что не так?
Сервант в недоумении от вашего комментария


DOS и DoS таки немного разные вещи, ага. И автор поста уже поправил.
Как остроумно, особено если учесть даты ответов.
DOS от DoS можно отличить вне зависимости от дат сообщений.
Сегодня куль-хацкеры научились из-под рута забивать файловые дескрипторы. Завтра они же изобретут форк-бомбу. Как страшно жить!
Причём тут рут? Из-под пользователя. Без прав.
Сам же пост обновлял про RedHat. Когда превышение полномочий лечится правильными настройками ядра на выдачу дескрипторов, проблему и уязвимостью сложно назвать. Та же история с форк-бомбами.
UFO just landed and posted this here
Забавно. А у меня всё вроде ок. То есть сообщение есть, но процесс просто тихо сам завершается. Но это центос, rhel я вписал по-аналогии. Сейчас поправлю.
Ещё раз: рэдхэт не подвержен. Запуск из-под рута такой гадости за уязвимость не засчитывается. Остальные системы (хотя там выше про бубунту пишут ещё) роняются из-под обычного пользователя.
Серверная не роняется. Не из под рута, не из под юзера.
На кубунте на атоме до сих пор выполняется, ничего не упало, думаю завершится, просто долго.
Я только что уронил с 2.6.34.

Какая версия ядра «нероняемой убунты»? (uname -a)
2.6.32-24-generic-pae #43-Ubuntu
Может я что то неправильно делаю\компилю\etc?
У меня возникла одна идея, сейчас проверяю…

Покажите /proc/cpuinfo и вывод vmstat
обе гипотезы неверные.

Я думал, что а) проблема в SMP'шности, что б) проблема в быстроте машины (что на медленных машинах проблемы не будет).

Нет, это не так. На медленной UP машине проблема так же есть. Вероятнее всего, какая-то закономерность есть, но поймать не могу.
На нетбуке тоже завершилось, пока я спал. Долго конечно, но ничего не упало.
Они из-под рута даже диск стереть могут. Правда-правда!
немедленно отобрать у человеков права рута!!! )))
убунту 10.10, ядро 2.6.36 x86_64, запуск под пользователем.
Повисло накрепко, соседние tty принимают логин, после ввода пароля виснут.
Ну у нас ещё всё неплохо, произвольный код выполнить не удастся )
UFO just landed and posted this here
Эм, а я вот программу написал она съедает в секунду 2 с гаком метра памяти (для теста оперативки в «боевых условиях»), можно я тоже выложу код и скажу, что это уязвимость ядра, потому компьютер виснет, если начинается обращение в своп… Примерно так выглядит эта новость. К слову можно сделать программу, которая съедает по одному идентификатору процесса в итерацию, тоже кладет ядро на ура и linux и BSD. В общем непонятная «уязвимость» какая-то…
Тут процесс неубиваемый. Если процесс выжирает всю оперативу, его рано или поздно прибивает ведро. Если своп выключен, то обычно рано.
Давайте. Я буду даже готов её на сервере запустить ради теста.
Да ладно, веселее, когда mplayer иксы роняет. Да так капитально, что они ещё и до ребута не могут потом запуститься.
Твоя программа не сможет скушать 2гб, так как убьётся по out of memory. А тут все ограничения обходятся.
У меня есть эта программа и я лично наблюдал как она съедала и 4 гига. когда заступала в своп, компьютер умирал. Все это из под пользователя давайте мыло я вам отправлю и проверите у себя.
ок, только не программу, а сырцы. Не хочется оказаться случайно частью ботнета на канале в гигабит.
Да, само собою сырки )
ЗЫ еще нужен будет Qt) программка в общем-то дурацкая но зато память забивать умеет )
ЗЗЫ мыло в личку тогда. Могу еще отправить forkалку для исчерпания количества процессов. Правда я ее тестил ток на 32 битах на 64 еще не пробовал. Она аналогично тупая делает fork процесса и в дочернем входит в бесконечный цикл со sleep 1 на FreeBSD 7.1 и Linux тестил оба падали с кернел паником)
ок, виртуалок у меня много. Но нужно понимать, что запускать я буду на непривилегированном пользователе с выставленными лимитами.
lkml.org накрыло то ли Хабраэффектом, то ли чем-то покрепче. Для страждущих копипастю сырец сюда.
Видимо кто то решил проверить уязвимость не отходя от кассы — прям на сервере klml.org
Щас и pastebin.com накроет ;)
Ведь пока у каждого линукс система не повиснет — народ не успокоится =)
FreeBSD 4.11, 8.1 — лежат.
OpebBSD 4.6, 4.8 — лежат.

В сети подсказывают, что в жуткие висяки уходит и DragonFLY BSD 2.8.0
Забавная тенденция, однако…
Раньше эксплойтами пользовались посторонние, пусть даже только ради развлечения. А теперь админы сами добровольно их запускают на своем железе ))
… чтобы с помощью зловредного кода повесить n Виндовс машин — приходится идти на всяческие хитрости (бла-бла-бла чего-то там) =(

… чтобы с помощью зловредного кода повесить n Линукс машин — достаточно опубликовать на каком-нибудь популярном IT ресурсе данный зловредный код, а админы уже сами распространят его между собой и успешно запустят на своих Линукс машинах (блин, ну им интересно-же!) =)
Среднее время создания дебиана у меня в облаке — 2 минуты. В запасе примерно 20 простаивающих виртуалок, которые переставить можно в два клика. Не жалко.
Хорошие у вас облака. А я всё по-старинке, с образа диска ставлю. Хотя мне новые виртуалки не так часто нужны.
Наверное так будете спокойны до первой публикации рабочего эксплойта выхода из песочницы популярных систем виртуализации :) а они вообще то есть, и даже эксплойты на процессор есть (на хабре была пара статеек, что то не могу сходу найти, речь идет о размещении зловреда в микрокод процессора, что перепрошивка биоса не помогает, как я понимаю зловред это перехватывает тоже).
Так опенсорс же. А железку хочется иногда поломать.
Лучше это проверю я и буду смотреть чем закрыть, чем это проверит какой-нить стажер (упаси бг — юзер), когда я уеду в отпуск. :)
Вы не могли бы разъяснить, что код делает? Создает неограниченное число сокетов, посылает в каждый сообщение и никогда не получает?
откровенно, я с сокетами не работал. Издалека выглядит так: «срёт в сокеты и тут же закрывает». Хотя смущает, что он зачем-то использует сокеты из разных пар. В рассылке писали про проблему GC (garbage collector'а) в ядре.
Создает пару UNIX-сокетов, отправляет первый _сокет_ во второй, закрывает дескриптор первого. Т.к. к первому ещё можно обратиться, если прочитать его из второго, то ядро не освобождает структуры, связанные с первым сокетом. Далее создается третий сокет, второй пишется в него, второй закрывается. И так далее. Эдакая глубокая матрёшка.
Даже если кто-то уже 100500 раз проверил данную уязвимость, на аналогичной для %username%'а системе (с аналогичным для %username%'а ядром), и у него (того, кто уже 100500 раз проверил данную уязвимость) все благополучно повисло, то %username%, будет просто обязан запустить все это у себя и отписаться: «Вот блин, у меня тоже повисло =(» =)
судя по тому, что я прочитал выше — очень странная зависимость от ОС и ядра…

Новая гипотеза: имеет отношение к preemptive сборке ядра.
2.6.35-ARCH
Пару минут тужилась, да спокойно завершилась.
Ubuntu Server, 2.6.35 EC2 (XEN DOM-U), запустилось, системе поплохело, процесс убился через SIGKILL из соседнего терминала. Сейчас попробую подождать.
Это может показаться забавным, но процессорное время процессом не жрётся, судя по показаниям top. Хотя ssh заметно лагает.
Ну, топ смотрит изнутри системы. Я смотрел из xentop'а (монитор виртуалок в xen'е) — мучимая виртуалка грузит процессор на 100%, ровно.
Глянул выскр ядра через 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]

oom — это известная проблема многих зеновских ядер. sysctrl vm.overcommit_memory=2 — и останется только soft lockup.
Последняя строчка повторяется уже несколько раз. Судя по показаниям 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 взбесится).
Я про «BUG: soft lockup — CPU#0 stuck for 61s!», убило 2 процесса всего и больше про out of memory ничего не говорило.
Взбесить питоном не удалось, убило только питона.
Используйте меньшие кусочки. На 2.6.18 баг трудноуловим. На 2.6.32-xen — цветёт и пахнет. В pv_ops его нет.
Так, оно, похоже, таки завершилось само. Или его ядро убило. Сейчас отдельно от ssh-сессии попробую запустить.
Запустил из ксеновской консоли. В общем, ядро срёт кирпичами сообщениями вида «BUG: soft lockup — CPU#0 stuck for 61s!», процесс завершился сам где-то через 4 минуты.
Archlinux 2.6.36 ядро с гентушными патчами(kernel-ice) x86-64

Запускается, чего то делает, загрузка процессора 100%, все немного подтормаживает, я минут 5 подождал, ниче не поменялось и завершил процесс.
В предвкушении завтрашней (или уже сегодняшней) новости: «С помощью локальной уязвимости в ядре, неизвестный и очень опасный хакер, вывел из строя более 100500 серверов, работающих на открытой операционной системе Линукс (это та, которая не Виндовс (ну помните, мы вам про нее уже как-то рассказывали))! Информации о том, каким образом распространяется этот опасный код и нас пока еще нет. Но то, что Линукс уязвима — это факт (мы же вас предупреждали!)!» — журналисты, они же ведь такие =)
Вообще-то, кто попало этим восмользоваться не сумеет. На правильно настроенных серверах /var, /home и /tmp смонтированы с noexec, так что даже имея там акк, запустить код не получится.
Я не помню, при прямом вызове ld оно атрибуты проверяет? Кроме того, от того, что ELF запрещён, не вытекает невозможность сделать то же самое на perl/php/python…
На FreeBSD 8.1-RELEASE воспроизвести не удалось, программа нормально завершается сразу же.
Она не может нормально завершится, там цикл бесконечный.
У вас там вот тут видимо «пшел вон»:

if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, fd)==-1)
return 1;

т.е. просто не поддерживается SEQPACKET
Проверил дома на 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 /, но в целом перезагрулся за минуту-полторы, не больше.

Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
Gentoo в смысле gentoo-sources или какие исходники?
Ну если я явно не указал кастомный набор патчей, значит gentoo-sources =)
не скажите, коллега, может Вы вообще vanilla-sources имели в виду ))
Добавьте пожалуйста, 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:
$ 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

Забыл дописать: перезагрузка шла медленно, но не слишком. Дошла до «Unmounting filesystems» и застряла. Висело так минут пять, нажал Reset.
У меня ребут на этом тоже заткнулся, но всего на минутку, после чего ребутнулся до конца сам.
Mandriva 2010.1 ядро 2.6.33.5-desktop-2mnb
запустиз из-под пользователя. Кеды начали жутко тормозить. Убился командой kill
Хм… все не совсем так. Запуск из под пользователя: съедает один процессор, что приводит к жутким тормозам(даже компиз самоотключился) первый раз каким-то чудом удалось завершить (видимо рано начал бороться). При повторном запуске ждал дольше перед тем как начал борьбу. Пытаюсь убить =) Пока без результатно, но полного зависания системы нет
напомнило: 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 вроде как нет
на убунту 10.10 пришли обновления ядра, но проверять нет ни времени, ни желания.
потестите кто-нибудь, скорее всего это фикс
Отлично! Отложим новость для будущих холливарных топиков «Linux VS Windows». :)
UFO just landed and posted this here
В openvz буду сегодня проверять.
OpenVZ + 2.6.18 Debian/Centos — не воспроизводится.

Ура! Ура! Я знал!
Кто-нибудь пробовал на макоси? Таки тоже unix.
Да, программа просто завершается сразу же. Что подозрительно, видно что-то не поддерживается, я в таком не спец.
На HP-UX ругается на ошибки в скрипте начиная с 4й строки, т.к. скорее всего нет эти библиотек по этим путям

#include
#include

а это не скрипт, это исходник
скомпильте и попробуйте

а плюс Вы бы определились HP-UX или Solaris 10
Тупанул, утро было тяжелое.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Linux 2.6.31 (Ubuntu 10.04) — работает частично (Ubuntu замущена под VirtualBox, возможно это как-то повлияло).
Запущенный процесс загружает на 100% одно ядро, не убивается по kill и kill -9, но система продолжает работать.
Какой интересный тег у статьи…
«Ядра — чистый изумруд» :)
LFS-20101029 2.6.36

viktprog[ ~ ]$ ./fail
[ 637.380714] VFS: file-max limit 25112 reached
viktprog[ ~ ]$

Под рутом так же завершается почти сразу
А что значит не получается завершить с помощью kill? Вылезает какая-то ошибка или системный вызов блокируется?
какой системный вызов? М… (ощущение полного непонимания происходящего).

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

Проц немного грузит, но музыка дальше играет, иногда прерывается. Работать возможно, но тормозно очень.
Sign up to leave a comment.

Articles