• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Plesk dead (500 server error) after upgrade from 10.1.1 to 10.3.1

P

PeterReynolds

Guest
I just upgraded from Plesk 10.1.1 to 10.3.1 and now I get "500 - Internal Server Error" on the login page.

My /var/log/sw-cp-server/error_log shows:

2011-08-08 13:06:21: (log.c.135) server stopped
2011-08-08 13:06:26: (log.c.75) server started
DEBUGGER DETECTED... Bye!
2011-08-08 13:06:38: (mod_fastcgi.c.2482) unexpected end-of-file (perhaps the fastcgi process died): pid: 6832 socket: unix:/usr/local/psa/tmp/sw-engine.sock-0
2011-08-08 13:06:38: (mod_fastcgi.c.3222) child signaled: 9
2011-08-08 13:06:38: (mod_fastcgi.c.3265) response not received, request sent: 868 on socket: unix:/usr/local/psa/tmp/sw-engine.sock-0 for /index.php , closing connection
DEBUGGER DETECTED... Bye!
2011-08-08 13:06:54: (mod_fastcgi.c.1748) connect failed: Connection refused on unix:/usr/local/psa/tmp/sw-engine.sock-0
2011-08-08 13:06:54: (mod_fastcgi.c.2903) backend died, we disable it for a 5 seconds and send the request to another backend instead: reconnects: 0 load: 1
2011-08-08 13:06:54: (mod_fastcgi.c.2676) child signaled: 9
DEBUGGER DETECTED... Bye!
2011-08-08 13:06:54: (mod_fastcgi.c.2482) unexpected end-of-file (perhaps the fastcgi process died): pid: 6874 socket: unix:/usr/local/psa/tmp/sw-engine.sock-0
2011-08-08 13:06:54: (mod_fastcgi.c.3222) child signaled: 9
2011-08-08 13:06:54: (mod_fastcgi.c.3265) response not received, request sent: 868 on socket: unix:/usr/local/psa/tmp/sw-engine.sock-0 for /index.php , closing connection
DEBUGGER DETECTED... Bye!
2011-08-08 13:07:11: (mod_fastcgi.c.1748) connect failed: Connection refused on unix:/usr/local/psa/tmp/sw-engine.sock-0
2011-08-08 13:07:11: (mod_fastcgi.c.2903) backend died, we disable it for a 5 seconds and send the request to another backend instead: reconnects: 0 load: 1
2011-08-08 13:07:11: (mod_fastcgi.c.2676) child signaled: 9
DEBUGGER DETECTED... Bye!
2011-08-08 13:07:12: (mod_fastcgi.c.2482) unexpected end-of-file (perhaps the fastcgi process died): pid: 6923 socket: unix:/usr/local/psa/tmp/sw-engine.sock-0
2011-08-08 13:07:12: (mod_fastcgi.c.3222) child signaled: 9
2011-08-08 13:07:12: (mod_fastcgi.c.3265) response not received, request sent: 868 on socket: unix:/usr/local/psa/tmp/sw-engine.sock-0 for /index.php , closing connection
DEBUGGER DETECTED... Bye!
2011-08-08 13:08:13: (mod_fastcgi.c.3834) child signaled: 9

Sethdavis has a similar problem in thread http://forum.parallels.com/showthread.php?t=112676 and I tried everything he did.


> 1. Editing the apc.shm_size (and similar) values in /usr/local/psa/admin/conf/php.ini
Tried increasing from 40BM to 80MB. No effect.

> 2. Running /opt/psa/admin/sbin/httpdmng --reconfigure-server and related commands.
Tried. Ran without errors.

