Development for LHC@home

This update provides the latest version of the vboxwrapper.

Looks fine.
My 1st task already processed 45k events out of 100k.

grep: /etc/redhat-release: No such file or directory
shown also for Theory and CMS when task is starting.
-dev or Production.
Is this a normal info?

This task is broken from Virtualbox.
Last lines from stderr.txt
2022-07-28 11:41:55 (22340): Guest Log: [INFO] Detected local proxy http://10.241.124.14:3128 in init_data.xml
2022-07-28 11:41:55 (22340): Guest Log: [INFO] Testing connection to 10.241.124.14 on port 3128
2022-07-28 11:41:55 (22340): Guest Log: [INFO] Ncat: Version 7.50 ( https://nmap.org/ncat )
2022-07-28 11:41:55 (22340): Guest Log: Ncat: Connected to 10.241.124.14:3128.
2022-07-28 11:41:55 (22340): Guest Log: Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.
2022-07-28 11:41:55 (22340): Guest Log: [INFO] 0
2022-07-28 11:41:58 (22340): Guest Log: 11:41:52 CEST +02:00 2022-07-28: cranky: [INFO] Detected Theory App
2022-07-28 11:41:58 (22340): Guest Log: 11:41:52 CEST +02:00 2022-07-28: cranky: [INFO] Checking CVMFS.
2022-07-28 11:41:59 (22340): Guest Log: Probing /cvmfs/sft.cern.ch... OK
2022-07-28 11:41:59 (22340): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2022-07-28 11:41:59 (22340): Guest Log: 2.5.2.0 4110 0 26084 23466 3 1 265080 4096000 0 65024 0 0 n/a 0 0 http://s1cern-cvmfs.openhtc.io/cvmfs/sft.cern.ch http://10.241.124.14:3128 1
2022-07-28 11:41:59 (22340): Guest Log: Probing /cvmfs/grid.cern.ch... OK
2022-07-28 11:41:59 (22340): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2022-07-28 11:41:59 (22340): Guest Log: 2.5.2.0 4061 0 28492 18843 3 1 265080 4096000 0 65024 0 2 0 2138 6022 http://s1cern-cvmfs.openhtc.io/cvmfs/grid.cern.ch http://10.241.124.14:3128 1
2022-07-28 11:42:00 (22340): Guest Log: Probing /cvmfs/cernvm-prod.cern.ch... OK
2022-07-28 11:42:00 (22340): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2022-07-28 11:42:00 (22340): Guest Log: 2.5.2.0 4082 0 26084 268 3 1 265080 4096000 0 65024 0 0 n/a 0 0 http://s1cern-cvmfs.openhtc.io/cvmfs/cernvm-prod.cern.ch http://10.241.124.14:3128 1
2022-07-28 11:42:00 (22340): Guest Log: Probing /cvmfs/alice.cern.ch... OK
2022-07-28 11:42:01 (22340): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2022-07-28 11:42:01 (22340): Guest Log: 2.5.2.0 4038 0 37860 12923 3 1 265080 4096000 0 65024 0 0 n/a 0 0 http://s1cern-cvmfs.openhtc.io/cvmfs/alice.cern.ch http://10.241.124.14:3128 1
2022-07-28 11:42:01 (22340): Guest Log: 11:41:55 CEST +02:00 2022-07-28: cranky: [INFO] Checking runc.
2022-07-28 11:42:01 (22340): Guest Log: 11:41:55 CEST +02:00 2022-07-28: cranky: [INFO] Creating the filesystem.
2022-07-28 11:42:01 (22340): Guest Log: 11:41:55 CEST +02:00 2022-07-28: cranky: [INFO] Using /cvmfs/cernvm-prod.cern.ch/cvm3
2022-07-28 11:42:01 (22340): Guest Log: 11:41:55 CEST +02:00 2022-07-28: cranky: [INFO] Updating config.json.
2022-07-28 11:42:01 (22340): Guest Log: 11:41:55 CEST +02:00 2022-07-28: cranky: [INFO] Running Container 'runc'.
2022-07-28 11:42:04 (22340): Guest Log: job: htmld=/shared/html/job
2022-07-28 11:42:04 (22340): Guest Log: job: unpack exitcode=0
2022-07-28 11:42:05 (22340): Guest Log: 11:41:59 CEST +02:00 2022-07-28: cranky: [INFO] ===> [runRivet] Thu Jul 28 09:41:58 UTC 2022 [boinc pp jets 7000 20,-,360 - pythia8 8.244 tune-monash13 100000 271]
https://lhcathomedev.cern.ch/lhcathome-dev/workunit.php?wuid=2197795
was also errored out from wingman.
making a upgrade of Virtualbox (6.1.36) in the next few hours. Was planned.
After this will restart this task.

https://lhcathomedev.cern.ch/lhcathome-dev/workunit.php?wuid=2197795
making a upgrade of Virtualbox (6.1.36) in the next few hours. Was planned.
After this installation restart this task.

Now: alice.cern.ch waiting for the delivery of SIGUSR1

5.40 Theory -dev and Production Theory seem to have been playing nicely together overnight and today but I would still like to see if, on finishing, the last attached -dev allows the .vdi to be released. It was the transition where there was no -dev attached but the vdi was not released, and subsequent tasks could not re-attach to it, was where I previously had postponements. As is typical when I want to watch that, I have a task that is at 60% after 14hrs so it'll be tomorrow evening before I can watch what happens.

Win10
Boinc 7.20.2
VBox 6.1.36

.... but I would still like to see if, on finishing, the last attached -dev allows the .vdi to be released.

It's not BOINC or vboxwrapper not releasing the vdi.
It is VBoxSVC.exe keeping last used vdi's in memory.
As long as that process keeps running, because of other VM's running or the GUI of VirtualBox Manager open, the unused vdi's will be shown in Virtual Media Manager.

The last vboxwrapper v26205, in use now on LHC@home Development for all three vbox-apps, had no issues since released here as test.

Ah, ok. I've not been paying attention recently, just been letting run with the VBox window closed.
Really we're waiting for VBox themselves for a proper fix.

Really we're waiting for VBox themselves for a proper fix.

No, we don't.
Vboxwrapper now includes 2 workarounds:


1st workaround follows the advice given in the virtualbox ticket system years ago:
https://www.virtualbox.org/ticket/18296
As you can see there they don't plan to change something on their side.


2nd workaround takes care of a bug in virtualbox which occasionally writes the 'multiattach' attribute to a disk entry in the 'global media store' although that attribute is not allowed there.
This must be handled in vboxwrapper to make it work with widely distributed unpatched virtualbox versions.

Since at least 3 calls to vboxmanage in a row are required vboxwrapper tries to resolve this issue only once (per VM).
If it fails again during a 2nd run it will report this condition back and fail the task.
This is by intention and may happen very rarely on extremely loaded computers starting lots of VMs concurrently.

Great, thanks for that clarification update 👍

Laurence,
for native Theory, can we change from runc to apptainer Container?
https://apptainer.org/docs/admin/main/user_namespace.html