Hmm, actually systemd allows overriding in this case. The file symlinks point to are only used as fallback if no better file is available in /run, /etc, /usr/lib.

So, are you sure that things are broken for you? Shouldn't it suffice just copying your getty service template from /usr/lib to /etc and be done with it?

Note: /etc/systemd/system/getty@.service is a symlink to mingetty@.service.

I copied getty@.service to /etc/systemd/system, edited it a bit, and rebooted. This new files is used.

(In reply to comment #1)
> Hmm, actually systemd allows overriding in this case. The file symlinks
> point to are only used as fallback if no better file is available in /run,
> /etc, /usr/lib.
> 
> So, are you sure that things are broken for you? Shouldn't it suffice just
> copying your getty service template from /usr/lib to /etc and be done with
> it?

I suspect what the reporter wants is automatically-generated instances from an alternative getty service template /etc/systemd/system/serial-getty@.service.

Currently systemd-getty-generator instantiates the template for, say, ttyS0 by creating a symlink /run/systemd/generator/getty.target.wants/serial-getty@ttyS0.service that always points to /lib/systemd/system/serial-getty@.service, even if /etc/systemd/system/serial-getty@.service exists.

Of course if you create a symlink /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service pointing to /etc/systemd/system/serial-getty@.service, your symlink overrides the automatically-generated symlink in /run/systemd, but having to do that sort of defeats the purpose of the generator.

The desired behavior would involve replacing the hardcoded SYSTEM_DATA_UNIT_PATH in add_symlink() in http://cgit.freedesktop.org/systemd/systemd/tree/src/getty-generator/getty-generator.c?id=v216 with the path lookup logic used for normal units.