🚀 go-pugleaf

Hola, J.R.:

"J.R." wrote:
> 
[...]
> 
> Si he entendido bien, lo que hace el script es guardar su propio pid
> y, por tanto, necesito un script para cada aplicaci�n que quiera
> lanzar �no?
> 
> Muchas gracias otra vez.
> Saludos.
> 

Cre�a entender que t� te quer�as asegurar de que no existiese otra
instancia del script/programa en cuesti�n.  En este caso, el *nombre*
del archivo de bloqueo ha de ser �nico para cada script (lo puedes
definir "duro" en el programa, pero tambi�n, podr�as tomar el primer
par�metro de llamada, que ese el propio nombre del script, quedarte con
la �ltima parte del nombre, -o sea, el nombre del programa, sin
directorios-, y utilizar esto como nombre �nico para el archivo de
bloqueo; esto �ltimo te permitir�a, por ejemplo, tener diversos alias
para el programa y que se ejecutaran independientemente, m�s o menos
como hace bash: bash y bashr son el mismo ejecutable, pero el binario de
bash, lo primero que hace es ver c�mo se le ha llamado y en funci�n de
eso tiene una u otra actitud... o tambi�n, permitir que se llame al
script con par�metros y construir el archivo de bloqueo con un nombre
distinto en funci�n del par�metro que se le pasa).

M�s o menos la cosa queda as� (ver con un tipo monoespaciado):
  EMPIEZA EL SCRIPT
          |
  �Existe el archivo de bloqueo?
       |            |
      NO            SI
       |            |
  Creo el archivo  aborto
       |
  (ejecuci�n del programa)
       |
  Borro el archivo de bloqueo

Lo dem�s, son peque�as sofisticaciones para tener en cuenta el hecho de
que est�s en un sistema multiusuario: En general, hay que comprobar el
resultado exitoso de cualquier operaci�n que salga del propio hilo de
ejecuci�n, sobre todo si puede dar lugar a condiciones de carrera.

Qu� pasar�a si, por ejemplo, dos instancias de tu aplicaci�n comenzaran
a ejecutarse casi a la vez (o por la red); cada una empezar�a,
comprobar�a que *no* existe el fichero de bloqueo, lo crear�an (la
instancia que fuese un pel�n retrasada simplemente sobreescribir�a el de
la primera, sin m�s contemplaciones) y seguir�an ejecut�ndose ambas a la
vez, con resultados, en principio, indeseables.
As�, el script que te pas� se limita a ser un pel�n m�s paranoico:
�Existe el archivo? ->SI->Aborto
NO
Lo creo y meto mi PID dentro de �l
Verifico que existe (podr�a haberse iniciado otra ejecuci�n entre tanto
y, por ejemplo, hab�rmelo borrado, o no tener permisos de escritura
donde intento escribir etc)
�Esta *mi* PID dentro?->NO->Aborto (probablemente, otra instancia ha
empezado justo despu�s que yo y me lo ha "pisado")
SI
Bueno, vale; ya me he quedado tranquilo: sigo con la ejecuci�n normal
La *�ltima* operaci�n, justo antes de salir es borrar el bloqueo (si no,
problemas, la siguiente instancia creer� que sigo en ejecuci�n y no
echar� a andar)
FIN

Esta aproximaci�n, que se usa bastante (se us� bastante, m�s bien) la
estoy usando yo en un entorno un pel�n m�s complicado para coordinar la
ejecuci�n de dos scripts distintos en "cremallera": Se supone que se
tiene que alternar la ejecuci�n del script A y el B (el porqu� no es al
caso, pero as� es).  En este caso lo que hago es (el manejo del
principio es enteramente an�logo al anterior, as� que no lo incluyo):
Comienza el ScriptA
Coloca el archivo de bloqueo
Borra el bloqueo
Finaliza
Comienza el scriptB
coloca su archivo de bloqueo (uso archivos distintos, igualmente podr�an
tener el mismo nombre, pero contenidos que los identificasen)
Borra el bloqueo
Finaliza
...

Para asegurase que esta "cremallera" funciona bien, cuando uno de los
scripts comienza, se fija si ya existe el bloqueo propio (si ya existe,
estoy en ejecuci�n: aborto); que no exista un bloqueo de "pido turno"
del otro script, en cuyo caso, �l tiene prioridad; se fija si existe el
bloqueo *del otro script* (en ese caso, coloco un bloqueo de "pido el
turno", con el fin de asegurarme de que, por esas casualidades, no me
gane el otro script siempre por la mano y no me pueda ejecutar); si todo
esta bien, coloco mi archivo de bloqueo y me ejecuto; al final, borro lo
que tenga que borrar.  La cosa se l�a un poco m�s por la cosa de los
retrasos: Despu�s de cada operaci�n de bloqueo, compruebo que todo est�
bien: por ejemplo, tras colocar mi bloqueo me aseguro de que no ha
aparecido entre tanto el bloqueo del otro script (ejecuci�n casi
simult�nea) y si lo est�, decido (program�ticamente) qui�n tiene
prioridad para seguir y qui�n debe abortar, etc.

...pero la idea b�sica, creo que se pilla, y el c�digo que te pas� es
funcional: es el mismo que estoy usando yo, recortado para tus
requerimientos.	
-- 
SALUD,
Jes�s
***
jesus_navarro@promofinarsa.es
***