<div dir="ltr">yes, i think it would be great to have a single library supporting all the systemd features, and perhaps at some point i can donate the dbus-systemd code to such a project (not that there's much to it, just a thin systemd-specific layer on top of the great ruby-dbus work), but so far as i'm aware, there's not a lot out there right now. at present the systemd-journal gem is the best thing going for journald, and dbus support is clearly out of scope. as i understand (from a brief comment in one of the conf videos i saw), there's currently deadlocking concerns preventing a journald dbus interface (?), but if one's ever implemented, i'd be happy to add support for it to dbus-systemd.<div><br></div><div>in general, i'm not aware of many system services being written in ruby (unless you count rack & friends), so perhaps there's just no real call for it. journald obviously has broad appeal for application developers, and an ecosystem of log aggregation tooling driving adoption with ops folks, but up to now i think the dbus APIs have been under-utilized. my intention with the dbus-systemd gem is to fill that need; selfishly, so i can scratch my own itch to stop using shellout in the systemd Chef cookbook when there's an API available to do what i want without all the contortions :). for the cfg mgmt use case, i think something that just handles dbus interfaces is right on target, and installing systemd-journal if i need it is no big deal.</div><div><br></div><div>cheers,</div><div><br></div><div>nathan</div><div><br></div><div>p.s. Pantheon's comments re: daemon-reload performance (great talks btw) are also a big motivation for this; the systemd-cookbook is hopefully headed toward needing far fewer reloads if we can swap in calls to SetProperties instead.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 4, 2016 at 7:30 PM David Timothy Strauss <<a href="mailto:david@davidstrauss.net">david@davidstrauss.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">For what it's worth, I try to encourage projects to identify their bindings as simply for systemd, even if the journal support is the first (and only) set of APIs available. It's just so easy to support the other APIs once the journal is already supported, and daemons that want to use the journal should consider using the notify API as well for startup/shutdown status -- and other APIs offered for daemons by systemd.</div>
</blockquote></div>