Intel Mac Core Duo OSX 10.6.8
7.0.20
too many exit(0)s
Process creation (../../projects/einstein.phys.uwm.edu/einstein_S6LV1_1.10_i686-apple-darwin__SSE2) failed: errno=13
Process creation (../../projects/einstein.phys.uwm.edu/einstein_S6LV1_1.10_i686-apple-darwin__SSE2) failed: errno=13
Process creation (../../projects/einstein.phys.uwm.edu/einstein_S6LV1_1.10_i686-apple-darwin__SSE2) failed: errno=13
Copyright © 2024 Einstein@Home. All rights reserved.
S6LV1 tasks all with computation errors.
)
errno=13 is a permission problem. Is the application binary in the project directory (/Library/Application Support/BOINC Data/projects/einstein.phys.uwm.edu/einstein_S6LV1_1.10_i686-apple-darwin__SSE2) readable & executable?
BM
BM
RE: errno=13 is a
)
It is not showing up as an executable file. It is showing as a document file.
Now I am getting a message
)
Now I am getting a message that no S6LV1 tasks are available even though there seem to be plenty available looking at the server status.
Sat 17 Mar 07:27:34 2012 | Einstein@Home | Scheduler request completed: got 0 new tasks
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work sent
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work is available for Gravitational Wave S6 GC search
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work is available for Gravitational Wave S6 LineVeto search
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work available for the applications you have selected. Please check your preferences on the web site.
RE: Now I am getting a
)
Would I be correct in assuming that you have disabled FGRP tasks for this host?
I have a host on which I've very recently disabled FGRP and I've noticed that it can sometimes take quite a few retries before S6LV1 tasks are sent. Just let BOINC keep retrying and you will get them eventually. Once you have some tasks to crunch, it will be less of a problem if BOINC happens to need several retries before it gets more. If you keep at least a 1 day cache, you shouldn't run out.
You are running a test version of BOINC, 7.0.20. Are you aware of the substantial changes made to the cache setting preferences for these test versions? If you don't know what I'm talking about you could be seeing (depending on your actual settings) some strange work fetch behaviours :-).
EDIT: I've also had a look at your other host which last contacted the server on March 8. You have over 100 tasks on board and none have yet been returned. Do you need any assistance with that host? If you are not able to process those tasks it would be much appreciated if you could abort them and then update the project so that the server can send them out now rather than waiting the full two weeks for them to time out, thanks.
Cheers,
Gary.
I agree that the message you
)
I agree that the message you got is confusing. Actually the reason why you are not getting any tasks may have nothing to do with your app selection. Unfortunately the current scheduler log output isn't very informative either:
[pre]
2012-03-17 11:27:34.0377 [PID=2979 ] [send] stopping work search - locality condition
2012-03-17 11:27:34.0377 [PID=2979 ] [send] stopping work search - locality condition
2012-03-17 11:27:34.0377 [PID=2979 ] [send] stopping work search - locality condition
2012-03-17 11:27:34.0391 [PID=2979 ] [debug] [HOST#4522238] MSG(high) No work sent
2012-03-17 11:27:34.0391 [PID=2979 ] [debug] [HOST#4522238] MSG(high) No work is available for Gravitational Wave S6 GC search
2012-03-17 11:27:34.0391 [PID=2979 ] [debug] [HOST#4522238] MSG(high) No work is available for Gravitational Wave S6 LineVeto search
2012-03-17 11:27:34.0391 [PID=2979 ] [debug] [HOST#4522238] MSG(high) No work available for the applications you have selected. Please check your preferences on the web site.
[/pre]
Actually there are four "locality condition"s that may have failed during "work search". I just changed the scheduler to write more detailed info to the log. This doesn't (yet) change the message that's sent, but at least the scheduler log should give a better idea of what's going wrong.
BM
BM
RE: RE: Now I am getting
)
I disabled FGRP because I was getting a lot of validation errors.
I have a low resource project for when my other main projects don't have any work. So, when there weren't any Einstein tasks available, 6 seconds later BOINC downloaded about 1 weeks worth of tasks from that project, YOYO. This computer won't be going back for more tasks from Einstein for about 1 week.
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work is available for Gravitational Wave S6 GC search
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work is available for Gravitational Wave S6 LineVeto search
Sat 17 Mar 07:27:34 2012 | Einstein@Home | No work available for the applications you have selected. Please check your preferences on the web site.
Sat 17 Mar 07:27:34 2012 | Einstein@Home | [work_fetch] backing off CPU 1291 sec
Sat 17 Mar 07:27:34 2012 | | [work_fetch] Request work fetch: RPC complete
Sat 17 Mar 07:27:40 2012 | | [work_fetch] work fetch start
Sat 17 Mar 07:27:40 2012 | | [work_fetch] set_request(): ninst 2 nused_total 6.000000 nidle_now 0.000000 fetch share 1.000000 req_inst 0.000000
Sat 17 Mar 07:27:40 2012 | | [work_fetch] ------- start work fetch state -------
Sat 17 Mar 07:27:40 2012 | | [work_fetch] target work buffer: 172800.00 + 432000.00 sec
Sat 17 Mar 07:27:40 2012 | CERNVM/Vboxwrapper Test Project | [work_fetch] REC 1.213 priority -0.000000 (no new tasks)
Sat 17 Mar 07:27:40 2012 | climateprediction.net | [work_fetch] REC 0.000 priority -0.000000 (no new tasks)
Sat 17 Mar 07:27:40 2012 | Einstein@Home | [work_fetch] REC 173.284 priority -0.391056 (project backoff 54.97)
Sat 17 Mar 07:27:40 2012 | SETI@home | [work_fetch] REC 19.540 priority -6.139862 (no new tasks)
Sat 17 Mar 07:27:40 2012 | yoyo@home | [work_fetch] REC 189.776 priority -1.130967
Sat 17 Mar 07:27:40 2012 | | [work_fetch] CPU: shortfall 851030.28 nidle 0.00 saturated 165557.39 busy 0.00
Sat 17 Mar 07:27:40 2012 | CERNVM/Vboxwrapper Test Project | [work_fetch] CPU: fetch share 0.000 rsc backoff (dt 0.00, inc 0.00)
Sat 17 Mar 07:27:40 2012 | climateprediction.net | [work_fetch] CPU: fetch share 0.000 rsc backoff (dt 0.00, inc 0.00)
Sat 17 Mar 07:27:40 2012 | Einstein@Home | [work_fetch] CPU: fetch share 0.000 rsc backoff (dt 1286.19, inc 1200.00)
Sat 17 Mar 07:27:40 2012 | SETI@home | [work_fetch] CPU: fetch share 0.000 rsc backoff (dt 0.00, inc 0.00)
Sat 17 Mar 07:27:40 2012 | yoyo@home | [work_fetch] CPU: fetch share 1.000 rsc backoff (dt 0.00, inc 0.00)
Sat 17 Mar 07:27:40 2012 | | [work_fetch] ------- end work fetch state -------
Sat 17 Mar 07:27:40 2012 | yoyo@home | [work_fetch] request: CPU (851030.28 sec, 0.00 inst)
Sat 17 Mar 07:27:40 2012 | yoyo@home | Sending scheduler request: To fetch work.
Sat 17 Mar 07:27:40 2012 | yoyo@home | Reporting 4 completed tasks, requesting new tasks for CPU
Sat 17 Mar 07:27:44 2012 | yoyo@home | Scheduler request completed: got 16 new tasks
Sat 17 Mar 07:27:44 2012 | | [work_fetch] Request work fetch: RPC complete
My minimum work buffer is 2 days, the maximum work buffer is 5 days for this computer. With these work fetch conditions, I won't be getting any Einstein tasks in the foreseeable future.
I have never understood the work fetch for BOINC 7. I used to report difficulties to the test managers, but the replies to me and others was that what we thought were strange work fetch behaviours were normal. So, I have given up on reporting any work fetch problems.
That other host computer is a new one that has never run BOINC. It has a different operating system from my older computer. I was testing that newer operating system with the newer BOINC. That other host is a portable computer. It is quite limited as to when it is allowed to run BOINC; battery, time of day, sleep, etc. So, in reality, it isn't allowed to run BOINC that much. However, I seem to recall that when I installed BOINC on that computer, it connected and downloaded a large number of tasks before I had set up the preferences for the computer or the project. I think that I was correctly following the instructions for installing BOINC on a computer. I also seem to recall when I set up my other computer a few years ago to run BOINC, the process was to set up the preferences for the computer and the individual project before any tasks were downloaded. Perhaps I am mistaken.
Even if that computer were running 24/7, I am not sure that it could complete the tasks that were downloaded when it first contacted the Einstein project.
RE: errno=13 is a
)
The application file, downloaded today, is still being reported as a document file, not an executable file.
Dual core AMD Athlon X2
)
Dual core AMD Athlon X2 QL-64, Kernel~3.3.0-trunk-amd64, Debian/Sid.
All S6LV1 tasks with with the same computation error.
Stderr output:
7.0.15
process exited with code 2 (0x2, -254)
sched_setscheduler: Operation not permitted
execv: No such file or directory
]]>
That might be an access right
)
That might be an access right problem with the alpha BOINC client when copying files. Try the newest version (7.0.15 is pretty old ;-).
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
My Boinc version 7.0.15 is
)
My Boinc version 7.0.15 is the latest one from Debian/Sid!
I never had such issue with the previous Gravitational Wave S6 GC search v1.01 (SSE2)