21) Message boards : Theory Application : New Native App - Linux Only (Message 5840)
Posted 11 Feb 2019 by gyllic
Post:
Now it shows the user namespace error also on Debian Stretch:

cranky-0.0.14 INFO: Starting
cranky-0.0.14 INFO: Detected Theory App
cranky-0.0.14 INFO: Checking CVMFS.
cranky-0.0.14 INFO: Checking runc.
cranky-0.0.14 INFO: Creating the filesystem.
cranky-0.0.14 INFO: Using /cvmfs/cernvm-prod.cern.ch/cvm3
cranky-0.0.14 INFO: Updating config.json.
cranky-0.0.14 INFO: Running Container 'runc'.
nsenter: failed to unshare user namespace: Operation not permitted
container_linux.go:336: starting container process caused "process_linux.go:279: running exec setns process for init caused \"exit status 39\""
cranky-0.0.14 ERROR: Container 'runc' failed.
13:52:12 (2366): cranky exited; CPU time 0.212000
13:52:12 (2366): app exit status: 0xce
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752261

The "/proc/sys/user/max_user_namespace" file shows "31300". Also, the flag in the .config file used for kernel building shows "CONFIG_USER_NS=y". Do you know any way how to fix this problem on debian stretch (kernel 4.9)?
22) Message boards : Theory Application : New Native App - Linux Only (Message 5824)
Posted 11 Feb 2019 by gyllic
Post:
cranky-0.0.13 ERROR: 'runc spec version < 1.1

The app requires runc to be at least version 1.1.

Have the same situation with opensuse where the standard package is <1.1.
Yes, but i have used the latest runc source code from their github master branch for building it. Is there any other repositoriy where the active development is done or where is the newest code, since the latest code on github delivers version 1.0.1. The standard runc version in debian stretch is 0.1.1.
23) Message boards : Theory Application : New Native App - Linux Only (Message 5822)
Posted 11 Feb 2019 by gyllic
Post:
I have cloned and built the lastest runc code (from https://github.com/opencontainers/runc) on Debian Stretch, and the task produces this error message:

<core_client_version>7.6.33</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)
</message>
<stderr_txt>
09:10:56 (2772): wrapper (7.7.26015): starting
09:10:56 (2772): wrapper: running ../../projects/lhcathomedev.cern.ch_lhcathome-dev/cranky-0.0.13 ()
cranky-0.0.13 INFO: Starting
cranky-0.0.13 INFO: Detected Theory App
cranky-0.0.13 INFO: Checking CVMFS.
cranky-0.0.13 INFO: Checking runc.
cranky-0.0.13 ERROR: 'runc spec version < 1.1
09:11:02 (2772): cranky exited; CPU time 0.188000
09:11:02 (2772): app exit status: 0x1
09:11:02 (2772): called boinc_finish(195)

</stderr_txt>
]]>

This is the corresponding task:
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752234

The command "runc --version" gives the output: "runc version spec: 1.0.1-dev"

Am I doing something wrong or is the mistake on the application side?
24) Message boards : Theory Application : New Native App - Linux Only (Message 5815)
Posted 9 Feb 2019 by gyllic
Post:
From this:-
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752133
came this:-
cranky-0.0.13 INFO: Running Container 'runc'.
nsenter: failed to unshare user namespace: Invalid argument
container_linux.go:336: starting container process caused "process_linux.go:279: running exec setns process for init caused \"exit status 39\""
cranky-0.0.13 ERROR: Container 'runc' failed.

For those more knowledgeable than I, there may be some ideas here:-
https://coderwall.com/p/s_ydlq/using-user-namespaces-on-docker
I've followed the instructions to enable namespaces on the kernel, but now there's no work to try it out... and it's Friday.
No clue if this will help fixing your problem (if it still persists), but here are two links:
https://github.com/moby/moby/issues/34011
https://github.com/opencontainers/runc/issues/1343

Yeah, unfortunately no testing is possible since no work is available.
25) Message boards : ATLAS Application : Atlas v.0.61 (Message 5780)
Posted 25 Jan 2019 by gyllic
Post:
for me the 0.61 native version ran without any obvious problems, but no HITS file within the working directory is shown in the logs. Instead it states "Moving ./HITS.16698131._038046.pool.root.1 to shared/HITS.pool.root.1" in the logs.
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2749806

EDIT: looks like the answer is here:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4929
26) Message boards : Number crunching : VirtualBox 6.0.2 (Message 5770)
Posted 18 Jan 2019 by gyllic
Post:
i have run a theory task over at the production site with VBox 6.0.0 and it worked without any problem. Currently some tasks with VBox 6.0.2 are running and are looking good so far. Didnt try to pause and resume the tasks though.
27) Message boards : News : Dev server updated (Message 5727)
Posted 13 Dec 2018 by gyllic
Post:
Feature proposal:

