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 <[email protected]> wrote: > On Tue, Jan 12, 2016 at 7:25 PM, Lennart Poettering < > [email protected]> wrote: > >> On Fri, 08.01.16 18:09, Rick Richardson ([email protected]) >> 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 <[email protected]> >
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
