Statut 203 d'un service systemd — l'exec qui n'a jamais tourné

tl;dr

Le statut 203 d'un service systemd s'affiche en status=203/EXEC : l'appel système execve du noyau a échoué, et ton programme n'a jamais exécuté une seule ligne. Ce n'est pas un crash — c'est un refus à la porte. Mesuré sur systemd 262 : un mauvais chemin, un bit d'exécution manquant, un shebang cassé — trois erreurs différentes — ont atterri sur le même ExecMainStatus=203, à quelques secondes d'écart, sur la même VM. La deuxième ligne du journal nomme laquelle des trois est la tienne.

203/EXEC signifie toujours une seule chose : systemd a tenté de remettre ta commande ExecStart au noyau, et le noyau l'a refusée avant même que ton code existe comme processus. La ligne du journal sous l'échec te dit quelle porte a refusé : Unable to locate executable … No such file or directory = mauvais chemin ; Unable to locate executable … Permission denied = bit d'exécution manquant ; Failed to execute … No such file or directory = l'interpréteur que nomme ton shebang n'existe pas. Corrige cette seule chose — chemin, chmod +x, ou une ligne 1 honnête — et l'unité démarre. Le remède du banc a tenu en un chmod et une retouche de shebang : Result=success.

Dernier test le 2026-11-11 · systemd 262 (262.1-1-arch) · VM Arch vierge. Chaque ligne ci-dessous est copiée de cette session.

Fig 1 — le relais d'exec. status=203/EXEC est le témoin qui tombe à la porte 1, 2 ou 3 ; le bloc du bas n'a jamais démarré.

Que signifie vraiment le statut 203/EXEC ?

La phrase à retenir : status=203/EXEC est systemd qui rapporte que l'execve de ta commande ExecStart a échoué au moment du lancement — ton processus n'a jamais existé, donc rien de la logique, de la config ou du code de ton programme n'est en cause pour l'instant. Sur le banc, une unité oneshot jetable qui portait chaque panne à tour de rôle a imprimé le même verdict à chaque essai :

$ systemctl show bench203.service -p ExecMainCode -p ExecMainStatus -p Result
ExecMainCode=1
ExecMainStatus=203
Result=exit-code

vérif : ExecMainCode=1 vaut CLD_EXITED et 203 est le statut de sortie de la famille exec ; la même unité une fois soignée lit ExecMainStatus=0 et Result=success (reçu plus bas).

Trois erreurs différentes, un seul numéro

Trois valeurs de ExecStart, trois démarrages sur le même boot, à quelques secondes d'écart. systemctl status — l'écran que la plupart des gens lisent vraiment — n'a pas su les distinguer :

Process: 703 ExecStart=/opt/bench203/no-such-binary (code=exited, status=203/EXEC)
Process: 778 ExecStart=/opt/bench203/worker.sh      (code=exited, status=203/EXEC)   # file exists, mode 0644
Process: 853 ExecStart=/opt/bench203/shebang.sh     (code=exited, status=203/EXEC)   # +x, interpreter missing

vérif : trois démarrages, trois fins identiques en status=203/EXEC — l'écran de statut montre le quoi, jamais le lequel.

Le remède du peuple : réinstaller le programme ou redémarrer l'unité en boucle. La boucle de redémarrage est le mensonge, ici : le programme n'a jamais été le patient. La deuxième ligne de l'entrée du journal — celle sous Starting… — porte le diagnostic, et elle diffère les trois fois :

bench203.service: Unable to locate executable '/opt/bench203/no-such-binary': No such file or directory
bench203.service: Unable to locate executable '/opt/bench203/worker.sh': Permission denied
bench203.service: Failed to execute /opt/bench203/shebang.sh: No such file or directory

vérif : copié verbatim depuis journalctl -u bench203.service, une ligne par panne, PIDs 703 / 778 / 853.

Laquelle des trois est la tienne ?

