Custom Query (43 matches)

Hi,

The debian package is quite handy, but it depends in the torque package. The packaging of torque in debian has changed (split in several torque-* and libtorque2*) packages, so this dependency creates a broken situation. You might want to replace it with libtorque2 or libtorque2-dev.

Could you update the package to be compatible with newer distributions?

Best wishes, Guillermo Marcus

It seems that by default, a make install installs the new_rack_pbsmon.py script into $prefix/bin/pbsmon. While this would seem okay, the new_rack_pbsmon.py depends on hostname formats to detect where the nodes are located in the individual racks. The problem here is that not all installation use this hostname format, and users will have to edit the resulting pbsmon script before it will work correctly.

On the other hand, the example pbsmon.py runs without changes regardless of the hostname configuration.

I suggest that a make install installs the pbsmon.py as $prefix/bin/pbsmon instead as it will work on a wider variety of clusters, and give the impression of a cleaner out-of-the-box install.

The quick fix here, to avoid installing new_rack_pbsmon.py is to remove the sara_install target from the Makefile's install line.

pbs_python reports the wrong error codes for responses returned from the server. The error lies in the mapping, and can be easily fixed.

See ​https://github.com/adaptivecomputing/torque/blob/4.2.7/src/include/pbs_error_db.h

For the up-to-date list. The symptoms of this bug cause the error message "Queue already exists" for the "Bad UID for job execution" error among others.

See also: ​http://stackoverflow.com/questions/23410801/torque-pbs-python-submit-job-error-15025-queue-already-exists