¿Por qué mi tarea 'launchd' no responde a los cambios en los archivos vistos?

3

Tengo una tarea launchd que no se activa cuando cambia un archivo, y no puedo entender por qué está fallando.

Cuando carga el .plist debajo con

launchctl load /Users/Rax/Library/LaunchAgents/com.crashplan.status.plist

el script especificado se ejecuta (una vez) y se ejecuta como se esperaba (también puedo ejecutarlo correctamente directamente desde la línea de comandos). Pero cuando cambia el archivo en la ruta del reloj ( /Library/Logs/CrashPlan/history.log.0 ), no sucede nada.

¿Qué podría faltar para evitar que esta tarea responda al cambio de archivo?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.crashplan.status</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Rax/Library/Automation/Shell/crashplan_status</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/Library/Logs/CrashPlan/history.log.0</string>
    </array>
</dict>
</plist>
    
pregunta orome 27.11.2013 - 20:32

2 respuestas

2

FWIW Lo probé aquí y parece estar funcionando para mí. Cada vez que agregué manualmente algo a /Library/Logs/CrashPlan/history.log.0, el script se activó.

Como tal, esto no es realmente una respuesta, sino más bien una serie de consejos para depurar launchd :

Algunos consejos para diagnosticar launchd:

1) Use las rutas stdout y stderr y vea si algo se registra en ellas. Puede hacerlo agregando estas líneas a su archivo com.crashplan.status.plist .

<key>StandardErrorPath</key>
<string>/tmp/com.crashplan.status.stderr.log</string>
<key>StandardOutPath</key>
<string>/tmp/com.crashplan.status.stdout.log</string>

(Si varias personas utilizan el mismo Mac, es posible que desee utilizar una ruta diferente a / tmp / pero si es solo usted, entonces es un lugar tan bueno como cualquier otro).

2) Con el # 1, es posible que también desee ajustar su secuencia de comandos (/ Users / Rax / Library / Automation / Shell / crashplan_status) para incluir información de depuración, como cuándo se inició y cuándo terminó. Esto puede ser tan simple como algo como esto que se agrega en la parte superior de la secuencia de comandos:

echo "$0: started at 'date'"

y algo como esto cerca del final

echo "$0: finished at 'date'"

3) Con el # 2 es posible que también desee utilizar algo como notificador de terminal para mostrarle cuándo está su script siendo llamado, al menos hasta que haya pasado la etapa de depuración.

4) Si nada de eso ayuda, debe verificar el estado de salida de los comandos que está llamando en crashplan_status y ver si están saliendo correctamente. Por ejemplo, digamos que estaba ejecutando echo en su crashplan_status

5) ¿Es su entorno en launchd diferente de su shell de alguna manera? Esto se verifica mejor agregando esta línea cerca de la parte superior de su script de launchd:

/usr/bin/printenv | /usr/bin/open -ef

lo que provocará que printenv se envíe a la salida estándar y los resultados se abran en TextEdit.

El problema más común del "entorno" con el que me encuentro es que no se haya configurado correctamente $ PATH para launchd. Por lo general, se establece en los archivos de inicio de shell como .bashrc y se hereda con cualquier script de shell que ejecute desde Terminal, pero no será para launchd .

Puede ver la ruta que está utilizando launchd mediante:

launchctl getenv PATH

Si desea configurarlo, puede configurarlo mediante

launchctl setenv PATH

por ejemplo, para mi sistema sería:

launchctl setenv /Users/luomat/Dropbox/bin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin

Si no desea tener que recordar configurar esto cada vez que inicie su computadora, puede agregarlo a /etc/launchd.conf agregando una línea:

setenv PATH /Users/luomat/Dropbox/bin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin

obviamente cambiar eso para que coincida con su sistema. Además, no se sorprenda si /etc/launchd.conf no existe en su sistema. Puede que tengas que crearlo. Para ello, te recomiendo un simple:

sudo pico -w /etc/launchd.conf

y cuando haya terminado de editar, presione control + X y siga las indicaciones para guardar los cambios.

    
respondido por el TJ Luoma 01.12.2013 - 08:33
0

Sé que esta es una publicación antigua, pero como no tiene una respuesta real, solo publicaré una sugerencia. ¿Todavía tienes el problema o ha sido resuelto finalmente? Si no, puedo tener una pista, ya que experimenté el mismo problema.

En la terminal, verifique si su archivo visto tiene argumentos extendidos usando este comando:

ls -l@

Si su archivo tiene argumentos extendidos como este:

com.apple.quarantine    32

intente y escriba este comando para eliminar los argumentos extendidos (use sudo si es necesario):

xattr -d -r com.apple.quarantine /Library/Logs/CrashPlan/history.log.0

en tu caso ...

Parece que las rutas de observación de launchd ignoran los archivos que tienen un argumento extendido de cuarentena ...

Espero que pueda ayudar.

    
respondido por el Pierre Lagarde 27.11.2014 - 22:11

Lea otras preguntas en las etiquetas