Re: [systemd-devel] StartupFinished signal is not sent on 210
Hi, -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: den 4 mars 2014 22:00 To: Umut Tezduyar Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] StartupFinished signal is not sent on 210 On Tue, 04.03.14 21:40, Umut Tezduyar (u...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartupFinished signal is not sent on 210
On Wed, 05.03.14 09:07, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: 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? machined and logind are the only ones in the systemd tree that call it currently. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] StartupFinished signal is not sent on 210
Hi, I have noticed systemd doesn't generate the StartupFinished dbus signal on 210 (probably 209 too). The code tells me we are generating the signal on all private connection and on api bus if we have client connected. if we have client connected statement is not clear to me. Have we change the behavior or is this a bug? I tried to make a private connection and tried to receive the signal with $ busctl --address=unix:path=/run/systemd/private monitor But that didn't work. 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 Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartupFinished signal is not sent on 210
On Tue, 04.03.14 14:12, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Hi, I have noticed systemd doesn't generate the StartupFinished dbus signal on 210 (probably 209 too). The code tells me we are generating the signal on all private connection and on api bus if we have client connected. if we have client connected statement is not clear to me. Have we change the behavior or is this a bug? I tried to make a private connection and tried to receive the signal with $ busctl --address=unix:path=/run/systemd/private monitor But that didn't work. 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. (Note that on normal desktops logind issues the call, so you might get away with not invoking it, but this will break in early boot and on systems without logind) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartupFinished signal is not sent on 210
Hi On Tue, Mar 4, 2014 at 8:55 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 04.03.14 14:12, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Hi, I have noticed systemd doesn't generate the StartupFinished dbus signal on 210 (probably 209 too). The code tells me we are generating the signal on all private connection and on api bus if we have client connected. if we have client connected statement is not clear to me. Have we change the behavior or is this a bug? I tried to make a private connection and tried to receive the signal with $ busctl --address=unix:path=/run/systemd/private monitor But that didn't work. 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. (Note that on normal desktops logind issues the call, so you might get away with not invoking it, but this will break in early boot and on systems without logind) We are embedded system without session bus (or logind). We listen on this signal and translate it to our internal event system. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartupFinished signal is not sent on 210
On Tue, 04.03.14 21:40, Umut Tezduyar (u...@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 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
