 Выяснить причины Fatal trap 12,  orzon, 12-Июл-13, 11:54 [смотреть все]Помогите найти причину отчего падает сервер.
# cd /var/crash
# kgdb -q /boot/kernel/kernel vmcore.N | tee backtrace.txt (N - это номер дампа)
(kgdb) bt
(kgdb) bt full
(kgdb) quit
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04474d7
stack pointer = 0x28:0xcc59f9c4
frame pointer = 0x28:0xcc59fa3c
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 = 24 (irq16: rl1)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 5d14h35m48s
Physical memory: 247 MB
Dumping 61 MB: 46 30 14
#0 doadump () at pcpu.h:195
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc051a9e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc051aca9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc06eb9ec in trap_fatal (frame=0xcc59f984, eva=4)
at /usr/src/sys/i386/i386/trap.c:899
#4 0xc06ebc50 in trap_pfault (frame=0xcc59f984, usermode=0, eva=4)
at /usr/src/sys/i386/i386/trap.c:812
#5 0xc06ec5d2 in trap (frame=0xcc59f984) at /usr/src/sys/i386/i386/trap.c:490
#6 0xc06d2f5b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc04474d7 in nat_new (fin=0xcc59fab4, np=0xc22d6a00, natsave=0x0, flags=)
at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2577
#8 0xc044ba32 in fr_checknatin (fin=0xcc59fab4, passp=0xcc59fab0)
at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4122
#9 0xc043d4f7 in fr_check (ip=0xc35a4d54, hlen=20, ifp=0xc1ddb400, out=0,
mp=0xcc59fb9c) at /usr/src/sys/contrib/ipfilter/netinet/fil.c:2572
#10 0xc044001f in fr_check_wrapper (arg=0x0, mp=0xcc59fb9c, ifp=0xc1ddb400,
dir=1) at /usr/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c:178
#11 0xc05b5418 in pfil_run_hooks (ph=0xc0791000, mp=0xcc59fbf4,
ifp=0xc1ddb400, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78
#12 0xc05d6321 in ip_input (m=0xc35a4d00)
at /usr/src/sys/netinet/ip_input.c:417
#13 0xc05b4f95 in netisr_dispatch (num=2, m=0xc35a4d00)
at /usr/src/sys/net/netisr.c:185
#14 0xc05af6e1 in ether_demux (ifp=0xc1ddb400, m=0xc35a4d00)
at /usr/src/sys/net/if_ethersubr.c:834
#15 0xc05afad3 in ether_input (ifp=0xc1ddb400, m=0xc35a4d00)
at /usr/src/sys/net/if_ethersubr.c:692
#16 0xc0650ee8 in rl_rxeof (sc=0xc1de1000) at /usr/src/sys/pci/if_rl.c:1205
#17 0xc0651daa in rl_intr (arg=0xc1de1000) at /usr/src/sys/pci/if_rl.c:1362
#18 0xc04fdc0b in ithread_loop (arg=0xc1deda60)
at /usr/src/sys/kern/kern_intr.c:1036
#19 0xc04faa09 in fork_exit (callout=0xc04fda60 <ithread_loop>,
arg=0xc1deda60, frame=0xcc59fd38) at /usr/src/sys/kern/kern_fork.c:781
#20 0xc06d2fd0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
(kgdb) bt full
#0 doadump () at pcpu.h:195
No locals.
#1 0xc051a9e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
_giantcnt = (kgdb) quit
|
- Выяснить причины Fatal trap 12, Andrew Kolchoogin, 23:21 , 12-Июл-13 (1)
> Помогите найти причину отчего падает сервер.А нельзя ли осведомиться хотя бы о версии используемой операционной системы? То, что это FreeBSD, понятно по использованию kgdb, но дальнейшее... Моя лично экстрасенсорикой не владеть, а штатный телепат в отпуск уехал.
- Выяснить причины Fatal trap 12, urgordeadbeef, 16:57 , 13-Июл-13 (2)
> 0xc04474d7 in nat_new (fin=0xcc59fab4, np=0xc22d6a00, natsave=0x0, flags=)
> at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2577Падает, скорее всего, из-за переполнения NAT таблицы. Но это предположение, точнее было бы посмотреть на:
frame 7
list А вообще, версию бы неплохо узнать, а релиз или стейбл ветки
- Выяснить причины Fatal trap 12, orzon, 10:07 , 15-Июл-13 (3)
>> 0xc04474d7 in nat_new (fin=0xcc59fab4, np=0xc22d6a00, natsave=0x0, flags=)
>> at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2577
> Падает, скорее всего, из-за переполнения NAT таблицы. Но это предположение, точнее было
> бы посмотреть на:
> frame 7
> list
> А вообще, версию бы неплохо узнать, а релиз или стейбл ветки Версия старенькая.
FreeBSD jag.ker.ru 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Fri Jul 5 18:14:11 MSD 2013 55@jag.ker.ru:/usr/obj/usr/src/sys/SERV2 i386 Я пробовал на тестовом сервере обновить эту систему до 8 версии, обновление прошло успешно, но падения не прекратились.
Сервер используется в качестве шлюза. Используется ipnat, ipf, еще стоит на нем squid и postfix. Вот статистика по ipnat (почти без нагрузки):
#ipnat -s
mapped in 6621462 out 5870774
added 464751 expired 463491
no memory 0 bad nat 0
inuse 1260
orphans 0
rules 48
wilds 0
hash efficiency 74.21%
bucket usage 45.68%
minimal length 0
maximal length 4
average length 1.348
TCP Entries per state
0 1 2 3 4 5 6 7 8 9 10 11
0 80 0 0 446 20 1 0 0 0 438 14 #ipf -T list | grep nattable
ipf_nattable_sz min 0x1 max 0x7fffffff current 2047
ipf_nattable_max min 0x1 max 0x7fffffff current 30000 Как думаете, по этой http://muff.kiev.ua/content/ipnat-tune статье можно оптимизировать ipnat?
- Выяснить причины Fatal trap 12, urgordeadbeef, 22:23 , 16-Июл-13 (4)
> #ipf -T list | grep nattable
> ipf_nattable_sz min 0x1 max 0x7fffffff current 2047
> ipf_nattable_max min 0x1 max 0x7fffffff
> current 30000
> Как думаете, по этой http://muff.kiev.ua/content/ipnat-tune статье можно оптимизировать
> ipnat?Можно, но для начала было бы неплохо убедиться, что тут требуется именно LARGE_NAT.
При нагрузке то реально размер таблицы близок к 30000?
Возможно правила некорректно прописаны и порождают паразитные стейты, что и приводит к исчерпанию таблицы
- Выяснить причины Fatal trap 12, orzon, 10:07 , 18-Июл-13 (5)
>[оверквотинг удален]
>> ipf_nattable_sz min 0x1 max 0x7fffffff current 2047
>> ipf_nattable_max min 0x1 max 0x7fffffff
>> current 30000
>> Как думаете, по этой http://muff.kiev.ua/content/ipnat-tune статье можно оптимизировать
>> ipnat?
> Можно, но для начала было бы неплохо убедиться, что тут требуется именно
> LARGE_NAT.
> При нагрузке то реально размер таблицы близок к 30000?
> Возможно правила некорректно прописаны и порождают паразитные стейты, что и приводит к
> исчерпанию таблицы дописал в rc.conf:
ipfilter_flags="-T ipf_nattable_sz=10009,ipf_nattable_max=300000 -E"
при перезагрузке выходит сообщение:
Enabling ipfilter.
ioctl(SIOCIPFSET): Device busy Таблица nat записей не увеличилась. Подскажите, как это исправить?
- Выяснить причины Fatal trap 12, lavr, 11:21 , 18-Июл-13 (6)
>[оверквотинг удален]
>> LARGE_NAT.
>> При нагрузке то реально размер таблицы близок к 30000?
>> Возможно правила некорректно прописаны и порождают паразитные стейты, что и приводит к
>> исчерпанию таблицы
> дописал в rc.conf:
> ipfilter_flags="-T ipf_nattable_sz=10009,ipf_nattable_max=300000 -E"
> при перезагрузке выходит сообщение:
> Enabling ipfilter.
> ioctl(SIOCIPFSET): Device busy
> Таблица nat записей не увеличилась. Подскажите, как это исправить?# ipf -D -T ipf_nattable_sz=10009,ipf_nattable_max=300000 -E
# ipf -T list |grep -i natt вручную работает?
если да - значит с /etc/rc.conf нужно иначе поступать
если нет, что-то у вас с ipfilter не то, мб старый с багами?
- Выяснить причины Fatal trap 12, urgordeadbeef, 12:59 , 18-Июл-13 (7)
> Enabling ipfilter.
> ioctl(SIOCIPFSET): Device busy
> Таблица nat записей не увеличилась. Подскажите, как это исправить?SIOCIPFSET отрабатывает только в том случае, если ipfilter загружен, но не активирован.
Иначе будет возвращаться EBUSY, как в твоём случае. Так что это некорректная инициализация. Т.е. надо сначала ipf -D, потом изменить параметры и только потом снова его включить. Если в /etc/rc.d/ipfilter такого механизма (бегло пробежался, не нашёл), то можно это сделать через переопределение start_precmd (придётся патчить /etc/rc.d/ipfilter)
- Выяснить причины Fatal trap 12, orzon, 16:09 , 18-Июл-13 (8)
>> Enabling ipfilter.
>> ioctl(SIOCIPFSET): Device busy
>> Таблица nat записей не увеличилась. Подскажите, как это исправить?
> SIOCIPFSET отрабатывает только в том случае, если ipfilter загружен, но не активирован.
> Иначе будет возвращаться EBUSY, как в твоём случае. Так что это некорректная
> инициализация.
> Т.е. надо сначала ipf -D, потом изменить параметры и только потом снова
> его включить.
> Если в /etc/rc.d/ipfilter такого механизма (бегло пробежался, не нашёл), то можно это
> сделать через переопределение start_precmd (придётся патчить /etc/rc.d/ipfilter) Я вначале прописал без опции -D. IPf прописан в ядре.
В rc.conf прописал так:
# -- IPF
ipfilter_enable="YES" # Start ipf firewall
ipfilter_rules="/etc/ipf.rules" # loads rules definition text file
ipfilter_flags="-D -T ipf_nattable_sz=10009,ipf_nattable_max=300000 -E"
ipmon_enable="YES" # Start IP monitor log
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names Загрузился вроде нормально, размерность таблиц увеличилась.
Но отрубился инет на машине. При пинге пишет:
cannot resolve ya.ru: Host name lookup failure.
От чего это произошло?
- Выяснить причины Fatal trap 12, urgordeadbeef, 18:46 , 19-Июл-13 (9)
> Загрузился вроде нормально, размерность таблиц увеличилась.
> Но отрубился инет на машине. При пинге пишет:
> cannot resolve ya.ru: Host name lookup failure.
> От чего это произошло?"У меня в подвале подземный стук, скажи мне, что там стучит."(c)
ты бы прежде чем сразу писать на форум сделал бы хоть какую-то диагностику, ну там ping 8.8.8.8 и шлюза дефолтного, правила показал бы. Задавай вопросы так, чтобы на них можно было ответить.
|
Версия для распечатки
