Skip to main content
Topic: Simulating systemd Type=dbus services (s6/dinit) (Read 664 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Simulating systemd Type=dbus services (s6/dinit)

systemd has a special service type that waits for the program to register itself on D-Bus before considering it ready (Type=dbus). For some packages, that's the only meaningful readiness information available, but s6 and dinit only support the simple "write newline to a fd" protocol. Therefore, in order to accurately translate these services, I needed a program that could wait until that happened, to then write the newline to the fd.

I found an old project laying around on GitHub called Unit2OpenRC that had a dbus-service-wait helper program that did the waiting part. To make it useful with s6, I'd need to write quite a bit of boilerplate in execline for every service so the waiting would be done in the background and a newline would be written after that. I made an extended version of the program that did just that without needing the execline script.

I forgot about it until last week when a dinit user on Telegram wanted help translating a Type=dbus systemd service. I polished it a bit further (fix help messages, etc.) and here it is, the extended version

To build:
Code: [Select]
git clone https://github.com/capezotte/dbus-service-wait && cd dbus-service-wait && ./build.sh

The resulting dbus-service-wait can be installed anywhere in your PATH.

To use it with s6 and dinit, for instance:
Code: [Select]
# Instead of the following 'run' file or 'command' variable
mako
# Write (dbus service name + executable), 3 is the notification-fd
dbus-service-wait -d3 org.freedesktop.Notifications mako

I hope it might be useful to you.



Runit doesn't have readiness notification so it can't really be used with it. Check the original project if you want something that can be used with OpenRC.

Re: Simulating systemd Type=dbus services (s6/dinit)

Reply #1
I was scrolling through davmac (dinit's dev) Mastodon and saw an announcement for a better implementation of this concept:

https://github.com/chimera-linux/dbus-wait-for

Compiling and installing (requires meson, which you likely already have if you use stuff from the AUR):

Code: [Select]
meson setup build && ninja -C build && sudo ninja -C build install

 It's far more robust — for instance, it actually checks if the PID that registered the name is the one being monitored by s6/dinit, optionally with cgroups if the init system has set them up.

Usage is similar:

Code: [Select]
# Instead of the following 'run' file or 'command' variable
mako
# Write -f (notification-fd) -n (dbus service name)
dbus-wait-for -f3 -norg.freedesktop.Notifications mako

Switching to it from my implementation is a simple sed:

Code: [Select]
sed -i -E 's!dbus-service-wait -d([0-9]) ([^ ]+)!dbus-wait-for -f\1 -n\2 --!' ~/.local/s6-rc/sv/*/run

(~/.local/s6-rc/sv/*/run script assumes you're using s6 — use ~/.config/dinit.d/* for dinit)

I'm archiving my GH repository, since this implementation is far better technically.

Re: Simulating systemd Type=dbus services (s6/dinit)

Reply #2
I use runit and dbus-wait-for seems a bit complex.

I looked in vain for a simple tool that would allow any shell script to test if a particular dbus endpoint is registered/ready.
It would allow a runit run script to check and either proceed or exit with an error. The runit standard process would retry after a delay.

I'm not an expert so perhaps that simple check is not easy or cannot be done without waiting.

I have no particular need for such a test, but perhaps others do.

 

Re: Simulating systemd Type=dbus services (s6/dinit)

Reply #3
I looked in vain for a simple tool that would allow any shell script to test if a particular dbus endpoint is registered/ready.

The dbus-service-wait I just archived can be used in this way if you give it a small timeout (at least, smaller than 7 seconds, which is the timeout of sv check) and don't ask it to run a program:

Code: [Select]
# -t = timeout in seconds
dbus-service-wait -t1 org.freedesktop.Notifications

While the repository is archived, this tool is likely to work for as long as D-Bus exists (the original was unmaintained for 5 years when I patched it, and I didn't have to change any of the core logic).

Quote
I'm not an expert so perhaps that simple check is not easy or cannot be done without waiting.

It can be checked without waiting, and with only standard dbus tools. It's not easy to type (or remember) though, and all the problems of constantly checking instead of instead of waiting apply.