ISPmanager: срыв стэка. Еще один сюрприз от ISP?

Если Вы помните, что на картинке, то там именно это приложение сбивалось. Никакое другое. Просто так этот баг не вылезет. Видимо переменная all_path тоже была "не такая".

В общем то, я конечно не прав, так назвав тему, но кнопки переименования к сожалению нет. Погорячился. Хотя столько уже натерпелся от ISP, что это нормально, что она первый подозреваемый )))) Может оно и заслуженно. Даже если здесь вина и косвенная, то все равно ISP - притча во языцах. И никуда с нее не слезть, раз уж начали на ней. Слишком глубоко ушли.

Ну так а патч на ядро.

Очень хочется на это посмотреть. Либо прекращайте фантазировать.

strncat(all_path, "/", sizeof("/"));

Эта строчка ГДЕ была? В коде вашего приложения или в коде ядра (например модуля)?

Ах в коде ядра... Ну вот то-то и оно. А Вы из обычного приложения панику устройте.

Не понимаете разницы? Ну так пора начинать учиться ;-) Идем в википедию и начинаем с kernel space vs user space. И далее по ссылкам.

PS: Смотрю, уже Boris A Dolgov написал аналогичный ответ. Извиняюсь, за некоторый повтор. Как говорится... оно ... мать ... его ... учения.

Ну и часто это бывает в реальности, чтобы ради этого собирать ядра вручную? Не выгоднее ли спокойно жить на обычных ядрах ?

Если хостер это найдет, то в соответствии с офертой договор будет расторгнут, остаток денег не вернут и тд и тп.

Ты готов оплатить хостинг на 5 лет вперед на потыканном пальцем хостинге ради такого эксперимента ?

Но если это делало одно приложение, то, теоретически, это могло делать и другое и, на самом деле, Вы должны быть безумно рады, что ispmanager это воспроизвел. Так как в противном случае об этом мог бы случайно узнать недоброжелатель и каким-нибудь chmod(0, 0) долго класть все Ваши серверы.

Ядро с патчем не называется ванильным ;)

Ок, тогда вопрос. Почему во всех картинках filemgr?

Это не вопрос доказывающий, мою правоту. Тем более я не могу понять, на какую тему вы со мной спорите. Это просто вопрос, на который никто из вас отетить не может. А факт на лице: filemgr во всех 100% случаев паники ядра.

Ядро с патчем от мейнтейнеров конкретного дистрибутива не называется ванильным. А ядро, скачанное с kernel.org ванильное. Впрочем я не настаиваю на терминологии. Главное, что ядро с kernel.org, а патч с BlueHost, только переделанный нашим инженером.

Я не назову ни одного хостинга, самого именитого, у которого в теме на серче нету слова "тормозит" (кроме сетевых причин на уровне датацентра). И это факт. Только тема не этому посвящена.

Это уже другой вопрос - что там накосячили, из-за чего у Вас функция падает :) Думаю, посмотрев стрейсом бинарник менеджера файлов, ответ станет очевиден. И если Вы вызовете эту функцию из другой программы, то ядро так же упадёт.

Спорю я, собственно говоря, о том, что проблема - в патче от BlueHost или еще кого-то, а не в ядре с kernel.org или ispmgr, потому что любой вызов любого сисколла из юзерспейса никогда не должен приводить к панике в ядре, и в kernel.org это достаточно неплохо соблюдается.

Увы, прочитав патч от фаствпс на 2.6.32 не могу придумать случая, когда это должно падать :(

Тут я полностью согласен.

Но ядро с kernel.org с патчем с BlueHost это не ядро с kernel.org :)

И каким образом ты решил, что эти хостинги тормозят из-за форкбомб и злонамеренных клиентов?.

при этом еще много тем типа "хостер отключил/гонит за нагрузку". то есть и эта тоже тенденция наблюдается.

невыгоден клиент, не хочет платить больше - гони его. он ведь никому не выгоден. пусть бегает по новым хостингам пока не дойдет.

Чего принципиально нового в предоставлении услуги ты добьешься этими патчами?

Ресурсов на сервере больше не станет. А вот даунтайм ты уже получил на свою голову.

netwind добавил 27.01.2011 в 11:22

а гиде патч то? я так понимаю это чуть ли не варез. легальное не скачаешь.

Мое ИМХО. Ресурсов больше не станет - но вот рациональность их использования вырастет в несколько раз, что позволит более плотно их использовать. Также не будет необходимости вылавливать тех кто делает нагрузку на сервер (Все будут получать те ресурсы за которые платят) и не будет недовольных клиентов, которые будут идти и искать новый хостинг - потому что их сайт создал нагрузку на предыдущем хостинге.

На самом деле добились многого (в основных проблемах типовой системы хостинга). Не будет дешевых нерентабельных тарифов - все тарифы будут рентабельными. Так что игра стоит свеч...

local123, так если у пользователя закончились выделенные ресурсы, то сайт просто перестанет открываться и мы получим крики "%hostername% тормозит". Добились автоматического отключения пользователя?

"Bluehost slow" Результатов: примерно 105 000

Каким образом? Вы думаете, на больших хостингах только и делают, что запускают форк-бомбы?

Я Вас разочарую, за пару лет работы на крупнейшем хостинге (саппортом, потом админом) - подобного вообще ни разу не видел. Теоретически, такое поведение может наблюдаться благодаря кривым скриптам какого-то пользователя, но вероятность мала - и с такими вещами вполне справляются обычные лимиты (limits.conf, login.conf и т.п.).

Основная причина нагрузок - обычная работа сайтов клиентов, с учетом кривости их движков и роста посещаемости. Никакие статические лимиты не позволят тут справиться с проблемой - она существенно динамическая. И ресурсов от лимитов больше никак не станет - ресурсы сервера проданы уже по нескольку раз, ибо оверселл.

Да, только прощай дешевые тарифные планы (100% существующих).

А что они делать будут? "Сайт не работает", значит хостер плохой - как эту "логику" Вы сумеете отменить?