Como desvincular una aplicación de la terminal en la cual se abrió en GNU/Linux

Introducción.

Cuando se inician aplicaciones desde una terminal en GNU/Linux sus procesos quedan ligados a la terminal, de manera que cuando esta se destruye (cierra) los procesos asociados también se terminan de manera ineludible.

Esto es particularmente inoportuno cuando se desea dejar ejecutándose una aplicación durante un largo periodo de tiempo sin supervisión ni interacción humana.  Esto es muy frecuente cuando se realiza administración de los servidores o se desea realizar tareas de larga duración como la transferencia de archivos.  En ese orden de ideas es necesario mantener la conexión y la terminal desde donde se ejecutó la aplicación abiertas hasta que termine el procedimiento.

Para evitar este problema existen varias alternativas de solución.  A continuación se expone el procedimiento de desvincular la aplicación de la terminal en la cual se invocó.

El problema.

Al ejecutar una aplicación en una terminal su proceso, representado por su PID (identificador de proceso) queda asociado con el de la terminal en la cual se ejecutó.

$ gedit &

[1] 2643

Por ejemplo, en el caso anterior, al ejecutar el programa gedit (en background) se puede apreciar que su PID es 2643.  Si se verifica la información de dicho proceso se obtienen los siguientes datos adicionales.

$ ps -fea | grep 2643 jimezam

2643  2576 0 Jun03 pts/1    00:00:00 gedit

Nótese que su proceso padre (segunda columna) es el 2576.  Si se solicita mayor información acerca de dicho proceso se obtiene lo siguiente.

$ ps -fea | grep 2576

jimezam   2576 2571  0 Jun03 pts/1    00:00:00 bash
jimezam   2643  2576 0 Jun03 pts/1    00:00:00 gedit
jimezam   2809  2576 0 00:17 pts/1    00:00:00 ps -fea
jimezam   2810  2576 0 00:17 pts/1    00:00:00 grep –color=auto 2576

De lo anterior se colige que dicho proceso corresponde con una terminal (bash) e inclusive se pueden apreciar los procesos que se desprenden de ella, en este caso los siguientes 3 procesos mostrados.

Si se termina el proceso 2576 se terminarán automáticamente entonces los procesos 2643, 2809 y el 2810.

La solución.

Como se mencionó inicialmente, la solución a esta situación corresponde con la desvinculación (detach) del proceso específico con la terminal del cual fue lanzado.  Esto se logra con un comando interno del Bash llamado disown de la siguiente manera.

$ disown -h 2643

Después de ejecutada esta instrucción, la terminal de orígen (en este caso con 2576 como PID) puede ser cerrada sin interferir con la ejecución del gedit del ejemplo (con 2643 como PID).

Scripts para copias de seguridad, versión 2008

Introducción.

Los scripts para las copias de seguridad que utilizaba el año pasado eran aún mas sencillos que la versión de este año pues su ejecución era completamente local, por este motivo podían aprovechar los recursos de la cuenta local.  De esta manera había automatizado la creación de copias de seguridad de las bases de datos  de los proyectos basados en Drupal y de los desarrollados utilizando CodeIgniter ya que estos cuentan con archivos con la configuración que especifican toda la información de conexión necesaria.  Actualmente no utilizo estos scripts pero son interesantes y pueden ser de utilidad para alguien.

En ambos casos es necesario editar las siguientes variables para personalizar el script.

  1. PT_CONFIG_FILE/DRUPAL_CONFIG_FILE: hace referencia al archivo de configuración de la base de datos del proyecto.  Para CodeIgniter será algo del estilo /RUTA/system/application/config/database.php mientras que para Drupal tendrá esta forma: /RUTA/sites/default/settings.php.
  2. TARGET: determina el directorio donde se va a almacenar la copia de seguridad generada con la ejecución del script.
  3. PROJECTNAME: es el nombre del proyecto al cual se le está haciendo copia de seguridad.  Es útil para complementar el nombre del archivo generado.

Adicionalmente es posible modificar la variable TZ con la zona horaria para hacer coincidir la información del tiempo con la local, DATE para modificar el formato de la fecha (se recomienda YYYMMDD) y TIME para modificar el formato de la hora (se recomienda HMS).  Los formatos DATE y TIME se utilizan para determinar el nombre de los directorios de backup y de los archivos generados.

Otro script interesante es el que utilizaba, junto con el proceso Cron de las copias de seguridad, para remover las versiones muy antíguas según su nombre de usuario (de ahí lo importante de los formatos de tiempo sugeridos).

Al igual que los primeros scripts, es posible personalizar las variables TZ y TARGET para iguales motivos.  Además existe la variable MONTHS_AGO para determinar el número de meses que se desean conservar las copias de seguridad.

Estos scripts se proveen como una referencia educativa y al igual que los anteriores no han sido diseñados para satisfacer  otro tipo de necesidades diferentes de las mias propias, así que deben usarse bajo su propia responsabilidad.

Enlaces.

Scripts para copias de seguridad, versión 20090203

Esta semana implementé unos scripts muy simples pero útiles para la ejecución de copias de seguridad de archivos y bases de datos MySQL. Estos se basan en que los datos a hacerles copia de seguridad se encuentran en diferentes equipos así que utiliza una combinación entre conexiones SSH y llaves RSA para su autenticación. Los archivos son empaquetados y copiados mientras que las bases de datos son extraídas mediante mysqldump, los datos resultantes son comprimidos (gzip -9) y traídos al directorio hogar del usuario de copias de seguridad para ser almacenados localmente.

Enlaces.