Created attachment 937632 [details] Reproducer Better to show via attached reproducer: $ tar xf simple_sample* && cd simple_sample $ ./configure --prefix=/usr $ # check that I'm not kidding you.. $ make install DESTDIR=`pwd`/installdir && find installdir ... installdir/etc/systemd/system/a.service ... installdir/usr/lib/systemd/system/a.service.d installdir/usr/lib/systemd/system/a.service.d/50-default.conf ... $ sudo make install $ # this fails intentionally $ sudo systemctl start a.service $ sudo systemctl status a.service .... Sep 15 16:19:45 redhat.com systemd-dump-env[16710]: RESULT=system-dropin .... NOTE THIS ^^^^ IMHO, you should see 'user-service' string there, as specified by installed /etc/systemd/system/a.service. This gives to user unexpected behavior when some system-default drop-in is installed and .include is used.
Drop-ins are applied "out-of-band". They are applied on top of configuration parsed from unit files, hence may reset/override those value. However usual configuration hierarchy semantics applies to them as well. Also note that use of .include is discouraged. Users should use drop-ins in /etc to permanently reset/override vendor supplied configuration.
(In reply to Michal Sekletar from comment #1) > Drop-ins are applied "out-of-band". They are applied on top of configuration > parsed from unit files, hence may reset/override those value. However usual > configuration hierarchy semantics applies to them as well. Truth, that is what is this bug about. I would expect that parser starts at /etc/lib/*/*.service, which invokes the .include ~> so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service and then '/etc/*/*.service.d/ dropins. > Also note that use of .include is discouraged. Users should use drop-ins in > /etc to permanently reset/override vendor supplied configuration. Yup, I plan on stopping the advices to use .include (in our service files documentation) and migrate to drop-in. The problem is that I would like to stay compatible (lets say that I - as a packager - wan't keep the InterfaceStabilityPromise) with existing service files under /etc admins already have. This (bug?), however, blocks me and I can't install drop-ins under /usr/lib.
Asked privately to do upstream report, thanks for looking at this issue, http://lists.freedesktop.org/archives/systemd-devel/2014-September/023089.html