LHC@home

since quite some time parts of my atlas logs look a little bit weird https://lhcathome.cern.ch/lhcathome/result.php?resultid=172189433 :

exitcode=0
******************************WorkDir***********************
insgesamt 395380
drwxrwx--x. 6 boinc boinc      4096  8. Jän 13:32 .
drwxrwx--x. 3 boinc boinc        15  5. Jän 21:26 ..
-rw-------. 1 boinc boinc       509  8. Jän 13:32 0VMMDmihMsrnDDn7oo6G73TpABFKDmABFKDm4jKKDmABFKDm7uBL0m.diag
-rw-------. 1 boinc boinc   5439769  8. Jän 13:30 agis_ddmendpoints.cvmfs.json
-rw-------. 1 boinc boinc   5115766  8. Jän 13:30 agis_schedconf.cvmfs.json
drwx------. 2 boinc boinc         6  8. Jän 09:05 .alrb
drwxrwxr-x. 3 boinc boinc        17  8. Jän 09:05 APPS
-rwx------. 1 boinc boinc      2312  7. Jän 10:46 ARCpilot
-rw-------. 1 boinc boinc       539  8. Jän 09:05 .asetup
-rw-------. 1 boinc boinc     11986  8. Jän 09:05 .asetup.save

this is how they should look:

exitcode=0
******************************WorkDir***********************
total 394544
drwxrwx--x  6 root root      4096 Jan  6 16:39 .
drwxr-x--x 10 root root        78 Jan  6 08:14 ..
-rw-------  1 root root   5439769 Jan  6 16:37 agis_ddmendpoints.cvmfs.json
-rw-------  1 root root   5114493 Jan  6 16:37 agis_schedconf.cvmfs.json
drwx------  2 root root         6 Jan  6 14:05 .alrb
drwxr-xr-x  3 root root        17 Jan  6 14:05 APPS
-rwx------  1 4871  566      2312 Jan  6 11:45 ARCpilot
-rw-------  1 root root       538 Jan  6 14:05 .asetup
-rw-------  1 root root     11985 Jan  6 14:05 .asetup.save

It seems that the date is a little bit messed up.

How do i fix this?
Does this have any influence on the validity of the results?

since quite some time parts of my atlas logs look a little bit weird https://lhcathome.cern.ch/lhcathome/result.php?resultid=172189433 :

Mine looks the same way:
https://lhcathome.cern.ch/lhcathome/result.php?resultid=172158042

The date is OK, and I don't see any problems with the validity.

yours looks good and is different to the posted one:
-rw-------. 1 boinc boinc 509 8. Jän 13:32 0VMMDmihMsrnDDn7oo6G73TpABFKDmABFKDm4jKKDmABFKDm7uBL0m.diag

the bold part is different.
The validity within BOINC is good (i.e. i get the credits). But validity for BOINC and actual "CERN/ATLAS validity" (to use the results and that the results are correct) are not the same thing (e.g. the existence of the HITS file).
So the question was reffered to the "CERN/ATLAS validity".

It seems like your locale is set to German? I see this earlier in the log

sh: lsb_release: Kommando nicht gefunden.

I think the strange characters in the date are an encoding of an accented character.

Thanks for the hint David!

Is it possible to integrate the Linux native App in the list of Applications with the use of GFlops?

the website http://atlasathome.cern.ch/boinc_conf
is only reachable with direct link.
http://atlasathome.cern.ch is down (show normally the active Atlas tasks!)

Here's my Ubuntu box with some completed native ATLAS tasks: https://lhcathome.cern.ch/lhcathome/show_host_detail.php?hostid=10506919

I don't remember exactly what I did, but here's the general idea. Hope it helps.

First, installed cvmfs using the instructions at https://cernvm.cern.ch/portal/filesystem/downloads and the script at https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4395 as guides. Although I'm running Artful (17.10), the Xenial (16.04) version worked.

sudo apt install lsb-release
wget https://ecsft.cern.ch/dist/cvmfs/cvmfs-release/cvmfs-release-latest_all.deb
sudo dpkg -i cvmfs-release-latest_all.deb
rm -f cvmfs-release-latest_all.deb

That sets up the repo for Precise (12.04). That old release may work, but I updated it to Xenial just in case. Just edit "precise-prod" to "xenial-prod":

sudo nano /etc/apt/sources.list.d/cernvm.list

Then I installed the cvmfs and singularity packages. I don't know if expat is required, but it was in the script, so I installed it just in case.

sudo apt update
sudo apt install expat cvmfs singularity-container

