LHC@home

This error seems to appear with VirtualBox installs on versions of macOS 10.13.

To fix this issue, you have to uninstall VirtualBox (use the VirtualBox_uninstall.tool of the VirtualBox downloaded dmg).

Then, install it again executing VirtualBox.pkg. At the end of the install, go to System Preferences, Security and Privacy, and the click the allow button :

Well you have maybe XEON cpu with 64 cores or maybe you only do word processing things on your hosts but I don't .

But anyway your arguments doesn't have any grip on reality. Why? Because for the last 6 hours, they haven't been enough paused and resumed processes and the VM from CERN could used 100% of the cpu time and still all the tasks have resulted in error and more than a few of them didn't had any pauses.

2020-12-20 09:40:29 (48180): VM state change detected. (old = 'Running', new = 'Paused')
2020-12-20 09:40:39 (48180): VM state change detected. (old = 'Paused', new = 'Running')
2020-12-20 09:51:31 (48180): VM state change detected. (old = 'Running', new = 'Paused')
2020-12-20 09:51:41 (48180): VM state change detected. (old = 'Paused', new = 'Running')
2020-12-20 09:53:14 (48180): Guest Log: [INFO] Mounting the shared directory

2020-12-20 09:54:02 (48180): VM Heartbeat file specified, but missing.
2020-12-20 09:54:02 (48180): VM Heartbeat file specified, but missing file system status. (errno = '2') 

2020-12-20 09:33:39 (48180): Preference change detected
2020-12-20 09:33:39 (48180): Setting CPU throttle for VM. (65%)
2020-12-20 09:33:39 (48180): Setting checkpoint interval to 3600 seconds. (Higher value of (Preference: 3600 seconds) or (Vbox_job.xml: 600 seconds))

So in place again, of pointing out the habits or the system of the people trying to help the community, just use some common sense please and see that there is too much of the same occurrence that it could be the cpu cap.

2020-12-19 20:38:02 (28448): Setting CPU throttle for VM. (65%)

CentOS Project shifts focus to CentOS Stream
Tuesday , 8, December 2020 Rich Bowen
The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux.

Meanwhile, we understand many of you are deeply invested in CentOS Linux 7, and we’ll continue to produce that version through the remainder of the RHEL 7 life cycle.

CentOS Stream will also be the centerpiece of a major shift in collaboration among the CentOS Special Interest Groups (SIGs). This ensures SIGs are developing and testing against what becomes the next version of RHEL. This also provides SIGs a clear single goal, rather than having to build and test for two releases. It gives the CentOS contributor community a great deal of influence in the future of RHEL. And it removes confusion around what “CentOS” means in the Linux distribution ecosystem.

When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases. If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.

We have an FAQ to help with your information and planning needs, as you figure out how this shift of project focus might affect you.

I am running native ATLAS, and have no problem running four ATLAS at once (two cores each).
I have often run four cores each also with no problem with multiple work units.

Maybe it is different on VirtualBox.

That's native. I'm running the vanilla VB version.

Does anybody have an idea what could have happened?

Not really.
Probably you have in your project preferences "No Limit" for # of cpus and are using an app_config.xml.

Your machine has 8 threads and the number of CPU-seconds reported is about 8 times the real number.

The project preferences for this venue is set to 3 for # of CPUs. Below is the Theory section from app_config.xml:

	<app>
		<name>Theory</name>
		<max_concurrent>4</max_concurrent>
	</app>
	<app_version>
		<app_name>Theory</app_name>
		<plan_class>vbox64_mt_mcore</plan_class>
		<avg_ncpus>1.000000</avg_ncpus>
		<cmdline>--nthreads 1 --memory_size_mb 750</cmdline>
	</app_version> 

All other Theory tasks for this host have normal runtime and CPU time, this was the only one like this I happened to notice. The host does about 30-35 Theory tasks a day + 2 Atlas tasks a day. App_config sets Atlas also to use only 1 CPU core.

Setting Memory Size for VM. (630MB)