Bug 28642 - Падение ядра при запуске сервиса vz
: Падение ядра при запуске сервиса vz
Status: CLOSED WORKSFORME
: Sisyphus
(All bugs in Sisyphus/kernel-image-ovz-el)
: unstable
: all Linux
: P3 major
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2013-03-07 12:22 by
Modified: 2014-01-10 18:11 (History)


Attachments
Отчёт system-report (104.70 KB, application/octet-stream)
2013-03-07 12:22, Evgenii Terechkov
no flags Details
Разница в конфигурации (646 bytes, patch)
2013-03-08 08:16, Evgenii Terechkov
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-03-07 12:22:41
Created an attachment (id=5762) [details]
Отчёт system-report

Положил в /etc/modprobe.d/local.conf такую проверенную временем конфигурацию:

options ipv6 disable_ipv6=1 disable=1
blacklist ipv6

В /etc/vz/vz.conf прописал IPV6="no" (потом проверял, эта переменная
не влияет). Сделал пару VE (в т.ч. 3314) запускаемыми при старте.

Перезагрузил сервер для того чтобы эти изменения вошли в силу и
получил 5-10-секундные периоды пинга прерываемые трёхминутными
периодами полной недоступности.

Оказалось, сервер циклически перезагружается (из-за panic=30)
показывая перед этим такое (пишу с фото, возможны мелкие неточности):
============8<=========================================8<============
Enabling IPv4 packet forwarding:
Configuring interface venet0:
Configuring cpuunits limit for VE0 to 1000:
Starting VE 3314: [55.7888195] BUG: unable to handle kernel NULL pointer
dereference at (null)
[  54.644070] IP: [<ffffffffa037ebdb>] ipv6_add_dev+0xab0x3d0 [ipv6]
[  54.666364] PGD 27358c067 PUD 27358d067 PMD 0
[  54.689213] Oops: 0000 [#1] SMP
[  54.712248] last sysfs file: /sys/device/virtual/net/veth334.0/add
[  54.689213] CPU 0
[  54.689213] Modules linked in: vzethdev vznetdev pio_nfs pio_direct pfmt_raw
pfmt_ploop1 ploop si
mfs vzrst nf_nat vzcpt nfs auth_rpcgss nfs_acl fscache lockd vzdquota vzmon
vzdev af_packet xt_lengt
h xt_hl xt_tcpmss xt_TCPMSS iptable_mangle xt_dscp vzevent autofs4 coretemp
hwmon sunrpc ipv6 bridge
 8021q garp stp llc xt_multiport xt_conntrack xt_pkttype xt_limt xt_tcpudp
ipt_REJECT nf_conntrack_
tftp nf_conntrack_snmp nf_conntrack_pptp nf_conntrack_proto_gre
nf_conntrack_netlink mfnetlink nf_co
nntrack_netbios_ns
============8<=========================================8<============

Экспериментально выяснено, что удаление конфигурации модуля ipv6 или
chkconfig vz off позволяют машине загрузиться до конца.

На выходных попробую воспроизвести на другом железе.
------- Comment #1 From 2013-03-07 13:28:12 -------
Используется veth?
------- Comment #2 From 2013-03-07 17:42:25 -------
Да.
------- Comment #3 From 2013-03-08 08:16:51 -------
Created an attachment (id=5764) [details]
Разница в конфигурации

Хм. Хотел выяснить, какая из двух опций модуля влияет на падение (или же обе).
В итоге вернул конфигурацию модуля к исходному виду:

options ipv6 disable_ipv6=1 disable=1
blacklist ipv6

Проверил, с ней машина загружается, VE стартуют. Стал смотреть, какие изменения
произошли с момента восстановления загрузки. Из того, что могло бы влиять, вижу
только миграцию конфигураций всех VE со старого формата на формат Vswap (по
сути, удаление всех счётчиков страниц, кроме physpages и swappages). Для
примера привожу разницу в конфигурации VE 3314 (т.к. она по номеру стартует
раньше всех).
------- Comment #4 From 2014-01-10 17:59:49 -------
Больше не воспроизводится, неактуально.