> 3. Running bootstrapper.sh repair
Ran from pp10.12.0-bootstrapper directory (I don't have a pp10.3.1 bootstrapped directory) and it ran without errors.

> 4. "df -h" looks good with plenty of disk space on all filesystems.
Likewise.

5. Running command: /usr/bin/sw-engine-cgi -c /opt/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm
Also gives me:

DEBUGGER DETECTED... Bye!
Killed

6.
I reinstalled (rpm -Uvh --force) psa-mod-fcgid-configurator and psa-mod-fcgid packages:
(Downloading from http://64.131.90.31/PSA_10.3.1/dist-rpm-CentOS-5-x86_64/base/)

7.
I tried changing "min-procs" in /etc/sw-cp-server/applications.d/plesk.socket.sh from 0 to 1. As this has fixed the problem for Seth. Still no joy.

8. I checked in with Atomic support in the event that their PHP might have interfered with Plesk. And they confirmed Plesk uses its own PHP and it would have no effect. I removed the Atomic PHP anyway; still no joy.

9. I tried reinstalling the update from the command line. Again –*as it had done through the interface –*everything appeared to complete successfully.

10. I shared my experience on this forum yesterday on Seth's thread but, although more recent posts have received responses from Parallels representatives mine hasn't; so I'm posting here again - perhaps they considered Seth's thread solved so didn't notice my new posts about my similar problem.

Please assist urgently as my clients are already complaining they are e.g. unable to turn off out of office emails.

System:
Linux www.withheld.com 2.6.32.28-1.art.x86_64 #1 SMP Mon Feb 14 11:06:49 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
 
Last edited by a moderator:
System Details

System is CentOS release 5.6 (Final)
 
Last edited by a moderator:
/usr/local/psa/admin/conf/php.ini

Here is my /usr/local/psa/admin/conf/php.ini file:

short_open_tag = On
y2k_compliance = Off
output_buffering = Off
allow_call_time_pass_reference = On
max_execution_time = 600
max_input_time = 600
memory_limit = 128M
max_file_uploads = 99999

error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
log_errors = On
display_errors = Off
warn_plus_overloading = Off
expose_php = off

variables_order = "ECGPS"
register_argc_argv = On
auto_globals_jit = Off
post_max_size = 2147483647
magic_quotes_gpc = Off
magic_quotes_runtime = Off

include_path = "/usr/local/psa/admin/plib:/usr/local/psa/admin/javascripts:/usr/local/psa/admin/plib/locales:/usr/local/psa/admin/auto_prepend:/usr/local/psa/adm$
upload_tmp_dir = "/tmp"
upload_max_filesize = 2147483647

apc.stat = 0
apc.shm_size = 80M
apc.slam_defense = 0
apc.enabled = 1

swkey.repository_dir = "/etc/sw/keys"

psasem.semfile = "/usr/local/psa/var/psasem.sem"
apc.filters="-/libraries/*,/themes/*"
 
I fixed it :)

I fixed it!!!! :)

The problem was the Atomic kernel.

I reverted using grub to my standard Kernel and now Plesk works again.

Previously default was 0; changed to 4 and rebooted. (I had rebooted before without changing this so pretty sure this was the solution).

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
#boot=/dev/sda

serial --unit=0 --speed=57600
terminal --timeout=5 serial console

timeout=5

