perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Alan Whinery writes:

 

After copying pscheduler auth rules from a working toolkit to /etc/postgresql/9.6/main/pg_hba.conf and also copying the limits file from a CentOS toolkit, I am able to run tests to the Beaglebone from a remote pscheduler host, but still unable to intitate tests from the Beaglebone itself.

 

pScheduler is nominally set up to run on PostgreSQL 9.5.  9.6 should not be a problem because the dev team for that project is very good about not breaking things between minor versions.  Where they get weird is by using the version number in the paths to their data files, but there’s probably a reason for it.  I wonder if maybe the Debian packages put the files in the 9.5 subtree or if they adjust for that.

 

[sidebar: how does one check the installed version of pscheduler?]

 

At the moment, the only way to do it is query the package manager.  The major version numbers are currently three behind the perfSONAR release, so what went out as part of 4.1.6 will show as 1.1.6.  We don’t make any of that information available through the API because it could be used to exploit holes in older versions.  (You can ask what API version it is, but that doesn’t identify the exact version of the software.)  A “pscheduler version” command that dumps out a list of the installed packages and their versions is in the pipeline for 4.2.

 

'troubleshoot' gets:

 

>Idle test on localhost... Failed.

>  Unable to post task: Unable to determine participants: Process took too long to run.

 

Does anyone recognize a symptom, or know of a shortcoming that prevents the pscheduler command line from working here?

 

Determining test participants is probably the easiest thing pScheduler does; for the idle test it just runs a short program that picks some things out of the test spec.  If that behavior is consistent, we’d have to get together to see what’s going on.

 

and -- currently limits.conf is a copy of the "identifier-always" example, just to simplify the limits question,

 

Removing the configuration file will disable the limit system entirely.  Limits are not the cause here.

 

--Mark