[OT] Heelp :( problem z vserverem - wszysko leży, pomaga tylko hard reset

Adam Sobieraj adam.sobieraj w neutrino.home.pl
Nie, 23 Paź 2011, 21:56:36 CEST 

Witam
 
 Pierwsza rzecz aktualizacja utils-vserver.
Druga rzecz to jak gdzieś poniżej rzuciło mi się w oczy masz kernel w
okolicach 2.6.36 i z tego co pamiętam to mi też się vservery zawieszały
więc propozycja żaby zaktualizować.

Pozdrawiam
Adam 

Dnia 2011-10-22, sob o godzinie 12:09 +0200, Jacek Osiecki pisze:
> 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).
> 
>    - 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,
> _______________________________________________
> pld-users-pl mailing list
> pld-users-pl w lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-users-pl

Więcej informacji o liście pld-users-pl