default=4
title CentOS (2.6.32.43-6.art.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32.43-6.art.x86_64 ro root=/dev/md1 console=tty0 console=ttyS0,57600 selinux=0 panic=5
initrd /boot/initrd-2.6.32.43-6.art.x86_64.img
title CentOS (2.6.32.41-4.art.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32.41-4.art.x86_64 ro root=/dev/md1 console=tty0 console=ttyS0,57600 selinux=0 panic=5
initrd /boot/initrd-2.6.32.41-4.art.x86_64.img
title CentOS (2.6.32.28-1.art.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32.28-1.art.x86_64 ro root=/dev/md1 console=tty0 console=ttyS0,57600 selinux=0 panic=5
initrd /boot/initrd-2.6.32.28-1.art.x86_64.img
title CentOS (2.6.18-194.32.1.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-194.32.1.el5 ro root=/dev/md1 console=tty0 console=ttyS0,57600
initrd /boot/initrd-2.6.18-194.32.1.el5.img
title CentOS (2.6.18-194.26.1.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-194.26.1.el5 ro root=/dev/md1 console=tty0 console=ttyS0,57600
initrd /boot/initrd-2.6.18-194.26.1.el5.img
 
This error:

DEBUGGER DETECTED... Bye!

No the issue is not the kernel. Its a bug in Plesk. This is caused by the ptrace bug in Plesk that causes Plesk to incorrect "detect" that you are running a non-existent debugger and then not start. You're not running a debugger.

This can happen on secure kernels that prevent certain ptrace exploits. Plesk incorrectly detects this to means you are running a debugger (which you are not). As a result, it doesn't start. To resolve this, you just have to disable that protection in the kernel and you are all set. (Or Parallels fixes this bug in Plesk)

Unfortunately, this means you have to leave your system open to ptrace exploits, so I recommend you encourage Parallels to fix this bug in their software. You could also run a non-secure kernel and be open to hundreds of exploits, but thats neither recommended nor necessary (and besides, you'd be vulnerable to a huge array of exploits then, so better one vulnerability than the hundreds in a vanilla kernel including ptrace exploits).

https://www.atomicorp.com/wiki/index.php/ASL_FAQ#DEBUGGER_DETECTED..._Bye.21

Just follow the guidance in that FAQ are you'll all set.

So, not a kernel bug, its a Plesk bug. There is no debugger, Plesk is incorrectly detecting one.

To that end: Parallels, could you please fix this bug in your code. Thanks!
 
Last edited by a moderator:
Thank you Mike.

That worked! Thank you Mike.

Parallels please fix this. I'd rather not have my kernel open to ptrace exploits please.

Thank you.
 
I'm having the same problem since update.

2011-08-27 10:37:37: (mod_fastcgi.c.1000) the fastcgi-backend /usr/bin/sw-engine-cgi -c /opt/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm failed to start:
2011-08-27 10:37:37: (mod_fastcgi.c.1015) terminated by signal: 9
2011-08-27 10:37:37: (mod_fastcgi.c.1105) [ERROR]: spawning fcgi failed.
2011-08-27 10:37:37: (server.c.864) Configuration of plugins failed. Going down.
2011-08-27 10:38:33: (log.c.75) server started
DEBUGGER DETECTED... Bye!
2011-08-27 10:38:33: (mod_fastcgi.c.1000) the fastcgi-backend /usr/bin/sw-engine-cgi -c /opt/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm failed to start:
2011-08-27 10:38:33: (mod_fastcgi.c.1015) terminated by signal: 9
2011-08-27 10:38:33: (mod_fastcgi.c.1105) [ERROR]: spawning fcgi failed.
2011-08-27 10:38:33: (server.c.864) Configuration of plugins failed. Going down.
2011-08-27 10:38:35: (log.c.75) server started
DEBUGGER DETECTED... Bye!
2011-08-27 10:38:35: (mod_fastcgi.c.1000) the fastcgi-backend /usr/bin/sw-engine-cgi -c /opt/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm failed to start:
2011-08-27 10:38:35: (mod_fastcgi.c.1015) terminated by signal: 9
2011-08-27 10:38:35: (mod_fastcgi.c.1105) [ERROR]: spawning fcgi failed.
2011-08-27 10:38:35: (server.c.864) Configuration of plugins failed. Going down.

I tried every proposed solution to no avail.
i tried 2.6.38 and 3.0 (standard server lucid backports) and the problem persist.

Is there a specific kernel compile option i should look for ?
 
Nope it's a vanilla kernel, which works fine on another server with plesk enabled.

It sounds like you have a totally different problem with Plesk. Unfortunately, if you are using a vanilla kernel then this doesnt have anything to do with ptrace protection, although it could be an selinux thing maybe but thats just a guess. If you're not comfortable tuning selinux, try disabling it temporarily and see if that resolves the issue. If it does, and you still want to use selinux then you'll need to tune your policies. If it doesn't, well you can probably rule out your kernel as the cause.

You'll have to ask Parallels about this error message with their software, sorry.
 
Last edited by a moderator:
If you have a recent kernel this might be due to Yama kernel hardening:

echo 0 > /proc/sys/kernel/yama/ptrace_scope
or
echo 0 > /proc/sys/kernel/grsecurity.harden_ptrace

Might fix the problem
 
Back
Top