J’ai également remarqué une différence dans le traitement de certaines commandes avec cron.
Même en définissant un utilisateur, certaines commandes passe (très) mal. Le sudo est en effet une solution viable si bien utilisé.
Je crois que le problème est que l’utilisateur dans lequel exécute la commande via cron permet d’associer en effet l’environnement a cet utilisateur, mais que lors de manipulation avec les PID (pkill, kill, …), certaines application passe leur vérification utilisateur autrement et détecte celui de cron au lieu de celui que cron exécute, et bloque la commande. Dans le cas de sudo, il traite également la commande autrement, ce qui fait que le processus reconnais un autre utilisateur, ce n’est pas pour rien qu’y existe un paramètre pour charger l’environnement du terminal qui lance la commande que ceux de sudo. (c’est un peu dur à comprendre, je sais)
De mémoire (car utilisé que dans un seul cas), c’est sudo - commande, le « - » fait en sorte que des variables par exemple sont chargé. Si tu défini une $VAR dans ton terminal, il sera alors partagé avec sudo. Dans le cas normal, sudo charge des variables et autres choses de manière indépendante pour exécuter la commande. Consulter la documentation pour plus de détails et confirmer sur ce point.
J’ai rencontré ce problème sur un setup de camera IP, je démarre avec ffmpeg la lecture et transmission sans problème, mais en commande cron ou même init.d, j’ai un accès refusé, la commande sudo marche, mais ce n’est pas safe. Alors j’ai plutot opté pour un démarrage du script via le fichier ~/.profile, qui lui est démarré par l’utilisateur lui-même proprement.
Bien sur, ce n’est pas un usage efficace pour toutes les situations.
En « visuel »
cron process : user cron
'-run cron pour user défini : user défini
'-commande : user défini
Dans l’exemple, la commande s’exécute, l’application peut détecter le user en ce basant sur le parent, soit le process cron. Alors ce n’est pas le « user défini » mais « cron ».
cron process : user cron
'-run cron pour user défini : user défini
'-sudo commande : user défini
sudo commande : user défini
'-commande : user défini
La avec sudo, par exemple, le process est lancé dans un autre processus, le parent est sudo, il lance la commande, l’utilisateur détecté sera celui de sudo, et il a été lancé et défini par « user défini ». Alors la commande s’effectue, malheureusement, avec le pouvoir root.
Après une légère réflexion, je crois que l’usage de screen pourrais résoudre le problème. Lancer un script qui démarre screen, devrais déjà détacher le screen du script de lancement (avec le paramètre pour démarrer détaché) et il sera sous le nom utilisateur du lanceur de script, fournis par le cron. Et cette solution te permet au besoin d’interagir ou de voir l’application exécuter. Et est l’option pour mes radio shoutcast.
Il me semble qu il faut indiquer le path de l exécutable