The following is stated in man pbs_release_nodes
SYNOPSIS
pbs_release_nodes [-j ] -a
(no options)
Without the -j option, pbs_release_nodes uses the value of the PBS_JOBID environment variable as the job ID of the job whose vnodes are to be released.
The following script works correctly.
[test@ohpc137pbsib-sms ~]$ cat sleep_10.sh
#!/bin/bash
#PBS -N sleep_10
#PBS -j oe
sleep 10
ssh ohpc137pbsib-sms pbs_release_nodes -j $PBS_JOBID -a
sleep 10
[test@ohpc137pbsib-sms ~]$ qstat -an
ohpc137pbsib-sms:
Req’d Req’d Elap
Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
932.ohpc137pbsi test workq sleep_10 13925 3 3 – – R 00:00
ohpc137pbsib-c001/0+ohpc137pbsib-c002/0+ohpc137pbsib-c003/0
[test@ohpc137pbsib-sms ~]$
[test@ohpc137pbsib-sms ~]$ qstat -an
ohpc137pbsib-sms:
Req’d Req’d Elap
Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
932.ohpc137pbsi test workq sleep_10 13925 1 1 – – R 00:00
ohpc137pbsib-c001/0
When you do the ssh to ohpc137pbsib-sms and run pbs_release_nodes you are no longer “in” the PBS job from the perspective of the command (PBS_JOBID environment variable is very likely unset in the ohpc137pbsib-sms that results from the ssh connection), so the error message is correct. You should be able to run pbs_release_nodes directly from within the job script (no ssh) without supplying -j.
Setting flatuid=true is one way to allow this, but it does introduce a security situation as now any user who can connect a system to the network and control the user name space on that system can submit a job as any other user. Everything I said in my post at “Where to submit a job instead of pbs server” would also apply here, since the server does the same check of the remote user’s authorization to submit a job (as discussed in that post) as to act on an existing job (such as releasing nodes from it).