Not only display PMs that are in your inbox, but also display PMs that you have sent.
28) Message boards : Theory Application : New version v3.12 (Message 5683)
Posted 28 Nov 2018 by gyllic
Post:
Laurence wrote,
they PLAN TO USE Alice software.
We have to wait therefore.
He also wrote that THIS version updates the cvmfs configuration to include the alice repository...
29) Message boards : Theory Application : New version v3.12 (Message 5673)
Posted 27 Nov 2018 by gyllic
Post:
How can we check that it actually works?

In the log it does not show any hint that the alice cvmfs repository is used:

2018-11-27 11:18:51 (7412): Guest Log: [DEBUG] VM is running outside WLCG
2018-11-27 11:19:54 (7412): Guest Log: [DEBUG] Probing CVMFS ...
2018-11-27 11:19:55 (7412): Guest Log: Probing /cvmfs/grid.cern.ch... OK
2018-11-27 11:19:56 (7412): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2018-11-27 11:19:56 (7412): Guest Log: 2.4.4.0 3518 1 25332 7789 3 1 7409 10240001 2 65024 0 3 100 0 0 http://s1cern-cvmfs.openhtc.io/cvmfs/grid.cern.ch DIRECT 1

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2740709
30) Message boards : Number crunching : An Alternative Approach For VM applications (Message 5633)
Posted 12 Nov 2018 by gyllic
Post:
any news regarding this topic?
31) Message boards : Number crunching : An Alternative Approach For VM applications (Message 5567)
Posted 7 Oct 2018 by gyllic
Post:
There is still the overhead of the time to boot the VM.
Obviously, there will always be the overhead to boot and shutdown the VM as long as you have to use one. Since also e.g boinc2docker uses VMs, they also have overhead there.

Actually more like boinc2runc
Nice!
32) Message boards : Number crunching : An Alternative Approach For VM applications (Message 5557)
Posted 2 Oct 2018 by gyllic
Post:
I still have one qustion:

    - Would you like to change the way how jobs are distributed as well? So switch from the HTCondor approach to a similar one like ATLAS where the boinc server is responsible for distributing the jobs?


One of the issues with the current approach is that as the VMs are rebooted, the local CVMFS cache is destroyed and over time the cache in the image degrades.
I just had an idea (don't know if that would work): Why not place the CVMFS cache directory within one of the directories that is shared with the host system and does not get deleted (maybe the scratch directory within the project's folder within the Boinc Data directory) and configure CVMFS to use this directory as cache. When a new VM is started, include this directory and the already existing cache can be used again. This way the cache won't get deleted once the VM has shutdown.

What are your views on the ATLAS native application and this potential new direction?
I really like the native ATLAS app. I think the direction you proposed is good since everything that makes it easier for volunteers to set everything up is good (if that is the case). Keeping it as simple as possible for the volunteers is the most important thing!

Have you considered a similar approach as boinc2docker, so something like boinc2singularity? Again, no idea if that approach would work: So providing a very small VM image that runs CVMFS (again place the CVMFS cache directory into a shared directory if thats possible) and is able to execute a singularity image. Then download/execute the prebuild singularity image which then do the actual calculations.
33) Message boards : Theory Application : New version v3.10 (Message 5532)
Posted 21 Sep 2018 by gyllic
Post:
Uses OpenHTC.io for CernVM
Maybe I am overlooking something obvious, but how can you verify that the VM really uses OpenHTC.io for CernVM? "Just" a successfull run does not directly indicate that openthc was used for CernVM, or does it?
34) Message boards : LHCb Application : New version v1.06 (Message 5521)
Posted 14 Sep 2018 by gyllic
Post:
looks like it is working https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2378907:
2018-09-13 18:49:20 (4656): Guest Log: VERSION PID UPTIME(M) MEM(K) REVISION EXPIRES(M) NOCATALOGS CACHEUSE(K) CACHEMAX(K) NOFDUSE NOFDMAX NOIOERR NOOPEN HITRATE(%) RX(K) SPEED(K/S) HOST PROXY ONLINE
2018-09-13 18:49:20 (4656): Guest Log: 2.4.4.0 3505 1 25688 7175 3 1 1740097 10240000 2 65024 0 15 100 0 0 http://s1cern-cvmfs.openhtc.io/cvmfs/grid.cern.ch http://192.168.1.2:3128 1
35) Message boards : LHCb Application : New version v1.02 (Message 5417)
Posted 29 Apr 2018 by gyllic
Post:
crunched a couple of these last days and almost all of them failed with error message "194 (0x000000C2) EXIT_ABORTED_BY_CLIENT".

