LHC@home

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.

The main issue with that for me is ATLAS loves to give me 8 core tasks. Which then kick 8 other jobs to the side, and usually break them.
What I want my tasks to do is say hey an atlas 8 core is ready. Let 8 more tasks finish and then slot the atlas in the free space. I could limit ATLAS to one core task,
but that kinds defeats the point of a threadrippper no?

This is a major flaw in the workings of the Boinc scheduler. You could try asking them to sort it, but they're a strange bunch. And you'll have to visit them in Github as they don't listen to anyone in the forums.

Although, why are your single core tasks breaking? The only problem I end up with is stuff not meeting deadlines. The Boinc scheduler is rubbish at that, it leaves things to the last minute, and if you happen to have the computer off or playing a game etc, you're a bit late sending them back.

The last 5 hours I have not been able to send any of the over 100 finished Sixtracks from here ( PDT)
Can't get new tasks either but since I planned ahead I still have 645 running.
Couldn't even send in one Theory to -dev and it can't be because of too many tasks at the same time.
Of course right now we have lots of Sixtracks running and supposed to be many more waiting right now.
I guess I will just watch and see if they finally let me update.

Seems to be fixed with the workaround on
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14006&postid=96882

LHC & Rosetta both seem to work. Other projects still work.

Add NumberFields@home as another project affected.

Unfortunately, opening ca-bundle.crt in Windows only shows the details for the first of the 133 certificates in the bundle. I've been through them all, and - although a few of them have expired - none expired this morning.

Although the COMODO certificate authenticating this website, and the InCommon certificate authenticating the NumberFields and Rosetta websites, all seem to be in order, I've seen a suggestion on the web that certificates may be rejected as expired in some cases when a newer certificate is issued (even if the old one appears still to have time left to run before expiry).

Just noticed this in Opera browser on Windows 10:
This discussion is fine, but this thread: https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5387
Which has images, specifically http://cms-results.web.cern.ch/cms-results/public-results/publications/SMP-15-003/CMS-SMP-15-003_Figure_006-a.png
Shows: https://www.dropbox.com/s/6qjbvllcsgslvrt/unsecure.jpg?dl=0