frozen - Page 16 - Developer IT

Why is the upgrade manager freezing when upgrading to 13.10

- by Nil

Earlier today I started to upgrade to 13.10 only to return much much later and notice that the update manager was still running. It seems to be frozen and I am reluctant to hit ctrl+C. I can't launch nautilus using the icon on the launcher. When I try to run it via the terminal, this is what happens: $ nautilus Could not register the application: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gtk.Actions' on object at path /org/gnome/Nautilus My printers aren't showing up when I attempt to print. I don't know whether these a symptoms of the same problem. Should I let the update manage continue to run, or should I shut it down? Here are the processes running if it is any help: $ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 5920 4072 ? Ss Oct18 0:02 /sbin/init root 2 0.0 0.0 0 0 ? S Oct18 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S Oct18 0:31 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S< Oct18 0:00 [kworker/0:0H] root 6 0.0 0.0 0 0 ? S Oct18 0:00 [kworker/u:0] root 7 0.0 0.0 0 0 ? S< Oct18 0:00 [kworker/u:0H] root 8 0.0 0.0 0 0 ? S Oct18 0:00 [migration/0] root 9 0.0 0.0 0 0 ? S Oct18 0:00 [rcu_bh] root 10 0.0 0.0 0 0 ? S Oct18 0:54 [rcu_sched] root 11 0.0 0.0 0 0 ? S Oct18 0:00 [watchdog/0] root 12 0.0 0.0 0 0 ? S Oct18 0:00 [watchdog/1] root 13 0.0 0.0 0 0 ? S Oct18 0:43 [ksoftirqd/1] root 14 0.0 0.0 0 0 ? S Oct18 0:00 [migration/1] root 16 0.0 0.0 0 0 ? S< Oct18 0:00 [kworker/1:0H] root 17 0.0 0.0 0 0 ? S< Oct18 0:00 [cpuset] root 18 0.0 0.0 0 0 ? S< Oct18 0:00 [khelper] root 19 0.0 0.0 0 0 ? S Oct18 0:00 [kdevtmpfs] root 20 0.0 0.0 0 0 ? S< Oct18 0:00 [netns] root 21 0.0 0.0 0 0 ? S Oct18 0:00 [bdi-default] root 22 0.0 0.0 0 0 ? S< Oct18 0:00 [kintegrityd] root 23 0.0 0.0 0 0 ? S< Oct18 0:00 [kblockd] root 24 0.0 0.0 0 0 ? S< Oct18 0:00 [ata_sff] root 25 0.0 0.0 0 0 ? S Oct18 0:00 [khubd] root 26 0.0 0.0 0 0 ? S< Oct18 0:00 [md] root 27 0.0 0.0 0 0 ? S< Oct18 0:00 [devfreq_wq] root 29 0.0 0.0 0 0 ? S Oct18 0:00 [khungtaskd] root 30 0.0 0.0 0 0 ? S Oct18 0:09 [kswapd0] root 31 0.0 0.0 0 0 ? SN Oct18 0:00 [ksmd] root 32 0.0 0.0 0 0 ? SN Oct18 0:00 [khugepaged] root 33 0.0 0.0 0 0 ? S Oct18 0:00 [fsnotify_mark] root 34 0.0 0.0 0 0 ? S Oct18 0:00 [ecryptfs-kthre root 35 0.0 0.0 0 0 ? S< Oct18 0:00 [crypto] root 46 0.0 0.0 0 0 ? S< Oct18 0:00 [kthrotld] root 49 0.0 0.0 0 0 ? S< Oct18 0:00 [binder] root 69 0.0 0.0 0 0 ? S< Oct18 0:00 [deferwq] root 70 0.0 0.0 0 0 ? S< Oct18 0:00 [charger_manage root 166 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_0] root 167 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_1] root 188 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_2] root 244 0.0 0.0 0 0 ? S Oct18 0:00 [kworker/u:4] root 245 0.0 0.0 0 0 ? S< Oct18 0:00 [ttm_swap] root 260 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_3] root 266 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_4] root 267 0.0 0.0 0 0 ? S Oct18 1:08 [usb-storage] root 268 0.0 0.0 0 0 ? S Oct18 0:00 [scsi_eh_5] root 269 0.0 0.0 0 0 ? S Oct18 0:06 [usb-storage] root 302 0.0 0.0 2904 504 ? S 14:11 0:00 upstart-udev-br root 305 0.0 0.0 12080 1632 ? Ss 14:11 0:00 /lib/systemd/sy root 329 0.0 0.0 0 0 ? S Oct18 0:24 [jbd2/sda2-8] root 330 0.0 0.0 0 0 ? S< Oct18 0:00 [ext4-dio-unwri root 352 0.0 0.0 2944 4 ? S Oct18 0:00 /sbin/ureadahea root 440 0.0 0.0 0 0 ? S Oct18 0:05 [flush-8:0] root 734 0.0 0.0 0 0 ? S< Oct18 0:00 [cfg80211] root 761 0.0 0.0 0 0 ? S< Oct18 0:00 [kpsmoused] root 780 0.0 0.0 0 0 ? S Oct18 0:00 [pccardd] root 784 0.0 0.0 0 0 ? S< Oct18 0:00 [kvm-irqfd-clea root 902 0.0 0.0 0 0 ? S< Oct18 0:00 [hd-audio0] syslog 916 0.0 0.0 31120 680 ? Sl Oct18 0:13 rsyslogd -c5 102 1010 0.0 0.1 4344 1988 ? Ss Oct18 0:04 dbus-daemon --s root 1061 0.0 0.0 4844 924 ? Ss Oct18 0:00 /usr/sbin/bluet root 1077 0.0 0.0 2268 388 ? Ss Oct18 0:00 /bin/sh /etc/in root 1079 0.0 0.0 4664 484 tty4 Ss+ Oct18 0:00 /sbin/getty -8 root 1087 0.0 0.0 4664 484 tty5 Ss+ Oct18 0:00 /sbin/getty -8 root 1089 0.0 0.0 0 0 ? S< Oct18 0:00 [krfcommd] root 1098 0.0 0.0 4664 484 tty2 Ss+ Oct18 0:00 /sbin/getty -8 root 1099 0.0 0.1 4408 2076 tty3 Ss Oct18 0:00 /bin/login -- root 1101 0.0 0.0 4664 484 tty6 Ss+ Oct18 0:00 /sbin/getty -8 root 1168 0.0 0.0 2780 524 ? Ss Oct18 0:00 cron daemon 1169 0.0 0.0 2636 212 ? Ss Oct18 0:00 atd root 1183 0.0 0.0 34872 1448 ? SLsl Oct18 0:00 lightdm root 1249 0.0 0.0 3536 468 ? S Oct18 0:00 /bin/bash /etc/ root 1254 4.2 2.2 125832 40040 tty7 Rsl+ Oct18 81:27 /usr/bin/X :0 - root 1261 0.0 0.0 2268 344 ? S Oct18 0:00 /bin/sh /etc/ac root 1265 0.0 0.1 42004 2836 ? Ssl Oct18 0:01 NetworkManager root 1272 0.0 0.0 2268 376 ? S Oct18 0:00 /bin/sh /usr/sb root 1286 0.0 0.3 30616 5824 ? Sl Oct18 0:05 /usr/lib/policy root 1304 0.0 0.0 2268 372 ? D Oct18 0:00 /bin/sh /usr/li root 1360 0.0 0.0 5532 560 ? S Oct18 0:00 /sbin/dhclient nobody 1368 0.0 0.0 5476 784 ? S Oct18 0:00 /usr/sbin/dnsma root 1514 0.0 0.1 34036 1932 ? Sl Oct18 0:01 /usr/lib/accoun root 1530 0.0 0.0 0 0 ? S Oct18 0:00 [kauditd] root 1536 0.0 0.1 30480 2260 ? Sl Oct18 0:01 /usr/sbin/conso root 1653 0.0 0.1 28908 2104 ? Sl Oct18 0:00 /usr/lib/upower root 1698 0.0 0.0 17464 1388 ? Sl Oct18 0:00 lightdm --sessi rtkit 1750 0.0 0.0 21368 696 ? SNl Oct18 0:00 /usr/lib/rtkit/ 1000 1844 0.0 0.1 88116 2320 ? SLl Oct18 0:00 /usr/bin/gnome- 1000 1855 0.0 0.3 73076 5884 ? Ssl Oct18 0:00 gnome-session - 1000 1901 0.0 0.0 4128 24 ? Ss Oct18 0:00 /usr/bin/ssh-ag 1000 1904 0.0 0.0 3880 192 ? S Oct18 0:00 /usr/bin/dbus-l 1000 1905 0.0 0.1 5520 2500 ? Ss Oct18 0:23 //bin/dbus-daem 1000 1915 0.0 0.0 43348 1420 ? Sl Oct18 0:00 /usr/lib/at-spi 1000 1919 0.0 0.0 3412 1252 ? S Oct18 0:01 /bin/dbus-daemo 1000 1922 0.0 0.0 17176 1624 ? Sl Oct18 0:00 /usr/lib/at-spi 1000 1932 0.0 0.5 165916 9124 ? Sl Oct18 0:21 /usr/lib/gnome- 1000 1947 1.9 0.2 100716 4024 ? S<l Oct18 37:48 /usr/bin/pulsea 1000 1949 0.0 0.0 27568 1616 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 1953 0.0 0.0 42628 1184 ? Sl Oct18 0:00 /usr/lib/gvfs// 1000 1962 0.0 0.0 14472 916 ? S Oct18 0:00 /usr/lib/pulsea 1000 1964 0.0 0.1 9548 2480 ? S Oct18 0:00 /usr/lib/i386-l 1000 1980 0.0 0.0 3764 364 ? S Oct18 0:43 syndaemon -i 1. 1000 1987 0.0 0.0 24476 1668 ? Sl Oct18 0:00 /usr/lib/dconf/ 1000 1990 0.0 0.4 122968 8844 ? Sl Oct18 0:00 /usr/lib/policy 1000 1991 0.0 0.2 80480 5392 ? Sl Oct18 0:00 /usr/lib/gnome- 1000 1992 0.0 1.2 167532 22776 ? Sl Oct18 0:07 nautilus -n 1000 1998 0.0 0.4 181444 7744 ? Sl Oct18 0:00 nm-applet 1000 2002 0.0 0.1 38020 2892 ? Sl Oct18 0:00 /usr/lib/gvfs/g root 2012 0.0 0.1 59908 2664 ? Sl Oct18 0:24 /usr/lib/udisks 1000 2024 0.0 0.0 26456 1540 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 2028 0.0 0.0 27684 1536 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 2036 0.0 0.0 38964 1452 ? Sl Oct18 0:00 /usr/lib/gvfs/g root 2049 0.0 0.0 3328 588 ? Ss Oct18 0:00 /sbin/mount.ntf 1000 2053 0.0 0.0 36792 1284 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 2058 0.0 0.1 53664 2364 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 2069 0.0 0.4 82816 8112 ? Sl Oct18 0:07 /usr/lib/i386-l 1000 2084 0.0 0.1 17984 2048 ? Sl Oct18 0:00 /usr/lib/gvfs/g 1000 2086 0.0 0.0 2268 392 ? Ss Oct18 0:00 /bin/sh -c /usr 1000 2087 0.0 0.7 68100 12856 ? Sl Oct18 0:13 /usr/bin/gtk-wi 1000 2089 0.0 0.9 98508 17756 ? Sl Oct18 0:13 /usr/lib/unity/ 1000 2091 0.0 0.3 65380 6692 ? Sl Oct18 0:01 /usr/lib/i386-l 1000 2117 0.0 0.2 98024 3888 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2125 0.0 0.1 86644 3408 ? Sl Oct18 0:00 /usr/lib/indica 1000 2126 0.0 0.3 84272 6664 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2127 0.0 0.1 94384 2752 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2128 0.0 0.1 83968 2828 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2129 0.0 0.2 150020 4684 ? Sl Oct18 0:01 /usr/lib/i386-l 1000 2130 0.0 0.2 86572 3884 ? Sl Oct18 0:00 /usr/lib/indica 1000 2131 0.0 0.1 69352 2524 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2144 0.0 0.1 74192 3152 ? Sl Oct18 0:00 /usr/lib/evolut 1000 2182 0.0 0.2 101120 4420 ? Sl Oct18 0:02 /usr/lib/gnome- 1000 2193 0.0 0.3 77752 6448 ? Sl Oct18 0:00 telepathy-indic 1000 2200 0.0 0.1 44032 2708 ? Sl Oct18 0:00 /usr/lib/telepa 1000 2209 0.0 0.2 77664 3860 ? Sl Oct18 0:02 zeitgeist-datah 1000 2216 0.0 0.2 44464 4180 ? Sl Oct18 0:01 /usr/bin/zeitge root 2234 0.0 0.0 0 0 ? S< Oct18 0:00 [kworker/1:1H] 1000 2246 0.0 1.1 93428 21256 ? Sl Oct18 0:02 /usr/bin/python 1000 2284 0.0 0.6 110040 11656 ? Sl Oct18 0:14 /usr/lib/i386-l 1000 2289 0.0 0.2 85632 3728 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2296 0.0 0.1 77900 3388 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2298 0.0 0.6 120356 11992 ? Sl Oct18 0:00 /usr/bin/python 1000 2300 0.0 0.1 87560 2408 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2301 0.0 0.2 91764 4404 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2303 0.0 0.2 78224 4592 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2370 0.0 0.2 74976 4908 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2372 0.0 0.4 106760 8972 ? Sl Oct18 0:00 /usr/bin/python 1000 2394 0.0 0.1 95624 2736 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2433 0.0 0.1 46640 2124 ? Sl Oct18 0:00 /usr/lib/i386-l 1000 2457 0.0 0.0 34496 1648 ? Sl Oct18 0:00 /usr/lib/libuni root 2513 0.0 0.0 0 0 ? S< Oct18 0:00 [kworker/0:1H] 1000 3361 0.0 0.0 2268 396 ? SN 07:54 0:20 /bin/sh -c /usr root 4919 1.8 2.1 201196 38760 ? SNl 13:29 11:25 /usr/bin/python root 4957 0.0 0.0 3880 400 ? SN 13:29 0:00 dbus-launch --a root 4958 0.0 0.0 3424 1196 ? SNs 13:29 0:05 //bin/dbus-daem root 5128 0.0 0.0 2268 416 ? SN 13:50 0:00 /bin/sh -c whil root 5141 0.0 0.0 2436 508 ? SN 13:50 0:00 gnome-pty-helpe root 5145 0.0 1.7 245280 30872 pts/1 SNs+ 13:50 0:05 /usr/bin/python root 5159 0.0 0.4 64200 7432 ? SNl 13:50 0:05 /usr/bin/gnome- root 5163 0.0 0.0 27440 1552 ? SNl 13:50 0:00 /usr/lib/gvfs/g root 5167 0.0 0.0 42628 1648 ? SNl 13:50 0:00 /usr/lib/gvfs// root 9236 0.0 0.1 19112 2680 ? Ss 14:33 0:00 /usr/sbin/winbi root 9243 0.0 0.0 19112 1448 ? S 14:33 0:00 /usr/sbin/winbi whoopsie 9409 0.0 0.2 53608 4264 ? Ssl 14:33 0:00 whoopsie root 20087 0.0 0.0 0 0 ? S< 14:34 0:00 [xfsalloc] root 20088 0.0 0.0 0 0 ? S< 14:34 0:00 [xfs_mru_cache] root 20089 0.0 0.0 0 0 ? S< 14:34 0:00 [xfslogd] root 20092 0.0 0.0 0 0 ? S 14:34 0:00 [jfsIO] root 20093 0.0 0.0 0 0 ? S 14:34 0:00 [jfsCommit] root 20094 0.0 0.0 0 0 ? S 14:34 0:00 [jfsCommit] root 20095 0.0 0.0 0 0 ? S 14:34 0:00 [jfsSync] root 20845 0.0 0.3 7980 6048 pts/2 SNs+ 14:29 0:04 /usr/bin/dpkg - root 23330 0.0 0.0 2896 568 ? S 14:09 0:00 upstart-file-br root 23332 0.0 0.0 2884 572 ? S 14:09 0:00 upstart-socket- root 24577 0.2 0.0 0 0 ? S 23:09 0:04 [kworker/1:2] root 24656 0.1 0.0 0 0 ? S 23:10 0:02 [kworker/0:0] 1000 24758 2.8 4.7 243692 85516 ? Sl 23:11 0:50 compiz root 25774 0.0 0.0 0 0 ? S< 14:39 0:00 [iprt] 1000 26128 5.5 10.3 641628 187420 ? Sl 23:27 0:46 /usr/lib/firefo root 26374 0.0 0.0 3964 720 ? Ss 14:39 0:02 /usr/sbin/irqba root 26534 0.0 0.0 0 0 ? S 23:34 0:00 [kworker/0:1] root 26564 0.0 0.0 0 0 ? S 23:35 0:00 [kworker/1:1] 1000 26664 0.0 0.1 6784 3068 tty3 S+ 23:36 0:00 -bash 1000 26936 15.2 1.3 67520 23672 ? Sl 23:39 0:21 gnome-system-mo root 26992 0.0 0.0 0 0 ? S 23:40 0:00 [kworker/1:0] root 27049 0.0 0.0 4248 288 ? SN 23:41 0:00 sleep 30 1000 27057 9.5 0.8 68624 16140 ? Rl 23:41 0:00 gnome-terminal 1000 27064 0.0 0.0 2440 704 ? S 23:41 0:00 gnome-pty-helpe 1000 27065 2.6 0.1 6344 2608 pts/3 Ss 23:41 0:00 bash 1000 27113 0.0 0.0 5240 1144 pts/3 R+ 23:41 0:00 ps aux root 28267 0.0 0.0 2216 632 ? Ss 14:39 0:00 acpid -c /etc/a root 28333 0.0 0.0 2272 552 pts/2 SN+ 14:39 0:00 /bin/sh /var/li root 29699 0.0 0.2 8384 4608 pts/2 SN+ 14:40 0:00 modprobe wl

Read the article

The impossible inline Javascript delay/sleep

- by trex005

There is a JavaScript function, of which I have zero control of the code, which calls a function that I wrote. My function uses DOM to generate an iFrame, defines it's src and then appends it to another DOM element. However, before my function returns, and thus allows continued execution of the containing function, it is imperative that the iFrame be fully loaded. Here are the things that I have tried and why they do not work : 1. The SetTimeout option : 99.999% of the time, this is THE answer. As a matter of fact, in the past decade that I have been mentoring in JavaScript, I have always insisted that code could always be refactored to use this option, and never believed a scenario existed where that was not the case. Well, I finally found one! The problem is that because my function is being called inline, if the very next line is executed before my iFrame finishes loading, it totally neuters my script, and since the moment my script completes, the external script continues. A callback of sorts will not work 2. The "Do nothing" loop :This option you use while(//iFrame is not loaded){//do nothing}. In theory this would not return until the frame is loaded. The problem is that since this hogs all the resources, the iFrame never loads. This trick, although horribly unprofessional, dirty etc. will work when you just need an inline delay, but since I require an external thread to complete, it will not.In FF, after a few seconds, it pauses the script and an alert pops up stating that there is an unresponsive script. While that alert is up, the iFrame is able to load, and then my function is able to return, but having the browser frozen for 10 seconds, and then requiring the user to correctly dismiss an error is a no go. 3. The model dialogue : I was inspired by the fact that the FF popup allowed the iFrame to load while halting the execution of the function, and thinking about it, I realized that it is because the modal dialogue, is a way of halting execution yet allowing other threads to continue! Brilliant, so I decided to try other modal options. Things like alert() work beautifully! When it pops up, even if only up for 1/10th of a second, the iFrame is able to complete, and all works great. And just in case the 1/10 of a second is not sufficient, I can put the model dialogue in the while loop from solution 2, and it would ensure that the iFrame is loaded in time. Sweet right? Except for the fact that I now have to pop up a very unprofessional dialogue for the user to dismiss in order to run my script. I fought with myself about this cost/benefit of this action, but then I encountered a scenario where my code was called 10 times on a single page! Having to dismiss 10 alerts before acessing a page?! That reminds me of the late 90s script kiddie pages, and is NOT an option. 4. A gazillion other delay script out there:There are about 10 jQuery delay or sleep functions, some of them actually quite cleverly developed, but none worked. A few prototype options, and again, none I found could do it! A dozen or so other libraries and frameworks claimed they had what I needed, but alas they all conspired to give me false hope. I am convinced that since a built in model dialogue can halt execution, while allowing other threads to continue, there must be some code accessible way to do the same thing with out user input. The Code is literally thousands upon thousands of lines and is proprietary, so I wrote this little example of the problem for you to work with. It is important to note the ONLY code you are able to change is in the onlyThingYouCanChange function Test File : <html> <head> </head> </html> <body> <div id='iFrameHolder'></div> <script type='text/javascript'> function unChangeableFunction() { new_iFrame = onlyThingYouCanChange(document.getElementById('iFrameHolder')); new_iFrame_doc = (new_iFrame.contentWindow || new_iFrame.contentDocument); if(new_iFrame_doc.document)new_iFrame_doc=new_iFrame_doc.document; new_iFrame_body = new_iFrame_doc.body; if(new_iFrame_body.innerHTML != 'Loaded?') { //The world explodes!!! alert('you just blew up the world! Way to go!'); } else { alert('wow, you did it! Way to go!'); } } var iFrameLoaded = false; function onlyThingYouCanChange(objectToAppendIFrameTo) { iFrameLoaded = false; iframe=document.createElement('iframe'); iframe.onload = new Function('iFrameLoaded = true'); iframe.src = 'blank_frame.html'; //Must use an HTML doc on the server because there is a very specific DOM structure that must be maintained. objectToAppendIFrameTo.appendChild(iframe); var it = 0; while(!iFrameLoaded) //I put the limit on here so you don't { //If I was able to put some sort of delay here that paused the exicution of the script, but did not halt all other browser threads, and did not require user interaction we'd be golden! //alert('test'); //This would work if it did not require user interaction! } return iframe; } unChangeableFunction(); </script> </body> blank_frame.html : <html> <head> </head> <body style='margin:0px'>Loaded?</body> </html>

Read the article

qemu-kvm virtual machine virtio network freeze under load

- by Rick Koshi

I'm having a problem with my virtual machines, where the network will freeze under heavy load. I'm using CentOS 6.2 as both host and guest, not using libvirt, just running qemu-kvm directly as follows: /usr/libexec/qemu-kvm \ -drive file=/data2/vm/rb-dev2-www1-vm.img,index=0,media=disk,cache=none,if=virtio \ -boot order=c \ -m 2G \ -smp cores=1,threads=2 \ -vga std \ -name rb-dev2-www1-vm \ -vnc :84,password \ -net nic,vlan=0,macaddr=52:54:20:00:00:54,model=virtio \ -net tap,vlan=0,ifname=tap84,script=/etc/qemu-ifup \ -monitor unix:/var/run/vm/rb-dev2-www1-vm.mon,server,nowait \ -rtc base=utc \ -device piix3-usb-uhci \ -device usb-tablet /etc/qemu-ifup (used by the above command) is a very simple script, containing the following: #!/bin/sh sudo /sbin/ifconfig $1 0.0.0.0 promisc up sudo /usr/sbin/brctl addif br0 $1 sleep 2 And here's the info on br0 and other interfaces: avl-host3 14# brctl show bridge name bridge id STP enabled interfaces br0 8000.180373f5521a no bond0 tap84 virbr0 8000.525400858961 yes virbr0-nic avl-host3 15# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff 3: em2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff 4: em3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 18:03:73:f5:52:1e brd ff:ff:ff:ff:ff:ff 5: em4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 18:03:73:f5:52:20 brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff inet6 fe80::1a03:73ff:fef5:521a/64 scope link valid_lft forever preferred_lft forever 7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff inet 172.16.1.46/24 brd 172.16.1.255 scope global br0 inet6 fe80::1a03:73ff:fef5:521a/64 scope link valid_lft forever preferred_lft forever 8: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:85:89:61 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 9: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500 link/ether 52:54:00:85:89:61 brd ff:ff:ff:ff:ff:ff 12: tap84: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether ba:e8:9b:2a:ff:48 brd ff:ff:ff:ff:ff:ff inet6 fe80::b8e8:9bff:fe2a:ff48/64 scope link valid_lft forever preferred_lft forever bond0 is a bond of em1 and em2. virbr0 and virbr0-nic are vestigial interfaces left over from CentOS's default installation. They are unused (as far as I know). The guest runs perfectly until I run a large 'rsync', when the network will freeze after some seemingly-random time (usually under a minute). When it freezes, there is no network activity in or out of the guest. I can still connect to the guest's console via vnc, but it is unable to speak out its network interface. Any attempt to 'ping' from the guest gives a "Destination Host Unreachable" error for 3/4 packets and no reply for every fourth packet. Sometimes (perhaps two thirds of the time), I can bring the interface back to life by doing a "service network restart" from the guest's console. If this works (and if I do it before the rsync times out), the rsync will resume. Usually it will freeze again within a minute or two. If I repeat, the rsync will eventually finish, and I presume the machine goes back to waiting for another period of heavy load. Throughout the whole process, there are no console errors or relevant (that I can see) syslog messages on either guest or host machine. If the "service network restart" doesn't work the first time, trying again (and again and again) never seems to work. The command completes normally, with normal output, but the interface stays frozen. However, a soft reboot of the guest machine (without restarting qemu-kvm) always seems to bring it back. I am aware of the "lowest mac address" assignment problem, where the bridge takes on the mac address of the slave interface with the lowest mac address. This causes temporary network freezes, but is definitely not what's happening for me. My freezes are permanent until manual intervention, and you can see from the 'ip addr show' output above that the mac address being used by br0 is that of the physical ethernet. There are no other virtual machines running on the host. I've verified that each virtual machine on the subnet has its own unique mac address. I have rebuilt the guest machine several times, and I have tried this on three different host machines (identical hardware, built identically). Oddly, I do have one virtual host (the second of this series) which never seemed to have a problem. It never had its network freeze when it was running the same rsync during its build. It's particularly odd because it was the second build. The first, on a different host, did have the freezing problem, but the second did not. I assumed at the time that I had done something wrong with the first build, and that the problem was resolved. Unfortunately, the problem reappeared when I built the third VM. Also unfortunately, I can't do many tests with the working VM, as it's now in production use, and I'm hoping I can find the cause of this issue before that machine starts having problems. It's possible that I just got really lucky while running the rsync on the working machine, and that one time it didn't freeze. Of course it's possible that I somehow changed the build scripts without realizing it and re-broke something, but I can't find any such thing. In any case, I'm hoping someone has some idea what could cause this. Addendum: Preliminary tests suggest that I don't have the problem if I substitute e1000 for virtio in the first -net flag to qemu-kvm. I don't consider this a solution, but it is suitable for a stopgap. Has anyone else had (or better yet, solved) this problem with the virtio network driver?

Read the article

Server randomly freezes

- by PsySkeletor

Im facing a very strange issue, my debian squeeze freezes up always at night (Berlin, time). Here is what i get from a time and after doing this a few times, it becomes frozen and must be hard-reset. From /var/log/messages Dec 11 01:36:11 srv156 kernel: [125983.204251] CPU 1: Dec 11 01:36:11 srv156 kernel: [125983.204251] Modules linked in: xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_recent xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables hwmon_vid snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm radeon snd_timer ttm drm_kms_helper snd k10temp i2c_piix4 soundcore snd_page_alloc edac_core parport_pc drm i2c_algo_bit i2c_core shpchp pci_hotplug pcspkr edac_mce_amd parport wmi evdev processor button ext3 jbd mbcache raid1 md_mod sd_mod crc_t10dif ata_generic ahci ohci_hcd pata_atiixp e100 mii libata xhci floppy ehci_hcd thermal thermal_sys usbcore scsi_mod nls_base [last unloaded: i2c_dev] Dec 11 01:36:11 srv156 kernel: [125983.204251] Pid: 758, comm: flush-9:0 Tainted: G B 2.6.32-5-amd64 #1 GA-78LMT-USB3 Dec 11 01:36:11 srv156 kernel: [125983.204251] RIP: 0010:[<ffffffff810b3506>] [<ffffffff810b3506>] find_get_pages_tag+0x66/0xdd Dec 11 01:36:11 srv156 kernel: [125983.204251] RSP: 0018:ffff8804235e7b30 EFLAGS: 00000286 Dec 11 01:36:11 srv156 kernel: [125983.204251] RAX: ffffffffffffffff RBX: ffff8804235e7c00 RCX: 0000000000000000 Dec 11 01:36:11 srv156 kernel: [125983.204251] RDX: 0000000000040000 RSI: ffffea000496b2a8 RDI: ffffea000496b2a0 Dec 11 01:36:11 srv156 kernel: [125983.204251] RBP: ffffffff8101166e R08: ffff8804235e7af0 R09: 0000000000000000 Dec 11 01:36:11 srv156 kernel: [125983.204251] R10: 0000000000000000 R11: 0000000000040000 R12: ffff8804235e7c08 Dec 11 01:36:11 srv156 kernel: [125983.204251] R13: 0000000d22678a20 R14: ffff8804235e7af0 R15: 00000000091b9060 Dec 11 01:36:11 srv156 kernel: [125983.204251] FS: 0000000000000000(0000) GS:ffff880010440000(0000) knlGS:000000007ebf7b70 Dec 11 01:36:11 srv156 kernel: [125983.204522] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Dec 11 01:36:11 srv156 kernel: [125983.204522] CR2: 00000000dec86000 CR3: 0000000001001000 CR4: 00000000000006e0 Dec 11 01:36:11 srv156 kernel: [125983.204522] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 11 01:36:11 srv156 kernel: [125983.204522] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Dec 11 01:36:11 srv156 kernel: [125983.204522] Call Trace: Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810bb792>] ? pagevec_lookup_tag+0x1a/0x21 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810ba330>] ? write_cache_pages+0x162/0x327 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810b9d48>] ? __writepage+0x0/0x25 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff8110758a>] ? writeback_single_inode+0xe7/0x2da Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81108290>] ? writeback_inodes_wb+0x424/0x4ff Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81108497>] ? wb_writeback+0x12c/0x1ab Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff8110870d>] ? wb_do_writeback+0x14f/0x165 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81108754>] ? bdi_writeback_task+0x31/0xaa Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810c8664>] ? bdi_start_fn+0x0/0xd0 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810c86d4>] ? bdi_start_fn+0x70/0xd0 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff810c8664>] ? bdi_start_fn+0x0/0xd0 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81064ac1>] ? kthread+0x79/0x81 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81011baa>] ? child_rip+0xa/0x20 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81064a48>] ? kthread+0x0/0x81 Dec 11 01:36:11 srv156 kernel: [125983.204522] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 From /var/log/syslog Dec 10 21:20:29 srv156 kernel: [110625.162930] BUG: Bad page map in process java pte:14fa4f067 pmd:424b54067 Dec 10 21:20:29 srv156 kernel: [110625.162937] page:ffffea000496c148 flags:0200000000000878 count:2 mapcount:-1 mapping:ffff88014f8d7de8 index:2f4 Dec 10 21:20:29 srv156 kernel: [110625.162946] addr:0000000009096000 vm_flags:00100077 anon_vma:ffff880422410d40 mapping:(null) index:9096 Dec 10 21:20:29 srv156 kernel: [110625.162955] Pid: 21356, comm: java Tainted: G B 2.6.32-5-amd64 #1 Dec 10 21:20:29 srv156 kernel: [110625.162961] Call Trace: Dec 10 21:20:29 srv156 kernel: [110625.162966] [<ffffffff810ca4bf>] ? print_bad_pte+0x232/0x24a Dec 10 21:20:29 srv156 kernel: [110625.162973] [<ffffffff810cb56f>] ? unmap_vmas+0x62d/0x931 Dec 10 21:20:29 srv156 kernel: [110625.162980] [<ffffffff810cfc74>] ? exit_mmap+0xc4/0x148 Dec 10 21:20:29 srv156 kernel: [110625.162986] [<ffffffff8104bbc1>] ? mmput+0x3c/0xdf Dec 10 21:20:29 srv156 kernel: [110625.162992] [<ffffffff8104f81e>] ? exit_mm+0x102/0x10d Dec 10 21:20:29 srv156 kernel: [110625.162998] [<ffffffff81051243>] ? do_exit+0x1f8/0x6c9 Dec 10 21:20:29 srv156 kernel: [110625.163004] [<ffffffff81071abb>] ? futex_wake+0xd6/0xe7 Dec 10 21:20:29 srv156 kernel: [110625.163010] [<ffffffff8105178a>] ? do_group_exit+0x76/0x9d Dec 10 21:20:29 srv156 kernel: [110625.163016] [<ffffffff8105df9f>] ? get_signal_to_deliver+0x310/0x339 Dec 10 21:20:29 srv156 kernel: [110625.163023] [<ffffffff81010037>] ? do_notify_resume+0x87/0x73f Dec 10 21:20:29 srv156 kernel: [110625.163029] [<ffffffff810cc664>] ? handle_mm_fault+0x7aa/0x80f Dec 10 21:20:29 srv156 kernel: [110625.163036] [<ffffffff81073f14>] ? compat_sys_futex+0x10d/0x12b Dec 10 21:20:29 srv156 kernel: [110625.163043] [<ffffffff812fb546>] ? do_page_fault+0x2e0/0x2fc Dec 10 21:20:29 srv156 kernel: [110625.163049] [<ffffffff81010e0e>] ? int_signal+0x12/0x17 Dec 10 21:20:29 srv156 kernel: [110625.163114] BUG: Bad page state in process java pfn:14fa0c Dec 10 21:20:29 srv156 kernel: [110625.163120] page:ffffea000496b2a0 flags:020000000002001c count:0 mapcount:-1 mapping:ffff88039dc0db30 index:11e3 Dec 10 21:20:29 srv156 kernel: [110625.164563] Pid: 21356, comm: java Tainted: G B 2.6.32-5-amd64 #1 Dec 10 21:20:29 srv156 kernel: [110625.164570] Call Trace: Dec 10 21:20:29 srv156 kernel: [110625.164578] [<ffffffff810b71a9>] ? bad_page+0x116/0x129 Dec 10 21:20:29 srv156 kernel: [110625.164586] [<ffffffff810b7692>] ? free_pages_check+0x38/0x57 Dec 10 21:20:29 srv156 kernel: [110625.164595] [<ffffffff810b89cf>] ? free_hot_cold_page+0x46/0x190 Dec 10 21:20:29 srv156 kernel: [110625.164603] [<ffffffff810b8b82>] ? __pagevec_free+0x69/0x7f Dec 10 21:20:29 srv156 kernel: [110625.164611] [<ffffffff810bba3f>] ? release_pages+0x137/0x18d Dec 10 21:20:29 srv156 kernel: [110625.164620] [<ffffffff810d8559>] ? free_pages_and_swap_cache+0x57/0x73 Dec 10 21:20:29 srv156 kernel: [110625.164629] [<ffffffff810cb5ed>] ? unmap_vmas+0x6ab/0x931 Dec 10 21:20:29 srv156 kernel: [110625.164637] [<ffffffff810cfc74>] ? exit_mmap+0xc4/0x148 Dec 10 21:20:29 srv156 kernel: [110625.164644] [<ffffffff8104bbc1>] ? mmput+0x3c/0xdf Dec 10 21:20:29 srv156 kernel: [110625.164652] [<ffffffff8104f81e>] ? exit_mm+0x102/0x10d Dec 10 21:20:29 srv156 kernel: [110625.164660] [<ffffffff81051243>] ? do_exit+0x1f8/0x6c9 Dec 10 21:20:29 srv156 kernel: [110625.164667] [<ffffffff81071abb>] ? futex_wake+0xd6/0xe7 Dec 10 21:20:29 srv156 kernel: [110625.164675] [<ffffffff8105178a>] ? do_group_exit+0x76/0x9d Dec 10 21:20:29 srv156 kernel: [110625.164683] [<ffffffff8105df9f>] ? get_signal_to_deliver+0x310/0x339 Dec 10 21:20:29 srv156 kernel: [110625.164692] [<ffffffff81010037>] ? do_notify_resume+0x87/0x73f Dec 10 21:20:29 srv156 kernel: [110625.164700] [<ffffffff810cc664>] ? handle_mm_fault+0x7aa/0x80f The last piece of log, has been recently posted, because I've just found it. It seems Java process do something and began to slowly eat all the resources of the server. I don't know exactly if this could be the root cause. Im using Debian Squeeze. uname -a Linux srv156 2.6.32-5-amd64 #1 SMP Sun Sep 23 11:00:33 UTC 2012 x86_64 GNU/Linux I really will appreciate your help, i dont know what more to do.

Read the article

Why are my hard drives failing?

- by WishCow

I have a small Ubuntu server running at home, with 2 HDDs. There are two software raids (raid1) on the disks, managed by mdadm, which I believe is irrelevant, but mentioning it anyway. Both of the HDDs are Western Digital, and have been used for around 2 years, when one of them started making clicking noises, and died. I figured that maybe it's natural after 2 years, so I bought a new one, and resynced the raid arrays. After about a month, the other drive also died. I didn't get suspicious, since both drives have been bought at the same time, it's not that surprising to see both of them near each other, so I bought another one. So far, 2 old drives failed, and 2 brand new in the system. After one month, one of the new drives died. This is when it started getting suspicious. Since the PC was put together from some really old parts (think AthlonXP), I figured that maybe the motherboard's SATA controller is the culprit. Of course you can't switch parts easily in an old PC like this, so I bought a whole system, new MB, new CPU, new RAM. Took the just failed drive back, since it was under warranty, and got it replaced. So it is up to 2 failed drives from the old ones, and 1 failed drive from the new ones. No problems, for 1 month. After that errors were creeping up again in /var/log/messages, and mdadm was reporting raid array failures. I started tearing my hair out. Everything is new in the system, it's up to the third brand new HDD, it's simply not possible that all of the new drives that I bought were faulty. Let's see what is still common... the cables. Okay, long shot, let's replace the SATA cables. Take HDD back, smile to the guy at the counter and say that I'm really unlucky. He replaces the HDD. I come home, one month passes and one of HDDs fails, again. I'm not joking. Two of the brand new HDDs have failed. Maybe it's a bug in the OS. Let's see what the manufacturer's testing tool says. Download testing tool, burn it to a CD, reboot, leave HDD testing overnight. Test says that the drive is faulty, and I should back up everything, if I still can. I don't know what's happening, but it does not look like a software problem, something is definitely thrashing the HDDs. I should mention now, that the whole system is in a shoebox. Since there are a load of "build your own ikea case" stuff, I thought there shouldn't be any problems throwing the thing in a box, and stuffing it away somewhere. The box is well ventilated, but I thought that just maybe the drives were overheating. There is no other possible answer to this. So I took the HDD back, and got it replaced (for the 3rd time), and bought HDD coolers. And just now, I have heard the sound of doom. click click whizzzzzzzzz. SSH into the box: You have new mail! mail r 1 DegradedArrayEvent on /dev/md0 ... dmesg output: [47128.000051] ata3: lost interrupt (Status 0x50) [47128.000097] end_request: I/O error, dev sda, sector 58588863 [47128.000134] md: super_written gets error=-5, uptodate=0 [48043.976054] ata3: lost interrupt (Status 0x50) [48043.976086] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [48043.976132] ata3.00: cmd c8/00:18:bf:40:52/00:00:00:00:00/e1 tag 0 dma 12288 in [48043.976135] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [48043.976208] ata3.00: status: { DRDY } [48043.976241] ata3: soft resetting link [48044.148446] ata3.00: configured for UDMA/133 [48044.148457] ata3.00: device reported invalid CHS sector 0 [48044.148477] ata3: EH complete Recap: No possibility of overheating 6 drives have failed, 4 of those have been brand new. I'm not sure now that the original two have been faulty, or suffered the same thing that the new ones. There is nothing common in the system, apart from the OS which is Ubuntu Karmic now (started with Jaunty). New MB, new CPU, new RAM, new SATA cables. No, the little holes on the HDD are not covered I'm crying. Really. I don't have the face to return to the store now, it's not possible for 4 drives to fail under 4 months. A few ideas that I have been thinking: Is it possible that I fuck up something when I partition and resync the drives? Can it be so bad that it physicaly wrecks the drive? (since the vendor supplied tool says that the drive is damaged) I do the partitoning with fdisk, and use the same block size for the raid1 partitions (I check the exact block sizes with fdisk -lu) Is it possible that the linux kernel or mdadm, or something is not compatible with this exact brand of HDDs, and thrashes them? Is it possible that it may be the shoebox? Try placing it somewhere else? It's under a shelf now, so humidity is not a problem either. Is it possible that a normal PC case will solve my problem (I'm going to shoot myself then)? I will get a picture tomorrow. Am I just simply cursed? Any help or speculation is greatly appreciated. Edit: The power strip is guarded against overvoltage. Edit2: I have moved inbetween these 4 months, so the possibility of the cause being "dirty" electricity in both places, is very low. Edit3: I have checked the voltages in the BIOS (couldn't borrow a multimeter), and they are all seem correct, the biggest discrepancy is in the 12V, because it's supplying 11.3. Should I be worried about that? Edit4: I put my desktop PC's PSU into the server. The BIOS reported much more accurate voltage readings, and also it has successfully rebuilt the raid1 array, which took some 3-4 hours, so I feel a little positive now. Will get a new PSU tomorrow to test with that. Also, attaching the picture about the box: (disregard the 3rd drive)

Read the article

webserver horrible slow, sometimes incredible fast

- by dhanke

i am running a small community ( 6000+ Members ) on a non-virtual 64-bit ubuntu 11.04 system. I am not a Linux-pro, not even advanced, i just tried to setup a webserver, which does nothing special actually. Delivering some dynamic PHP and RoR websites is its task. So it might be that my configuration files do look horrible bad. Also, i might use the wrong vocabulary, so in doubt, please ask. Having a current all-time record of 520 registered users (board-accounts, no system-users) online at same time, average server-load is about 2.0 - 5.0. Meantime (~250 users) average server load value is at about 0.4 - 0.8, sometimes, on some expensive searches a bit higher. everything fine. From time to time however, the load increases up to 120 (120.0, not 12.0 ;) ). In this time, its hard to even connect via SSH, but when i reach the server, and use top/htop/iotop to see whats happening, i cannot identify any process causing high CPU load. iotop tells me about a current reading/writing speed of about approx. 70kb/s, which is quite equal to power-off i think. Memory-Usage is max. at ~ 12GB of 16GB, so swap remains empty. now the odd (at least for me:) waiting some minutes ( since i always get a bit into a panic when this happens, it feels like 5 minutes, but i suppose its more like 20-30 minutes) and the server is back to normal. everything continues as normal. another odd fact: when i run hdparm -tT /dev/sda, i get answer like: /dev/sda: Timing cached reads: 7180 MB in 2.00 seconds = 3591.13 MB/sec Timing buffered disk reads: 348 MB in 3.02 seconds = 115.41 MB/sec when i run the same command while the server is "frozen", the answer is like /dev/sda: <- takes about 5 minutes until this line appears Timing cached reads: 7180 MB in 2.00 seconds = 3591.13 MB/sec <- 5 more minutes Timing buffered disk reads: 348 MB in 3.02 seconds = 115.41 MB/sec <- another 5 minutes so the values are the same, but the quoted time is completely wrong. using time command as prefix also tells me that ~ 15 minutes were used. I searched in dmesg, /var/log/[messages|syslog] - nothing found. /var/log/errors however tells me that: Jul 4 20:28:30 localhost kernel: [19080.671415] INFO: task php5-fpm:27728 blocked for more than 120 seconds. Jul 4 20:28:30 localhost kernel: [19080.671419] "echo 0 /proc/sys/kernel/hung_task_timeout_secs" disables this message. multiple times. now that message does tell me that php5-fpm task was blocked or did block ? - but not if that is the cause or just one of the results of that "freeze". Anyone? to cut the long story short, i dont know where even to start analyzing. So if you can give me any advice by looking at following specs and configs, or ask me to provide more information, i`d be glad. Specs: 6 Core AMD Phenom(tm) II X6 1055T Processor * 16 Gigabyte Ram 2x 1.5 TB Seagate ST1500DL003-9VT16L via SATA 3 via SoftwareRaid (i suppose) Services: (due to service --status-all, those with [ + ]) nginx Webserver 1.0.14 mySQL 5.1.63 Server Ruby on Rails 2.3.11 ( passenger-nginx-module ) php5-fpm 5.3.6-13ubuntu3.7 SSH ido2db Further services: default crontab + nightly backup. syslog-ng Website consists of 2 subdomains, forum. and www. where forum is a phpBB3.x PHP-Board, and www a Ruby on Rails 2.3.11 application (portal). Mini-Note: sometimes i notice that the forum is pretty slow, in contrast to the always-fast (except for this "freeze") portal. Both share the same Database, but the portal is using it read-only. The Webserver is nginx, using phusion passenger module to communicate with the ruby-application. Also, for the forum it communicates with php5-fpm via socket: relevant nginx configuration parts ( with comments/questions starting by ; ) ; in case of freeze due to too high Filesystem activity, maybe adding a limit? #worker_rlimit_nofile 50000; user www-data; ; 6 cores, so i read 6 fits. maybe already wrong? worker_processes 6; pid /var/run/nginx.pid; events { worker_connections 1024; } http { passenger_root /var/lib/gems/1.8/gems/passenger-3.0.11; passenger_ruby /usr/bin/ruby1.8; ; the forum once featured a chat, which was working w/o websockets. ; so it was a hell of pull requests (deactivated now, freeze still happening) keepalive_timeout 65; keepalive_requests 50; gzip on; server { listen 80; server_name www.domain.tld; root /var/www/domain/rails/public; passenger_enabled on; } server { listen 80; server_name forum.domain.tld; location / { root /var/www/domain/forum; index index.php; } ; satic stuff to be handled by nginx location ~* ^/style/.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ { access_log off; expires 30d; root /var/www/domain/forum/; } ; now the php magic, note the "backend"-fcgi_pass location ~ .php$ { fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_pass backend; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/domain/forum$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 256 16k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_max_temp_file_size 0; } location ~ /\.ht { deny all; } } ;the php5-fpm socket. i read that /dev/shm/ whould be the fastes place for this. bad idea in general? upstream backend { server unix:/dev/shm/phpfpm; } ... } php5-fpm settings (i changed this values due to php5-fpm error log messages higher and higher.. (freeze-problem was there before as well)* listen = /dev/shm/phpfpm user = www-data group = www-data pm = dynamic ; holy, 4000! well, shinking this value to earth-level gave me ; 100s of 502 bad gateway commands. this values were quite stable. ; since there are only max 520 users online i dont get it, why i would need ; as many children as configured here. due to keep-alive maybe? ; asking questions is easier for me since restarting server will make ; my community-members angry ;) pm.max_children = 4000 pm.start_servers = 100 pm.min_spare_servers = 50 pm.max_spare_servers = 150 pm.max_requests = 10 pm.status_path = /status ping.path = /ping ping.response = pong slowlog = log/$pool.log.slow ;should i use rlimit? ;rlimit_files = 1024 chdir = / mysql/my.cnf [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp skip-external-locking bind-address = 127.0.0.1 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP ; high number, but less gives some phpBB errors. max_connections = 450 table_cache = 512 ; i read twice the cpu cores, bad? thread_concurrency = 12 join_buffer_size = 2084K concurrent_insert = 3 query_cache_limit = 64M query_cache_size = 512M query_cache_type = 1 log_error = /var/log/mysql/error.log log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 expire_logs_days = 10 max_binlog_size = 100M low_priority_updates=1 [mysqldump] quick quote-names max_allowed_packet = 16M [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/ I used smartctl already, hdds seem to be fine. /proc/mdstatus quotes: Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md3 : active raid1 sda3[1] 1459264192 blocks [2/1] [_U] md1 : active raid1 sda1[0] 3911680 blocks [2/1] [U_] unused devices: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127727 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 127727 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I quote some questions in my configuration files, these are not (intentional) directly problem-related, but would be nice for me to know wether they are indeed questionable or done right. One additional Fact: my MYSQL-database is at 12GB size. i dont know if that does matter, but mytop sometimes shows me 4-5 seconds long insert queries, some are 20-30 seconds long. Its just a feeling that i am unable to prove (because i dont know how), but when i disable the database, the freeze seems not to happen. Example: i created a dummy rails application to see the development log. the app made some sql-queries, reads and inserts. the log quite often was like: DbTest Load (0.3ms) SELECT * FROM `db_test` WHERE (`db_test`.`id` = 31722) LIMIT 1 SQL (0.1ms) BEGIN DbTest Update (0.3ms) UPDATE `db_test` SET `updated_at` = '2012-07-04 23:32:34' WHERE `id` = 31722 - now the log stands still for 5-60 seconds. SQL (49.1ms) COMMIT - SQL-Update time in the log does not include freeze time Rendering test/index Completed in 96ms (View: 16, DB: 59) | 200 OK [http://localhost:9000/test] Bad part is: this mini-freeze here only happens from time to time as well. note: meanwhile i cannot even upload files via scp. I currently feel like running form bad to worse and back by googling for my server-problem due to immense lack of knowledge regarding server configurations. It still makes me wonder, why those problems even appear, since 250 users a time is not such a high amount, right? So my questions: whats wrong and how to fix? ;) or: what information can i provide to make the situation more clear? can you point at some critical bad configuration-line which i should consider to catch up in the documentation? are there any tools i can run to see some possible bottlenecks? any further advice? (next to: "pay someone who knows what he does" - its a private project, server costs enough already. :)) Thanks for your time and help. Best Regards, Daniel P.S.: i renamed the configfiles to domain.tld since i dont want to have any % more load to the server until its fixed. might be a exaggeratedly thought.. P.P.S: if i asked a complete duplicate question, sorry. my search results seemed to be quite specific in their own way.

Developer IT