-1 votos

Tras la actualización a Monterey, no se ejecuta una tarea launchd creada por el usuario

Tengo un trabajo launchd que se supone que debe ejecutar un php script a las 6 de la mañana todos los días. El script ejecuta una serie de tareas relacionadas con las copias de seguridad. Después de actualizar a Monterey, la tarea ya no se inicia a la hora programada.

Utilizo Lingon X para controlarlo. Cuando lo ejecuto manualmente desde Lingon X como "prueba", se inicia, pero a veces no termina. Cuando ejecuto el comando desde el terminal, el trabajo se inicia y siempre se ejecuta hasta finalizar.

Aquí está el plist:

<?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>Disabled</key>
    <false/>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/jas/Keybase.app/Contents/SharedSupport/bin:/usr/local/sbin</string>
    </dict>
    <key>Label</key>
    <string>RH-backup</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/local/bin/php</string>
        <string>/Users/jas/Websites/RepHunter/cron/RH-backup.php</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
    <key>StandardErrorPath</key>
    <string>/Volumes/Backup1/RH-backup/dbtemp/stderr.log</string>
    <key>StandardOutPath</key>
    <string>/Volumes/Backup1/RH-backup/dbtemp/stdout.log</string>
    <key>StartCalendarInterval</key>
    <array>
        <dict>
            <key>Hour</key>
            <integer>6</integer>
            <key>Minute</key>
            <integer>0</integer>
        </dict>
    </array>
    <key>StartOnMount</key>
    <false/>
</dict>
</plist>

Nunca hay ninguna salida ni en stderr.log ni en stdout.log.

El único patrón sospechoso es que, al parecer, cuando se inicia manualmente, la tarea suele interrumpirse tras un cierto intervalo. Dado que el ejecutable es un script php, lo primero que comprobé fue si el script estaba agotando el tiempo de espera.

Como prueba, he añadido set_time_limit(900) al php script. Eso no debería importar, ya que según la documentación de php el tiempo de espera de script no incluye el tiempo en el que se realizan las llamadas al sistema. El propósito de script es hacer numerosas llamadas al sistema. Así que no debería consumir mucho tiempo de ejecución por sí solo.

Además este script lleva varios años funcionando sin ningún problema de este tipo.

¿Alguna idea?

EDITAR 1:

Después de más pruebas descubrí algunos problemas, pero no la solución.

  1. Tener el StandardOutPath y el StandardErrorPath impide que el trabajo launchd se ejecute. Estábamos pensando que era porque esas rutas se establecieron en unidades externas estaba causando un problema. Acabamos de eliminarlos por completo. El script entonces se ejecuta.

  2. El script se ejecuta y llama a todos los comandos externos. Hay un par de llamadas a rsync para copiar algunos archivos, incluso desde servidores remotos. Esto funciona bien.

  3. A continuación, el script llama a duplicity para extraer un archivo del conjunto de copias de seguridad. Duplicity sale inmediatamente sin extraer el fichero. Esto hace que el resto de las funciones del script sean inútiles.

  4. Cuando se ejecuta el script desde la línea de comandos, siempre funciona como se esperaba. También funcionó como se esperaba como un trabajo launchd durante más de dos años bajo Mojave y Catalina. Sólo después de la actualización a Monterey el script perdió su capacidad de escribir archivos.

  5. Como prueba, he dado acceso total al disco a la duplicidad. Eso no hace ninguna diferencia.

  6. La solución es ejecutar el script manualmente desde la línea de comandos. Siempre funciona.

¿Por qué Monterey bloquea las tareas de launchd para que no escriban archivos?

EDITAR 2:

  1. Como otra prueba, moví todos los archivos intermedios a /tmp/ con la esperanza de que si un problema de permisos podría ser revelado. Eso no ayudó.

  2. He añadido captura de salida de error para el comando duplicity. La siguiente es la salida de error cuando se ejecuta como un trabajo launchd (lo siento por el formato - el código de marcado no funciona para este texto, así que lo puse como una cita):

Traceback (innermost last): File "/opt/local/bin/duplicity", line 117, in with_tempdir(main) File "/opt/local/bin/duplicity", line 103, in with_tempdir fn() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/dup_main.py", línea 1522, en main action = commandline.ProcessCommandLine(sys.argv[1:]) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/commandline.py", línea 1158, en ProcessCommandLine config.gpg_profile = gpg.GPGProfile() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/gpg.py", línea 92, en init self.gpg_version = self.get_gpg_version(config.gpg_binary) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/gpg.py", línea 108, en get_gpg_version res = gnupg.run([u"--version"], create_fhs=[u "stdout"]) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py", línea 376, en run process = self._attach_fork_exec(gnupg_commands, args, File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py", línea 429, en _attach_fork_exec self._as_child(process, gnupg_commands, args) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py", línea 468, en _as_child os.execvp(command[0], command) Archivo "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/os.py", línea 574, en execvp _execvpe(file, args) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/os.py", línea 616, en _execvpe raise last_exc File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/os.py", línea 607, en _execvpe exec_func(fullname, *argrest) FileNotFoundError: [Errno 2] No such file or directory

GPGError: fallo al determinar la versión gnupg de None a partir de b''

EDITAR 3:

Buscando en ese mensaje de error "GPGError: failed to determine gnupg version ...", encontré una página en https://bugs.launchpad.net/duplicity/+bug/1865427 . En esa página se sugería que para las tareas cron se añadiera --gpg-binary con la ruta a gpg.

Lo intenté, pero la tarea launchd seguía sin funcionar.

EDICIÓN FINAL

Antes de la actualización de Monterey, gpg estaba en la ruta por defecto utilizada por el trabajo launchd, por alguna razón. Los cambios de configuración debidos a la actualización del sistema operativo hicieron que dejara de estar en esa ruta por defecto. Así que antes no era necesario ajustar la ruta para el script de launchd, pero ahora sí. Arreglando eso se solucionó el problema. Así que marcando esta pregunta como respondida.

0voto

typeseven Puntos 612

Adivinanza total: ¿Podría deberse el problema al cambio de MacOS a Zsh en lugar de Bash como shell por defecto? Ese cambio se produjo en Catalina, y me parece recordar problemas con mi launchd scripts en ese momento... ¿Podría haber mantenido Bash como predeterminado en aquel entonces, y ahora el launchd de Monterey espera Zsh?

Vale, ahora me ha picado la curiosidad. ¿Conocías este artículo de la documentación de Apple?

"Actualización de ejecutables de ayuda de versiones anteriores de MacOS", en https://developer.apple.com/documentation/servicemanagement/updating_helper_executables_from_earlier_versions_of_macos

0voto

hstoerr Puntos 5771

SOLUCIÓN

Antes de la actualización de Monterey, gpg estaba en la ruta por defecto utilizada por el trabajo launchd, por alguna razón. Los cambios de configuración debidos a la actualización del sistema operativo hicieron que dejara de estar en esa ruta por defecto. Así que antes no era necesario ajustar la ruta para el script de launchd, pero ahora sí.

Eso resolvió el problema.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X