This chapter describes the signaling process. The following topics are discussed:
Signaling your requests (“Signaling Your Requests”)
Signaling another user's requests (“Signaling Another User's Requests”)
 | Note: If you do not have an NQE license, you cannot access the NQE GUI and the cqdel command. You can access only the qdel command from an NQS server. |
For information about deleting running requests by using the cqdel -k command or the qdel -k command, see “Using the cqdel Command or qdel Command to Delete an Executing Request” in Chapter 12.
You can send a signal to any request, whether or not the request is executing. If the request is not yet executing, the request is deleted, no matter which signal is sent.
You can send a signal to one or more of your requests by using either the NQE GUI Status window or the cqdel command or the qdel command.
Standard output, standard error, and job log files are produced for an executing request that is deleted by a signal. These files record the execution of the request up to the moment when the signal is received. The files are returned to the submitting user through the normal output return mechanisms.
If you submitted the request to NQS, an executing request is a request that is in an NQS batch queue and has the letter R (running), H (held), or S (suspended) under the Job Status field of the NQE GUI Status window or under the ST column of the cqstatl or qstat display.
If you submitted the request to the NQE database, an executing request is a request that is in the NQE database and has the letter N (in the NQE database), R (running), H (held), or S (suspended) under the Job Status field of the NQE GUI Status window or under the ST column of the cqstatl or qstat display.
| Note: A request in the NQE database is known as a task and is assigned a task ID (tid). When a copy of the request is executing under NQS, it also is assigned a request ID (requestid), and it is displayed in parentheses after the tid in the NQE GUI Status window Job Identifier field. |
Three of the most common signals that you can send to a request are as follows:
| Signal | Description | |
| SIGINT | Interrupts the executing request, flushes buffers, and displays a traceback. Examples of the SIGINT command follow:
| |
| SIGQUIT | Does the same as SIGINT, but it also writes a core file. | |
| SIGKILL or -k | Kills the executing request and all processes that the request started without flushing I/O buffers, displaying a traceback, or writing a core file. |
However, you can send any valid signal. To catch some signals for error handling or postprocessing, you can include code in the job request script.
The following Korn or standard shell example traps (using trap) the SIGCPULIM signal and copies a data file into the user home directory from $TMPDIR. (For SIGCPULIM, there is a small grace period before the job is killed, during which the user can do some quick clean-up processing.)
#QSUB -s /bin/sh
set -x
postproc ()
{
echo "pp: SIGCPULIM caught"
echo "pp: copying $TMPDIR/data to $HOME/save.data"
cp $TMPDIR/data $HOME/save.data
}
trap postproc 26
echo "begin program that creates file: $TMPDIR/data"
$HOME/bin/program |
You can send a signal to one or more of your requests by using the NQE GUI Status window. For each request you want to signal, highlight the request in the job summary area, select the Actions menu, and then select Signal Job. A dialog box appears and asks you to select a signal to send. Select the signal you want to send by clicking on one of the signal buttons. The dialog box disappears and the job is signaled. A second dialog box will appear with a reply from the signal request. After you review the reply, click on the OK button and the process is complete.
| Note: If your site uses password validation, you must either set the NQS_PASSWORD_NEEDED environment variable or, in the NQE GUI Submit window, select Set Password on the Actions menu to ensure that you are prompted for a password; otherwise, your request will not execute. If you do not set the environment variable or the NQE GUI for password prompting and you use the NQE GUI, the NQE GUI will still prompt you for your password. The password you supply is for the user name under which the request will execute. |
The following is an example of how to signal a request using the NQE GUI.
After you submitted the request to be executed, you received a response similar to one of the following:
If you submitted your request to NQS, you received a response similar to the following:
Request 46.latte submitted to queue: nqenlb
If you submitted your request to the NQE database, you received a response similar to the following:
Task id t4 inserted into database nqedb
To display its status, use the NQE GUI Status window. Figure 13-1 shows an example of the NQE GUI Status window:
Highlight the request in the job summary area, select the Actions menu, and then select Signal Job. A dialog box appears and asks you to select a signal to send. To delete the request, select the SIGKILL signal by clicking on one of the signal buttons. The dialog box disappears and the job is signaled. A second dialog box appears with a reply from the signal request stating that your request was deleted. After you review the reply, click on the OK button.
For a summary of the NQE GUI Status options, see the nqe(1) man page.
You can use only the cqdel command to signal a request from the NQE database. To send a signal to one or more of your own requests, use one of the following command formats; separate a list of NQS request identifiers (requestids) or NQE database task identifiers (tids) with a space:
cqdel [{-k | -s sig_name | -signo}] [requestids |
tids] |
qdel [{-k | -s sig_name | -signo}] requestids |
The -k option sends a SIGKILL signal to the running request.
The -s sig_name and -signo options both send a signal to a request. The only difference is the way in which the signals are specified.
Because various platforms may use different numbers for a given signal, you may want to use the -s option, rather than the signal number, to specify a signal name. If you know the signal number for the platform on which your request is running, however, the -signo option will work equally well.
The requestids argument specifies one or more requests executing under NQS.
The tids argument specifies one or more requests in the NQE database; a request in the NQE database is known as a task and is assigned a task ID (tid).
| Note: If your site uses password validation, you must include the cqdel -P option or set the NQS_PASSWORD_NEEDED environment variable to ensure that you are prompted for a password. The password you supply is for the user name under which the signal request will execute. |
To display a list of all your requests that are still in NQS queues, use the qstat -a command. To tell whether a request is executing, use the qstat requestids command.
To tell whether a request is executing, use the qstat command, as follows:
qstat requests |
% qstat 454.coal ------------------------------- NQS 3.1 BATCH REQUEST SUMMARY ------------------------------- IDENTIFIER NAME USER QUEUE JID PRTY REQMEM REQTIM ST ------------- ------- -------- --------------------- ---- ---- ------ ------ --- 454.coal sleeper snow [email protected] 319 23 192 30 R02 % |
For a summary of the cqdel and the qdel command options, see the cqdel(1) and the qdel(1) man pages.
If your site uses both validation files and password checking, you can delete a request without using a password. NQS will then search for a validation file. For more information on NQS validation, see “NQS Validation Requirements” in Chapter 2.
| Note: For requests submitted to the NQE database, you can signal only the requests in the NQE database that were submitted by the same database user. |
If you use the NQE GUI, you can signal a request by selecting Signal Job on the Actions menu of the NQE GUI Status window as described in “Using the NQE GUI Status Window”.
If you use the cqdel or the qdel command to signal requests you submitted under another user name, use one of the following command formats; separate a list of NQS request identifiers (requestids) or NQE database task identifiers (tids) (used only with the cqdel command) with a space:
cqdel [-k | -s sig_name | -signo] -u username -d nqs requestids |
cqdel [-k | -s sig_name | -signo] -u username -d nqedb tids |
qdel [-k| -s sig_name | -signo] -u username requestids |
| Note: If your site uses password validation, you must include the cqdel -P option or set the NQS_PASSWORD_NEEDED environment variable to ensure that you are prompted for a password. The password you supply is for the user name under which the signal request will execute. |
The following cqdel command signals a request that has identifier 1173.coal submitted by sandy (assuming you are authorized correctly):
cqdel -2 -u sandy 1173.coal |
You will receive the following response:
Request 1173.coal is running and has been signaled. |