Development for LHC@home

It should be possible to pause the container with the following command:

sudo /cvmfs/grid.cern.ch/vc/containers/runc --root /var/lib/boinc-client/slots/0/cernvm/ pause Theory_859210_1543416190.499432_0

But I am getting the following error:

no such directory for freezer.state

If anyone has any ideas, please let me know.

Did you give the above command as user Laurence or as user boinc?
runc pause may fail if you don't have the full access to cgroups

I have tried as myself and root. Have contacted the developers.

I have tried as myself and root. Have contacted the developers.

Looks like it is a cgroup configuration issue.

I have tried as myself and root. Have contacted the developers.

Looks like it is a cgroup configuration issue.

Problem solved! Need to create a cgroup and add the following to the config.json

	"cgroupsPath": "/boinc",

Problem solved! Need to create a cgroup and add the following to the config.json

	"cgroupsPath": "/boinc",

When every simple Linux user has to do that himself, I think that will radically reduce the number of BOINC users for the Theory native application.

Could you provide more detailed information how to create the cgroup with which parameters.
??

groupadd -g group-ID cgroup

Which ID?

And where in config.json should that line be inserted? Environment maybe?:

       "env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/shared/bin",
            "TERM=xterm",
            "cgroupsPath": "/boinc",
        ],

When every simple Linux user has to do that himself, I think that will radically reduce the number of BOINC users for the Theory native application.

I don't expect users to do this. I have to package this up and make it automatic. Was trying to get something ready today but stopped myself as last minute Friday afternoon specials are never a good idea.

The current priority is to get the native Theory app production ready. The recent experience on dev suggests that it should be a separate app to the VM apps as they have different requirements at least for memory and disk. The two main improvements needed are:

1. Fix suspend/resume
   
2. Detect bad hosts and restrict the number of jobs sent.
   

If there is anything else, please let me know. We can revisit the VM apps once the native app is solid.

Both of the above improvements have been done. Is there anything else that needs addressing before we can move this to production? Note that I will add this as a separate app as it has different disk, memory and runtime requirements than the VM app.

As more and more apps with different and partly conflicting requirements become active it may be a good idea to increase the number of venues.

As more and more apps with different and partly conflicting requirements become active it may be a good idea to increase the number of venues.

This is hard-coded in the BOINC software. I would suggest that you open an issue in the BOINC issue tracker.

Both of the above improvements have been done. Is there anything else that needs addressing before we can move this to production? Note that I will add this as a separate app as it has different disk, memory and runtime requirements than the VM app.

Only Linux Theory native, I suppose.
Minor issue, could you 2 lines reduce to 1:

11:40:13 (10717): wrapper (7.15.26016): starting
11:40:13 (10717): wrapper (7.15.26016): starting

When going into production, inform the users that
- When a task is suspended, the task stays in memory ignoring the setting of "Leave non-GPU tasks in memory while suspended".
- When BOINC is restarted the task will start from the very beginning (no checkpointing).

Only Linux Theory native, I suppose.

Yes.

Minor issue, could you 2 lines reduce to 1:

11:40:13 (10717): wrapper (7.15.26016): starting
11:40:13 (10717): wrapper (7.15.26016): starting

This is an upstream BOINC issue. The message is printed here and here.
I will open an issue and make a PR along side updating our wrapper.

When going into production, inform the users that
- When a task is suspended, the task stays in memory ignoring the setting of "Leave non-GPU tasks in memory while suspended".
- When BOINC is restarted the task will start from the very beginning (no checkpointing).

Yes.

Minor issue, could you 2 lines reduce to 1:

11:40:13 (10717): wrapper (7.15.26016): starting
11:40:13 (10717): wrapper (7.15.26016): starting

This is an upstream BOINC issue. The message is printed here and here.
I will open an issue and make a PR along side updating our wrapper.

Strange.
With version 4.18 that line was printed only once.
Example: https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2759454

The double printing was introduced at last with version 4.21.

Here is a reply that explains why it is printed twice.

Both of the above improvements have been done. Is there anything else that needs addressing before we can move this to production? Note that I will add this as a separate app as it has different disk, memory and runtime requirements than the VM app.

Unless anyone provides any objections, on Monday I will enable this on the production project.

A small notice.
Today, had ALT+F4 taken for Boinc (x-Button). After starting Boinc again, all 5 tasks running from the beginning.
My fault,
When you transfer it to production, become native a selection in preferences for testing, or is it the only Application for Linux (no VM)?

A small notice.
Today, had ALT+F4 taken for Boinc (x-Button). After starting Boinc again, all 5 tasks running from the beginning.
My fault,
When you transfer it to production, become native a selection in preferences for testing, or is it the only Application for Linux (no VM)?

It is only the native Linux application.

Both of the above improvements have been done. Is there anything else that needs addressing before we can move this to production? Note that I will add this as a separate app as it has different disk, memory and runtime requirements than the VM app.

Unless anyone provides any objections, on Monday I will enable this on the production project.

No objections, but cause it will not run out of the box for new users, who didn't install needed packages,
you may overview your instructions mentioned in your Native Setup Linux thread and extend it with
instructions/remarks which are made afterwards keeping in mind that also ATLAS native have to run on those machines.

The current priority is to get the native Theory app production ready. The recent experience on dev suggests that it should be a separate app to the VM apps as they have different requirements at least for memory and disk. The two main improvements needed are:

1. Fix suspend/resume
   
2. Detect bad hosts and restrict the number of jobs sent.
   

If there is anything else, please let me know. We can revisit the VM apps once the native app is solid.

Laurence,
now more than 50 Tasks in production for Theory-native without any problem so long.
Thanks for your good work.
How is it possible to combine Atlas+Theory both native in one pref (Home,School or Work)?
Cpu is only avalaible with one parameter (1 or more CPU's).
When Theory using 1 Cpu how can Atlas be defined with 4 CPU's?

When Theory using 1 Cpu how can Atlas be defined with 4 CPU's?

app_config.xml