Come accennato da @JdeBP, le etichette di file SELinux errate sono la ragione del comportamento. Il . carattere nell'output di ls indica che esiste un contesto di sicurezza impostato per il file. Quindi fai attenzione al . nel ls uscita!
cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service stampe
-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
Si può vedere che l'altro file di servizio ha il systemd_unit_file_t etichetta, mentre il servizio non funzionante no. Questo può essere risolto con restorecon anfragen-3dkonfig-mapper.service . Successivamente le etichette appaiono come segue:
-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 ora si comporta come previsto.
-rw-r--r--.
Le restrizioni di SELinux ti stanno rendendo la vita complessa.