search

bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
677 stars 79 forks source link

What are the minimum components of systemd needed to make dbus-broker-launch work? #313

Closed DidierSpaier closed 1 year ago

DidierSpaier commented 1 year ago

Hello,

I maintain the Slint distribution based on Slackware and our init system is not systemd. However I would like to included dbus-broker and am looking for the path of least resistance (read: as less changes and added maintenance work as possible).

I have considered two ways:

  1. As Artix does, do not use the launcher but ship an adapted dbus.
  2. Do use the launcher, but include only the needed part of systemd to make it work correctly.

To explore the second way I have stolen (just repackaged, not built from source) systemd-libs and bits of a systemd packages (version 250 to be compatible with our version of glibc if that matters) from Arch and been able to make a (built from source) dbus-broker package for Slint, including the launcher. However, starting dbus-broker-launch invariably leads to this error message: No listener socket inherited, most probably because I didn't package some necessary parts of systemd (googling this message didn't help). This leads to this question:

What are the minimum files and/or features of systemd needed to make dbus-broker-launch work?

If the answer is "the whole systemd" this second way is a dead end for me as I can't afford to replace our init system by another one and maintain it, let alone write a launcher myself.

Cheers, Didier

dvdhrm commented 1 year ago

dbus-broker-launch currently requires systemd for service activation. That is, it calls the PID1 APIs to spawn transient units which run activated dbus services (it also uses non-transient units, if specified). There might be some more niche API calls, but the service-activation is the biggest one by far. This means, you need to provide an API similar to the PID1-API of systemd (or "manager API").

dvdhrm commented 1 year ago

We explicitly separated the launcher from dbus-broker to provide a pure bus implementation and allow for integration into different systems / setups. The broker itself has no interaction with the outside but is a pure message broker. The provided launcher grants compatibility to dbus-daemon by parsing the same configuration and service files, and it activates services by using systemd.

My recommended approach to avoid systemd would be to copy the launcher code and replace the service activation with a simple fork+exec model. This should be straightforward to do.

DidierSpaier commented 1 year ago

My recommended approach to avoid systemd would be to copy the launcher code and replace the service activation with a simple fork+exec model. This should be straightforward to do.

Thanks for your answer David. Straightforward to do, maybe... For a developer, unfortunately this is "above my pay grade" as they say in the US. I am not bad at shell scripting but just know a tiny little of Python and my knowledge of C is non-existent, so I would need to find a volunteer to do that.

As an aside I have tried kmscon several years ago to be able to properly display Japanese or Persian in the text installer of a previous version of Slint. Eventually I used fbterm instead but since then got back to a Linux console as some of our users need braille during installation and associated software need discrete characters, not images, as input.