qdel(1)
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
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