Previous  Next  Contents 


5. ¿Tiene Problemas?

5.1 ¿Cómo permito conexiones remótas?

Debido a uno fallo de funcionamiento #97893 (específico en Linux) y #97889 (para Solaris) en el programa sqlexecd, escucha clientes remotos y dispoara un proceso sqlexec para esa conexión, cuando la sesión de sqlexec termina, dejar un proceso zombi en la tabla de procesos (vea ¿Qué son estos zombis en mi tabla de procesos ? y ¿Cómo los prevengo?). Esta advertencia, si todavía insiste, hace el siguiente:

     Configure /etc/services en el servidor. Agregue la siguiente línea

                      sqlexecd     1536/tcp

La entrada se puede ubicar en cualquier lugar del archivo. Puede utilizar cualquier otro número de puerto en lugar del 1536 mientras no está ya en uso.

                      $INFORMIXDIR/lib/sqlexecd demo_se

Este ejemplo asume que su nombre del servidor de db es demo_se.

5.2 ¿Qué son esos zombis en mi tabla de procesos?

Es la forma que tiene Informix para decir, "We take a licking and keep on ticking!"; -) Seriamente, es la manifestación del error # 97893. Parece ocurrir con mayor probabilidad al usar los socketes (sesoctcp) para permitir un acceso remoto a una base de datos. Se han reportados también cuando se utiliza pipes sin nombres (seipcpip) en conexiones locales.

Este error #97893 ha sido reparado en la glibc, pero se ha detectado un nuevo error, #101155: el protocolo de conexión de SEIPCPIP (pipes) no funciona bajo la plataforma de RedHat 5,1.

5.3 ¿Cómo los prevengo?

Jonathan Leffler ( jleffler@informix.com) envió un trabajo, nozombie.c, se lo utiliza de la misma manera que nohup. El código y sus observaciones de Jonathan están a continuación. Observe que esto no es un arreglo oficial (aprobado por Informix), y hay informes que no funciona en todos los casos. YMMV.

La explicación es bastante simple -- si el proceso está ignorando la 
señal SIGCHLD, luego no se acumulan los procesos zombis hijos
El programa modifica el modo en que se maneja la señal SIGCHLD por
SIG_IGN y luego ejecuta lo que se le dió como argumentos.  Si
éste es sqlexecd, éste parece ignorar la señale SIGCHLD, de tal
modo que no aparece ningún proceso zombi.



   /*
     @(#)File:            $RCSfile: nozombie.c,v $
     @(#)Version:         $Revision: 1.1 $
     @(#)Last changed:    $Date: 1998/08/20 21:24:40 $
     @(#)Purpose:         Prevent process from accidentally creating zombies
     @(#)Author:          J Leffler
     @(#)Copyright:       (C) JLSS 1998
     @(#)Product:         :PRODUCT:
     */

     /*TABSTOP=4*/

     #include <signal.h
     #include <unistd.h
     #include <stdio.h
     #include <stdlib.h

     #ifndef lint
     static const char rcs[] = "@(#)$Id: nozombie.c,v 1.1 1998/08/20 21:24:40 jleffler Exp $";
     #endif

     /*
     ** Exec program specified by arguments with SIGCHLD signals ignored.
     ** This ensures that unless the program re-enables the SIGCHLD signal
     ** handling, it does not leave zombies around, even if it doesn't
     ** clean up behind its children.  This works on POSIX.1 systems (such
     ** as Solaris 2.6 and Linux) pretty straight-forwardly.
     **
     ** Motivation: the initial version of sqlexecd 7.24.UC1 on Linux
     ** caused problems with lots of zombies.
     **
     **      nozombie $INFORMIXDIR/lib/sqlexecd [service]
     */

     int main(int argc, char **argv)
     {
         signal(SIGCHLD, SIG_IGN);
         execv(argv[1], &argv[1]);
         fprintf(stderr, "Failed to execv() %s\n", argv[1]);
         return EXIT_FAILURE;
     }



