On Tue, 12.01.16 19:38, 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?
Not seeing how a distributed key store could be related to daemon status notifications? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
