[systemd-devel] StartupFinished signal is not sent on 210

[Umut Tezduyar Lindskog]

Hi,

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: den 4 mars 2014 22:00
> To: Umut Tezduyar
> Cc: Umut Tezduyar Lindskog; systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] StartupFinished signal is not sent on 210
> 
> On Tue, 04.03.14 21:40, Umut Tezduyar (umut at tezduyar.com) wrote:
> 
> > >> To compare 208 and 210, I pretty much followed steps @
> > >> https://wiki.ubuntu.com/DebuggingDBus and by using $> dbus-monitor
> > >> "type=signal,sender='org.freedesktop.systemd1'" --system
> > >
> > > You have to invoke "Subscribe()" first on the manager bus, to get
> > > something. We only send out the messages as long as at least one
> > > living client has issued this call.
> >
> > Don't you think this is something worth mentioning in the NEWS since
> > we were able to retrieve signals without subscribing to them on 208.
> > Excuse me if it is documented somewhere and I missed it.
> 
> Subscribe() is actually around since day #1 of systemd. And it is documented
> here:
> 
> http://www.freedesktop.org/wiki/Software/systemd/dbus/
> 
> Of course, I must admit it is less than ideal that with logind around you might
> be able to get away with never calling it... That certainly hides bugs...

We don't have logind and we certainly weren't calling Subscribe(). Then I can't explain how come we were receiving the signal, can you? Could it be that one of systemd applications was subscribing and we were just lucky to get the signal?

> 
> We changed a couple of times how systemd delivers those signals during the
> history, but clients which called Subscribed() should always just have worked.
> 
> Note that 211 actually changes things back to be more like < 209...
> 
> The difference between < 209 + > 210 and 209+210 is the single subscriber
> case. With < 209 + > 210 we have the following rule:
> 
> 1. when there's no subscriber we don't send out any signals 2. when there's
> one or more subscribers we broadcast signals to everybody
> 
> In 209+210 we had this ruleset instead:
> 
> 1. when there's no subscriber we don't send out any signals 2. when there's
> one subscriber send all signals as unicast to it 3. when there's two or more
> subscribers we broadcast signals to everybody
> 
> I thought for a while that doing step #2 was smart, but then again, it's kinda
> stupid, since it second guesses the dbus filter logic too much, and the
> messages look different to the receiver depending on the number of other
> subscribers. So I dropped this again...
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat