Avec la dernière version de Raspbian, j’ai commencé à avoir du mal à exécuter automatiquement des scripts Python au démarrage à l’aide de Cron ou de rc.local. Il semble que la séquence de démarrage de Raspbian ait changé et que ces processus s’exécutent à différents moments de cette séquence. L’ampleur du problème dépend de ce que votre script Python essaie de faire et des ressources dont il a besoin.
Le point auquel votre script Python est exécuté dans la séquence de démarrage est essentiel si votre script repose sur des fonctionnalités système disponibles à ce moment-là. Pour moi, cela comprend souvent :
- Le réseau est connecté et disponible
- Le répertoire /home/pi est monté et lu pour utilisation
- L’heure du système a été mise à jour par NTP
J’ai décidé d’utiliser « systemd » car cela semble être la méthode recommandée pour lancer des fonctionnalités personnalisées et de nombreuses distributions Linux l’adoptent. systemd est une suite logicielle pour la gestion et la configuration centrales d’un système Linux et vise à remplacer d’autres outils populaires qui remplissaient auparavant ce rôle. En conséquence, il semble avoir beaucoup d’ennemis, mais vous pouvez tout lire sur la controverse sur la page Wikipédia de systemd.
systemd est assez effrayant. Ou facile. Selon votre niveau d’expérience. Mon objectif était juste de lui faire lancer un de mes scripts avec un minimum de tracas et sans avoir à trop taper que je ne comprenais pas.
Étape 1 – Votre script Python
Mon exemple de script a été stocké dans le répertoire /home/pi et nommé « myscript.py ». Évidemment, votre script peut être appelé autrement, mais gardez un œil sur l’endroit où il est référencé dans les commandes et le texte ci-dessous.
À ce propos, si vous souhaitez mieux comprendre ce script et l’adapter plus finement, vous pouvez vous former pour devenir développeur et maîtriser pleinement Python. Visitez ce site pour suivre une formation au langage Python.
Étape 2 – Créer un fichier d’unité
Ensuite, nous allons créer un fichier de configuration (alias un fichier d’unité) qui indique à systemd ce que nous voulons qu’il fasse et quand :
sudo nano /lib/systemd/system/myscript.service
Ajoutez dans le texte suivant :
[Unit] Description=My Script Service After=multi-user.target [Service] Type=idle ExecStart=/usr/bin/python /home/pi/myscript.py WorkingDirectory=/home/pi User=pi [Install] WantedBy=multi-user.target
Vous pouvez enregistrer et quitter l’éditeur nano en utilisant [CTRL-X], [Y] ensuite [ENTER].
Cela définit un nouveau service appelé « My Script Service » et nous demandons qu’il soit lancé une fois que l’environnement multi-utilisateurs sera disponible. Le paramètre « ExecStart » est utilisé pour spécifier la commande que nous voulons exécuter. Le « Type » est défini sur « inactif » afin de garantir que la commande ExecStart n’est exécutée que lorsque tout le reste a été chargé. Pour mes scripts basés sur GPIO, le type par défaut de « simple » ne fonctionnait pas.
Notez que les chemins sont absolus et définissent entièrement l’emplacement de Python ainsi que l’emplacement de notre script Python.
Afin de stocker la sortie texte du script dans un fichier journal, vous pouvez modifier la ligne ExecStart en :
ExecStart=/usr/bin/python /home/pi/myscript.py > /home/pi/myscript.log 2>&1
L’autorisation sur le fichier d’unité doit être définie sur 644 :
sudo chmod 644 /lib/systemd/system/myscript.service
Étape 3 – Configurer systemd
Maintenant que le fichier unité a été défini, nous pouvons dire à systemd de le démarrer pendant la séquence de démarrage :
sudo systemctl daemon-reload sudo systemctl enable myscript.service
Redémarrez le Pi et votre service personnalisé devrait s’exécuter :
sudo reboot
Étape 4 – Vérifiez l’état de votre service
Vous pouvez vérifier l’état de votre service en utilisant :
sudo systemctl status myscript.service