Lis la deuxième ligne en deux temps. D'abord la formule : Unable to locate executable parle de ton chemin (panne A ou B) ; Failed to execute signifie que systemd a dépassé ton fichier et a perdu quelque chose qu'il nomme dedans — l'interpréteur de la ligne 1 (panne C). Ensuite l'errno après le deux-points : No such file or directory contre Permission denied sépare A de B.

La formule de la panne B mérite son propre avertissement : Unable to locate executable … Permission denied accuse le fichier de ne pas exister pendant qu'il est là, sous tes yeux — 28 octets, mode 0644, bien tranquille. systemd l'a bien localisé ; il ne peut juste pas le dire dans cette formule. La vérité, c'est l'errno, jamais le verbe.

Amauvais chemin — Unable to locate … No such file or directory : le fichier n'est vraiment pas là

Bpas de bit exec — même formule Unable to locate, errno Permission denied : le bit est la pièce manquante

Cshebang cassé — Failed to execute … No such file or directory : ton fichier est bon, c'est #!/usr/bin/bashh qui ne l'est pas

Comment corriger le statut 203/EXEC ?

Le remède sur le banc : un chmod pour la forme B et une ligne 1 honnête pour la forme C — pas de réinstallation, pas de boucle de redémarrage :

sudo chmod 0755 /opt/bench203/worker.sh        # give back the exec bit
# and make line 1 of the script name a real interpreter:
#!/bin/bash
$ systemctl show bench203.service -p ExecMainStatus -p Result
ExecMainStatus=0
Result=success

vérif : le journal de la session soignée lit worker.sh[931]: worker ran → Deactivated successfully. → Finished bench203 fault shapes. — le oneshot a fait son travail et s'en est allé.

L'article de septembre service systemd qui ne démarre pas : le journal avait déjà nommé la cause faisait la même promesse pour un échec plus silencieux. Le 203, c'est cette même loi à pleine voix — l'aveu atterrit dans le journal avant même que tu aies ouvert le fichier d'unité.

Le remède, dans l'ordre

systemctl status <unit> -l — confirme le status=203/EXEC sur la ligne Main PID
journalctl -u <unit> --no-pager — lis la deuxième ligne : Unable to locate (ton chemin) ou Failed to execute (l'interpréteur)
l'errno après le deux-points — No such file or directory ou Permission denied
ls -l sur le chemin (les bits x) · head -1 sur le script (l'interpréteur nommé) · test -x sur cet interpréteur
corrige la seule chose en cause, systemctl start à nouveau — show -p Result lit success

Les trois aveux d'un coup d'œil

le journal dit	ce qui manque	le remède
Unable to locate executable … No such file or directory	le chemin `ExecStart` lui-même	corrige le chemin — absolu, sans faute de frappe
Unable to locate executable … Permission denied	le bit d'exécution	`sudo chmod +x /path/to/script`
Failed to execute … No such file or directory	l'interpréteur du shebang	corrige la ligne 1 (`#!/bin/bash`) ou installe l'interpréteur

« Le 203, ce n'est pas ton programme qui meurt — c'est systemd qui échoue à lui remettre les clés. Le journal nomme laquelle, à chaque fois. »

ce que le banc n'a pas couvert

Mesuré : trois formes de panne (chemin absent, mode 0644, shebang cassé) sur une VM Arch vierge, systemd 262 (262.1-1-arch), unité oneshot, à quelques secondes d'écart, plus la session soignée. Non mesuré : un chemin ExecStart relatif — systemd refuse ceux-là au moment du parse avec son propre message, pas 203 (source publique) ; les refus SELinux/AppArmor, qui remontent avec le même errno Permission denied — vérifie ton LSM avant d'accuser le bit ; les chemins ExecStart en chroot. Une machine, un build : la règle de lecture est la partie transportable ; ta propre ligne de journal est le verdict.

BANC VÉRIFIÉ À LA MAIN · systemd 262 (262.1-1-arch) · VM Arch vierge · dernier test 2026-11-11

Un numéro, trois portes, et un journal qui nomme la porte à chaque fois. Lis la deuxième ligne avant de relancer quoi que ce soit. ■