New Kernel Less Stable than Last Kernel

[premierhosting]

Done, where should I look for results?

[mikeshinn]

If you configured syslog correctly, then you should start to see lines in your syslog like this:

Aug 28 12:34:46 hostname -- MARK --

[Troy McClure]

premierhosting,

I am having this same exact problem. I didn't realize there was another thread about this issue. I will start posting to this thread. Here is my thread (http://www.atomicorp.com/forum/viewtopi ... 4&start=30). I am going to downgrade my kernel to kernel-2.6.32.41-4.art and see if that helps. I just moved to this server, so I haven't tried running that kernel yet. I have run kernel-2.6.18-238.9.1.el5 without any problems for over a month though. Like you, I haven't been able to resolve this issue. It just hangs and I have to reboot it from the 1and1 admin panel. The hangs are completely random. Day, time of day, part of the hour, etc. are all random for me.

[premierhosting]

Hi Troy,

Let me know the results of your kernel downgrade! I still haven't bit the bullet on that. I use the sercon to take a peek and watch it come back up and it's always just "hung". Really weird. Did you have to disable your s99raid as well? The raid1 sync process always takes a bunch of resources after a hang-reboot, which makes me think there's some disk integrity issues going on.

The link appears to be to this thread, want to try again?

[premierhosting]

Just in case Troy, here's the 99raid-check thread:

https://www.atomicorp.com/forums/viewto ... f=1&t=4847

[Troy McClure]

Ha, oops. Here is my thread - http://www.atomicorp.com/forum/viewtopic.php?f=3&t=5120. Looking back over that, I have tried the 41-1 kernel. Oh well, guess that isn't going to help me. I thought I had only used the latest kernel, but I forgot that this did happen when I first setup ASL and the current kernel was 41-1. I have tried these kernels with the same results (2.6.32.41-4.art.x86_64, 2.6.32.41-1.art.x86_64, and 2.6.32.43-6.art). I do check sercon too with the same results as you. By chance is your server a newer server? I just got mine 3 or 4 months ago. I was also involved in that 99-raid-check thread. I did have problems with it, but was able to add it back about 1 month ago and haven't seen the problem again. Not sure what changed with that.

[Troy McClure]

Mike, could you tell me the furthest back I can go on the kernel and not be left more vulnerable than the current kernel? I would like to go back as far as possible just to see if it will fix the problem, but don't want to open my server up to problems.

[premierhosting]

BTW, this could be related, plesk backup to FTP is a doozy.

Code: Select all

#ps faxww

 7348 ?        S      0:12 /usr/bin/perl /usr/local/psa/admin/bin/plesk_agent_manager server --owner-uid=ac58d447-e66b-4e13-bbe7-96cfa2e09468 --dump-rotation=7 --session-path=/usr/local/psa/PMM/sessions/2011-09-03-021903.773 --output-file=ftp://user@backupserver/ --ftp-passive-mode
14215 ?        S      0:25  \_ /usr/bin/perl /usr/local/psa/admin/bin/plesk_agent_manager server --owner-uid=ac58d447-e66b-4e13-bbe7-96cfa2e09468 --dump-rotation=7 --session-path=/usr/local/psa/PMM/sessions/2011-09-03-021903.773 --output-file=ftp://user@ --ftp-passive-mode
14217 ?        D      0:11  |   \_ /bin/tar -f - -c -T /tmp/fileFkvVg4
14216 ?        S      0:19  \_ /usr/bin/perl /usr/local/psa/admin/bin/plesk_agent_manager server --owner-uid=ac58d447-e66b-4e13-bbe7-96cfa2e09468 --dump-rotation=7 --session-path=/usr/local/psa/PMM/sessions/2011-09-03-021903.773 --output-file=ftp://user@/ --ftp-passive-mode
 7350 ?        S      0:00 python /usr/local/psa/admin/share/pmmcli/pmmcli_daemon_runner.py
14329 ?        S      0:00 /usr/bin/perl -w /usr/bin/psmon --daemon --cron

# w
 03:16:41 up 7 days, 20:05,  2 users,  load average: 25.48, 10.95, 5.10
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
russell  pts/0    76.178.183.164   00:30    0.00s  0.32s  0.02s sshd: russell [priv]
root     ttyS0    -                26Aug11  7days  0.03s  0.03s -bash

[premierhosting]

Well, I haven't had a freezeup in 14 days. What I did was add an httpd restart to cron on the hour. I did that because occasionally httpd would coredump and go stupid until it was restarted. Couldn't figure out why it was coredumping but an occasional restart seems to "fix" it.

Noticed on another thread that httpd freezeups can have ASL causes. Any suggestions on how to track that down? I'm getting the sense that perhaps a memleak or race in httpd was causing the real issue.

[mikeshinn]

Well, I haven't had a freezeup in 14 days. What I did was add an httpd restart to cron on the hour. I did that because occasionally httpd would coredump and go stupid until it was restarted. Couldn't figure out why it was coredumping but an occasional restart seems to "fix" it.

Have you looked at the core dumps to see whats causing them?

Noticed on another thread that httpd freezeups can have ASL causes.

They can? I'm not aware of any. Can you tell me what threads?

[premierhosting]

Trying to find the thread, maybe I read something wrong

On core dumps, when I have them enabled I run risks of filling up the disk, right? I have them enabled right now, and I can have some PHP (wordpress) page load that show up blank. No core dump, no php error, no apache error. Just blank page. I restart httpd and bingo, page processes and displays.

Trying to generate the core dump situation.

[mikeshinn]

https://www.atomicorp.com/wiki/index.ph ... Core_Files

I'm going to fork this thread as this has nothing to do with the kernel anymore.

https://www.atomicorp.com/forums/viewto ... f=1&t=5439

[premierhosting]

Oh look someone else with the same types of issues and fixes. A bunch of people, even some of them with ASL and 1and1.

http://forum.parallels.com/pda/index.php/t-108340.html

[mikeshinn]

I cant find anything in that thread about any kernel, ASL or 1and1. Did you mean a different thread?

[premierhosting]

atomicturtle - not you guys?

No kernel mention, but the stability / memory issues could have come up with the Plesk upgrade as it was about the same time as the kernel upgrade. The fix for the thread and my fix have been the same - restart apache at intervals. Which is not a fix, just a workaround.