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.
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.
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
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:
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.
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.
No. En lugar de mountar un filesystem que sporte a su base de datos vía NFS,
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: