Help!
 

I followed Jeff's guide to GGNFS and downloaded all the executables on the right directories.

My machine is a corei5 with Ubuntu 9.10 and Python 2.6 installed.

I get this error:

[code]
-> This is client 1 of 1
-> Using 4 threads
-> Working with NAME = example
-> Error: Polynomial file example.poly does not exist!
-> Found n = 2881039827457895971881627053137530734638790825166127496066674320241571446494762386620442953820735453.
-> Running polynomial selection ...
-> msieve -s example/example.dat -l example/example.log -i example/example.ini -nf example/example.fb -v -np
Traceback (most recent call last):
File "../factmsieve.py", line 1974, in <module>
run_msieve_poly(fact_p)
File "../factmsieve.py", line 905, in run_msieve_poly
elif run_msieve('-v -np'):
File "../factmsieve.py", line 328, in run_msieve
ret = run_exe(MSIEVE, args + ap)
File "../factmsieve.py", line 300, in run_exe
p = subprocess.Popen([ex] + args.split(' '), **al)
File "/usr/lib/python2.6/subprocess.py", line 621, in __init__
errread, errwrite)
File "/usr/lib/python2.6/subprocess.py", line 1126, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

[/code]

I guess it is an error related to the subprocess.py file while creating a pipe, but I just can't handle it :cry: Any hints?

Luigi

Did you edit the paths in facatmsieve.py to point to the locations of msieve and ggnfs. It looks as if the programme did not find the msieve executable file where it expected it to be.

Brian

[QUOTE=Brian Gladman;207566]Did you edit the paths in facatmsieve.py to point to the locations of msieve and ggnfs. It looks as if the programme did not find the msieve executable file where it expected it to be.

Brian[/QUOTE]

I did. msieve and ggnfs executables are in the same directory of factmsieve.py and the example directory (where the example.n is).

[code]
drwxr-xr-x 2 luigi luigi 4096 2010-02-27 14:35 backup
drwxr-xr-x 2 luigi luigi 4096 2010-03-06 17:10 example
-rw-r--r-- 1 luigi luigi 15 2010-03-06 17:09 example.job.resume
-rw-r--r-- 1 luigi luigi 268 2010-03-06 17:10 example.log
-rwxr-xr-x 1 luigi luigi 70071 2010-03-06 17:09 factmsieve.py
-rw-r--r-- 1 luigi luigi 70071 2010-03-06 17:09 factmsieve.py~
-rwxr-x--x 1 luigi luigi 991136 2009-04-15 10:38 gnfs-lasieve4I11e
-rwxr-x--x 1 luigi luigi 974752 2009-04-15 10:34 gnfs-lasieve4I12e
-rwxr-x--x 1 luigi luigi 970656 2009-04-15 10:34 gnfs-lasieve4I13e
-rwxr-x--x 1 luigi luigi 966560 2009-04-15 10:34 gnfs-lasieve4I14e
-rwxr-x--x 1 luigi luigi 958368 2009-04-15 10:34 gnfs-lasieve4I15e
-rwxrwxrwx 1 luigi luigi 1055887 2009-06-10 04:25 gnfs-lasieve4I16e
-rwxr-xr-x 1 luigi luigi 389490 2010-02-21 20:33 msieve
[/code]

I run "python ../factmsieve.py example" from the example directory.

I just noticed that I don't have these files.

[code]
def-nm-params.txt
def-par.txt
[/code]


Luigi

You will certainly need the parameter files but it still looks as if it hasn't found msieve. What are the MSIEVE_PATH and GGNFS_PATH set to?

[QUOTE=Brian Gladman;207581]You will certainly need the parameter files but it still looks as if it hasn't found msieve. What are the MSIEVE_PATH and GGNFS_PATH set to?[/QUOTE]

[code]
# Set binary directory paths

GGNFS_PATH = '../'
MSIEVE_PATH = '../'
[/code]

I tried and inserted the two default parameters files in the directory, and copied a example.fb file in the "example" directory: lasieve was startd without problems, altough the files were in the same directory of msieve.

I also successfully started msieve from command line to check if it was working, and it was.


Luigi

I think the default files are in ggnfs\bin. They are certainly in the ggnfs distribution.

Brian

One thing you could try is to set both the MSIEVE_PATH and the GGNFS_PATH as absolute paths rather than relative ones.

Brian

[QUOTE=Brian Gladman;207587]One thing you could try is to set both the MSIEVE_PATH and the GGNFS_PATH as absolute paths rather than relative ones.

Brian[/QUOTE]

It didn't work either... :cry:

I really don't understand... If I put a correct factorbase file, the script runs happily through the sieving phase, using the GGNFS executables on the same directory where msieve is, while if I run a barebone example.n file, it hangs.

Luigi

Can you show us the latest log where you are using absolute paths for MSIEVE_PATH and GGNFS_PATH? Also show us the diff b/w your factmsieve.py and the original.

It looks like you are on a Unix platform. A few things you can check/try:

1. What happens if you run the large msieve command line (shown in the log) from your example directory? i.e. mimic what factmsieve.py is trying to do.
2. Is . in your current path? If not add it.
3. Does /usr/lib/python2.6/subprocess.py exist?

Note that in order to invoke msieve, factmsieve.py changes directories to where msieve is and reconstructs paths back to the example directory before starting msieve. This is different than how the ggnfs binaries are invoked so I could imagine the ggnfs working and the msieve not.

[QUOTE=tmorrow;207610]Can you show us the latest log where you are using absolute paths for MSIEVE_PATH and GGNFS_PATH? Also show us the diff b/w your factmsieve.py and the original.

It looks like you are on a Unix platform. A few things you can check/try:

1. What happens if you run the large msieve command line (shown in the log) from your example directory? i.e. mimic what factmsieve.py is trying to do.
2. Is . in your current path? If not add it.
3. Does /usr/lib/python2.6/subprocess.py exist?

Note that in order to invoke msieve, factmsieve.py changes directories to where msieve is and reconstructs paths back to the example directory before starting msieve. This is different than how the ggnfs binaries are invoked so I could imagine the ggnfs working and the msieve not.[/QUOTE]

Here is the 2 example.log from ggnfs and example directories:

[code]
Sun Mar 07 01:39:52 2010 -> msieve -s example/example.dat -l example/example.log -i example/example.ini -nf example/example.fb -v -np
-----
Sun Mar 07 01:39:52 2010 -> factmsieve.py (v0.57)
Sun Mar 07 01:39:52 2010 -> This is client 1 of 1
Sun Mar 07 01:39:52 2010 -> Using 4 threads
Sun Mar 07 01:39:52 2010 -> Working with NAME = example
Sun Mar 07 01:39:52 2010 -> Running polynomial selection ...
[/code]

The only differences are in lines 59-62 (paths), 66 (NUM_CPUS) and 68 (USE_CUDA).

1 - msieve is not in my example directory. If I run it from where it is (ggnfs directory) I must add "./" before msieve to run it.
2 - Geee, it worked! :blush::redface: I used to type ./ to run a file.
3 - Yes, the affected python file exists.

Thank you tmorrow (and Brian), and sorry for my inexperience.

Maybe Jeff could add this "trick" in his "HOWTO" tutorial... :smile:

Luigi

Excellent! I had a suspicion that it might be the missing . from the path.

We'll let Brian decide whether he wants to cater for the possibility it in factmsieve.py or whether it should be added as an assumption as to how your environment is setup.

Many tightened Unix systems will not have . in the path for users by default as a security precaution. Most Unix user I know compromise by adding it to the end of their PATH variable rather than at the start. The classic example of the vulnerability is where someone creates a rogue ls program that does something malicious and places it somewhere commonly accessed like the /tmp directory. Any user with . at the front of their path that are in the /tmp directory will unknowingly be accessing the rogue program whenever they type ls. Personally I think the risk is low on the Unix systems I use (either single user Linux systems or company Unix systems behind a company firewall).