Development for LHC@home

I have updated the image. Please let me know whether or not they all start fine on Windows. I have reduced the memory as requested. The cut-off time I will leave until the image is working as a precaution.

I have updated the image. Please let me know whether or not they all start fine on Windows.

The issue of not found /shared/* is not solved.

I'm getting the same first image shown in message 6676

The difference is that the VM gets a shutdown signal now, because also #bash cranky can't be found.

Failed task: https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2825994

Like in version 5.03 I get the VM startup successful, when I pause all tasks on other threads.

The issue of not found /shared/* is not solved.

I have made another change and added some debugging statements.

Testing with 7 other threads busy, I see



... and no job is starting.

I'll see whether the job is killed by itself, else I'll stop it gracefully. Result: https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2826358

This is strange. From the image it appears that the job is started before CVMFS is mounted. However the job is configured to start after the target muliti-user system is reached. Also I don't see this on my Linux machine. A new version is on it's way where I very kindly ask it to start after the HTTP server.

The first task with version 5.07 has started under 7-threads-load and is doing the 124th attempt of pp jets 7000 300 - pythia8 8.235 tune-A2m 84000, probably lasting a bit longer to finish.
On the other threads, I surely will get shorter tasks too, sometime popping up in my list of tasks.
You see, it takes some time between Checking CVMFS and Checking runc.

I allowed the Linux machine and 1 Windows host to get 1 of the latest 5.07s each so as not to have to Abort any on finding that it didn't work. From CP's comments on them possibly not being too happy if they weren't getting all the attention on start-up, I suspended most other work on those hosts and both are currently running Jobs. WooHoo
I resumed all other LHC sixtracktest tasks but I have limited these at single-core, single Job so we'll see if they start up ok normally when these finish.
Linux box finished 1 job, Task reported and credited, new task booted fine and new Job started.

Strangely, "Show graphics" on both hosts lands on the SAME partially complete Vincia job, that I'm not running, but clicking through to the logs gets to the logs of the actual running jobs. Even the new Tasks again lands there.

Windows host also completed its task, reported, credited and, with all other cores busy, booted up and started a new job.

From CP's comments on them possibly not being too happy if they weren't getting all the attention on start-up, I suspended most other work on those hosts ....

The problem was with the previous versions.
With version 5.07, a load on all the threads, except the one where the new VM is starting, should be no problem anymore.

Strangely, "Show graphics" on both hosts lands on the SAME partially complete Vincia job, that I'm not running, but clicking through to the logs gets to the logs of the actual running jobs. Even the new Tasks again lands there.

This is maybe the default job that is displayed before anything is generated. It might not be picking up the new job images due to permissions. Will investigate later.

With version 5.07, a load on all the threads, except the one where the new VM is starting, should be no problem anymore.

Great! Thanks for your help with testing.

With version 5.07, a load on all the threads, except the one where the new VM is starting, should be no problem anymore.

Great! Thanks for your help with testing.

My pleasure. ... and another wish ;)
In the native version of cranky, you have added a procedure to add a line to stderr like

09:04:00 CEST +02:00 2019-09-16: cranky-0.1.1: [INFO] ===> [runRivet] Mon Sep 16 07:03:58 UTC 2019 [boinc pp jets 7000 400 - pythia6 6.428 psoft 100000 108]

Maybe you can add that in this version too and also display that line on ALT-F1 at the end of the startup just after datetimegroup: cranky: [INFO] Running Container 'runc'.
So during runtime the user has an easy access to what job is actually running and how many events.

With version 5.07, a load on all the threads, except the one where the new VM is starting, should be no problem anymore.

Great! Thanks for your help with testing.

My pleasure. ... and another wish ;)
In the native version of cranky, you have added a procedure to add a line to stderr like

09:04:00 CEST +02:00 2019-09-16: cranky-0.1.1: [INFO] ===> [runRivet] Mon Sep 16 07:03:58 UTC 2019 [boinc pp jets 7000 400 - pythia6 6.428 psoft 100000 108]

Maybe you can add that in this version too and also display that line on ALT-F1 at the end of the startup just after datetimegroup: cranky: [INFO] Running Container 'runc'.
So during runtime the user has an easy access to what job is actually running and how many events.

The code to do that is there, it is just not working. Second thing to investigate.

Strangely, "Show graphics" on both hosts lands on the SAME partially complete Vincia job, that I'm not running, but clicking through to the logs gets to the logs of the actual running jobs. Even the new Tasks again lands there.

You should have your plots now.

The code to do that is there, it is just not working. Second thing to investigate.

Still not working after an attempt to fix, it is a tricky one.

Still not working after an attempt to fix, it is a tricky one.

Fixed now.

Still not working after an attempt to fix, it is a tricky one.

Fixed now.

On the ALT-F1 Console it's working. Thanks!

It is not written to stderr output.
It's done now in the current production Theory VBox version directly at the start of a job.
E.g.:
2019-09-26 17:16:01 (5336): Guest Log: [INFO] ===> [runRivet] Thu Sep 26 17:15:43 CEST 2019 [boinc pp jets 8000 600 - pythia8 8.210 default-noCR 100000 124]
2019-09-26 22:28:30 (5336): Guest Log: [INFO] Job finished in slot1 with 0.

Yes, "Show Graphics" now goes to the actual running job.

On the Linux host, I'm getting yellow-triangle ghost images left behind in VBox Media Manager when a task finishes, which have to be manually deleted. I freely admit to being not much good with Linux so it could be something I haven't set up correctly here.
No ghosts on Windows hosts.

I extended the job duration of max 18 hours to make this task finish after >22 hours run time: https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2826366

===> [runRivet] Thu Sep 26 22:11:56 UTC 2019 [boinc pp z1j 7000 150 - sherpa 2.1.1 default 100000 124]

Some comments regarding Theory 5.09 (vbox64_theory) on linux.


1.
Startup is much faster than for the recent production app (vbox).
Very nice.


2.
The app uses a bootstrap that contains some weird commands (for me).

2.1

printf "\033c" & # Clears the console

Why do you send the command to the background?
This causes an additional shell process to be set up just to clear the screen and to terminate that shell immediately after the screen is cleared.
Should work a few us faster without "&".

printf "\033c" 

2.2
Setup the consoles

CP already mentioned that ALT-F2 and ALT-F3 are switched compared to other vbox apps.
This should be streamlined.

bash -c "top 2>&1 >/dev/tty2 2>/dev/null </dev/tty2" &

Looks weird for 2 reasons:
- stderr is redirected twice. Why?
- stdin is redirected from tty2

The latter causes top to be stopped if a user accidentally hits a key at the top console.
I suggest to redirect the input from a console that can't be reached by keybord, e.g. tty13.
The following command works on a VM running opensuse, update delay is extended to 5 s:

bash -c "top -d 5 >/dev/tty3 2>/dev/null </dev/tty13" &

3.
Network
The app's CVMFS is not yet configured to use openhtc.io.
Instead it uses the normal CVMFS-Stratum-Ones.
In addition it bypasses a local proxy.

Both should be solved in future releases.


4.
stderr.txt doesn't include a line like this (CP already mentioned that):

2019-09-26 17:16:01 (5336): Guest Log: [INFO] ===> [runRivet] Thu Sep 26 17:15:43 CEST 2019 [boinc pp jets 8000 600 - pythia8 8.210 default-noCR 100000 124]