Uncomment "user_allow_other" in /etc/fuse.conf:

sudo nano /etc/fuse.conf

Uncomment "/misc /etc/auto.misc" and "/net -hosts" in /etc/auto.master:

sudo nano /etc/auto.master

Get /etc/cvmfs/default.local, restart the service, and make sure it's working

sudo wget http://atlasathome.cern.ch/boinc_conf/default.local -O /etc/cvmfs/default.local
sudo service restart cvmfs
cvmfs_config probe
cvmfs_config stat atlas.cern.ch

Native ATLAS tasks should now be good to go.

After several completed native ATLAS tasks on Ubuntu, followed by a few hours of SixTrack tasks, BOINC returned to an ATLAS task, which failed with a cvmfs error. I think autofs unmounted /cvmfs after 600 seconds of inactivity.

So I added "--timeout=0" to the "/cvmfs" line in /etc/auto.master. It seemed to do the trick.

sudo nano /etc/auto.master

/cvmfs /etc/auto.cvmfs --timeout=0

sudo service autofs restart
cvmfs_config probe
cvmfs_config stat atlas.cern.ch

The slot numbers in Boinc-manager are growing up to hundred.
They where all empty (only the folder), but NOT deleted.
So when hundred are reached, the next Atlas-task is not started, with the message:
Hundred slots are reached. SL69 with Boinc 7.5.1.

Edit: After deleting the empty folders, tasks are starting normally.

Thanks very much for these detailed instructions! I have finally posted an overview of the native app in the Linux Q&A forum which should make an easier starting point for people who want to try it. I put a link there to the Ubuntu instructions here.

After a longer break I thought I would give LHC@Home another try, and started with a clean install of Ubuntu 16.04.3 LTS. Previously, I had no issues with the native app, despite being new to Linux. However, the intermittent issues several users reported before now have caught up to me.

To help me, I am using the script at
http://atlasathome.cern.ch/boinc_conf/

as well as the information provided in both
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4502#33029
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4396&postid=34346

At last I resorted to the CVMFS documentation.
https://cernvm.cern.ch/portal/filesystem/quickstart

After several retries I still can't get the native app to work.
Removing vbox or forcing "dont_use_vbox" simply produces a message that vbox isn't installed.
cvmfs_config probe, status, stat *repository*.cern.ch and chksetup all work.
/scratch/cvmfs contains what I assume to be a CERN network share.

These are my observations:
1) There is some ambiguity about default.local in the sources I mentioned above. The script at /boinc_conf/ suggests using the *internal* CERN proxies. Others suggest replacing the proxies with "DIRECT" (with quotation marks) or DIRECT (w/o quotation marks). Is using the CERN proxies advisable? What is the correct value/syntax?

All three alternatives "work" i.e. don't obviously break anything. cvmfs_config stat atlas.cern.ch simply reports the different settings.

2) cvmfs_config chksetup is complaining about Geo-API not working, but I remember this being normal even when CVMFS worked. Does this need to be addressed?

3) The documentation uses cvmfs-config-default and cvmfs_config setup. No further editing of fuse.conf or auto.master is required. However "/misc /etc/auto.misc" and "/net -hosts" in auto.master aren't uncommented i.e. put to use. Is this necessary for full functionality?

4) Why not use the script at /boinc_conf/? Cause it uses yum and selinux that I don't use on Ubuntu. It didn't work anyway.

5) It's difficult to diagnose the issue, because there is no reliable supply of ATLAS tasks. I can never tell, whether there are no tasks or I am not sent any.

I am using a fresh install of Ubuntu 16.04.3 LTS
BOINC 7.6.31 from the ubuntu rep
VirtualBox 5.2.x from the Oracle PPA
Singularity-container 2.4.1-2 from Neurodebian rep (Ubuntu 17.10 would still use 2.3.1?)
CVMFS 2.4.3 from the CERN PPA

A simple question: Is AMD-V or VT-X enabled in Bios?
Have Proxy ="DIRECT" in the declaration for SL69.
Sorry, but for Ubuntu, I have no feedback in my brain!

A simple question: Is AMD-V or VT-X enabled in Bios?

Yes, and confirmed working with Virtualbox.

Have Proxy ="DIRECT" in the declaration for SL69.

Can I ask why? The documentation suggests DIRECT (without quotation marks).
How did you make the call not to use the proxies CERN included in the script at /boinc_conf/?

Frankly I don't even know what to try, ask or look up next.

Have Proxy ="DIRECT" in the declaration for SL69.

