Comme l'indique @JdeBP, les mauvaises étiquettes de fichiers SELinux sont la raison du comportement. Le . caractère dans la sortie de ls indique qu'un contexte de sécurité est défini pour le fichier. Soyez donc attentif au . dans le ls sortie !
cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service impressions
-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
On peut voir que l'autre fichier de service a le systemd_unit_file_t étiquette, alors que le service cassé ne le fait pas. Cela peut être corrigé avec restorecon anfragen-3dkonfig-mapper.service . Après cela, les étiquettes se présentent comme suit :
-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 se comporte maintenant comme prévu.
-rw-r--r--.
Les restrictions SELinux vous compliquent la vie.