Forzar el vaciado de la salida a un archivo mientras el script bash aún se está ejecutando

Tengo un pequeño script, que crontab llama a diario usando el siguiente comando:

/homedir/MyScript &> some_log.log

El problema con este método es que some_log.log solo se crea después de que MyScript finaliza. Me gustaría vaciar la salida del programa en el archivo mientras se está ejecutando para poder hacer cosas como

tail -f some_log.log

y realizar un seguimiento del progreso, etc.

bash en sí mismo nunca escribirá ninguna salida en su archivo de registro. En cambio, los comandos que invoca como parte de la secuencia de comandos escribirán individualmente la salida y se eliminarán cuando lo deseen. Entonces, su pregunta es realmente cómo forzar que los comandos dentro del script bash se descarguen, y eso depende de lo que sean.

Encontré una solución a esto aquí . Usando el ejemplo de OP, básicamente ejecutas

stdbuf -oL /homedir/MyScript &> some_log.log

y luego el búfer se vacía después de cada línea de salida. A menudo combino esto con nohuppara ejecutar trabajos largos en una máquina remota.

stdbuf -oL nohup /homedir/MyScript &> some_log.log

De esta manera, su proceso no se cancelará cuando cierre la sesión.

script -c <PROGRAM> -f OUTPUT.txt

La clave es -f. Cita del guión del hombre:

-f, --flush
     Flush output after each write.  This is nice for telecooperation: one person
     does 'mkfifo foo; script -f foo', and another can supervise real-time what is
     being done using 'cat foo'.

Ejecutar en segundo plano:

nohup script -c <PROGRAM> -f OUTPUT.txt

Puede utilizar teepara escribir en el archivo sin necesidad de vaciarlo.

/homedir/MyScript 2>&1 | tee some_log.log > /dev/null

Esto no es una función de bash, ya que todo lo que hace el shell es abrir el archivo en cuestión y luego pasar el descriptor del archivo como salida estándar del script. Lo que debe hacer es asegurarse de que la salida se elimine de su secuencia de comandos con más frecuencia de la que tiene actualmente.

En Perl, por ejemplo, esto podría lograrse configurando:

$| = 1;

Consulte perlvar para obtener más información al respecto.

El almacenamiento en búfer de la salida depende de cómo /homedir/MyScriptse implemente su programa . Si encuentra que la salida se está almacenando en búfer, debe forzarla en su implementación. Por ejemplo, use sys.stdout.flush () si es un programa de Python o use fflush (stdout) si es un programa de C.

¿Ayudaría esto?

tail -f access.log | stdbuf -oL cut -d ' ' -f1 | uniq 

Esto mostrará inmediatamente entradas únicas de access.log utilizando la utilidad stdbuf .

El problema que se acaba de ver aquí es que tienes que esperar a que los programas que ejecutas desde tu script terminen su trabajo.
Si en su secuencia de comandos ejecuta el programa en segundo plano , puede intentar algo más.

En general, una llamada a syncantes de salir permite vaciar los búferes del sistema de archivos y puede ayudar un poco.

Si en el script inicia algunos programas en segundo plano ( &), puede esperar a que terminen antes de salir del script. Para tener una idea de cómo puede funcionar, puede ver a continuación.

#!/bin/bash
#... some stuffs ...
program_1 &          # here you start a program 1 in background
PID_PROGRAM_1=${!}   # here you remember its PID
#... some other stuffs ... 
program_2 &          # here you start a program 2 in background
wait ${!}            # You wait it finish not really useful here
#... some other stuffs ... 
daemon_1 &           # We will not wait it will finish
program_3 &          # here you start a program 1 in background
PID_PROGRAM_3=${!}   # here you remember its PID
#... last other stuffs ... 
sync
wait $PID_PROGRAM_1
wait $PID_PROGRAM_3  # program 2 is just ended
# ...

Dado que waitfunciona tanto con trabajos como con PIDnúmeros, una solución perezosa debería ser poner al final del script

for job in `jobs -p`
do
   wait $job 
done

Más difícil es la situación si ejecuta algo que ejecuta otra cosa en segundo plano porque tiene que buscar y esperar (si es el caso) el final de todo el proceso hijo : por ejemplo, si ejecuta un demonio, probablemente no sea el caso esperar que termine :-).

Nota:

• esperar $ {!} significa "esperar hasta que se complete el último proceso en segundo plano" donde $!está el PID del último proceso en segundo plano. Así que ponerwait ${!} justo después program_2 &es equivalente a ejecutar directamente program_2sin enviarlo en segundo plano con&

• Con la ayuda de wait:

  Syntax    
      wait [n ...]
  Key  
      n A process ID or a job specification
  

Gracias @user3258569, ¡el script es quizás lo único que funciona busybox!

Sin embargo, el caparazón se me estaba congelando después de eso. Buscando la causa, encontré estas grandes advertencias rojas "no usar en shells no interactivos" en la página del manual del script :

scriptestá diseñado principalmente para sesiones de terminal interactivas. Cuando stdin no es una terminal (por ejemplo:) echo foo | script, la sesión puede bloquearse, porque el shell interactivo dentro de la sesión del script pierde EOF y scriptno tiene idea de cuándo cerrar la sesión. Consulte la sección NOTAS para obtener más información.

Cierto. script -c "make_hay" -f /dev/null | grep "needle"estaba congelando el caparazón para mí.

Contrariamente a la advertencia, pensé que echo "make_hay" | scriptPASARÁ un EOF, así que intenté

echo "make_hay; exit" | script -f /dev/null | grep 'needle'

¡Y funcionó!

Tenga en cuenta las advertencias en la página de manual. Puede que esto no funcione para usted.

La alternativa a stdbuf es awk '{print} END {fflush()}' que desearía que hubiera un bash incorporado para hacer esto. Normalmente no debería ser necesario, pero con versiones anteriores puede haber errores de sincronización de bash en los descriptores de archivos.

No sé si funcionaría, pero ¿qué hay de llamar sync?

Tuve este problema con un proceso en segundo plano en Mac OS X usando el StartupItems. Así es como lo resuelvo:

Si lo hago sudo ps auxpuedo ver que mytoolse lanza.

Descubrí que (debido al almacenamiento en búfer) cuando Mac OS X se apaga, mytoolnunca transfiere la salida al sedcomando. Sin embargo, si ejecuto sudo killall mytool, mytooltransfiero la salida al sedcomando. Por lo tanto, agregué un stopcaso al StartupItemsque se ejecuta cuando Mac OS X se apaga:

start)
    if [ -x /sw/sbin/mytool ]; then
      # run the daemon
      ConsoleMessage "Starting mytool"
      (mytool | sed .... >> myfile.txt) & 
    fi
    ;;
stop)
    ConsoleMessage "Killing mytool"
    killall mytool
    ;;

te guste o no, así es como funciona la redirección.

En su caso, la salida (lo que significa que su secuencia de comandos ha finalizado) de su secuencia de comandos se redirigió a ese archivo.

Lo que quiere hacer es agregar esas redirecciones en su secuencia de comandos.