[systemd-devel] how to get sd_notify state/variables from dbus?

[Rick Richardson]

Etcd can certainly store config variables. We have our own versioned
configuration database. However, I was hoping to use systemd as the
canonical source for binding which versions of which configs a process
launched with, since the information world be atomically associated with a
service's ready notification.

Looking at the source, I was disappointed to learn that any variables that
are not the "known" variables are dropped on the floor. The sd_notify man
page should probably be updated accordingly.



On Tue, Jan 12, 2016, 12:38 PM Mantas Mikulėnas <grawity at gmail.com> wrote:

> On Tue, Jan 12, 2016 at 7:25 PM, Lennart Poettering <
> lennart at poettering.net> wrote:
>
>> On Fri, 08.01.16 18:09, Rick Richardson (rick.richardson at gmail.com)
>> wrote:
>>
>> > I have a fleet of applications that need to pass some critical variables
>> > back to systemd so that our services monitor can collect them.  My hope
>> is
>> > that this can be done via sd_notify as it is very much a
>> config-management
>> > and process monitoring related task.
>> >
>> > Currently my monitor subscribes to PropertiesChanged in dbus, and gets
>> the
>> > active/running notification upon an sd_notify from the service, I can
>> see
>> > the StatusText variable set via the STATUS=... but I can't seem to
>> figure
>> > out where the rest of the notify state is stored.
>>
>> It currently is not.
>>
>> We could expose this data I figure, but I am not entirely sure how
>> that could even look like, as for unknown sd_notify() fields it's not
>> clear whether they are supposed to extend or replace any unrelated
>> previously set settings... i.e. if you first send X_FOO=1 and then
>> X_BAR=1 and then query the data, would you get "X_FOO=1 X_BAR=1" back,
>> or just "X_BAR=1"? The former would mean we'd might get into trouble
>> if people keep inventing new fields. The latter would mean it's
>> useless if people assume additive operation of the the data...
>>
>
> Isn't this basically something that etcd was meant to do?
>
> --
> Mantas Mikulėnas <grawity at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20160112/64475ce2/attachment-0001.html>