Wie von @JdeBP angedeutet, sind falsche SELinux-Dateilabels der Grund für das Verhalten. Der . Zeichen in der Ausgabe von ls gibt an, dass für die Datei ein Sicherheitskontext festgelegt ist. Achten Sie also auf . im ls Ausgabe!
cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service druckt
-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
Es ist ersichtlich, dass die andere Dienstdatei den systemd_unit_file_t hat Label, während der defekte Dienst dies nicht tut. Dies kann mit restorecon anfragen-3dkonfig-mapper.service behoben werden . Danach sehen die Labels wie folgt aus:
-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 verhält sich jetzt wie erwartet.
-rw-r--r--.
SELinux-Beschränkungen machen Ihnen das Leben schwer.