The BOINC client core

Edit Package boinc-client

The Berkeley Open Infrastructure for Network Computing (BOINC) is an open-
source software platform which supports distributed computing, primarily in
the form of "volunteer" computing and "desktop Grid" computing. It is well
suited for problems which are often described as "trivially parallel". BOINC
is the underlying software used by projects such as SETI@home, Einstein@Home,
ClimatePrediciton.net, the World Community Grid, and many other distributed
computing projects.

This package installs the BOINC client software, which will allow your
computer to participate in one or more BOINC projects, using your spare
computer time to search for cures for diseases, model protein folding, study
global warming, discover sources of gravitational waves, and many other types
of scientific and mathematical research.

Refresh
Refresh
Source Files
Filename Size Changed
8.0.4.tar.gz 0046986206 44.8 MB
README.SUSE 0000005364 5.24 KB
_scmsync.obsinfo 0000000159 159 Bytes
boinc-client-rpmlintrc 0000000039 39 Bytes
boinc-client.changes 0000029059 28.4 KB
boinc-client.service 0000000842 842 Bytes
boinc-client.spec 0000011336 11.1 KB
boinc-docbook2x.patch 0000000900 900 Bytes
boinc-logrotate 0000000486 486 Bytes
boinc-manager 0000000221 221 Bytes
build-client-scripts.patch 0000000250 250 Bytes
build.specials.obscpio 0000000256 256 Bytes
libboinc-shared.patch 0000006971 6.81 KB
sysconfig.boinc-client 0000001510 1.47 KB
xlocale.patch 0000000470 470 Bytes
Latest Revision
Comments 12

Linus Kardell's avatar

Why did you break idle detection in this?


Jan Engelhardt's avatar

What kinda question is that... if you have a bug report to make, please do so upstream at https://github.com/BOINC/boinc .


Linus Kardell's avatar

No, this is something that was done deliberately in the OpenSUSE packages, it works fine in the upstream version.


Aaron Puchert's avatar

Idle detection was always broken. If you're running BOINC as a separate service, as openSUSE does it, it doesn't have access to your X server, and it will do nothing more than spam your logs (https://github.com/BOINC/boinc/issues/2256). Needless to say that it doesn't work on Wayland at all. That's why I proposed to disable it entirely in sr#626119.

Solving this doesn't seem trivial, which is why the upstream bug is almost three years old. My recommendation would be to go with exclusive applications or limits on CPU or memory usage for now.

Alternatively, solve the issue by finding a way to detect idleness without access to an X session.


Linus Kardell's avatar

It does work just fine, as long as you give Boinc access to the X server, except here the functionality has been patched out to very little benefit, with no alternative given. So now it will just refuse to work for no apparent reason even with the workarounds that work for the upstream version, and used to work with this version, leading to confusion. And you don't even mention this in the description. How about you find a way, if you're gonna patch out core functionality that works perfectly fine. As for limits, they do not work for GPU usage.


Aaron Puchert's avatar

You can certainly give BOINC access to the X server, but we're talking about a service that downloads random binaries from not-really-trusted sources and runs them, so I wouldn't recommend this.

Removing the "functionality" provides the benefit of not spamming the system log to the point of rendering it unusable. Which is something that people care about. Also people care about a computation daemon not depending on X libraries.

The biggest problem about the existing idle detection is that it's architecturally wrong. The right architecture is a process running under the X or Wayland session and its user that signals to BOINC from the outside if it should do work or not. Gladly people are working on that. But I think you know that, since you commented on the issue.

Could we reenable idle detection in its current sorry state? Yes, but it's fundamentally at odds with users who want more security, see e.g. #4105. At some point we will run into conflicts between strengthening the sandboxing of the service and the current idle detection. If that were a fundamental conflict I would be happy to discuss it, but since a proper design would both allow idle detection and be secure that discussion doesn't make sense.

If you want this to work, my best advice is to check in with Germano about the state of his efforts or help get them in yourself. Resurrecting this broken mess isn't going to help anyone in the long run.


Linus Kardell's avatar

Not saying it's ideal in the long run. It should certainly be replaced as soon as possible. But until then, this is the only option. So I guess until then I'll keep compiling it on my own.


Markus Elfring's avatar

Removing the "functionality" provides the benefit of not spamming the system log to the point of rendering it unusable. Which is something that people care about. Also people care about a computation daemon not depending on X libraries.

  • How do you think about any updates for these software dependencies?
  • Would you like to add any more technical background information?

Aaron Puchert's avatar

The issue that you've linked seems unrelated to idle detection, unless I'm missing something. And if you're using BOINC 7.25 as you wrote in the issue, you're probably not using this package here, which is at 7.24.1.

Apart from that, I don't really understand your questions. Not wanting boinc-client to depend on X libraries has nothing to do with whether they're up-to-date or not. You can find all technical background information in the issues linked above.


Markus Elfring's avatar

The issue that you've linked seems unrelated to idle detection,

Did you get an other impression from the software situation according to the message “Authorization required, but no authorization protocol specified” than the feedback by Vitalii Koshura on 2023-09-27?

unless I'm missing something.

Probably.

Apart from that, I don't really understand your questions.

I am trying to find solutions for undesirable software behaviour which I observed on my openSUSE Tumbleweed system.

Which source code generates the mentioned message?

Not wanting boinc-client to depend on X libraries has nothing to do with whether they're up-to-date or not.

Would you like to influence progress for the issue “redesign Linux idle detection”?

I added some debug output in used source files.

Thus I wonder still about another test result like the following.

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 [---] [gui_rpc] Listening on port 31416
-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 [---] [http] HTTP_OP::init_get(): https://boinc.berkeley.edu/project_list.php
-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 [---] CLIENT_STATE::start_cpu_benchmarks() finished
-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 [---] X_display_values_initialize() started
-Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] X_display_values_initialize() finished
-Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XScreenSaverAllocInfo() call
-Oct 02 08:31:04 Sonne boinc[9863]: 02-Oct-2023 08:31:04 [---] xss_idle() XScreenSaverAllocInfo() called
-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
…

How should the control flow evolve further here?


Markus Elfring's avatar

You can find all technical background information in the issues linked above.

How do you think about to compare software run time characteristics for the following code variant?

#if HAVE_XSS
// …
long xss_idle() {
#if 1
    msg_printf(NULL, MSG_INFO, "xss_idle() Skip detection");
    return true;
#else
    // …
    return idle_time;
#endif
}
#endif // HAVE_XSS

A corresponding test result looks promising.

Markus_Elfring@Sonne:/var/lib/boinc> /usr/local/bin/boinccmd --client_version
…
Client version: 7.25.0

Will any development ideas become more appealing (so that undesirable communication blockages will also be reconsidered accordingly)?


Markus Elfring's avatar

Apart from that, I don't really understand your questions.

I am curious how another clarification approach will evolve.

openSUSE Build Service is sponsored by