these are the WUs with the Stderr output:
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=821859
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=821868
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=821861
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=821737
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=821875
36) Message boards : News : ATLAS load tests (Message 5381)
Posted 12 Mar 2018 by gyllic
Post:
These are real tasks, from the same pool of tasks that go to LHC@Home. So if you run tasks here you are both contributing to the science and testing the new infrastructure. But as Nils said this is still the dev project so things can go wrong at any time!

thanks for the info david! pc is now connected to -dev project (just one pc, but better than nothing i guess ;-) )
37) Message boards : News : ATLAS load tests (Message 5372)
Posted 8 Mar 2018 by gyllic
Post:
are the tasks in queue just test tasks or are these "real" tasks.
i.e. if i enable my pc to run dev project tasks, would this be a "scientific calculation" or would it just be a "calculation/test for the new backend" or both?
38) Message boards : ATLAS Application : ATLAS 0.40 (Message 4995)
Posted 13 Jun 2017 by gyllic
Post:
If it were a Native-Linux-App I never could run it as I don't have any Linux machines

True! Also in Applications it says:
0.40 (vbox64_mt_mcore_atlas) (beta test)


But according to this (4 months old) post, it should be: https://lhcathomedev.cern.ch/lhcathome-dev/forum_thread.php?id=348.

Maybe they changed their mind or are testing something else at the moment.
39) Message boards : ATLAS Application : ATLAS 0.40 (Message 4993)
Posted 13 Jun 2017 by gyllic
Post:
Am i missing something obvious, but why does it say:
2017-06-13 16:12:15 (17992): Create VM. (boinc_e157925161010234, slot#4) 2017-06-13 16:12:15 (17992): Setting Memory Size for VM. (3600MB) 2017-06-13 16:12:15 (17992): Setting CPU Count for VM. (2) 2017-06-13 16:12:15 (17992): Setting Chipset Options for VM. 2017-06-13 16:12:15 (17992): Setting Boot Options for VM. 2017-06-13 16:12:15 (17992): Enabling VM Network Access. 2017-06-13 16:12:15 (17992): Setting Network Configuration for NAT. 2017-06-13 16:12:15 (17992): Disabling USB Support for VM. 2017-06-13 16:12:15 (17992): Disabling COM Port Support for VM. 2017-06-13 16:12:15 (17992): Disabling LPT Port Support for VM. 2017-06-13 16:12:15 (17992): Disabling Audio Support for VM. 2017-06-13 16:12:15 (17992): Disabling Clipboard Support for VM. 2017-06-13 16:12:15 (17992): Disabling Drag and Drop Support for VM. 2017-06-13 16:12:15 (17992): Adding storage controller(s) to VM. 2017-06-13 16:12:15 (17992): Adding virtual disk drive to VM. (vm_image.vdi) 2017-06-13 16:12:15 (17992): Adding VirtualBox Guest Additions to VM. 2017-06-13 16:12:15 (17992): Adding network bandwidth throttle group to VM. (Defaulting to 1024GB) 2017-06-13 16:12:15 (17992): forwarding host port 61916 to guest port 80 2017-06-13 16:12:15 (17992): Enabling remote desktop for VM. 2017-06-13 16:12:15 (17992): Enabling shared directory for VM. 2017-06-13 16:12:15 (17992): Starting VM. (boinc_e157925161010234, slot#4) 2017-06-13 16:12:28 (17992): Guest Log: BIOS: VirtualBox 5.1.16 2017-06-13 16:12:28 (17992): Guest Log: BIOS: ata0-0: PCHS=16383/16/63 LCHS=1024/255/63 2017-06-13 16:12:28 (17992): Guest Log: BIOS: Boot : bseqnr=1, bootseq=0032 2017-06-13 16:12:28 (17992): Guest Log: BIOS: Booting from Hard Disk... 2017-06-13 16:12:28 (17992): Guest Log: BIOS: KBD: unsupported int 16h function 03 2017-06-13 16:12:28 (17992): Guest Log: BIOS: AX=0305 BX=0000 CX=0000 DX=0000 2017-06-13 16:12:28 (17992): Successfully started VM. (PID = '3008') 2017-06-13 16:12:28 (17992): Reporting VM Process ID to BOINC.
in your logs?
Should that not be a native linux app without the need of virtual box?
40) Message boards : News : Dev server was down today (Message 4966)
Posted 3 Jun 2017 by gyllic
Post:
That is strange since LHC@Home runs perfectly - and quickly. SETI is also rather fast. I had to drop Quake because that is way too slow.

Then you are probably running sixtrack tasks only which need much less resources. All other projects run within a VM

Which one should I enable for Android and low-end machine?

Android: currently no one will work on android (in future maybe sixtrack, check out the "normal" lhcathome page)

low-end machine: also probably no one will work because you have only 2gb of ram, and i guess that this is not enough for OS and VM. if one will work, its the theory simulation, but i doubt that it will work.


Previous 20


©2024 CERN