dBus server

[k0d]

I'm wanting to extend finit so that it can be controlled by dBus. I'm thinking an external daemon that talks over the unix-socket and then exposes it over dBus is the way to go, instead of creating a service inside of finit itself. Comments on that would be welcome.

So I need to talk over the unix-socket, and wondered if there is any docs (I didn't find any yet...) about the protocol initctl uses to talk to the finit process. Or maybe some tips on how I can figure it out easily.

Thanks, this is an amazing project!

[troglobit]

I'm not opposed to this, but could you elaborate a bit on the why and what is in it for the Finit project? Personally I've never used dbus so you'll have to explain it to a total noob :-)

There are no documentation for the IPC because I've wanted to keep keep it free to change and a closed business between PID 1 and initctl. I'm not sure if it's the best API for dbus, may be better to have native support, but please explain a bit more first.

[k0d]

With dBus, it would be possible to manage finit from other programs. Instead of calling initctl and parsing the output. dBus has support for calling methods reading/writing variables' and 'listening for signals. So it would be possible for the client program to receive a signal from finit if a service restarts etc.

From what I can see the current IPC protocol doesn't support sending the signal info, so something would have to be coded inside of the finit code anyway.

So that suggests native support for dBus inside of finit is the best way. The main issue with that at the moment is getting a dBus implementation to work with libuev as it normally uses a GLib loop. Possible of course, but is it the right way?

I think dBus control support for finit would be very useful, especially on embedded devices where you might want to control it over some external API (rest/mqtt/coap etc).

[troglobit]

OK, I've read up on the topic a bit more now. I don't see an immediate use for dbus in Finit proper right now, at least not in the projects I'm involved in that use it. We integrate Finit in the Infix NOS without any need for closer interaction with it than what initctl supports (it has JSON output).

Other users of Finit may of course be interested, but since adding support for another IPC mechanism is quite intrusive I must be honest with you that I cannot take an active part in the project, nor am I certain that I'd even accept a pull request for adding a libdbus or GDBus implementation to the project. The systemd project implemented their own sd-bus, which is the path that I'd probably take myself, if I was to add D-Bus support to Finit.

So, just to be clear, I'm not principally against D-Bus, but adding such a component is a major undertaking and it seems like the systemd design approach would be the best -- fully integrating it and thus replacing the current IPC between finit and initctl. Something I do not have the time or resources for atm.

You can of course make your own Finit plugin to access the internals, and that project is probably a better home for this functionality at the time being.

[troglobit]

Scheduling for v5.0, where we've said other major/breaking changes may happen.

[k0d]

Didn't look at finit for about a year, then I looked at it last night...now that's kind of scary! Great timing!