| Updated: April 19, 2023 |
Execute a command (for example, on another node or tty) (QNX Neutrino)
on [-A ability-spec] [-ad | -ae] [-C cpunum] [-c] [-d] [-E] [-e key=value] [-h] [-L rlimit:cur[:max]] [-n|f nodename] [-p priority[policy]] [-R runmask] [-S path] [-s] [-T type] [-t tty] [-u uid[:gid[,gid,…] | -u user_name] [-W nsec[:msec]] [-w device] [-Xsched_command] [command [args]]
QNX Neutrino
Note that the lock, inherit, and noinherit operations apply to the ability as a whole; you can't affect the root and non-root domains independently for any of them.
The operation and domain values map to the flags used by procmgr_ability(); for information about the required and allowed flag combinations, see the ability argument for this function and the list of allowable operation and domain flags. The order of the flag settings doesn't matter, and there are no default settings. For instance, if you don't specify either inherit or noinherit, there's no change to the ability's inheritance setting.
on -A root,deny,fork -A nonroot,allow,confset:2 ...
If you specify allow, deny, lock, root, nonroot, or all without an ability name, the action applies to all abilities not specifically mentioned in another -A option. For more information about abilities, see the procmgr_ability() reference.
If you are using a security policy, use the -T option rather than -A to manage which channels the process may attach to. For information about security policies, see the Security Developer’s Guide.
For more information about the limits, see the entry for setrlimit() in the QNX Neutrino C Library Reference.
Priorities are in the range from 0 through 255. Priority 0 is used for the idle thread; by default, priorities of 64 and greater are privileged, so only processes with the PROCMGR_AID_PRIORITY ability enabled (see procmgr_ability() in the C Library Reference) can use them. Unprivileged (and privileged) processes can use priorities from 1 through 63.
You can change the range of privileged priorities with the -P option for procnto.
The scheduling policy must be one of:
If you don't specify a command, the change applies to the parent process.
Runs the command as a given type after looking up the policy for the type in the security policy file; determines its attach rules for the path manager as well as which channels the process may attach to. In this way, the process is launched with respect to policy. Types are defined in the security policy file.
The procmgr ability PROCMGR_AID_SETTYPEID controls the ability of a process to specify a type ID when creating a new process from itself. The procmgr ability PROCMGR_AID_CHANNEL_CONNECT controls attaching/connecting to channels.
For more information about security policies, see the Security Developer’s Guide.
(QNX Neutrino 6.6 or later) You can optionally specify a polling interval, in milliseconds. The default is 100 milliseconds.
If you are attempting to launch a process with a non-root userid, you may require additional procmgr abilities within the on command line. For example, you may want to add the abilities to add physical memory and attach an interrupt if you are launching a serial driver with a non-root userid.
If the -d option isn't specified, a network connection is created as a local agent for the remote child process. When the child terminates, the parent must do a wait() on the created connection to reap the zombie process entry for the child. If the -d option is specified, the command is detached from its parent. The parent isn't able to do a wait() for the child, nor is it able to control it via signals.
By default, the command is run in the current session. The -t option starts a new session, which means the command won't receive a SIGHUP if the current session leader terminates.
The -f vs -n option
The -f and -n options look similar, but they're subtly different. To illustrate this, let's consider two nodes, this_node and that_node. On each node, we'll create a copy of the sleep command, appending the node name; on the this_node node, this looks like this:
cp /usr/bin/sleep /tmp/sleep_this_node
Now, let's run the sleep_that_node command with the -f and -n options:
$ on -f /net/that_node /tmp/sleep_that_node 1 $ on -n /net/that_node /tmp/sleep_that_node 1 on: No such file or directory (/tmp/sleep_that_node)
The first command succeeds because we're using /net/that_node as the network root, and that's where sleep_that_node exists. The second command fails because sleep_that_node doesn't exist on our local node.
$ on -f /net/that_node /tmp/sleep_this_node 1 on: No such file or directory (/tmp/sleep_this_node) $ on -n /net/that_node /tmp/sleep_this_node 1
This time, the first command fails because sleep_this_node doesn't exist on /net/that_node. The second command finds sleep_this_node on the local node, and executes it on /net/that_node.
As a more useful example, let's use pidin to get information about the processes running on that_node:
on -f /net/that_node pidin | less
If you use the -n option instead, like this:
on -n /net/that_node pidin | less
you get information about the processes running on this_node, but the command is executed on that_node.
On a multicore system, you can use a runmask to specify which processors a thread or process can run on. The default is all 1s (i.e., all CPUs).
You can use on to set the runmask and inherit mask for a new process; to change the masks for threads that are already running, use slay. Both commands interpret the -C and -R options in the same way.
You can use more than one -R option to specify a runmask that's more than 32 bits long. The first -R option specifies bits 0 through 31, the second specifies bits 32 through 63, and so on.
If you use both the -C and -R options or multiple instances of them, the resultant mask is the bitwise ORing of all -C and -R options. For example, on -R 0x1 is equivalent to on -C0, and on -R 0x1 -C3 is equivalent to on -C0 -C3. The on command sets the process's runmask and inherit mask to the same value.
For more information about runmasks, see the Multicore Processing chapter of the System Architecture guide, and the Multicore Processing chapter of the QNX Neutrino Programmer's Guide.
Run login on console 2:
on -t con2 login
Run pidin on the node named ruth:
on -n ruth pidin
Run sort as an orphan on the node named peter:
on -d -n peter sort file.dat
Run pidin on node george with a new session, its standard I/O connected to console 1 on node ruth:
on -t /net/ruth/dev/con1 -n george pidin
The on utility exits with the exit status of command. If you specify the -w option, on exits with a status of 0 on success, or a nonzero value if a timeout occurred.