9:32 a.m.
I have a shell script that needs to dig the values of a couple of
"Environment=" settings out of a systemd service file. Currently
it just assumes it knows the search path for such things, finds
the file, and greps for the right lines. This seems unduly friendly
with the file format, and it was just pointed out to me that it
completely fails to handle .include directives. So I'm wondering if
there is anything in the systemd infrastructure that could help me
do this in a more robust way. Ideas anyone?
regards, tom lane
9:47 a.m.
On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
I have a shell script that needs to dig the values of a couple of
"Environment=" settings out of a systemd service file. Currently
it just assumes it knows the search path for such things, finds
the file, and greps for the right lines. This seems unduly friendly
with the file format, and it was just pointed out to me that it
completely fails to handle .include directives. So I'm wondering if
there is anything in the systemd infrastructure that could help me
do this in a more robust way. Ideas anyone?
You can try
systemctl show -p Environment <unit>
--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg(a)chrome.pl it's a dangerous thing for a man. -- Alia
10:41 a.m.
Tomasz Torcz <tomek(a)pipebreaker.pl> writes:
On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
> I have a shell script that needs to dig the values of a couple of
> "Environment=" settings out of a systemd service file. Currently
> it just assumes it knows the search path for such things, finds
> the file, and greps for the right lines. This seems unduly friendly
> with the file format, and it was just pointed out to me that it
> completely fails to handle .include directives. So I'm wondering if
> there is anything in the systemd infrastructure that could help me
> do this in a more robust way. Ideas anyone?
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!
regards, tom lane
6:45 p.m.
On Sat, 17.03.12 11:41, Tom Lane (tgl(a)redhat.com) wrote:
Tomasz Torcz <tomek(a)pipebreaker.pl> writes:
> On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
>> I have a shell script that needs to dig the values of a couple of
>> "Environment=" settings out of a systemd service file. Currently
>> it just assumes it knows the search path for such things, finds
>> the file, and greps for the right lines. This seems unduly friendly
>> with the file format, and it was just pointed out to me that it
>> completely fails to handle .include directives. So I'm wondering if
>> there is anything in the systemd infrastructure that could help me
>> do this in a more robust way. Ideas anyone?
> 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.
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.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:39 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> writes:
On Sat, 17.03.12 11:41, Tom Lane (tgl(a)redhat.com) wrote:
> Tomasz Torcz <tomek(a)pipebreaker.pl> 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.
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?
regards, tom lane
8:19 p.m.
On Wed, 21.03.12 20:39, Tom Lane (tgl(a)redhat.com) wrote:
Lennart Poettering <mzerqung(a)0pointer.de> writes:
> On Sat, 17.03.12 11:41, Tom Lane (tgl(a)redhat.com) wrote:
>> Tomasz Torcz <tomek(a)pipebreaker.pl> 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
problems.
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
--
Lennart Poettering - Red Hat, Inc.
8:37 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> writes:
On Wed, 21.03.12 20:39, Tom Lane (tgl(a)redhat.com) wrote:
> ... 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
problems.
Yeah, it's shell.
But you are right, we should drop the duplicate entry. I will fix
this. Added to the TODO list.
What would be more useful is to fix the format ambiguity. After some
thought, one possibility is to emit a separate Environment= line for
each env var:
Environment=PGPORT=5432
Environment=PGDATA=/var/lib/pgsql/data
which is both unambiguous (at least, as long as there are not newlines
in the variable values) and natural given the input language. If you
wanted it to not be order-sensitive then yes you'd need to get rid of
duplicates internally; don't know if that's important to you.
regards, tom lane
6:51 a.m.
On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
I have a shell script that needs to dig the values of a couple of
"Environment=" settings out of a systemd service file. Currently
it just assumes it knows the search path for such things, finds
the file, and greps for the right lines. This seems unduly friendly
with the file format, and it was just pointed out to me that it
completely fails to handle .include directives. So I'm wondering if
there is anything in the systemd infrastructure that could help me
do this in a more robust way. Ideas anyone?
Augeas *ought* to be able to do this. Unfortunately I don't see any
lens in upstream augeas git :-( But it'd be a nice feature to add.
(CC'd to augeas-devel)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
1:19 p.m.
New subject: [augeas-devel] Does systemd expose any unit-file-parsing functionality?
On 18/03/12 11:51, Richard W.M. Jones wrote:
On Sat, Mar 17, 2012 at 10:32:22AM -0400, Tom Lane wrote:
> I have a shell script that needs to dig the values of a couple of
> "Environment=" settings out of a systemd service file. Currently
> it just assumes it knows the search path for such things, finds
> the file, and greps for the right lines. This seems unduly friendly
> with the file format, and it was just pointed out to me that it
> completely fails to handle .include directives. So I'm wondering if
> there is anything in the systemd infrastructure that could help me
> do this in a more robust way. Ideas anyone?
Augeas *ought* to be able to do this. Unfortunately I don't see any
lens in upstream augeas git :-( But it'd be a nice feature to add.
Thanks for the idea Rich, I've added a lens to Augeas to parse unit files:
http://git.fedorahosted.org/git/?p=augeas.git;a=commitdiff;h=53ba599c
For Tom's use it still requires knowing unit file paths and it won't
automatically follow .include directives, but it will parse them and
present them in the config tree.
See the unit test in the above commit for an example of the layout, or
this augtool print output of one service with some environment variables
set: http://fpaste.org/PrtY/
You can use the above lens with released versions of Augeas, either
putting it into /usr/share/augeas/lenses or using augtool -I.
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
4454
days inactive
4459
days old
8 comments
5 participants
participants (5)
-
Dominic Cleal -
Lennart Poettering -
Richard W.M. Jones -
Tom Lane -
Tomasz Torcz