Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
Message boards :
Sieving :
execv: No such file or directory
| Author |
Message |
|---|
|
|
|
Paid no attention here, I'm sorry. Got loads of failures like this -- checked 40 of them, all the same. That misterious 'file or directory', what is it I'm missing here?
____________
I'm counting for science,
Points just make me sick. | |
|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 436,457,683
RAC: 890,318
                               
|
Paid no attention here, I'm sorry. Got loads of failures like this -- checked 40 of them, all the same. That misterious 'file or directory', what is it I'm missing here?
It's impossible to say from this end, but usually that sort of error is related to the BOINC installation not being correct for some reason. It's usually possible to find and correct the problem, but often the easiest thing is to just remove (completely) the BOINC installation and all BOINC directories and reinstall.
____________
My lucky number is 75898524288+1 | |
|
|
|
It's impossible to say from this end, but usually that sort of error is related to the BOINC installation not being correct for some reason.
I was beeing sarcastic here. I've meant -- wouldn't it be nice, if science app would say what is that thing it's trying to execv?
It's usually possible to find and correct the problem, but often the easiest thing is to just remove (completely) the BOINC installation and all BOINC directories and reinstall.
OK then, I'll reset first. If it doesn't help then I should force yourself to re-install, what's possible. I just don't get it, if debsums is fine with boinc-client then how installation can be somehow messed?
____________
I'm counting for science,
Points just make me sick. | |
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 436,457,683
RAC: 890,318
|
It's impossible to say from this end, but usually that sort of error is related to the BOINC installation not being correct for some reason.
I was beeing sarcastics here. I've meant -- wouldn't it be nice, on science app side, to say what is this thing it's trying to execv?
Assuming the error is coming from the science app, it's the wrapper trying to invoke the sieve. But it could also be the BOINC client trying to invoke the wrapper. Those should be the only two execl()-type calls being made.
In either case, it's usually a problem with the file system, such as a full disk, or, more likely, a problem with permissions on the files or directories. That's why I said that a reinstallation is often the easiest way to fix this kind of error.
As for why it might work on some projects but not others, there's a lot of different "correct" ways for BOINC apps to work. Some use older methods, some newer methods. If there's a problem with the directory permissions, an app that runs the executables directly from the main BOINC directory might work while an app that copies the executable to the slot directory might not work. Both apps are working correctly, but only one would be affected by the permission problem.
____________
My lucky number is 75898524288+1 | |
|
|
|
|
Well, looks like BOINC is full of surprises and television. That's something I can fight with ol' strace. I'll be back soon.
____________
I'm counting for science,
Points just make me sick. | |
|
|
|
|
Well, I would really appreciate a little help here. Just for starters:
ENOENT The file filename or a script or ELF interpreter does not exist, or a shared library needed for file or interpreter cannot be found.
That's a range of causes, what belong here
open("/dev/null", O_RDWR|O_LARGEFILE) = 15
dup2(15, 1) = 1
close(15) = 0
chdir("slots/1") = 0
close(2) = 0
open("stderr.txt", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 2
fstat64(2, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77bb000
fstat64(2, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(2, 0, [0], SEEK_SET) = 0
setpriority(PRIO_PROCESS, 0, 19) = 0
sched_setscheduler(0, 0x3 /* SCHED_??? */, { 0 }) = 0
execve("../../projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu", ["../../projects/www.primegrid.com"...], [/* 42 vars */]) = -1 ENOENT (No such file or directory)
time(NULL) = 1433951754
write(1, "10-Jun-2015 15:55:54 [PrimeGrid]"..., 131) = 131
stat64("stderrdae.txt", 0xfff004d0) = -1 ENOENT (No such file or directory)
stat64("stdoutdae.txt", 0xfff004d0) = -1 ENOENT (No such file or directory)
dup(2) = 15
fcntl64(15, F_GETFL) = 0x8401 (flags O_WRONLY|O_APPEND|O_LARGEFILE)
close(15) = 0
write(2, "execv: No such file or directory"..., 33) = 33
write(1, "10-Jun-2015 15:55:54 [PrimeGrid]"..., 171) = 171
exit_group(22) = ?
And, yes, it is:
$ file projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
No, it's not:
$ ldd projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
not a dynamic executable
I'm still supposed to reinstall?
Any comments?
p.s. Reset doesn't make it any different.
____________
I'm counting for science,
Points just make me sick. | |
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1033
ID: 301928
Credit: 543,624,271
RAC: 5,083
                   
|
|
The error seems to be produced by Boinc itself, so all complains about quality of error messages should go to Berkeley.
1) Did this file have "executable" attribute?
2) Could you run this file yourself from command line? It's safe - without correct setup it will only create "stderr.txt" with some error messages in current directory and silently exit after few seconds.
3) Note that path is relative ("../.."). Somewhere above in the strace output, you should see _successful_ chdir() to one of slot directories ("slots/0", for example). Was this call successful?
4) Be sure that boinc data directory is not a symlink to different location. Also, no subdirectories inside data directory (e.g. "slots") could be symlinks! Symlinks may produce weird effects when used with relative "../"-style paths.
| |
|
|
|
The error seems to be produced by Boinc itself, so all complains about quality of error messages should go to Berkeley.
Indeed error *message* is produced by BOINC. The *error* is produced by kernel what fails to exec wrapper. Post-strace error *message* isn't the issue anymore.
1) Did this file have "executable" attribute?
It would be EPERM then. It's ENOENT instead. Anyway, as you wish:
$ ls -l projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
-rwxr-xr-x 1 boinc boinc 977364 Jun 10 19:52 projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
2) Could you run this file yourself from command line? It's safe - without correct setup it will only create "stderr.txt" with some error messages in current directory and silently exit after few seconds.
As you already see from dump, wrapper can't, literally, do anything. Because it fails to exec. Anyway, as you wish:
$ projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
boinc.sh: projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: No such file or directory
3) Note that path is relative ("../.."). Somewhere above in the strace output, you should see _successful_ chdir() to one of slot directories ("slots/0", for example). Was this call successful?
I've straced with '-ff', there's no 'above'. Dump is what BOINC is doing in just forked process (it's actually clone(2), not fork) up to exiting. And there's chdir(2) at line #4, right between 'close(15)' and 'close(2)'. And yes, it's successful.
4) Be sure that boinc data directory is not a symlink to different location. Also, no subdirectories inside data directory (e.g. "slots") could be symlinks!
What on Earth can make that possible? Anyway, as you wish:
$ find . -lname '*'
./ca-bundle.crt
./global_prefs_override.xml
./cc_config.xml
./gui_rpc_auth.cfg
./remote_hosts.cfg
Symlinks may produce weird effects when used with relative "../"-style paths.
You can't elabortate on this, right?
____________
I'm counting for science,
Points just make me sick. | |
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1033
ID: 301928
Credit: 543,624,271
RAC: 5,083
|
|
Ok, thank you for tests. Unfortunately, it appears that your system itself cannot execute this file, and the reason is still not clear - access rights are ok, chdir was ok (missed it from logs first time):
As you already see from dump, wrapper can't, literally, do anything. Because it fails to exec. Anyway, as you wish:
$ projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
boinc.sh: projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: No such file or directory
I only don't understand what boinc.sh means here? It must be a shell name, right? When I tried to execute non-existing file, I got:
stream@crunchy:~$ .cache/boinc/projects/www.primegrid.com/primegr
-bash: .cache/boinc/projects/www.primegrid.com/primegr: No such file or directory
Unfortunately, I'm afraid that I'm out of ideas and now it only up to you to find why only your system cannot run this wrapper. As I've already noted, you could copy it anywhere, re-download directly from PG site, and try to run from command line until the problem is determined or solved.
4) Be sure that boinc data directory is not a symlink to different location. Also, no subdirectories inside data directory (e.g. "slots") could be symlinks!
What on Earth can make that possible?
Well, in the beginning, I've tried to move slots out to ramdisk (symlinking it) to reduce load of SSD (some wrappers could write status file every second). It failed with weird error messages.
Symlinks may produce weird effects when used with relative "../"-style paths.
You can't elabortate on this, right?
My English is not perfect and I may have misunderstood you, but if you want proofs, it's quite simple:
stream@crunchy:~$ ls -l .cache
lrwxrwxrwx 1 stream stream 38 June 11 23:44 .cache -> /dev/shm/asd-stream/home/stream/.cache
stream@crunchy:~$ ls -l results01.txt
-rw-rw-r-- 1 stream stream 880 May 6 2014 results01.txt
stream@crunchy:~$ cd .cache
stream@crunchy:~/.cache$ cat ../results01.txt
cat: ../results01.txt: No such file or directory
As you can see, the "results01.txt" file "magically" becomes inaccessible via "../"-path - but only if ".cache" is symlink. With normal directories, it'll be no problems. The explanation is quite trivial.
| |
|
|
|
Ok, thank you for tests. Unfortunately, it appears that your system itself cannot execute this file, and the reason is still not clear - access rights are ok, chdir was ok (missed it from logs first time):
Because nothing can be done with binary that fails to exec (except, may be, staring at it), may I have sources very very please? I've googled and found sieve itself, but I need sources of wrapper.
$ projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
boinc.sh: projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: No such file or directory
I only don't understand what boinc.sh means here? It must be a shell name, right?
No. That's how 'bash' manifests errors -- it uses whatever has been set as argv[0] in exeve(2) call. It's, usually, filename of executable itself, but it's not required. 'super' ('sudo' replacement in use) puts there a command name it was requested to do. In this case, it's "boinc.sh".
Well, in the beginning, I've tried to move slots out to ramdisk (symlinking it) to reduce load of SSD (some wrappers could write status file every second). It failed with weird error messages.
You can't do it. BOINC must cope then, it doesn't. And parent directories might be just a minor problem here. If BOINC (or its kind) ever calls rename(2) it will fail because this syscall doesn't work over filesystem boundaries. You should move whole data directory (and you already did that).
stream@crunchy:~$ ls -l .cache
lrwxrwxrwx 1 stream stream 38 June 11 23:44 .cache -> /dev/shm/asd-stream/home/stream/.cache
stream@crunchy:~$ ls -l results01.txt
-rw-rw-r-- 1 stream stream 880 May 6 2014 results01.txt
stream@crunchy:~$ cd .cache
stream@crunchy:~/.cache$ cat ../results01.txt
cat: ../results01.txt: No such file or directory
As you can see, the "results01.txt" file "magically" becomes inaccessible via "../"-path - but only if ".cache" is symlink. With normal directories, it'll be no problems. The explanation is quite trivial.
No, I don't. That's how symlinks work. Abuse doesn't count as weird.
____________
I'm counting for science,
Points just make me sick. | |
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1033
ID: 301928
Credit: 543,624,271
RAC: 5,083
|
|
Look like I missed this:
$ ldd projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
not a dynamic executable
Which OS/distro and kernel version are you using? Look like something is completely incompatible. Here is output on my system (Ubuntu 14.04):
stream@crunchy:~/.cache/boinc$ ldd projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
linux-vdso.so.1 => (0x00007ffc0f5c9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7640891000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7640673000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f76402ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7640bab000)
and this:
stream@crunchy:~/.cache/boinc$ file projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
stream@crunchy:~/.cache/boinc$ md5sum projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
3ecc842f7316d856e341acdaa3cd6ab2 projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
stream@crunchy:~/.cache/boinc$ file ~/boinc/boinc
/home/stream/boinc/boinc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=f833764c2a8bbcc1ce4718dca61af2c5a8649c17, stripped
| |
|
|
|
Look like I missed this:
$ ldd projects/www.primegrid.com/primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
not a dynamic executable
No, you didn't. What I missed is this:
$ ldd projects/www.primegrid.com/primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
not a dynamic executable
And somehow it's not a problem at all:
$ ps w -u boinc
PID TTY STAT TIME COMMAND
1997 ? S 18:18 /usr/bin/boinc --check_all_logins --redirectio --dir /var/lib/boinc-client
2447 ? SNl 7:13 ../../projects/www.primegrid.com/primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
2449 ? RN 13111:55 primegrid_llr -d
11078 ? SNl 0:17 ../../projects/wuprop.boinc-af.org/data_collect_v4_419_i686-pc-linux-gnu__nci -n 360 -c 60 -g 14
11527 pts/11 Ss+ 0:00 tail -F /var/lib/boinc-client/stdoutdae.txt /var/lib/boinc-client/stderrdae.txt
20708 pts/17 S 0:00 boinc.sh
21122 pts/17 R+ 0:00 ps w -u boinc
31267 ? SNl 7:25 ../../projects/www.primegrid.com/primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
31269 ? RN 13338:31 primegrid_llr -d
31270 ? SNl 7:34 ../../projects/www.primegrid.com/primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
31272 ? RN 13338:23 primegrid_llr -d
Which OS/distro and kernel version are you using?
You don't want to get into it.
Look like something is completely incompatible.
Well, if you insist, then:
$ cat /proc/version ; ldd --version
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2
ldd (Debian EGLIBC 2.13-38) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
And this is from other host, which one is totally fine:
% cat /proc/version ; ldd --version
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2
ldd (Debian EGLIBC 2.13-38) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
May I have sources of sr2sieve_wrapper very very please?
____________
I'm counting for science,
Points just make me sick. | |
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1033
ID: 301928
Credit: 543,624,271
RAC: 5,083
|
$ ldd projects/www.primegrid.com/primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
not a dynamic executable
And somehow it's not a problem at all:
Because it's not a dynamic. llr wrapper is static 32-bit executable:
$ file primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu
primegrid_llr_wrapper_6.24_x86_64-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=12569339d2bf58991ba8ddcc08f2a0180a681e69, not stripped
but sieve wrapper is dynamic and 64-bit:
$ file primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu
primegrid_sr2sieve_wrapper_1.07_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
and ldd must print something. But for unknown reason, your system does not recognizes second file as executable. Sorry, but I'm out of general ideas.
May I have sources of sr2sieve_wrapper very very please?
I don't know is this source available or not. You have to ask somebody from PG stuff/developers.
| |
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1033
ID: 301928
Credit: 543,624,271
RAC: 5,083
|
|
Look like there are similar topics
http://unix.stackexchange.com/questions/13391/getting-not-found-message-when-running-a-32-bit-binary-on-a-64-bit-system
http://stackoverflow.com/questions/1562071/how-can-i-find-which-elf-dependency-is-not-fulfilled
shows that error can be produced by missing kernel loader (which is requested by application using full path, stored inside executable)
Wrapper requires kernel loader /lib64/ld-linux-x86-64.so.2
Do you have this directory and file on your system? is it reachable by boinc installation? (asking to exclude trivial cases like something wrong with access rights, or chroot'ed environment used)
On mine, this file is a only one in /lib64, it's just a symlink to current system loader:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.19.so
| |
|
|
|
Look like there are similar topics
Too bad SO doesn't serve elinks for couple of years.
On mine, this file is a only one in /lib64, it's just a symlink to current system loader:
ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.19.so
I've got on this puzzle too after last week iteration. Now I must wait for more ten days or such before attempting another fix.
I don't know is this source available or not. You have to ask somebody from PG stuff/developers.
Wouldn't it be so much easier if sources were readily available, instead of messing around in darkness for a month? Never mind, it's just an old man muttering around.
____________
I'm counting for science,
Points just make me sick. | |
|
|
|
Wouldn't it be so much easier if sources were readily available, instead of messing around in darkness for a month? Never mind, it's just an old man muttering around.
The sources for the wrappers are available on SourceForge http://sourceforge.net/p/primegrid/, I'm not 100% sure they are fully up-to-date, but they may be of some help/interest to you!
Cheers
- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime! | |
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 436,457,683
RAC: 890,318
|
Wouldn't it be so much easier if sources were readily available, instead of messing around in darkness for a month? Never mind, it's just an old man muttering around.
The sources for the wrappers are available on SourceForge http://sourceforge.net/p/primegrid/, I'm not 100% sure they are fully up-to-date, but they may be of some help/interest to you!
Cheers
- Iain
ONLY the sr2sieve wrapper in that archive is still in use. That's the one you're looking for. The other two sieve wrappers are no longer used because those sieves are now native BOINC apps.
That source is definitely on the ancient side, but I believe it's what we're currently using. The executable files on the server are from 2009.
____________
My lucky number is 75898524288+1 | |
|
|
|
|
Well, that's something interesting. Now I have better understanding of nature of this mystery. However, I still must wait for 3.62day before I can try another approach.
____________
I'm counting for science,
Points just make me sick. | |
|
|
|
|
As you can imagine, due client doing-its-thing, it took about 10day :) Anyway,..
My understanding (based mostly on conspirology) is like this. None of my systems, in spite of what client reports, is actually amd64. They're 64bit kernel, plus 32bit libc built for i686, and usual 32bit userspace. Now, llr_wrapper, in spite of being delivered as 64bit, is actually 32bit or weak form of 64bit (how that happens can be understood from routine, for building warppers, provided by BOINC itself). However, sr2sieve_wrapper is a serious 64bit, no options (probably, due changes in the routine that happened over time). (I believe, that sr2sieve_wrapper binary is younger than llr_wrapper binary.)
Now, debian provides another layer of psychosis known as libc built for running 64bit code in 32bit userspace on 64bit kernel. It was installed, prematurely, and then purged because it was always popping out in deborphan output. Turns out, it was premature too. How I would have expected?
____________
I'm counting for science,
Points just make me sick. | |
|
|
|
|
Yes, it's a bit confusing, isn't it? As far as the hardware (CPU architecture) goes, PG currently supports x86-64 (a.k.a "AMD64", "AMD x86-64", and some other designations), which is the 64-bit instruction set used by Intel and AMD. "AMD" got into the name because originally there was something of a tug-of-war between Intel and AMD over the exact specifications of a 64-bit instruction set, and AMD won when Intel caved. Anyway, there's no implication as to the actual manufacturer.
Any designation like just "x86" is a 32-bit CPU architecture. This is also supported at Primegrid.
There are of course other CPU architectures, like PowerPC and SPARC. But those aren't usable here; though one would see them in specialized, generally non-boinc, situations.
-------------
All of the above being said, failure of PG apps to run is generally caused by outdated O/S versions, conflicting libraries, and stuff like that at the user-space level, not a lack of support for a particular CPU.
OK enough rambling from me. I've been away for a while and felt a surge of blather coming on :-)
--Gary | |
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 436,457,683
RAC: 890,318
|
|
For anyone who is interested, I put up a list of the source code repositories for the software used at PrimeGrid:
http://www.primegrid.com/forum_thread.php?id=6359
____________
My lucky number is 75898524288+1 | |
|
Message boards :
Sieving :
execv: No such file or directory |
