communication deferred
Anonymous
12 Jan 2013 15:28:45 UTC
Topic 196735
(moderation:
Last night I noticed that einstein was in a "communications deferred" state for 19 hours. Checking the server status i noticed that several servers were "disabled/not running". I am new to this project so this might be normal. Any correlation between server status and the "deferred communication"?
I did notice a post elsewhere about "reduced" brp work units. Related?
This morning I am in a 7 hours deferred comm status.
communication deferred
)
Hi robl, welcome to thw E@H project.
Some of the daemons running (like WU generators for example) only 'run on demand' so it is normal to see some 'not running' from time to time. Your problem is nothing to do with that.
If you look back through your tasks list in the online database and you filter on gamma-ray pulsar tasks (FGRP2), you will find that every single one of them has errored out right from the date you joined. When tasks error like this, your daily quota is reduced temporarily until successful tasks come along and restore it.
It's quite probable that your host made a work request at a time when the quota had been lowered to the point that the server refused to send any more tasks. Your host would have been told to 'back-off' until a new daily quota was available. In the meantime, successful tasks in other searches may very well have restored your quota. The best thing to do to understand why the server put you on 'back-off' is to open BOINC Manager's event log and scroll back through the record. You should be able to find an entry giving all the details. If you have rebooted your machine recently, you will have started a new event log. To see earlier logs you can browse the file 'stdoutdae.txt' in your BOINC Data directory.
Getting back to your errored FGRP2 tasks, if you click on the task name of any one of them on the website, you can see the error message that was returned to the server.
process exited with code 22 (0x16, -234)
execv: No such file or directory
]]>
I think you get this sort of message when libraries are missing. I notice you are using 64 bit Linux. Do you have all the 32 bit compatibility libs installed?
No.
You need to fix the problem with FGRP2 tasks.
Cheers,
Gary.
Its always something! Just
)
Its always something! Just when you think all is well someone points out another "bucket" to look into.
I hunted down (or I think I have) the missing file "execv". I believe its actually defined in a header file called: "unistd.h". The FC 17 package I installed which includes this file is: syslinux-devel-4.05-1.fc17.x86_64. This rpm did install quite a few /path/path/com32/include/file.h(s) I am hoping this fixes the error problems I am having with the noted jobs. I will check to see if the errors go away or at least stop.
If anyone knows of a way for me to test this to determine success or failure let me know.
Bad Linux, BAD, BAD, BAD!!!!
I found two c programs to
)
I found two c programs to test a call to "execv". I offer them here so that others may be able to check out their "execv" environment.
Program 1 - hello.c
#include
main(int argc,char *argv[],char *envp[]){
printf("Filename: %s\n",argv[0]);
printf("%s %s\n",argv[1],argv[2]);
}
compile the above like this: gcc hello.c -o hello
this will produce an executable called "hello"
Program 2 - test.c
#include
#include
#include
main () {
char *temp[] = {NULL,"hello","world",NULL};
temp[0]="hello";
execv("hello",temp);
printf("error");
}
compile this program like: gcc test.c -o test
this will produce an executable called "test"
to test:
./test
the "test" executable will "execv" the "hello" executable outputting data.
The output follows:
Filename: hello
hello world
I am now hopeful that my problem with "execv" are now resolved.
And Gary, thanks for pointing this out to me. I was not ware that I could get results/debug of failed jobs.
Hope this helps,
Ron
My problem with "execv"
)
My problem with "execv" continues. While I can successfully compile code that utilizes "execv" e@h can't find it where it expects it to be.
I am assuming that the problem is in defining the location of unistd.h, a header file that defines execv. In a "C" program I can determine where the required header files are to be located. How would I determine where e@h is expecting them to be located? Or does the boinc application have a defined default? FC 17 has many 32 bit libraries and I would prefer to install the one needed rather then all of them. So is there a way to determine where e@h or the boinc application is expecting the the header files to be located. With this information I can easily identify the missing RPM and install it.
If you can compile the
)
If you can compile the programs ok, unistd.h wasn't the problem (else you'd get an error when trying to build the programs).
Nice to see it looks like it's working for you now anyway.
RE: Nice to see it looks
)
His problem is with the FGRP2 app - not the BRP4 app.
To find the missing lib, why not try 'ldd path/to/FGRP2/app'? That should tell you all libs used and any that are 'not found'. Then install the package for the 'not found' lib(s) from repositories for your distro.
Cheers,
Gary.
FWIW ( IIRC ) 'execv' is the
)
FWIW ( IIRC ) 'execv' is the unix function which ( amongst other things ) forks/launches from some given process. So that's a pretty basic OS function. To build you need to both have and find the right header, find and link to the right library if static, likewise if dynamic.
I note your dev package has an 'x86_64' extension, but you have also mentioned 32 bit libraries. Is that an issue? :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: I note your dev package
)
The app requires certain 32 bit shared libraries to be installed. They are documented in the BOINC Wiki and I should have gone and found the link. My apologies!
robl needs to look here.
EDIT: I was puzzled with the 32 bit libs explanation since BRP4 was running fine but it has suddenly registered that there is a 64 bit BRP4 app so he wouldn't need the libs for that. FGRP2 is 32 bit only and the libs are needed.
Cheers,
Gary.
I think you have it there
)
I think you have it there Gary! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: Nice to see it
)
Oops, my mistake! As a side question if I may, why do some stats (like those) show reported CPU time as 0, and claimed credit as "--"?