On Sat, 22 Oct 2011, Jacek Osiecki wrote:
Witam,
Już drugi raz z rzędu na jednym z hostów, noszących parę prostych guestów
(jeden nieco intensyjniejszy - stary serwer WWW, wrzucony na żywca do
vservera) wszystko się wykłada. Nagle przestają reagować vservery (a raczej -
niektóre usługi na nich), nie da się nic w nich zdiagnozować.
Dzieje się tak najprawdopodobniej przy logrotate logów apache'a na tym
większym vserverze (jako jeden z działających procesów jest odpalony
logrotate, a problem występuje o 5:02, gdy odpala się logrotate).
Aha, jeszcze dla uzupełnienia: dwa kernele na których się ten serwer
wyłożył to były kolejno:
- 2.6.36.2 + vserver&grsec
- 2.6.36.4 + vserver
Oba ręcznie kompilowane z gołych źródeł + patche z linux-vserver.org.
"Maszyny" wirtualne wisiały dosyć dziwnie - np. podsystem z bazą mysql
miał tak, że:
- działał nginx
- wisiał php-fpm (nginx zgłaszał timeout)
- mysql działał (można było wejść przez mysql-cli i zshutdownować
Podsystem podejrzewany o zwieszenie wszystkiego leżał i kwiczał - nie
działał nginx, apache, mysql, proftpd, nie dało się zabić ani jednego
procesu przy użyciu vkill -s 9 -c <context> <id>
Jakieś pomysły co to jest?
Miałem tak dwa ranki (5:02) z rzędu, teraz od dwóch dni nic (choć jest na
tym samym kernelu, czyli 2.6.36.4+vserver)...
Pozdrawiam,
--
Jacek Osiecki [email protected] GG:3828944
I don't want something I need. I want something I want.
- przy vserver svr-oldwww stop - terminal zwisa. Przy debug końcówka
jest taka:
++ test -e /etc/vservers/svr-oldwww/noisy -o -n ''
++ SILENT_OPT=--silent
+ case "$2" in
+ shift 2
+ . /usr/lib64/util-vserver/vserver.stop
+++ /usr/sbin/vserver-info /etc/vservers/svr-oldwww CANONIFY
++ lock /var/lock/vserver.etcvserverssvroldwww.startup
+++ /usr/bin/env -u TMPDIR /bin/mktemp -t vserver-lock.XXXXXX
++ local tmp=/tmp/vserver-lock.tk8JhA
++ /bin/rm -f /tmp/vserver-lock.tk8JhA
++ /usr/bin/mkfifo -m600 /tmp/vserver-lock.tk8JhA
- przy vserver --debug svr-oldwww enter kończy się tak:
++ for _fo_i in '"$@"'
++ test -n /etc/vservers/.defaults/cgroup/subsys
++ test '!' -f /etc/vservers/.defaults/cgroup/subsys
++ for _fo_i in '"$@"'
++ test -n ''
++ continue
++ test -z '' -o -n ''
++ eval 'file=""'
+++ file=
++ test -n ''
++ CGROUP_SUBSYS=($($_SED '/^#/d;/^ns[[:space:]]/d;s/[[:space:]].*//'
/proc/cgroups))
+++ /bin/sed '/^#/d;/^ns[[:space:]]/d;s/[[:space:]].*//' /proc/cgroups
Przy okazji - przy cat "/proc/cgroups" też terminal zwisa.
Top wygląda mniej więcej tak:
top - 09:03:44 up 1 day, 50 min, 7 users, load average: 130.56, 127.87,
123.75
Tasks: 399 total, 53 running, 346 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 50.1 sy, 0.0 ni, 49.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0
st
Mb Mem: 24220 total, 16410 used, 7810 free, 1375 buffers
Mb Swap: 23846 total, 0 used, 23846 free, 8502 cached
mimo to host reaguje bez zarzutu.
No i klu: w kernel.log:
Oct 22 05:02:04 alpha kernel: [74765.375087] general protection fault: 0000
[#1] SMP
Oct 22 05:02:04 alpha kernel: [74765.375301] last sysfs file:
/sys/devices/system/cpu/online
Oct 22 05:02:04 alpha kernel: [74765.375415] CPU 5
Oct 22 05:02:04 alpha kernel: [74765.375467] Modules linked in: sch_sfq xfs
exportfs e1000e iTCO_wdt i2c_i801
Oct 22 05:02:04 alpha kernel: [74765.376090]
Oct 22 05:02:04 alpha kernel: [74765.376201] Pid: 16943, comm: httpd.prefork
Not tainted 2.6.36.4-vs2.3.0.36.39golf #5 X8DT6/
X8DT6
Oct 22 05:02:04 alpha kernel: [74765.376381] RIP: 0010:[<ffffffff8103e6d8>]
[<ffffffff8103e6d8>] task_rq_lock+0x58/0xe0
Oct 22 05:02:04 alpha kernel: [74765.376619] RSP: 0018:ffff8805c3ef1da8
EFLAGS: 00010086
Oct 22 05:02:04 alpha kernel: [74765.376736] RAX: 0000000000000282 RBX:
0000000000013080 RCX: 00000000ffffffff
Oct 22 05:02:04 alpha kernel: [74765.376856] RDX: 0000000000000282 RSI:
ffff8805c3ef1df0 RDI: 2e6666666666c308
Oct 22 05:02:04 alpha kernel: [74765.376976] RBP: ffff8805c3ef1dc8 R08:
dead000000100100 R09: dead000000200200
Oct 22 05:02:04 alpha kernel: [74765.377098] R10: dead000000100100 R11:
dead000000200200 R12: 2e6666666666c308
Oct 22 05:02:04 alpha kernel: [74765.377220] R13: ffff8805c3ef1df0 R14:
0000000000013080 R15: 000000000000000f
Oct 22 05:02:04 alpha kernel: [74765.377343] FS: 00007f4992c1b740(0000)
GS:ffff88034aa80000(0000) knlGS:0000000000000000
Oct 22 05:02:04 alpha kernel: [74765.377527] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
Oct 22 05:02:04 alpha kernel: [74765.377645] CR2: 00000000019f08a0 CR3:
000000058ecd6000 CR4: 00000000000006e0
Oct 22 05:02:04 alpha kernel: [74765.377768] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Oct 22 05:02:04 alpha kernel: [74765.377889] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Oct 22 05:02:04 alpha kernel: [74765.378012] Process httpd.prefork (pid:
16943, threadinfo ffff8805c3ef0000, task ffff88060a9
30f80)
Oct 22 05:02:04 alpha kernel: [74765.378194] Stack:
Oct 22 05:02:04 alpha kernel: [74765.378303] 2e6666666666c308
ae8a05c708ec8348 0000000000000000 0000000000000005
Oct 22 05:02:04 alpha kernel: [74765.378634] <0> ffff8805c3ef1e28
ffffffff81047687 ffff8805c3ef1de8 00000000810b4f50
Oct 22 05:02:04 alpha kernel: [74765.379053] <0> ffff8805c3ef1df8
0000000000000282 ffff8805c3ef1e48 000000000044b380
Oct 22 05:02:04 alpha kernel: [74765.379572] Call Trace:
Oct 22 05:02:04 alpha kernel: [74765.379763] [<ffffffff81047687>]
try_to_wake_up+0x37/0x420
Oct 22 05:02:04 alpha kernel: [74765.379881] [<ffffffff81047a90>]
wake_up_process+0x10/0x20
Oct 22 05:02:04 alpha kernel: [74765.380002] [<ffffffff811f341f>]
wake_up_sem_queue_do+0x2f/0x50
Oct 22 05:02:04 alpha kernel: [74765.380120] [<ffffffff811f3600>]
freeary+0x1c0/0x240
Oct 22 05:02:04 alpha kernel: [74765.380238] [<ffffffff811f44d7>]
semctl_down.clone.9+0xa7/0x110
Oct 22 05:02:04 alpha kernel: [74765.380359] [<ffffffff810ac021>] ?
audit_syscall_entry+0x241/0x270
Oct 22 05:02:04 alpha kernel: [74765.380477] [<ffffffff811f48f0>]
sys_semctl+0x70/0xb0
Oct 22 05:02:04 alpha kernel: [74765.380595] [<ffffffff81003002>]
system_call_fastpath+0x16/0x1b
Oct 22 05:02:04 alpha kernel: [74765.380714] Code: 0f 1f 44 00 00 48 89 c2 48
83 3d 13 76 7f 00 00 0f 84 8e 00 00 00 48 c7 c3
80 30 01 00 fa 66 0f 1f 44 00 00 49 89 55 00 49 89 de <49> 8b 44 24 08 8b 40
18 4c 03 34 c5 a0 41 8a 81 4c 89 f7 e8 80
Oct 22 05:02:04 alpha kernel: [74765.384089] RIP [<ffffffff8103e6d8>]
task_rq_lock+0x58/0xe0
Oct 22 05:02:04 alpha kernel: [74765.384262] RSP <ffff8805c3ef1da8>
Oct 22 05:02:04 alpha kernel: [74765.384376] ---[ end trace cd66cdaeb5eebcec
] ---
Oct 22 05:44:46 alpha kernel: [77321.852715] vxW: [<BB>ps<AB>,14747:#1|0|0]
did lookup hidden devpts:ffff88030d56f5e8[#0,8]
<BB>/dev/pts/5<AB>.
Oct 22 05:44:46 alpha kernel: [77321.853127] vxW: [<BB>ps<AB>,14747:#1|0|0]
did lookup hidden devpts:ffff8802fc42cac8[#0,7]
<BB>/dev/pts/4<AB>.
Oct 22 05:44:46 alpha kernel: [77321.853453] vxW: [<BB>ps<AB>,14747:#1|0|0]
did lookup hidden devpts:ffff8802fc42cac8[#0,7]
<BB>/dev/pts/4<AB>.
Oct 22 05:44:46 alpha kernel: [77321.853789] vxW: [<BB>ps<AB>,14747:#1|0|0]
did lookup hidden devpts:ffff8802fc42cf18[#0,9]
<BB>/dev/pts/6<AB>.
a potem ostatnie dwie linie w kółko.
util-vserver i okolice najświeższe, generalnie system up-to-date.
Kernele różne, za każdym razem vaniliowe + patch vserver.
Jedyne co można zrobić to hard reset (za pomocą /proc/sysrq-trigger).
Jakieś pomysły co może być nie tak? Bo jest to dosyć załamujące, strach
stawiać vservery :(
Pozdrawiam,
--
Jacek Osiecki
[email protected]
GG:3828944
--
Jacek Osiecki [email protected] GG:3828944
I don't want something I need. I want something I want.
_______________________________________________
pld-users-pl mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
