El estado 203 de un servicio systemd — el exec que nunca se ejecutó

tl;dr

El estado 203 de un servicio systemd se imprime como status=203/EXEC: la llamada execve del kernel falló, y tu programa nunca ejecutó una sola línea. No es un crash — es un rechazo en la puerta. Medido en systemd 262: una ruta equivocada, un bit de ejecución ausente y un shebang roto — tres errores distintos — produjeron el mismo ExecMainStatus=203, con segundos de diferencia, en la misma VM. La segunda línea del journal nombra cuál de los tres es el tuyo.

203/EXEC siempre significa una sola cosa: systemd intentó entregarle tu comando ExecStart al kernel y este lo rechazó antes de que tu código existiera como proceso. La línea del journal bajo el fallo te dice qué puerta rechazó: Unable to locate executable … No such file or directory = ruta equivocada; Unable to locate executable … Permission denied = falta el bit de ejecución; Failed to execute … No such file or directory = el intérprete que nombra tu shebang no existe. Arregla esa única cosa — la ruta, chmod +x, o una línea 1 honesta — y la unidad arranca. La cura del banco fueron un chmod y una corrección de shebang: Result=success.

Última prueba 2026-11-11 · systemd 262 (262.1-1-arch) · VM Arch recién creada. Cada línea de abajo está pegada tal cual de esa sesión.

Fig 1 — el relevo del exec. status=203/EXEC es el testigo que cae en la puerta 1, 2 o 3; la caja de abajo nunca arrancó.

¿Qué significa realmente el estado 203/EXEC?

La frase clave: status=203/EXEC es systemd reportando que la execve de tu comando ExecStart falló al momento de crear el proceso — tu proceso nunca existió, así que nada de la lógica, la config o el código de tu programa está en cuestión todavía. En el banco, una unidad oneshot desechable que probó cada fallo por turnos imprimió el mismo veredicto cada vez:

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

verifica: ExecMainCode=1 es CLD_EXITED y 203 es el estado de salida de la familia exec; la misma unidad ya curada lee ExecMainStatus=0 y Result=success (recibo abajo).

Tres errores distintos, un solo número

Tres valores de ExecStart, tres arranques en el mismo boot, con segundos de diferencia. systemctl status — la pantalla que la mayoría lee de verdad — no supo distinguirlos:

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

verifica: tres arranques, tres finales idénticos en status=203/EXEC — la pantalla de estado muestra el qué, nunca el cuál.

La cura popular es reinstalar el programa o reiniciar la unidad en bucle. El bucle de reinicios es la mentira aquí: el programa nunca fue el paciente. La segunda línea de la entrada del journal — la que va bajo Starting… — es el diagnóstico, y difiere las tres veces:

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

verifica: pegado verbatim de journalctl -u bench203.service, una línea por fallo, PIDs 703 / 778 / 853.

¿Cuál de los tres es el tuyo?

Lee la segunda línea en dos pasos. Primera frase: Unable to locate executable habla de tu ruta (fallo A o B); Failed to execute significa que systemd pasó tu archivo y perdió algo que nombra dentro — el intérprete de la línea 1 (fallo C). El errno después de los dos puntos: No such file or directory contra Permission denied separa A de B.

La redacción del fallo B merece su propio aviso: Unable to locate executable … Permission denied acusa al archivo de no existir mientras el archivo está justo ahí — 28 bytes, modo 0644, en lo suyo. systemd sí lo localizó; solo que no puede decirlo con esa frase. La verdad es el errno, nunca el verbo.

Aruta equivocada — Unable to locate … No such file or directory: el archivo de verdad no está ahí

Bsin bit de exec — la misma frase Unable to locate, errno Permission denied: el bit es la pieza que falta

Cshebang roto — Failed to execute … No such file or directory: tu archivo está bien, #!/usr/bin/bashh no

¿Cómo arreglo el estado 203/EXEC?

La cura en el banco fue un chmod para la forma B y una línea 1 honesta para la forma C — sin reinstalar, sin bucle de reinicios:

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

verifica: el journal de la sesión curada lee worker.sh[931]: worker ran → Deactivated successfully. → Finished bench203 fault shapes. — el oneshot hizo su trabajo y se fue.

El artículo de septiembre servicio systemd que no arranca: el log ya había nombrado la causa hizo la misma promesa para un fallo más silencioso. El 203 es esa ley a todo volumen — la confesión aterriza en el journal antes de que abras siquiera el archivo de unidad.

La cura, en orden

systemctl status <unit> -l — confirma el status=203/EXEC en la línea del Main PID
journalctl -u <unit> --no-pager — lee la segunda línea: Unable to locate (tu ruta) o Failed to execute (el intérprete)
el errno después de los dos puntos — No such file or directory o Permission denied
ls -l a la ruta (los bits x) · head -1 al script (el intérprete que nombra) · test -x a ese intérprete
arregla lo único que falla, systemctl start otra vez — show -p Result lee success

Las tres confesiones de un vistazo

el journal dice	qué falta	la cura
Unable to locate executable … No such file or directory	la ruta de `ExecStart` en sí	corrige la ruta — absoluta, sin erratas
Unable to locate executable … Permission denied	el bit de ejecución	`sudo chmod +x /path/to/script`
Failed to execute … No such file or directory	el intérprete del shebang	corrige la línea 1 (`#!/bin/bash`) o instala el intérprete

«El 203 no es tu programa muriendo — es systemd que falla en entregarle las llaves. El journal nombra cuál llave, todas las veces.»

lo que el banco no cubrió

Medido: tres formas de fallo (ruta ausente, modo 0644, shebang roto) en una VM Arch recién creada, systemd 262 (262.1-1-arch), unidad oneshot, con segundos de diferencia, más la sesión curada. No medido: una ruta ExecStart relativa — systemd las rechaza al parsear con su propio mensaje, no 203 (registro público); denegaciones SELinux/AppArmor, que aparecen con el mismo errno Permission denied — revisa tu LSM antes de culpar al bit; rutas ExecStart en chroot. Una máquina, un build: la regla de lectura es lo portable; tu propia línea del journal es el veredicto.

BANCO VERIFICADO A MANO · systemd 262 (262.1-1-arch) · VM Arch recién creada · última prueba 2026-11-11

Un número, tres puertas, y un journal que nombra la puerta todas las veces. Lee la segunda línea antes de relanzar lo que sea. ■