Archivo de la categoría: Sysadmin

mod_fcgid: process /usr/local/cpanel/cgi-sys/php5 exit(communication error), get unexpected signal 7

Administro varios servidores con una configuración muy similar, 8 vps en la misma empresa todos con APC pero solo en uno tengo ese error

Error en cPanel mod_fcgid: exit(communication error), get unexpected signal 7

La configuración en la mayoría de VPS:

PHP 5.3.25 o php 5.4 algunos con IONcube y otros sin el, algunos con ZEND y otros sin el, todos con fcgi y APC.

El caso curioso es que solo un servidor tienen el error descrito anteriormente, el cual he deducido que pasa por tener APC, al quitar APC el error desaparece.

El error no es solo un get unexpected signal 7 en el error log si no que también provoca un error 500 en las páginas web del servidor.

Bien según las pruebas que hecho el error desaparece al quitar APC, al cambiar a PHP 5.4 y poner xcache persiste el error pero aparece en ocasiones muy raras.

Así que viendo el error: mod_fcgid: exit(communication error), get unexpected signal 7 puedo ver que pasa con cualquier optcode: apc o xcache.

cPanel
PHP 5.4 ( muy de vez en cuando )
PHP 5.3.25
Con o sin ZEND o ION
Pasa en un solo VPS con cpanel con unas 25 webs.
Pasa en un VPS de 8 en la misma empresa:

4 gigas de RAM
CPU 4x Xeon(R) CPU E5-2660 0 @ 2.20GHz
SSD raid10
Loadaverage entre 0.80 y 2 según la hora y cantidad de tráfico.
Ram consumida no sobre pasa los 3 gigas.

En fin, con esto digo que con php 5.4 y xcache se reduce la cantidad de veces que sucede, aunque es pronto decirlo los cambios en el server los he hecho hace varias horas y aún no llegamos a hora pico, pero lo que si puedo decir es que si tienen el mismo problema, el mismo mensaje en los logs y errores 500 en la web desabiliten APC o xCache.

Yo volveré a escribir cuando pase la hora pico hoy por la noche que es cuando más se ve el error y veremos si PHP 5.4 y xcache lo solucionan si es así probaré con APC y si tampoco recae en el error atribuiré el fallo a php 5.3.25, algún modulo dañado o algo por el estilo que ya me a pasado en otras ocasiones y reinstalandolo me a solucionado otros fallos similares y cargas altas sin motivo aparente.

Lo otro sería que el VPS este en un nodo con algún problemilla con la RAM, se quede sin RAM o algo parecido, aunque la empresa en la que están los VPS siempre tienen mucha RAM libre y no hay overselling en los nodos.

Ver el tipo de puerto sata que tenemos: sata 2 o sata 3 en Linux

Hay una forma sencilla de ver que tipo de puerto sata tenemos en nuestra pc, basta con ejecutar un comando y tendremos el resutaldo, como root ejecutamos:

Saber que puerto sata tenemos | velocidad

dmesg | grep -i sata | grep ‘link up’

Y tendremos como resultado:

[    1.580650] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.900463] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

O bien:

grep -i SATA /var/log/messages | grep ‘link up’

Mar 31 05:25:44 soporte kernel: [    1.608258] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar 31 05:25:44 soporte kernel: [    1.932070] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr  1 01:58:02 soporte kernel: [    1.604196] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr  1 01:58:02 soporte kernel: [    1.924013] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr  1 14:57:28 soporte kernel: [    1.580650] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr  1 14:57:28 soporte kernel: [    1.900463] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

Espero les sirva, el pequeño tip

Entrar a Mysql sin Clave

Si, la he perdido alguna vez, y no es perder, es olvidarse ya sea por que la hemos puesto demasiado segura y no la apuntamos y no entramos al mysql después de mucho o cualquier otra cosa que nos haya pasado, les dejo esta guía que es la mas fácil ya que solo hay que editar el my.cnf, en centos /etc/my.cnf y en debian /etc/mysql/my.cnf

Aquí el enlace: Entrar sin Contraseña en Mysql

Hay otra forma que es entrando en el safe mode de mysql, que básicamente es lo mismo, se accede igual haciendo skip grant pero solo funciona para una vez, o sea se reinicia el mysql y se acceder sin la clave y luego se vuelve a reiniciar y ya nos pedirá la clave.

Acceder Como Root al Mysql de Plesk por SSH sin la Clave

Si a todos nos pasa que perdemos la clave de root de mysql en plesk, más que nada por que a veces ni la tenemos ( si usamos el autoinstalador y tal ) aunque la leyenda cuenta de que es la misma que la del admin, pero a mi casi nunca me funciona, así que bueno, hay una forma sencilla de acceder al mysql desde el ssh sin tener que dar el skip a las claves ya que es un riesgo para la seguridad, así que la forma correcta para hacerlo es:

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

Y listo con eso entramos 🙂

Hay más info en la documentación de plesk de plesk: http://kb.parallels.com/en/427