Can I ask why? The documentation suggests DIRECT (without quotation marks).
How did you make the call not to use the proxies CERN included in the script at /boinc_conf/?

Frankly I don't even know what to try, ask or look up next.

I have installed native ATLAS files on several Ubuntu 16.04.3 machines. This works for "default.local":
CVMFS_REPOSITORIES=atlas.cern.ch,atlas-condb.cern.ch,grid.cern.ch
CVMFS_HTTP_PROXY=DIRECT

Looking at the other instructions you referenced, I think they are a bit overly-complicated for Ubuntu.
These work for Ubuntu (if you need Lubuntu, there are some slight modifications I can supply):

CVMFS:

In order to add the apt repository, run:
wget https://ecsft.cern.ch/dist/cvmfs/cvmfs-release/cvmfs-release-latest_all.deb
sudo dpkg -i cvmfs-release-latest_all.deb
rm -f cvmfs-release-latest_all.deb
sudo apt update

=================================================
Installation:

Step 1  Install the CernVM-FS packages:
sudo apt install cvmfs cvmfs-config-default

-------------------------------------------------
Step 2 Base setup:
sudo cvmfs_config setup

-------------------------------------------------
Step 3
Create /etc/cvmfs/default.local and open the file for editing.
(e.g., using sudo gedit)
sudo gedit /etc/cvmfs/default.local

-------------------------------------------------
Step 4
Place the desired repositories in "default.local". 
For ATLAS, for instance, set
CVMFS_REPOSITORIES=atlas.cern.ch,atlas-condb.cern.ch,grid.cern.ch
CVMFS_HTTP_PROXY=DIRECT

-------------------------------------------------
Step 5
Check if CernVM-FS mounts the specified repositories by: 
sudo cvmfs_config probe 
sudo cvmfs_config chksetup

If the probe fails, try to restart autofs with sudo service autofs restart.

Singularity:
Also, while we are on the subject, for Singularity I had a bit of a problem with the NeuroDebian repository once, and just use the following:

First, check the latest version on GitHub: https://github.com/singularityware/singularity/releases
And substitute that for "$VERSION"

$VERSION=2.4.2 (as of 6 December 2017)

wget https://github.com/singularityware/singularity/releases/download/$VERSION/singularity-$VERSION.tar.gz
=> wget https://github.com/singularityware/singularity/releases/download/2.4.2/singularity-2.4.2.tar.gz

tar xvf singularity-$VERSION.tar.gz
=> tar xvf singularity-2.4.2.tar.gz

cd singularity-$VERSION
=> cd singularity-2.4.2

./configure --prefix=/usr/local
make
sudo make install

To check the version installed:  singularity --version
To check the usage:  singularity --help

It works, when they send you the stuff.

Thank you very much for your detailed reply!

Concerning CVMFS:
I went the exact same route. Well, except I modified fuse.conf and auto.master after the first failure.

* Is it safe to assume that modifications to fuse.conf and auto.master are not necessary?

* Did sudo cvmfs_config chksetup complain about geo-API (seems to be related to GRID)?

Singularity:
I guess I'll further focus on Singularity.

* How can I check whether Singularity (by itself) is working properly?

Again, thank you!

*** EDIT: I tried building Singularity and will report back in case I receive native ATLAS.

Concerning CVMFS:
I went the exact same route. Well, except I modified fuse.conf and auto.master after the first failure.

* Is it safe to assume that modifications to fuse.conf and auto.master are not necessary?

Since I never heard of them, I guess they are not necessary.

* Did sudo cvmfs_config chksetup complain about geo-API (seems to be related to GRID)?

Yes, recently they did complain, but not originally. I guess some website went down.
And the only check for Singularity that I have used is the "version" check.

And you are welcome. I am always surprised at the lack of simple instructions for a lot of Linux installs.
I guess it relates to the multiple versions.

Thank you, but no change unfortunately. I either get vbox tasks or no tasks.

I was able to verify that Singularity is working with an example file.

Thank you, but no change unfortunately. I either get vbox tasks or no tasks.

For the past day or two, I have also been getting VBox only on a machine that is set up for both VBox and native ATLAS. It comes and goes a lot.
They need a checkbox to allow you to select which ones you want.

If you run a separate BOINC client instance for ATLAS (native), you can force it to not accept vbox tasks by setting
<p_vm_extensions_disabled>1</p_vm_extensions_disabled> in client_state.xml and <dont_use_vbox>1</dont_use_vbox> in cc_config.xml.

In addition you may check your preferences on the project website.
Are beta tasks enabled there?


It may need a couple of update requests to get a task as they are not always available.