Каким образом? Вы думаете, на больших хостингах только и делают, что запускают форк-бомбы?
Я Вас разочарую, за пару лет работы на крупнейшем хостинге (саппортом, потом админом) - подобного вообще ни разу не видел. Теоретически, такое поведение может наблюдаться благодаря кривым скриптам какого-то пользователя, но вероятность мала - и с такими вещами вполне справляются обычные лимиты (limits.conf, login.conf и т.п.).
Основная причина нагрузок - обычная работа сайтов клиентов, с учетом кривости их движков и роста посещаемости. Никакие статические лимиты не позволят тут справиться с проблемой - она существенно динамическая. И ресурсов от лимитов больше никак не станет - ресурсы сервера проданы уже по нескольку раз, ибо оверселл.
Да, только прощай дешевые тарифные планы (100% существующих).
А что они делать будут? "Сайт не работает", значит хостер плохой - как эту "логику" Вы сумеете отменить?
В PHP какие настройки upload_max_filesize & max_post_size?
В nginx client_max_body_size выставлено чему равным?
Очень хочется на это посмотреть. Либо прекращайте фантазировать.
strncat(all_path, "/", sizeof("/"));
Эта строчка ГДЕ была? В коде вашего приложения или в коде ядра (например модуля)?
Ах в коде ядра... Ну вот то-то и оно. А Вы из обычного приложения панику устройте.
Не понимаете разницы? Ну так пора начинать учиться ;-) Идем в википедию и начинаем с kernel space vs user space. И далее по ссылкам.
PS: Смотрю, уже Boris A Dolgov написал аналогичный ответ. Извиняюсь, за некоторый повтор. Как говорится... оно ... мать ... его ... учения.
И что, это вызовет kernel panic?
Ну, если код работает в пространстве ядра - это баг ядра, верно? А уж сторонний это модуль или из vanila - Вам виднее, мы ж тут не телепаты совсем ;-)
Он может то, что в линукс не может ЛЮБАЯ программа, написанная на ЛЮБОМ языке программирования?
Это баг ядра. Проблемой является не приложение, а этот самый баг. Раз нашли способ воспроизвести проблему - по идее можно было бы на тестовой машинке оформить все что нужно для нормального багрепорта на @kernel.org.
А есть технические проблемы там это сделать?
Просто не называйте первый попавшийся сервер с установленной панелькой ispmanager/plesk/whatever "хостингом" - и их число упадет на много порядков. Боюсь, единицы из этих "хостеров" хоть что-то вообще знают про возможности ОС по ограничению пользователей.
А картинка прежняя?
Ну сталбыть Вы не знаете. Ни C++ ни принципов работы программ в linux.
А я просто не называю хостингами эти "каждые вторые". Вот и все. Хостинговых компаний на самом деле - десятка два-три в России. О форк-бомбах там забыли поди лет десять назад, когда большинство этих хостингов и появилось ;-)
И что надо сделать чтобы оно у меня заработало?
"Доктор - я всегда ковырял гвоздем в ухе. А вот сегодня проколол. Почему так?"
Ну а вообще что-то менялось? Нагрузка? ISP обновляли? Может вообще filemgr был отключен, если такое возможно?
Нет. Это просто фатальная ошибка - связанная либо с некоректной работой аппаратного обеспечения либо кода операционной системы.
По идее, ситуация ровно обратная - любая ошибка в пользовательском коде должна быть корректно обработана ядром. Не говоря уже, что прогаммы знать не знают о каких-то там kernel stack'ах.
Ага - он сам с треском падает.
Форк бомбы не работают у любого мало-мальски приличного хостера. Это что-то совсем бородатое.
Т.е. конкретных примеров атаки, которая гарантированно не работает на 2.6.35, но работает скажем на 2.6.26 (это debian stable) - Вы привести не можете?
Думаю, большинство довольствуется сборкой ядра из дистрибутива (+/- пара патчей).
Сменить ядро не пробовали? ИМХО, нужно крайне веские причины, чтобы такое на продакшен использовать.
А драйвера FS, контроллера и т.п. - они разве в юзерспейсе работают? Вот то-то.
Но вообще говоря, мы тут погорячились - там время ошибки с диском существенно другое.
Думаю, надо начать с того, что представить присутствующим версию ядра.
думаю, дело в диске или контроллере, а приложение вряд-ли причем тут...
