[systemd-devel] ruby bindings

[Nathan Williams]

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.

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.

cheers,

nathan

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.

On Tue, Oct 4, 2016 at 7:30 PM David Timothy Strauss <david at davidstrauss.net>
wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20161005/2eddcbba/attachment.html>