Upgrading to BOINC 7.18.1 (from LoctusOfBorg, ppa:costamagnagianfranco/boinc) caused rapid invalids on my Ryzen 3600 under Ubuntu 20.04.3.
But BOINC 7.16.6 (from Ubuntu Software) and 7.16.17 (the previous version from LOB) work OK.

(But there is a new build of 7.18.1 on LOB. I have not tried it.)

Why would one choose to run this version instead of the one in the Linux repository?

Why would one choose to run this version instead of the one in the Linux repository?

It is the latest one in the development release (LocutusOfBorg) repository.
https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/boinc
Sometimes they fix problems. Sometimes they cause them.

Hey, Jim1348! Nice to meet you. We was talking five months ago about, I think, the same issue.

Sebastien provided a solution and now I think we know the root cause. I copy/paste here what I think important:

To fix this issue, I edited the file /lib/systemd/system/boinc-client.service and replaced ProtectSystem=strict by ProtectSystem=full

systemctl stop boinc-client
sed -i 's/ProtectSystem=strict/ProtectSystem=full/g' /lib/systemd/system/boinc-client.service
systemctl daemon-reload
systemctl start boinc-client

Reading the systemd.exec man page I saw it is recommended, due to security measures, to use the strict parameter, and also that that parameter was introduced in 2016. The distinct Linux distributions are incorporating the recomendations, and if the project of Boinc you want to run tries to store data in a path not authorized by the "strict" parameter, the app fails. So the issue finally depends on the systemd version, the Boinc version and the project you are executing.

Thank you YAG. That looks like the secure way to do it.
I am back to BOINC 7.16.6. Maybe the new Ubuntu 20.04.4 will incorporate the fix?

I do not know. I am a Debian 11 user. I am afraid future linux distributions will use the strict mode and will expect that the several projects will update their apps for using only authorized paths.

I do not know. I am a Debian 11 user. I am afraid future linux distributions will use the strict mode and will expect that the several projects will update their apps for using only authorized paths.

I installed Ubuntu 20.04.4, and it still downloads BOINC 7.16.6 from the Ubuntu Software center. They are probably giving the projects more time to make their stuff compatible.
But it looks like it is coming.

I am using BOINC 7.18.1 on my Linux Virtual Machine running OpenSUSE Tumbleweed, and nwchem runs fine. Since the Tunbleweed kernel is frequently updated and I have to reboot, a message comes out that 7.18.1 is a development version and could cause errrors.
Tullio

---

I have 2 hosts on Debian 11, where one (#10506) works fine and the other (#10563) returns invalid workunits after ~3 seconds. Looks like the difference came down to the BOINC client's systemd service file. 10506 has "PrivateTmp=true" whereas 10563 has "#PrivateTmp=true #Block X11 idle detection". Everything else in the file is the same, including "ProtectSystem=strict". After changing 10563 to use PrivateTmp, it has started returning valid results.

Just checked the boinc-client packages on Debian today. Only 7.16.17+dfsg-2 (no longer available for amd64) included a service file that uses PrivateTmp. The other recent versions (7.16.16+dfsg-1, 7.18.1+dfsg-4) have it commented out and the old version (7.14.2+dfsg-3) doesn't even have that line.

EDIT: Looks like PrivateTmp was commented out to fix idle detection (issue, pull request). Apparently other projects have similar issues. It seems the long-term fix is for the QuChem program to write to the slot folder instead of /tmp.

I've just installed Ubuntu 22.04 on a VM under VirtualBox (MacOS). The version of BOINC in the repository is now 7.18.1, which still fails on security, and can still be fixed by the instructions below, plus judicious security liberation on /var/lib/boinc-client. For the time being, it still means manual start of the daemon after a reboot, but that's live-able with for the time being.

Will report if I suffer invalid workunits.

---

I am using BOINC 7.18.1 on a Linux Virtual Machine running SuSE Tumbleweed, a development version of Linux updated very frequently. Now its kernel is 5.17.4. When the kernel is updted I have to reboot after installing it. It is running Einstein@home and QuChemPedIA@home. When rebooted it warns that 7.18.1 is a development version and might not work, but it does.
Tullio

---

any news?

for now only QuChemPedIA have issues, all other projects doing good

any news?

for now only QuChemPedIA have issues, all other projects doing good

The Rosetta/Pythons also don't work. They won't even start up.
I tried upgrading to BOINC 7.20.2 and get the same result. That is because it isn't a bug in BOINC, just a new security requirement.
I think all writes have to go to the slots folder, not a tmp folder. Not all projects are up to speed on it yet.

I don't recall if I tried it on Cosmology, but it is a VirtualBox project, and has not been updated for some time. I doubt that the new BOINC works there either.