Como lo insinuó @JdeBP, las etiquetas de archivo SELinux incorrectas son la razón del comportamiento. El . carácter en la salida de ls indica que hay un contexto de seguridad establecido para el archivo. Así que atento al . en el ls salida!
cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service impresiones
-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0 440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service
Se puede ver que el otro archivo de servicio tiene el systemd_unit_file_t etiqueta, mientras que el servicio roto no lo hace. Esto se puede arreglar con restorecon anfragen-3dkonfig-mapper.service . Después de esto, las etiquetas quedan de la siguiente manera:
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service
systemd ahora se comporta como se esperaba.
-rw-r--r--.
Las restricciones de SELinux le complican la vida.