Quando cron esegue un evento, utilizza l'ambiente di shell predefinito dell'UID in esecuzione. Tuttavia, non viene applicata alcuna personalizzazione di "profilo", cioè il tuo .bash_profile non è originario e quindi le impostazioni PATH non vengono rilevate. Inoltre, non credo che i profili comuni vengano raccolti. Di conseguenza, probabilmente non hai impostazioni di ambiente PATH o LD_LIBRARY_PATH disponibili per il processo che stai tentando di avviare ed è per questo che pdfimages e gs non vengono prelevati per impostazione predefinita.
In passato, ho risolto questo in due modi:
- Fa riferimento direttamente al percorso completo del file di cui ho bisogno.
- Crea uno script di shell wrapper per il lavoro.
Di solito preferisco il 2 ° poiché non solo mi consente di configurare un ambiente in cui eseguire il lavoro, ma rende anche relativamente facile aggiungere facilmente le situazioni di debug. Ad esempio, se il lavoro non funziona correttamente, posso semplicemente modificare lo script della shell e inserire il reindirizzamento STDOUT in un file di debug.
Quindi, in breve, avrei una voce cron di
* 6 * * * cd /path/to/ && ./executable.sh
.. che cambierebbe nel percorso, ma executable.sh farebbe tutto il export PATH , export LD_LIBRARY_PATH , ecc. per ottenere il mio lavoro impostato.
Il tuo campione executable.sh potrebbe essere semplice come questo:
#!/bin/bash
# if you want to just pick up your profile, you can '.' source it
. ~/.bash_profile
export PATH=/where/i/find/gs
export LD_LIBRARY_PATH=/if/i/need/libs
(./executable 2&>1) >executable.out
Il reindirizzamento del file executable.out non è necessario poiché senza tutto STDOUT va a cron.out , ma rende un po 'più pulito farlo in questo modo. Anche il 2>&1 nonsense con le parentesi assicura che sia STDERR che STDOUT lo facciano nel file di output; questo aiuta a fare il debug perché un lavoro non è stato eseguito.