QDEL(1)

NAME
qdel - delete or signal NQS request(s).

SYNOPSIS
qdel [ -k ] [ -r request-pattern [ -c ] ] [ -signo ] [ -u username ] [ -v ] request-id ...

DESCRIPTION
Qdel deletes all queued NQS requests whose respective request-id is listed on the command line.

Alternatively, if the -r switch is used, the user can specifiy a request name pattern using grep style patterns. If the -r switch is used, the -c switch may be used to prompt the user for each match of the request pattern. The user will be given the request name and will be prompted as to whether the job should be deleted or not, or if the user wishes to quit. This is supported only for requests running on the local system.

Additionally, if the flag -k is specified, then the default signal of SIGKILL (-9) is sent to any running request whose request-id is listed on the command line. This will cause the receiving request to exit and be deleted. If the flag -signo is present, then the specified signal is sent instead of the SIGKILL signal to any running request whose request-id is listed on the command line. In the absence of the -k and - signo flags, qdel will not delete a running NQS request.

To delete or signal an NQS request, the invoking user must be the owner; namely the submitter of the request. The only exception to this rule occurs when the invoking user is the superuser, or has NQS operator privileges as defined in the NQS manager database. Under these conditions, the invoker may specify the -u username flag which allows the invoker to delete or signal requests owned by the user whose account name is username. When this form of the command is used, all request-ids listed on the command line are presumed to refer to requests owned by the specified user.

An NQS request is always uniquely identified by its request-id, no matter where it is in the network of the machines running NQS. A request-id is always of the form: seqno or seqno.hostname or seqno.hostname@hostname2 where hostname identifies the machine from whence the request was originally submitted, seqno identifies the sequence number assigned to the request on the originating host, and hostname2 identifies the host on which the request is running. Hostname2 is not required if the request is running on the local machine. If the hostname portion of a request-id is omitted, then the local host is always assumed.

The request-id of any NQS request is displayed when the request is first submitted (unless the silent mode of operation for the given NQS command was specified). The user can also obtain the request-id of any request through the use of the qstat(1) command.

The -v switch will print out the version of qdel.

CAVEATS
When an NQS request is signalled by the methods discussed above, the proper signal is sent to all processes comprising the NQS request that are in the same process group. Whenever an NQS request is spawned, a new process group is established for all processes in the request. However, should one or more processes of the request successfully execute a setpgrp() system call, then such processes will not receive any signals sent by the qdel(1) command. This can lead to "rogue" request processes which must be killed by other means such as the kill(1) command. For the UNIX implementations that support the ability to "lock" a process, and all of its progeny into a process-group, NQS will exploit this capability to prevent processes from "escaping" in this manner.

SEE ALSO
qdev(1), qlimit(1), qpr(1), qstat(1), qsub(1),
kill(2), setpgrp(2), signal(2) in the NPSN UNIX System Programmer Reference Manual.
qmgr(1M) in the NPSN UNIX System Administrator Reference Manual.

NPSN HISTORY
Origin: Sterling Software Incorporated

August 1985 - Brent Kingsbury, Sterling Software
Original release.

May 1986
Second release.

August 1994 - John Roman, Monsanto Company
Release 3.36