I could run the service “boinc-client” for a while as usual.
I noticed then that I could not control it by the application “BOINC Manager” any more on my openSUSE Tumbleweed system.

See also:
BOINC Manager interface shouldn't fully block user interaction when in communicating with client dialog

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 a related clarification approach.

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?

Markus was referred to this message board from Github, where he joined a rwo-year-old conversation started by someone else. We had a long conversation, involving several developers, but we failed to solve his problem - largely because Markus was reluctant to supply any hard data, such as Event Logs and system configuration, which might help us to diagnose the cause of the problem he's experiencing.

I got as far as this:

As @CharlieFenton said, error -102 is a file read error.

That points to a problem with the file location, ownership, or permissions. Failure to comply with BOINC's security model is a user or distribution problem, not a coding issue.

As far as I can tell, the file in question is 'gui_rpc_auth.cfg', which contains the password required for client RPC authentication - but that's my interpretation, not Markus'.

For a client RPC to work,

• There has to be a password
  
• The client must be listening for that password
  
• The password is only read at startup - you can't add or change it after the client has already started running
  
• The calling program, whether BOINC Manager or boinccmd, has to supply a matching password
  
• If the password is to be read from that file for automatic use, then the system has to be accessing the right location, and have the right permissions set.
  

If Marcus can explain how he's enabled each of those conditions, we can explore further.
-------------
Since the conversation on GitHub fizzled out, I've my own battle with a Linux installation which was returning 'Authorization failure -155'.

I'd used a script in Terminal to invoke boinccmd. It worked under Linux Mint 20, but failed after an upgrade to Linux Mint 21. It turned out after experimentation that the script worked if I started my script in /hdd/boinc-client (my choice of BOINC data directory), but not in the location I'd used previously. I hope that shows how BOINC problem-solving can sometimes take unexpected twists, and can require full clarity of the whole system environment.

We had a long conversation, involving several developers, but we failed to solve his problem - largely because Markus was reluctant to supply any hard data, such as Event Logs and system configuration, which might help us to diagnose the cause of the problem he's experiencing.

How much information do you understand from the wording variant for this development topic so far?

As far as I can tell, the file in question is 'gui_rpc_auth.cfg', which contains the password required for client RPC authentication - but that's my interpretation, not Markus'.

This software area can usually work in the way it is documented.

If Marcus can explain how he's enabled each of those conditions, we can explore further.

More useful data processing can be performed if the questionable technique “Linux idle detection” is skipped (or temporarily disabled) also in my test environment.

It turned out after experimentation that the script worked if I started my script in /hdd/boinc-client (my choice of BOINC data directory), but not in the location I'd used previously.

Yes, it's the same under Windows. You have to start the parts of BOINC in the directory they're in, not from another directory, while linking to it with a full path. I think it will work if you add both of the directory's paths to the %PATH% environment variable.