Tecnología · GUÍA PRÁCTICA
¿systemd muestra status=203/EXEC? Audita la ruta execve antes de cambiar permisos
203/EXEC significa que el gestor no pudo ejecutar el proceso configurado. Usa el motivo exacto del registro para separar objetivo o intérprete ausente, formato inválido, bloqueo de ruta o montaje y política MAC.

Cuando una unidad termina con code=exited, status=203/EXEC, normalmente no llegó a la lógica de la aplicación. systemd define 203 como EXIT_EXEC: falló la llamada execve. Eso acota el problema, pero no identifica qué ruta, intérprete, regla de montaje o decisión de seguridad lo causó.
No empieces con chmod 777, un envoltorio de shell ni desactivando SELinux. Conserva la unidad efectiva y la primera línea “Failed at step EXEC”, y luego audita el límite de ejecución que el servicio debe cruzar.
1. Conserva el comando que realmente falló
Ejecuta systemctl cat UNIT y systemctl show -p ExecStart -p User -p Group -p RootDirectory -p RootImage UNIT. Guarda la ruta y el motivo de la primera línea de fallo EXEC. Usa daemon-reload solo si cambió la definición de la unidad.
Lee ExecStart como sintaxis de systemd, no como shell interactivo. Usa un shell explícito solo si el diseño realmente necesita tuberías, redirecciones o expansión. El caso systemd #23235 reproduce 203/EXEC cuando ${APP} ocupa la posición del ejecutable.
2. Asocia el motivo del registro con una rama de execve
Ante “No such file or directory”, verifica el objetivo con readlink -f y stat, y el intérprete con head -n1 o readelf -l. El manual de execve incluye en ENOENT la ausencia del intérprete de script o ELF; CRLF puede añadir un retorno oculto al shebang.
Ante “Permission denied”, usa namei -l en objetivo e intérprete y findmnt -T PATH -o TARGET,FSTYPE,OPTIONS para noexec. Ante “Exec format error”, usa file y readelf -h para formato y arquitectura. Estas órdenes recogen pruebas; no autorizan cambios de permisos, etiquetas o montaje.
3. Comprueba el contexto del servicio, no solo tu shell
Confirma User y Group efectivos y realiza solo una comprobación inocua de identidad y ruta. Con RootDirectory o RootImage, el binario y sus auxiliares deben existir dentro de la nueva raíz. Las protecciones del sistema de archivos también cambian lo que ve la unidad.
Si aparece EACCES y los permisos ordinarios son correctos, revisa registros de política con las herramientas admitidas por la distribución. Red Hat documenta 203/EXEC junto con denegaciones AVC de init_t sobre default_t, user_home_t, nfs_t y cifs_t. Un AVC exige corregir etiqueta o política con precisión, no desactivar el modo obligatorio.
4. Repara únicamente la causa demostrada
Corrige ruta, intérprete, finales de línea, bit de ejecución, búsqueda en padres, montaje, arquitectura, visibilidad del espacio o etiqueta solo tras demostrar esa rama. chmod 777 no arregla un intérprete ausente, arquitectura incorrecta, noexec ni transición de política.
Prefiere un ejecutable absoluto directo en ExecStart. Añadir /bin/bash puede ocultar un shebang defectuoso y cambia el archivo que inicia execve. Si el shell es necesario, decláralo y cítalo como diseño, no como cura universal.
5. Demuestra que el servicio cruzó el límite de ejecución
Tras la corrección mínima, ejecuta daemon-reload solo si cambió la unidad, inicia una vez y lee el nuevo registro. Que desaparezca 203/EXEC prueba que se cruzó execve, pero la aplicación aún puede fallar; comprueba ActiveState, SubState, ExecMainCode y ExecMainStatus.
Registra el motivo original, el único cambio y el estado posterior. Si continúa 203, vuelve a la nueva primera línea EXEC y no acumules cambios. Detente y escala si la ruta o política pertenece a un paquete, el origen del binario es incierto o la solución debilita una frontera de seguridad.
