There are some drawbacks of storing regular files in
/etc/systemd/system, not because of the systemd itself, but because
systemctl resides in this location. Placing regular files in this directory will break some of the functionality of systemctl, in this case, the ability to mask your .service, and there is no reason to believe other applications will handle this any differently. Now, systemd has a predefined set of unit search paths, most of which are preoccupied with the distribution, this makes locations where you can place your .service basically limited to (or at least until this is resolved):
This work exceptionally well and without loss in functionality:
# cp -a hello-world.service /usr/local/lib/systemd/system
'hello-world.service' -> '/usr/local/lib/systemd/system/hello-world.service'
# systemctl daemon-reload
# dpkg -i hello-world_1.0-1_all.deb
Selecting previously unselected package hello-world.
(Reading database ... 396452 files and directories currently installed.)
Preparing to unpack hello-world_1.0-1_all.deb ...
Unpacking hello-world (1.0) ...
Setting up hello-world (1.0) ...
Created symlink /etc/systemd/system/multi-user.target.wants/hello-world.service → /usr/local/lib/systemd/system/hello-world.service.
# systemctl mask hello-world
Created symlink /etc/systemd/system/hello-world.service → /dev/null.
the same chronological order applies to drop-ins as well, where
/etc take precedence over
/run which in turn take precedence over
/lib ... and so on, drop-ins with different names will be applied in lexicographic order regardless of location. If you have overlapping directives, then the last will take precedence:
: systemctl cat hello-world
Description=Hello world (lib).
Description=Hello world (local).
: systemctl start hello-world
jun 28 15:20:24 betazoid systemd: Starting Hello world (local)....
jun 28 15:20:24 betazoid hello: hello etc
jun 28 15:20:24 betazoid systemd: hello-world.service: Succeeded.
jun 28 15:20:24 betazoid systemd: Finished Hello world (local)..