Braiiiiiins…
Aprovechando una consulta que me han realizado, vamos a hacer un pequeño recordatorio sobre los procesos defunct, también llamados zombies. Es una buena época del año para ello, teniendo Halloween al lado. Hasta en World of Warcraft lo zombie está de moda 
Hagamos un pequeño repaso para los que se perdieran las clases.
Los procesos en los sistemas Unix cuentan con una jerarquía de ejecución, de forma que, en caso de que se necesite, un proceso puede generar procesos nuevos (denominados hijos) para realizar funciones adicionales. De hecho, este punto es absolutamente normal y un proceso padre más o menos complejo puede llegar a generar buena cantidad de procesos hijos. Pensemos en una base de datos o un servidor web, por ejemplo.
Para poner un ejemplo, he aquí la jerarquía de procesos de un servidor ssh:
root@madhatter # ptree 19963
876 /usr/lib/ssh/sshd
19963 /usr/lib/ssh/sshd
19966 /usr/lib/ssh/sshd
19968 -sh
19972 bash
20025 ptree 19963
Así podemos ver que el proceso 19963 ha generado el proceso 19966, etc…
Los procesos no acabarán completamente hasta que el padre haya elegido sus estados de salida y acabado con ellos. En caso de que exista un gran número de procesos en estado defunct, sería conveniente examinar cual es el ID del proceso padre, ya que es responsabilidad de este proceso padre identificar todos los hijos que hayan acabado y obtener su estado. En caso contrario, el proceso padre de ese proceso padre heredaría los hijos, de forma que eventualmente puedan llegar al PID 1 (Init).
Si init hereda un proceso defunct (zombie), este proceso será “segado” o eliminado de la tabla de procesos, ya que esta es una de las tareas asignadas a init.
En caso de que el número de procesos defunct en la máquina no os parezca normal, convendría vigilar qué proceso está causando ese número de zombies para depurarlo.
Como detalle adicional, si el número de procesos defunct se descontrola, en Solaris 8 no queda otra opción que rebotar la máquina, mientras que en Solaris 9 y superior se puede emplear el comando preap para eliminar estos procesos defunct.
Por cierto, mucho ojo al emplear preap, que debería ser empleado únicamente como último recurso, ya que si se usa para matar un proceso que luego intenta ser eliminado por su proceso padre esto puede dañar el proceso padre de forma impredecible.
Ah, y no intentéis utilizar kill -9 para eliminar procesos defunct, ya que no hay ningún proceso corriendo para recoger la señal de KILL y no responderá al comando.
Colega, ¿donde está mi last?
Uno de los misterios más habituales, que ha causado más de un quebradero de cabeza a los sysadmins del mundo mundial es la falta de informacióncuando hacemos un last.
Para los que no lo tengan muy claro, last es una herramienta de seguridad que indica los últimos accesos a la máquina en orden reverso. Cada línea nos va a indicar nombre de usuario, la consola (tty) desde donde conecta, nombre de máquina y el comienzo y el fin de la sesión. Utilísimo para los paranoicos en todos nosotros
Un ejemplo práctico:
root@madhatter # last root pts/4 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Tue Oct 21 13:57 still logged in root sshd 10.10.1.229 Wed Oct 8 12:30 - 12:36 (00:05) root sshd 10.0.231.64 Wed Oct 8 11:55 - 12:25 (00:29) root pts/4 10.10.1.229 Wed Oct 8 11:30 - 12:41 (01:11) root sshd 10.10.1.229 Wed Oct 8 11:30 - 11:55 (00:25) root console :0 Tue Sep 30 12:27 still logged in root pts/2 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root sshd 10.10.3.43 Mon Sep 29 11:30 - 11:30 (00:00) root pts/2 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Wed Sep 24 07:25 - 07:51 (00:26) root sshd 10.10.1.229 Thu Sep 18 14:17 - 14:32 (00:15) root pts/2 10.10.1.229 Thu Sep 18 14:15 - 14:47 (00:31) root sshd 10.10.1.229 Thu Sep 18 14:15 - 14:17 (00:01) root pts/2 10.10.1.229 Thu Sep 18 08:44 - 08:44 (00:00) [...]
Imaginemos ahora una situación como esta
root@madhatter # last wtmp begins Wed Feb 25 04:30
La cara de tonto que se te queda cuando compruebas que el fichero está actualizado
root@madhatter # ls -l /var/adm/wtmpx -rw-r--r-- 1 adm adm 43599145 Oct 21 13:28 /var/adm/wtmpx
Que forzando te manda a peinarte
root@madhatter # last -f /var/adm/wtmpx wtmp begins Wed Feb 25 04:30
Que el filesystem no está lleno
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/bootdg/rootvol 15345315 8665186 6526676 58% /
La causa más normal de este comportamiento es corrupción de datos en el fichero /var/adm/wtmpx que es donde se almacenan los datos para sacar el last. Las causas son variadas, desde llenado temporal de ese filesystem, un backup mal realizado, truncados de ficheros o simple y pura mala práctica.
La cuestión es arreglarlo. La forma más sencilla es, simplemente, recrearlo con los permisos adecuados, haciendo copia de seguridad previa:
root@madhatter # mv /var/adm/wtmpx /var/adm/wtmpx.BAK root@madhatter # touch /var/adm/wtmpx root@madhatter # chown adm:adm /var/adm/wtmpx root@madhatter # chmod 644 /var/adm/wtmpx
Listo. En caso de que nos interese mucho guardar los datos contenidos en el fichero, hay una operativa mucho más complicada que podéis examinar a fondo.
Esto es grande… Esto es pequeño
La comprobación de que el tamaño de las cosas es elástico (ejem, ejem) y más todavía en Unix.
Como me imagino que todos sabréis, el archivo de /var/adm/lastlog registra y almacena el tiempo de login de cada usuario, sea este correcto o incorrecto. Es útil para saber quien se ha conectado, cuanto tiempo, y desde donde.
En ocasiones, me han dado un toque de atención por el excesivo tamaño de /var y concretamente el de lastlog. Yo siempre les digo que para qué andan mirando donde no deben 
y luego les explico lo que me contaron a mí en su momento: El tamaño del archivo de lastlog al hacer un ls no se corresponde con su tamaño real.
El tamaño indicado al hacer un ls -l del fichero lastlog está basado en el UID más alto de los usuarios que estén conectados a la máquina. La fórmula que utiliza Solaris para esto es tamaño total de lastlog=(UID más alto de los usuarios + 1) * 28
De ésta manera, el fichero de lastlog se convierte en un fichero “disperso” en el que su tamaño real es mucho más pequeño del que pueda parecer. Para comprobarlo, vamos a seguir unos ejemplos sencillos:
Tamaño de /var actual de la máquina nuestra de pruebas:
root@madhatter # df -k /var/ Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472886 497282 75% /var
Tamaño de lastlog según ls (Aparente)
root@madhatter # ls -la /var/adm/lastlog -r--r--r-- 1 root root 1820084 Dec 10 14:17 /var/adm/lastlog root@madhatter # ls -lha /var/adm/lastlog -r--r--r-- 1 root root 1.7M Dec 10 14:17 /var/adm/lastlog
Tamaño real del mismo fichero
root@madhatter # du -ks /var/adm/lastlog 24 /var/adm/lastlog
Procedemos a vaciar el fichero lastlog y comprobamos su tamaño
root@madhatter # > lastlog
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 0 Dec 10 14:30 lastlog
root@madhatter # du -ks lastlog
0 lastlog
Así como el de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472862 497306 75% /var
Vemos que sólo ha aumentado en 24 Kb.
Ahora, entramos como usuario root. Según lo especificado en la fórmula, crece de tamaño en 28 bytes aparentes (Pero solo 1 kb real)
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 28 Dec 10 14:32 lastlog
root@madhatter # du -ks lastlog
1 lastlog
Kb que se descuenta de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472863 497305 75% /var
Ahora, procedemos a entrar con el usuario que tiene el UID mas alto en la maquina
prueba:x:65002:1::/var/tmp/usuario_prueba:/usr/bin/ksh
De nuevo, el fichero crece según la fórmula (65002+1)*28=1820084
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 1820084 Dec 10 14:35 lastlog
Pero sólo ha aumentado 23 Kb
root@madhatter # du -ks lastlog 24 lastlog
Así como /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472894 497274 75% /var
Así pues no hay reserva de espacio en/var por parte de last log en lo que concierne al tamaño aparente, sino únicamente al tamaño real.
Y recordad: This is not a bug, is a feature
