Closed xvitaly closed 3 years ago
dvdhrm
commented
3 years ago Hi
Can you please include all the relevant information in your bug report? In particular, I am missing a description of the bug. Also, what is it that you want fixed? Why do you believe it needs to be fixed in dbus-broker?
Thanks David
xvitaly
commented
3 years ago Can you please include all the relevant information in your bug report? In particular, I am missing a description of the bug.
Dbus-broker hangs (stops responding) on logout and breaks new logins for the same user.
Why do you believe it needs to be fixed in dbus-broker?
Switching to another Dbus implementation (dbus-daemon) fixes logout issues for me.
benzea
commented
3 years ago Having been involved with the upstream bug, I do agree with your comment there that there is probably no dbus-broker specific issue.
That said, it would make sense to either have the equivalent of systemctl --user reset for dbus to reset pending activations. Or for dbus (both dbus-broker and dbus-daemon) to always try to activate the systemd service and let systemd handle repeated requests instead of only sending the request once to systemd.
dvdhrm
commented
3 years ago Having been involved with the upstream bug, I do agree with your comment there that there is probably no dbus-broker specific issue.
That said, it would make sense to either have the equivalent of
systemctl --user resetfor dbus to reset pending activations. Or for dbus (both dbus-broker and dbus-daemon) to always try to activate the systemd service and let systemd handle repeated requests instead of only sending the request once to systemd.
Yeah, I am following the bug since the beginning (as you noticed). I do not believe that there is any particular bug in dbus-broker that needs to be fixed, nor do I think there is a behavioral difference between dbus-broker and dbus-daemon, that would affect this bug. But I can be wrong, and I am aware that things might pop up, where dbus-broker needs to adapt.
However, I do not appreciate how this GH-issue is reported, nor do I believe that I am taken seriously. I expect upstream bug reports to include all the information necessary, to describe in detail what behavior is believed to be the issue, how exactly the behavior was observed and diagnosed, and what the expected result should be. In particular, I expected this issue to include what hangs or stops responding means, because there has been no clue about this whatsoever in the downstream bug report. The entire discussions talks about the session hanging or lingering, and I particularly doubt that dbus-broker actually stops responding, in whatever sensible way I can interpret that. If an issue is opened for cross-referencing, to raise awareness, or to just keep track, this is fine, if stated explicitly.
I am closing this issue. I will continue to track the downstream bug, I do respond to every question directly addressed to me, and I will continue to speak up when I have valuable insights. But I do not appreciate the tone this bug-report was opened in by the reporter. I do not appreciate the lack of information, their unwillingness to interact with me, and the complete lack of self-doubt of the reporter ("This bug is definitely related to dbus-broker, not sddm.", "The real solution is to get rid of the buggy dbus-broker.").
If you want the dbus-broker developers to investigate this, please open a new report with relevant information attached, and with an attitude that values our time. Thanks. David
Dbus-broker hangs on Fedora 33 (with KDE Plasma 5) logout.
Downstream bug report with useful debug information and logs: https://bugzilla.redhat.com/show_bug.cgi?id=1861700
Can be easily reproduced from Fedora 33 KDE LiveCD ISO.
Steps to reproduce:
Looks similar to #205.