Si el código de Jonathan no lo soluciona, intente el siguiente, que apareció recientemente en informix.idn.linux. Resuelve el problema del zombi reescribiendo la manera en que trabaja la función signal.

Primero, cree un archivo signalfix.c :



     #include "signal.h"
     #include <unistd.h
     #include <stdio.h
     void *signal(int signum,void (*handler)(int))
     {
       struct sigaction sa;
       sa.sa_handler=handler;
       sa.sa_mask=SA_NOMASK;
       sa.sa_flags=SA_RESTART;
       sigaction(signum,&sa,(struct sigaction *)NULL);
     }


Después, copie / usr/include/signal.h, y comente la función signal. Luego compile signalfix.c de la siguiente forma:

                         $ gcc -fpic -shared signalfix.c -o libsig.so

Finalmente, corra sqlexecd con:

              $ LD_PRELOAD=/root/sqlexecfix/libsig.so $INFORMIXDIR/lib/sqlexecd servername

5.4 DBACCESS error de segmento (seg fault) en mi xterm!

El problema inmediato es que dbaccess aparentemente reserva un buffer estático para alojar la información de termcap/terminfo y ésta es mayor que la capacidad disponible. Real Soon Now (c), reportó esto a Informix, con la esperanza que se repare en la siguiente versión.

Mientras tanto, alguna de las soluciones son:

  1. Cambie la variable de entorno  $TERM a algo que no sea xterm, tal como linux, vt220 VT100
  2. Modifique las entradas relacionadas en termcap o terminfo (después de hacer una copia de respaldo, por supuesto). dbaccess no utilizan las entradas "ti" o "te", por lo tanto pueden ser eliminadas. Esto funciona, pero afectará todas las sesiones de xterm, incluya aquellas que realmente pudiera utilizar las entradas ti/te.
  3. Duplique la entrada del xterm como,por ejemplo, xterm-dbaccess, elimine las entradas "ti" y "te", y establezca la variable de entorno $TERM al valor xterm-dbaccess cuando usted vaya a ejecutar dbaccess en una terminal xterm.
  4. Utilice el fichero el archivo de reemplazo termcap/terminfo disponible en http://www.informix.com/idn-secure/Linux/WebPages/termcap.html. Observe los cuidados y  sugerencias enumeradas allí.

Roger Allen ( rja@sis.rpslmc.edu) recomienda la tercera opción y explica 

Realice una copia de la entrada de xterm en /etc/termcap con un 
nombre diferente y use el nuevo nombre almacenándolo en TERM
directamente cambie la entrada actual. En algún lugar de los
apéndices de los manuales de Informix existe una lista de los 
campos que utiliza Informix. Generalmente elimino los campos
ti y te. También puede agregar una entrada Informix especial
que le habilite el color, los caracteres para líneas de dibujo
mayor cantidad de teclas de función, si bien esto es más para 
las herramientas de Informix que para el DB-Access.

 

5.5 &iexcl;El puerto ya esta siendo utilizado!

Use otro. El puerto canónico de Informix es el 1536, pero realmente puede usar cualquier otro socket, con tal que no este siendo utilizado por otro servicio.

5.6 &iquest;Puedo usar un filesystem montado con NFS?

No. En lugar de mountar un filesystem que sporte a su base de datos vía NFS,

  1. La computadora remota tiene que estar corriendo sqlexecd, y
  2. Tiene que acceder a la base de datos usándo la red.

Las versiones no Linux de SE imponen esta restricción en los binarios, pero este puede no ser el caso con el producto Linux. Como sugiere Jonathan Leffler, "espere problemas si trata de engañarlo -- problemas de corrupción de datos."

Si esto se exige en los binarios o no, montar su base de datos sobre un punto NFS es una mala idea (al menos) por dos razones:

  1. El acceso será lento, porque NFS es lento.
  2. Si pierde el enlace NFS, estará en problemas, y quién sabe lo que le suceda a los archivos de la base de datos.


Previous  Next  Contents