Nice conversation here on (water) cooling but completely off topic in this thread. Please start a thread outside this one on the subject and I'll happily move your earlier posts over. But for the topic, let's go back to sprzyswa and his problem(s).

BOINC (the program) is highly unlikely to stress "4 CPUs are at more than 90% load", except for 60 seconds or less at startup during benchmarking. That level of CPU activity is more likely to be attributable to one or more science projects, running under the direction of BOINC. We haven't discussed projects yet in this thread.

An additional idea that came in my mind.

One of the first tests the BOINC client does is to launch a subprocess that checks the GPU capabilities.
If the system uses a wrong or somehow broken GPU driver this may be a possible source for the trouble.

Could be tested starting BOINC without GPU support.
See options "<ignore_ati_dev>N</ignore_ati_dev>" ... "ignore_nvidia_dev>N</ignore_nvidia_dev>":
https://boinc.berkeley.edu/wiki/Client_configuration

A (very long) while ago I had a power outage due to a heavy thunderstorm.
After that all my machines rebooted and seemed to work fine for a couple of weeks.
Then, as of a sudden, 1 machine crashed (rebooted) every time BOINC started a GPU task.

I finally could trace the error down to a corrupted filesystem (multiple sector allocation on the harddisk).
The solution was to
- backup all data
- reformat the disk
- restore all data
- force a reinstall of the OS, drivers and all applications

Since then the machine runs fine again.

You know you can run BOINC without VirtualBox. Its only needed if the project in question only have that type of work unit. I'm still crunching for Rosetta although they have a "rosetta python projects" which uses vbox. I'm running their normal CPU work units only. VirtualBox allows you to run virtual machines. In the case of the various BOINC projects they supply work units which are a VM image.

The Linux versions of BOINC don't keep an old version of stdoutdae around. They use the standard Linux way of doing things. You can view the log by doing a "sudo journalctl --unit=boinc-client" command in a terminal or ssh session. The journal entries can go back quite some time (I have some from Sept 2021 on one machine).

As for directory naming on Raspberry Pi OS, they are following the Debian standard. Debian used to use /var/lib/boinc-client and other Linux distros use /var/lib/boinc. The later BOINC releases have both folders and a symlink from /var/lib/boinc to /var/lib/boinc-client so they are basically the same directory.

You know you can run BOINC without VirtualBox. Its only needed if the project in question only have that type of work unit. I'm still crunching for Rosetta although they have a "rosetta python projects" which uses vbox. I'm running their normal CPU work units only. VirtualBox allows you to run virtual machines. In the case of the various BOINC projects they supply work units which are a VM image.

The Linux versions of BOINC don't keep an old version of stdoutdae around. They use the standard Linux way of doing things. You can view the log by doing a "sudo journalctl --unit=boinc-client" command in a terminal or ssh session. The journal entries can go back quite some time (I have some from Sept 2021 on one machine).

As for directory naming on Raspberry Pi OS, they are following the Debian standard. Debian used to use /var/lib/boinc-client and other Linux distros use /var/lib/boinc. The later BOINC releases have both folders and a symlink from /var/lib/boinc to /var/lib/boinc-client so they are basically the same directory.

The log history for Linux systemd installations is kept in the system journal.

Mar 30 00:00:48 jupiter boinc[11481]: dir_open: Could not open directory 'locale' from '/var/lib/boinc-client'.

You should have the Log backup file stdoutdae.old in your /var/lib/boinc-client directory

You shouldn't need to do anything like that, as with each change of project applications are swapped out of memory and new ones start. At least at the default setting of "Leave applications in memory" set to No.

Even applications within the same project, when tasks end and new ones start, they do so with their own science application, leaving memory and starting anew.

You shouldn't need to do anything like that, as with each change of project applications are swapped out of memory and new ones start. At least at the default setting of "Leave applications in memory" set to No.

Even applications within the same project, when tasks end and new ones start, they do so with their own science application, leaving memory and starting anew.

You shouldn't need to do anything like that, as with each change of project applications are swapped out of memory and new ones start. At least at the default setting of "Leave applications in memory" set to No.

Even applications within the same project, when tasks end and new ones start, they do so with their own science application, leaving memory and starting anew.

Because that exits the tasks out of memory and restarts them, possibly from the beginning.

What is your setup for Atlas tasks? How many CPU cores are you using per task? This can be setup on LHC web site or by an app_config.xml. Are you using VirtualBox or are you running Atlas tasks as native linux tasks? On LHC website project preferences you can also limit how many tasks you have on your computer at one time. On Boinc preferences (locally with Boinc manager or on project website) you can limit how many CPU cores you allow Boinc to use at any time.