[Bug 1215872] New: Checking run time characteristics of the function call “XOpenDisplay(":0")” (by service implementations)
https://bugzilla.suse.com/show_bug.cgi?id=1215872 Bug ID: 1215872 Summary: Checking run time characteristics of the function call “XOpenDisplay(":0")” (by service implementations) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs@suse.de Reporter: Markus.Elfring@web.de QA Contact: gfx-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- I could run the service “boinc-client” (which was derived from a corresponding software package) for a while as usual. I noticed then that I could not control it by the application “BOINC Manager” any more. See also: BOINC Manager interface shouldn't fully block user interaction when in communicating with client dialog https://github.com/BOINC/boinc/issues/4048#issuecomment-1712562997 I noticed then that the program “boinccmd” did also not present expected data processing results. Thus I extended exception handling and debug output in original source files so that my understanding of the involved control flow could grow. I determined that it was tried to call the function “XOpenDisplay(":0")”. See also: https://build.opensuse.org/package/show/openSUSE%3AFactory/boinc-client#comm... https://github.com/BOINC/boinc/blob/44295c1a50d84e44992d97b9e949700d3b9af2d1... Test result example: Sonne:~ # systemctl start boinc-client-variant.service && sleep 2 && systemctl stop boinc-client-variant.service Sonne:~ # XX=/tmp/boinc_log-one_day.txt && YY=/tmp/boinc_log-one_day-only_with_Authorization_required.txt && journalctl --since=today --identifier=boinc > $XX && journalctl --since=today --identifier=boinc --grep='Authorization required' > $YY && diff --unified=1 $XX $YY … @@ -118836,69 +118764,2 @@ … -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] Starting BOINC client version 7.25.0 for x86_64-suse-linux-gnu -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] This a development version of BOINC and may not function properly -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] log flags: file_xfer, sched_ops, task, benchmark_debug, cpu_sched_debug, gui_rpc_debug -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] log flags: http_debug, http_xfer_debug, idle_detection_debug, network_status_debug -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] log flags: poll_debug, work_fetch_debug … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] Setting up GUI RPC socket -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] [gui_rpc] Local control only allowed … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] Checking presence of 133 project files … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 Initialization completed -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] CLIENT_STATE::poll_slow_events() started -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] Running CPU benchmarks … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] HOST_INFO::user_idle_time() started -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() started … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XOpenDisplay(:0) call Oct 02 08:31:04 Sonne boinc[9863]: Authorization required, but no authorization protocol specified … I got the impression finally that a return from this function call did not happen here so far while the shown error message was logged with a remarkable frequency. Would you like to reconsider function implementation details any more? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c4 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net --- Comment #4 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Markus Elfring from comment #0)
Thus I extended exception handling and debug output in original source files so that my understanding of the involved control flow could grow. I determined that it was tried to call the function “XOpenDisplay(":0")”. [...] -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] HOST_INFO::user_idle_time() started -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() started … -Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XOpenDisplay(:0) call
Here you differ from the package though. XOpenDisplay is part of libX11, and the packaged client no longer links with that since sr#626119 [1]. The manager links with it, but that's a different program: $ ldd /usr/bin/boinc-client | grep libX11 $ ldd /usr/bin/boinc-gui | grep libX11 libX11.so.6 => /lib64/libX11.so.6 ([...]) If you want to do the same for your build, you have to either remove the package libXScrnSaver-devel, or configure with --without-x. The log should say that "X ScreenSaver user idle detection" is disabled. Other than that, we can not help you if you don't describe the issue:
I noticed then that I could not control it by the application “BOINC Manager” any more.
Why can you not control it any longer? What exactly happened? Start at the beginning, not at the end. My understanding is that XSS idle detection, especially if it doesn't work, should not block, so it's probably just an unrelated warning. [1] https://build.opensuse.org/request/show/626119 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c5 --- Comment #5 from Markus Elfring <Markus.Elfring@web.de> --- (In reply to Jan Engelhardt from comment #3)
Thus I extended exception handling and debug output in original source files -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] Starting BOINC client version 7.25.0 for x86_64-suse-linux-gnu -Oct 02 08:31:02 Sonne boinc[9863]: 02-Oct-2023 08:31:02 [---] This a development version of BOINC and may not function properly
openSUSE:Factory and develprj have v7.24.1
This is one known software combination.
and you are running something completely different and custom.
I would like to try further software combinations out. They can use also my adjustments then.
-Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XOpenDisplay(:0) call Oct 02 08:31:04 Sonne boinc[9863]: Authorization required, but no authorization protocol specified
/usr/bin/boinc runs as a separate identity and as a daemon. It has no access to /home and thus, in general, cannot read Xauthority files.
Which software behaviour would you expect for the mentioned function call? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c6 --- Comment #6 from Markus Elfring <Markus.Elfring@web.de> --- (In reply to Aaron Puchert from comment #4)
-Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XOpenDisplay(:0) call
Here you differ from the package though.
Yes, of course.
XOpenDisplay is part of libX11,
Yes.
and the packaged client no longer links with that since sr#626119 [1].
Thanks for this background information (from 2018-07-29). https://build.opensuse.org/request/show/626119
The manager links with it, but that's a different program:
It is interesting how the involved software dependencies were separated.
If you want to do the same for your build,
It depends …
you have to either remove the package libXScrnSaver-devel,
Would you like to refer to the name “libXss-devel” instead? Are there any reasons to keep this package occasionally installed because of other software development attempts?
or configure with --without-x.
How do you think about further constraints for such a build configuration option?
Other than that, we can not help you if you don't describe the issue:
It seems that you missed an opportunity to take a linked information source better into account. https://github.com/BOINC/boinc/issues/4048#issuecomment-1712562997
My understanding is that XSS idle detection, especially if it doesn't work, should not block,
I observed special software behaviour. Can it be reproduced by any other interested system testers?
so it's probably just an unrelated warning.
Would anybody like to point the source file out which contains the discussed message? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c7 --- Comment #7 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Markus Elfring from comment #6)
you have to either remove the package libXScrnSaver-devel,
Would you like to refer to the name “libXss-devel” instead?
Correct, I wasn't aware that libXScrnSaver-devel is just an alias for that.
Are there any reasons to keep this package occasionally installed because of other software development attempts?
Likely not, but it's up to you. The configuration option should also work.
or configure with --without-x.
How do you think about further constraints for such a build configuration option?
What kind of constraints? And why should I think about them?
Other than that, we can not help you if you don't describe the issue:
It seems that you missed an opportunity to take a linked information source better into account. https://github.com/BOINC/boinc/issues/4048#issuecomment-1712562997
There you write:
I wonder […] which circumstances hinder to present my BOINC project selection
You're describing your thought process, but we need a description of the program behavior on the screen. What do you see?
so it's probably just an unrelated warning.
Would anybody like to point the source file out which contains the discussed message?
Do you mean "Authorization required, but no authorization protocol specified"? Then https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/os/auth.c has it. But I'm not sure if this will help you. XSS idle detection should not block, and it's not active in the package. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c8 --- Comment #8 from Markus Elfring <Markus.Elfring@web.de> --- (In reply to Aaron Puchert from comment #7)
What kind of constraints?
It seems that you would like to concentrate on provided software packages which were generated from commands of a known RPM file format. https://build.opensuse.org/package/view_file/openSUSE:Factory/boinc-client/b...
And why should I think about them?
I would occasionally like to use an other development repository directly.
You're describing your thought process, but we need a description of the program behavior on the screen.
Reminder: I added my application concern within the context of an existing issue.
What do you see?
Repetition: I saw the German message “Kommuniziere mit dem BOINC Client. Bitte warten ...” within a modal dialogue which was similar to the English message that was shown also in a screenshot from Austin Conlon on 2020-10-05. See also: https://github.com/BOINC/boinc/blob/44295c1a50d84e44992d97b9e949700d3b9af2d1...
Do you mean "Authorization …"?
Obviously, yes.
But I'm not sure if this will help you.
How do you think about to inspect the control flow between the called functions “XOpenDisplay” and “CheckAuthorization” any further? https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/c745719e23af44a4b40ab4... https://gitlab.freedesktop.org/xorg/xserver/-/blob/722e464bffdcfc7c4beb00e09... Would you find a loop which would hinder the return of a null pointer?
XSS idle detection should not block,
This is a reasonable expectation. I came along other observations.
and it's not active in the package.
It can eventually be relevant for development software variations. The understanding is still incomplete for the presented function call trace. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c9 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Checking run time |Cannot communicate with |characteristics of the |BOINC client (possibly |function call |related to XSS idle |“XOpenDisplay(":0")” (by |detection) |service implementations) | --- Comment #9 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- Sorry for the late reply. (In reply to Markus Elfring from comment #8)
I would occasionally like to use an other development repository directly.
Understood, but then you're on your own, or have to discuss with the owner of that repository.
Repetition: I saw the German message “Kommuniziere mit dem BOINC Client. Bitte warten ...” within a modal dialogue which was similar to the English message that was shown also in a screenshot from Austin Conlon on 2020-10-05.
So the actual issue is not necessarily related to idle detection. That this doesn't work, as indicated by the log messages, might be unrelated to the failure to communicate.
But I'm not sure if this will help you.
How do you think about to inspect the control flow between the called functions “XOpenDisplay” and “CheckAuthorization” any further? https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/ c745719e23af44a4b40ab4508447637b35d91a1e/src/OpenDis.c#L60 https://gitlab.freedesktop.org/xorg/xserver/-/blob/ 722e464bffdcfc7c4beb00e0995c105bc431d0d4/os/auth.c#L164
Would you find a loop which would hinder the return of a null pointer?
You could certainly try in a debugger, or index the code base and go through the call graph manually. But for now I don't think we have enough information to be sure that is your problem.
XSS idle detection should not block,
This is a reasonable expectation. I came along other observations.
Did you actually observe such a call being stuck? I didn't see any indication of that. And if it gets stuck, where? If there is no progress with ~100% CPU, a profile might be interesting, with ~0% CPU something offcputime from bcc-tools should help. Just guessing based on the log won't get us there.
[XSS idle detection] can eventually be relevant for development software variations.
But not for the package that we're going to ship. If we're going to ship idle detection again, it will have a service running under the logged-in user that communicates the idle state to the BOINC client, and that ideally works with Wayland as well. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1215872 https://bugzilla.suse.com/show_bug.cgi?id=1215872#c10 Markus Elfring <Markus.Elfring@web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Cannot communicate with |Checking run time |BOINC client (possibly |characteristics of the |related to XSS idle |function call |detection) |“XOpenDisplay(":0")” (by | |service implementations) --- Comment #10 from Markus Elfring <Markus.Elfring@web.de> --- (In reply to Aaron Puchert from comment #9)
…, or have to discuss with the owner of that repository.
I obviously tried to clarify involved technical details for a while accordingly.
So the actual issue is not necessarily related to idle detection. That this doesn't work, as indicated by the log messages, might be unrelated to the failure to communicate.
Please take another look at published information.
Did you actually observe such a call being stuck?
Yes. - I got such an impression from added debug output.
XSS idle detection can eventually be relevant for development software variations.
But not for the package that we're going to ship. If we're going to ship idle detection again, it will have a service running under the logged-in user that communicates the idle state to the BOINC client, and that ideally works with Wayland as well.
I am curious which software design options will be taken better into account here. Would you like to influence any progress on the topic “redesign Linux idle detection”? https://github.com/BOINC/boinc/issues/5226 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com