Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: dnsmasq dependency on dbus? (Read 3363 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: dnsmasq dependency on dbus?

Reply #15 –
Quote from: dnkl – on
From a human perspective it does. But it has to execute X number of instructions to get there. This creates a small window where the process is running but the service hasn't fully started up. More or less all services have this problem.

So, it's a race; sometimes dnsmasq is started and tries to connect to dbus before it is accepting connections. Other times dbus wins the race.

PID-file based service managers are actually better off since they effectively let the services decide when they've started. Dbus, for example, can hold off with writing its PID-file until after it has started accepting connections.

Hmm, I thought s6's dependency management is supposed to magically solve this problem in a race-free way. Admittedly, I don't know how it really works

Re: dnsmasq dependency on dbus?

Reply #16 –
It might be possible to do something with s6's variant of socket activation, but I'm not familiar enough with s6 to say how, it if it even can be done.

Re: dnsmasq dependency on dbus?

Reply #18 –
Quote
s6 supports that mechanism natively: when the service directory for the daemon contains a valid notification-fd file, the daemon's supervisor, i.e. the s6-supervise program, will properly catch the daemon's message, update the status file (supervise/status), then notify all the subscribers with a 'U' event, meaning that the service is now up and ready.

Interesting. So it sounds like a patch doing that for dbus would completely solve the problem. Not sure how easy/difficult that would be of course.
 

Re: dnsmasq dependency on dbus?

Reply #19 –
Preliminary result: this looks like it was a lot easier than I had anticipated.

I'm piggybacking on dbus' --print-pid=fd option. I figured that it writes the PID to this fd at the same time it creates the PID file, which should be after it is done initializing.

For a "real" pipe (not stdout or stderr) it closes the fd right after writing to it (verified by strace:ing). Thereby fulfilling s6's requirements for a notification-fd.

So, here's what I did:

* Revert the dbus policy (i.e. only allow root)
* Added /etc/s6/sv/dbus/notification-fd, with the content '3'
* Added --print-pid=3 to /etc/s6/sv/dbus/run
* Added dbus as a dependency to dnsmasq

5-6 reboots later I haven't seen a single dbus connection failure.

Re: dnsmasq dependency on dbus?

Reply #20 –
Quote
* Revert the dbus policy (i.e. only allow root)
Note that I still thinks it is a good idea to have the dnsmasq user allowed in the policy since we are running as that user. I reverted it just to verify the notification-fd worked.

Re: dnsmasq dependency on dbus?

Reply #21 –
Quote from: dnkl – on
Preliminary result: this looks like it was a lot easier than I had anticipated.

I'm piggybacking on dbus' --print-pid=fd option. I figured that it writes the PID to this fd at the same time it creates the PID file, which should be after it is done initializing.

For a "real" pipe (not stdout or stderr) it closes the fd right after writing to it (verified by strace:ing). Thereby fulfilling s6's requirements for a notification-fd.

So, here's what I did:

* Revert the dbus policy (i.e. only allow root)
* Added /etc/s6/sv/dbus/notification-fd, with the content '3'
* Added --print-pid=3 to /etc/s6/sv/dbus/run
* Added dbus as a dependency to dnsmasq

5-6 reboots later I haven't seen a single dbus connection failure.

This is great! I didn't know dbus had such a handy option. Not only would dnsmasq benefit from this, but so does every other service that depends on dbus (which is quite a few of course). Doing this would make dnsmasq-s6 have a hard dependency on dbus-s6, but I think at this point, it's probably OK.