Je l'ai déjà écrit : nous utilisons Puppet pour configurer des stations de travail. Sur ces machines-là, le CRON qui lance Puppet (pourquoi ?) au démarrage (mot-clé @reboot
dans CRON) effectue aussi un dpkg --configure -a
afin de réparer les installations cassées (utilisateur qui éteint brutalement la machine en pleine installation / mise à jour…). On a donc dpkg --configure -a && puppet agent --enable && puppet agent -t ; apt -y update && apt -y upgrade
. À plusieurs reprises, je constate que puppet n'est pas exécuté et que les mises à jour ne sont pas effectuées.
Pour debug, j'ai fait dans l'habituel : un echo, une commande, un echo, une commande, etc. On ne va pas plus loin que dpkg --configure -a
. Rediriger la sortie standard et la sortie d'erreur dans un fichier (1>/tmp/testcron 2>&1
) n'apporte pas d'information (si ça avait été le cas, j'aurai reçu un email, car CRON envoie la sortie standard et les erreurs par email). echo $? >/tmp/testcron
est plus intéressant : dpkg
termine avec le code d'erreur 2. D'après son manuel, il s'agit d'une erreur fatale ou irrécupérable. Rien que ça.
Pour la suite, ça a été un coup de chance. Dans CRON, le PATH n'est pas celui de root, mais « /usr/bin:/bin ». Or, dpkg
a besoin de « /usr/sbin:/sbin ». Je ne vois pas trop quels binaires il exécute dedans, mais soit. Ajouter export PATH=$PATH:/sbin:/usr/sbin
dans mon script résout mon problème.
Pour les plus attentifs : pourquoi je ne chaîne pas « apt -y upgrade » à « puppet agent -t » avec &&
? Lorsqu'il effectue des actions, puppet agent
ne termine pas avec le code d'erreur 0 mais 2 (cf son manuel), donc le chaînage en cas de succès (&&
) est caduque.