amx Опубликовано 5 марта, 2010 · Жалоба После апгрейда системы на 7.2 периодически стала выплывать следующая фича. ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xd fault code = supervisor read, page not present instruction pointer = 0x20:0xc08ce8f6 stack pointer = 0x28:0xe5b16770 frame pointer = 0x28:0xe5b16aa0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 47 (dummynet) trap number = 12 panic: page fault cpuid = 1 Uptime: 7h6m59s Physical memory: 2034 MB Dumping 205 MB: google по запросу dummynet page fault выдает много чего интересного, но мало решений, из которых до сути проблемы мало кто дошел, а все решения на уровне колдовства с sysctl, без объяснения причин, опять же. Одной из первых вылазит такая статья: http://opennet.ru/base/sys/freebsd_panic_solution.txt.html И как оказалось, СИСТЕМА ПАДАЕТ КОГДА УДАЛЯЕТСЯ ПРАВИЛО КОТОРОЕОТПРАВЛЯЕТ ПАКЕТЫ НА DUMMYNET, причем без разницы, есть ли в данный момент пакеты на обработке dummynet. Причем, когда загрузка меньше 1 (в еденицах из top), то все нормально, а когда загрузка превышает 1 - вероятность падежа повышается прямо пропорционально загрузке. Решение: Никогда не удалять правила фаервола, которые отправляют пакеты в DUMMYNET. Создать при старте или при необходимости, определить пайпы или queue и не торгать их больше. Надо запретить пакеты - или deny раньше по фаерволу или дать пользователю пару бит в сек. Надо отменить шейпинг - говорим "bw 0" или сказать skipto. Да, есть мнение, что наличее ненужных pipe (так как скорость на них не лимитируется) только уменьшает производительность (занимают память и dummynet с частотой Hz (из параметров ядра) их обходит), но лучше так, чем kernel panic. После замены логики - сервер без перезагрузок более недели. P.S. Не пробывали только менять правила фаэрвола через сеты (ipfw set см. man ipfw) - быть может там другая ситуация. Что же мне теперь динамически пайпы не менять или клиентов не вносить или не выносить из них? Или делать это раз в неделю с роутером в обнимку? Нет, я уж на крайняк шейпер сменю. Я кстати как раз через сеты меняю, ну так реализовано - проблема есть. Господа на фре 8.0 никто с таким не сталкивался? Самое простое мне сейчас конечно заапгредиться до 8.0. Нагрузки не очень большие: 10-20 Кппс. Или все же проблема в прокладке? :) Такое происходит при выстановлении этого параметра в 0/sbin/sysctl net.inet.ip.fw.one_pass=0 Т.е. когда пакет проходит через все правила фаервола. В момент перезапуска скрипта он у вас скорее всего флушит все правила, пайпы и очереди в результате появляются пакеты которые не знают куда заворачивать, если таких пакетов много ядро уходит в паник :-) Ушел копать как у нас там правила меняются, похоже на правду. НО: все равно, у меня будет необходимость удалять клиента из трубы и вносить его в нее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 5 марта, 2010 (изменено) · Жалоба А правило то зачем удалять ? ipfw add XXX pipe tablearg ip from any to table\(1\) out ipfw add XXX pipe tablearg ip from table\(2\) to any out (поправить по месту) набейте table 1 и 2 списком IP с номерами пайпов, как параметры. и НИКОГДА не удаляйте эти 2 правила. Сделайте table 1 flush, если никого больше шейпить вдруг не надо. смена пайпа проходит через table delete, table add И проблема стара. на 6 точно также бывало. Если у Вас не случалось раньше, то просто везло. Оно от нагрузки зависит. Изменено 5 марта, 2010 пользователем st_re Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
amx Опубликовано 5 марта, 2010 · Жалоба А правило то зачем удалять ? ipfw add XXX pipe tablearg ip from any to table\(1\) out ipfw add XXX pipe tablearg ip from table\(2\) to any out (поправить по месту) набейте table 1 и 2 списком IP с номерами пайпов, как параметры. и НИКОГДА не удаляйте эти 2 правила. Сделайте table 1 flush, если никого больше шейпить вдруг не надо. смена пайпа проходит через table delete, table add И проблема стара. на 6 точно также бывало. Если у Вас не случалось раньше, то просто везло. Оно от нагрузки зависит. Спасибо, буду копать.Мне стыдно признаться, но у нас поменьше чем 6 до этого было :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...