Does systemd expose any unit-file-parsing functionality?

Lennart Poettering mzerqung at
Thu Mar 22 01:19:19 UTC 2012

On Wed, 21.03.12 20:39, Tom Lane (tgl at wrote:

> Lennart Poettering <mzerqung at> writes:
> > On Sat, 17.03.12 11:41, Tom Lane (tgl at wrote:
> >> Tomasz Torcz <tomek at> writes:
> >>> You can try
> >>> systemctl show -p Environment <unit>
> >> [ experiments with that ... ]  Hm, the output format seems pretty
> >> ill-designed, but I guess I can pick it apart with some careful
> >> sed'ing.  Better than trying to handle .include for myself, anyway.
> >> Thanks for the suggestion!
> > Hmm, what are you mising in the output format? We are always interested
> > in suggestions for imprvoement.
> The case that I was interested in was for postgresql, which needs to
> scrape the PGPORT port number setting and the PGDATA data directory path
> out of postgresql.service.  Assuming that somebody has overridden the
> PGPORT setting by using a custom service file that .include's the
> standard one, what I find "systemctl show" producing is a line like
> 	Environment=PGPORT=5432 PGDATA=/var/lib/pgsql/data PGPORT=5433
> So I have to pick this apart, understanding that later entries override
> earlier ones.  And the really nasty problem with it is that the layout
> is simply broken by environment variable names or values that contain
> spaces.  I don't mind so much needing to implement a "take the last
> match" rule, but it'd be nice if I didn't have to tell people they can't
> use a PGDATA path that includes spaces.  I don't have an immediate
> proposal for making it better though.

This is shell? If it wasn't shell the clean way would be to simply go to
the bus and ask for this raw. Which is trivial and not prone to parsing

But you are right, we should drop the duplicate entry. I will fix
this. Added to the TODO list.

> > Note that this command will not show you the environment inherited by
> > the PID 1 or any other env that is passed on that is not explicitly
> > configured in the unit files.
> No, that's not a problem, I just need to know what's configured in the
> unit file(s).
> BTW, while I'm thinking about it: I found in testing that any editing
> of the on-disk files was reflected immediately in "systemctl show"'s
> output.  Which was exactly what I wanted, but it surprised me quite a
> bit --- I was expecting that what this command shows is systemd's
> internal state and thus I'd have to do daemon-reload to make it update
> after an edit.  Can I expect that that behavior will persist, or am I
> relying on something that's going to change?

Umm, this is only instantly applied if the unit file got evicted from
ram for not being used first, via GC. If it is continiously referenced
it will only be refreshed on "systemctl daemon-reload".


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list