In reply to Laurence's message of 2 Feb 2026:

CVMFS_REPOSITORIES="atlas,atlas-condb,grid,cernvm-prod,sft,alice"

Maybe you are missing cernvm-prod

The nut to crack was the missing mount of cvmfs-config.cern.ch to CVMFS.
Unfortunately no one has point out that this is necessary now.
Because of my system I have to register all the mounts manually to the automounter.

For now I have done my first Theory-docker wu.
Thank you Laurence

Docker container runs fine over here, but at the end all tasks fail:

Wed 04 Feb 2026 11:23:34 AM CET | LHC@home | [error] Can't rename output file slots/3/shared/output.tgz to projects/lhcathome.cern.ch_lhcathome/Theory_2922-4838179-486_0_r1805586945_result: rename() failed
Wed 04 Feb 2026 11:23:34 AM CET | LHC@home | Computation for task Theory_2922-4838179-486_0 finished
Wed 04 Feb 2026 11:23:34 AM CET | LHC@home | Output file Theory_2922-4838179-486_0_r1805586945_result for task Theory_2922-4838179-486_0 absent

Is it an issue on my side?

Did likely have the same problem with Docker on Arch linux(final steps fail and on the LHC website no Stderr output)

https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=6438&postid=52901

Not sure why docker did not work but Podman with linger enabled works fine with multiple tasks finished successfully.

Theory-docker tasks run fine now.
But run-time and cpu-time are far from realistic!

Podman runs ok,
On my side not with lingering but containers switched to cgroupfs

cgroup_manager = "cgroupfs"

In reply to Saturn911's message of 4 Feb 2026:

Theory-docker tasks run fine now.
But run-time and cpu-time are far from realistic!

The run-time is realistic. Don't look at BOINC Manager's "Remaining (estimated)" time. That was and will always be way off, because Theory tasks have a wide variaty of runtimes.
Cpu-time: For a lot of systems that time is multiplied with the number of host cores. That bug is fixed in the next version of docker_wrapper.

I posted to the BOINC forum if its even possibale to use systemd. I have not found a way to make it work.

I don't need linger with cgroupfs, systemd & linger does not work for me.

In reply to Toby Broom's message of 4 Feb 2026:

systemd & linger does not work for me.

+1

While using systemd with Gentoo, I'd always get this error:

error running container: from /usr/bin/crun creating container for [/bin/sh -c dnf install -y https://cvmrepo.s3.cern.ch/cvmrepo/yum/cvmfs-release-latest.noarch.rpm && dnf install -y epel-release && dnf install -y libxcrypt-compat bc bzip2 lighttpd procps-ng make gcc which cvmfs bind-utils netcat zlib-devel compat-openssl11 freetype && dnf clean all]: sd-bus call: Access denied as the requested operation requires interactive authentication. However, interactive authentication has not been enabled by the calling program.: Permission denied
: exit status 1

I've found that this formula works with systemd and rootless podman. If you setup a user level podman service and podman socket in the regular account you want to use for boinc and then run your boinc client thru that user account, the podman app works with boinc.

systemctl --user enable podman.socket podman.service

systemctl --user start podman.socket podman.service

Then start boincmgr in your desired directory in the regular user account you're using. Because it's a regular user and not the "boinc" service user, it has a proper $XDG directory structure set up to run the containers using the user privileges from your regular user account. It even stopped complaining about falling back to --cgroup-manager=cgroupfs. Just remember to give your regular user account subuids and subgids.

I will note that I don't have to set up the boinc client this way with BOINC-Central@home. It can run podman thru the BOINC service daemon.

In reply to Saturn911's message of 4 Feb 2026:

In reply to Toby Broom's message of 4 Feb 2026:

systemd & linger does not work for me.

+1

I second that

I tried to create the $XDG directory structure for the "boinc" service user but I ended up breaking the whole install of boinc/podman that boinc didn't recognise that podman was installed anymore so it need a better linux sysadmin than me to workout how to do for the service account.

got a couple that failed with this:

Error: unable to start container "9fe003afd41f15ffa5b388dfb5ea974d68f1fbf8091238bd7d852f5f36831776": pasta failed with exit code 1:
Failed to bind port 52051 (Address already in use) for option '-t 52051-52051:80-80'

if you run 10 dockers at once then you might need a bigger pool of adresses?

In reply to Toby Broom's message of 13 Mar 2026:

if you run 10 dockers at once then you might need a bigger pool of adresses?

Maybe even with 8

Have three Theory(docker) from yesterday 5 UTC waiting for success.

In reply to maeax's message of 16 Mar 2026:

Have three Theory(docker) from yesterday 5 UTC waiting for success.

+1 Theory Simulation 302.10 (docker)
14/03/2026 10:30:34 | | Starting BOINC client version 8.2.8 for windows_x86_64
14/03/2026 10:30:43 | | Usable WSL distros:
14/03/2026 10:30:43 | | - boinc-buda-runner (WSL 2) (default)
14/03/2026 10:30:43 | | - OS: Alpine Linux (Alpine Linux v3.22)
14/03/2026 10:30:43 | | - Docker version 5.6.2 (podman)
14/03/2026 10:30:43 | | - BOINC WSL distro version 4
14/03/2026 10:30:43 | | VirtualBox version: 7.0.6

Theory_2922-4793396-705_0
Theory_2922-4795478-705_0
Theory_2922-4857277-705_0
Theory_2922-4911671-705_0

In reply to maeax's message of 16 Mar 2026:

Have three Theory(docker) from yesterday 5 UTC waiting for success.

I have these two
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=239917623 Theory Docker
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=239909296 Atlas

I have one new "stuck" Theory Simulation v302.10 (docker)
windows_x86_64 that has been running now for over 18 hours and has been showing Progress 100% for at least 10 hours. I have been running the docker app successfully for several weeks processing numerous Theory Simulation tasks (all validated) with processing times ranging from 1 to 4 hous. A few of the 4 hour tasks ran at 100% Progress for around an hour. This latest "stuck" task is well beyond the previous norm. And I noticed that this task had been previosly issued to another computer but had timed out with no response,

They do that all the time......I have Valid ones that took over 4 days and many 2 day+ tasks
They just stay at 100% and running every time and I let them continue even had one run for over 10 days
Just depends on if you want to do that or not

In reply to Stick's message of 19 Mar 2026:

I have one new "stuck" Theory Simulation v302.10 (docker)
windows_x86_64 that has been running now for over 18 hours and has been showing Progress 100% for at least 10 hours.

Ignore BOINC's 100% progress indication. It's of no use.
Your job is a long runner. In your case: pp z1j 13000 90 - herwig7 7.2.1 nlo-dipole. That job had 46 attempts whereof 20 successes, 6 fails and 20 unknown.
In BOINC's corresponding slot/shared folder on your host is a runRivet.log where the progress is written.
Your Herwig job normally does 760 integrations of 4 iterations each, before the event processing starts. (in your job 19000 events)

The server don't create new tasks at the moment, so what you get are resends. The chance to get a long runner out of these resends is much bigger, because of failed, aborted or overtime tasks.

Is it possible to run Docker (podman) theory workunits and VirtualBox theory workunits at the same time with Linux? I'm getting both types of workunits.