On Thu, 03.07.14 19:11, Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> writes:
> Please migrate away from ".include", please use .d/ drop-ins instead. We
> kinda are deprecating ".include", only support it for compatibility
> instead. ...
> Unit files are configuration files. It's OK to copy unit files from
> /usr/lib/systemd/system into /etc/systemd/system and edit it there.
FWIW, I don't think that's OK at all, and that's what I tried to avoid in
the original layout for Postgres' systemd files. If people create the
files for secondary postmasters by cloning the entire unit file, then
there is no way for us to push out fixes in the unit file; or at least
none that doesn't break secondary servers.
If unit files tended to be trivial two-line affairs, this concern might
not have much force, but they're generally not. Certainly the Postgres
one isn't.
Link?
Are you sure that you didn't make them this complex because you wanted
to not simply allow people to copy them?
So I think deprecation of ".include" is *seriously* misguided. We really
need a way to create secondary-server unit files that don't contain
anything more than alternate PGPORT and PGDATA settings plus an inclusion
of a master unit file. (I'll grant that there might be other ways to
mechanize such a behavior, but if you're telling me I don't need this,
you're mistaken, sir.)
Well, the .include stuff is awful, since it's incredible hard to figure
out when they are out of date, and whether there are loops in the
include chain. The .d/ drop-ins don't suffer by the problem.
Also note that we do provide template units, for the cases where people
want to run multiple instances. You can even mix .d and template units:
postgresql(a)foobar.service
postgresql(a)foobar.service/addition.conf
postgresql(a)waldo.service
postgresql(a)waldo.service/extension.conf
And so on...
Lennart
--
Lennart Poettering, Red Hat