LHC@home

2023-02-07 15:05:56 (46556): Adding network bandwidth throttle group to VM. (Defaulting to 1024GB)
.
.
.
2023-02-07 15:06:02 (46556): Setting network throttle for VM. (5120KB)

It looks like you tweak your network bandwidth settings for the VMs (or BOINC as a whole).
This makes no sense since it applies only to outgoing traffic (from the VM perspective), but it may affect the connection timing.

You may leave those settings unlimited or at default values.

Have checked one Theory-Task from you.
Seeing entries from Boinc-slot No. 29, 19 and 31 for the same Theory task.

26202 is a problem wrapper per the link https://boinc.berkeley.edu/trac/wiki/VboxApps#Premadevboxwrapperexecutables as it uses the COM interface.
26203 is reporting in the logs as '26202' and really should be reporting its own version number.

The bad WUs in this forum thread took care of themselves. It looked to be more an error of CVMFS within the VM hanging and the processing never starting.

Since you are on Win10, VirtualBox 5.2.44 will be better. I don't think it makes much difference on Linux.
https://www.virtualbox.org/wiki/Download_Old_Builds_5_2

<core_client_version>7.16.11</core_client_version>
<![CDATA[
<message>
Incorrect function.
 (0x1) - exit code 1 (0x1)</message>
<stderr_txt>
2021-09-08 08:42:14 (4032): Detected: vboxwrapper 26197
2021-09-08 08:42:14 (4032): Detected: BOINC client v7.7
2021-09-08 08:42:21 (4032): Error in guest additions for VM: -2147024891
Command:
VBoxManage -q list systemproperties
Output:
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: The object is not ready
VBoxManage.exe: error: Details: code E_ACCESSDENIED (0x80070005), component VirtualBoxClientWrap, interface IVirtualBoxClient

2021-09-08 08:42:21 (4032): Detected: VirtualBox VboxManage Interface (Version: 6.1.26)
2021-09-08 08:42:27 (4032): Error in host info for VM: -2147024891
Command:
VBoxManage -q list hostinfo 
Output:
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: The object is not ready
VBoxManage.exe: error: Details: code E_ACCESSDENIED (0x80070005), component VirtualBoxClientWrap, interface IVirtualBoxClient

2021-09-08 08:42:27 (4032): WARNING: Communication with VM Hypervisor failed.
2021-09-08 08:42:27 (4032): ERROR: VBoxManage list hostinfo failed
08:42:27 (4032): called boinc_finish(1)

</stderr_txt>
]]>

This is also in regards to your post in the Theory thread:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5431&postid=42775


You may first check your access.log and cache.log.
Do you notice error messages that correspond to your issues?

If no, squid is most likely running fine and the issues are caused by something else.

If yes, you should clear the cache and restart fresh.

You may also insert the following line in your squid.conf and do a "squid -k reconfigure".

shutdown_lifetime 3 seconds

This avoids the 60 seconds default delay when you shutdown/restart squid but I'm not 100% sure if changing this timeout requires a squid -k restart. At least Squid will be prepared for the next restart.

Ok got another one that was just stuck there with the same message.
This time it was not due to task switching.

Could it be due to the squid cache that I set up earlier?

Hopefully this will update to something more helpful then aborted by user.
https://lhcathome.cern.ch/lhcathome/result.php?resultid=275990643

Hi all,

This message is only relevant if you run your own squid proxy server for ATLAS tasks.

After the CERN database outage last week, a problem was seen with the cached information on squid proxy servers all over the ATLAS Grid which can cause tasks to fail. The solution to the problem is to restart the squid service, so if you are running your own squid please restart it in order to avoid potential problems.

The ATLAS-managed squid servers which tasks use by default were restarted earlier today, so if you saw strange failures in tasks between Thursday last week and now this might have been the reason.