neulab/tldr huggingface dataset:
XAUTHPATH specifies the path to xauth
CLIENTRETRY specifies the integer seconds between retry attempts to communicate with pbs_server
VALIDATEGROUP set this parameter to force qsub to verify the submitter's group id
DEFAULTCKPT specifies the default value for the jobs checkpoint attribute.  The user overrides this with the -c qsub option.
VALIDATEPATH set this parameter to force qsub to validate local existence of a "-d" working directory
RERUNNABLEBYDEFAULT this parameter specifies if a job is rerunnable by default. The default is true, setting this to false causes the rerunnable attribute value to be false unless the users specifies otherwise with the -r option
FAULT_TOLERANT_BY_DEFAULT this parameter specifies if a job is fault tolerant by default.  The default value for the fault_tolerant job attribute is false, setting this parameter to true causes the default value of the attribute to be true. The user can specify their preference with the -f qsub option.
For example: QSUBSLEEP  2 RERUNNABLEBYDEFAULT  false
Script Processing:
A job script may consist of PBS directives, comments and executable statements.  A PBS directive provides a way of specifying job attributes in addition to the command line options.  For example: : #PBS -N Job_name #PBS -l walltime=10:30,mem=320kb #PBS -m be # step1 arg1 arg2 step2 arg3 arg4
The qsub command scans the lines of the script file for directives.  An initial line in the script that begins with the characters "#!" or the character ":" will be ignored and scanning will start with the next line. Scanning will continue until the first executable line, that is a line that is not blank, not a directive line, nor a line whose first non white space character is "#".  If directives occur on subsequent lines, they will be ignored.
A line in the script file will be processed as a directive to qsub if and only if the string of characters starting with the first non white space character on the line and of the same length as the directive prefix matches the directive prefix.
The remainder of the directive line consists of the options to qsub in the same syntax as they appear on the command line.  The option character is to be preceded with the "-" character.
If an option is present in both a directive and on the command line, that option and its argument, if any, will be ignored in the directive.  The command line takes precedence.
If an option is present in a directive and not on the command line, that option and its argument, if any, will be processed as if it had occurred on the command line.
The directive prefix string will be determined in order of preference from:
The value of the -C option argument if the option is specified on the command line.
The value of the environment variable PBS_DPREFIX if it is defined.
The four character string #PBS.
If the -C option is found in a directive in the script file, it will be ignored.
User Authorization:
When the user submits a job from a system other than the one on which the PBS Server is running, the name under which the job is to be executed is selected according to the rules listed under the -u option.  The user submitting the job must be authorized to run the job under the execution user name.  This authorization is provided if
(1)  The host on which qsub is run is trusted by the execution host (see /etc/hosts.equiv),
(2)  The execution user has an .rhosts file naming the submitting user on the submitting host.
C-Shell .logout File:
The following warning applies for users of the c-shell, csh.  If the job is executed under the csh and a .logout file exists in the home directory in which the job executes, the exit status of the job is that of the .logout script, not the job script.  This may impact any inter-job dependencies.  To preserve the job exit status, either remove the .logout file or place the following line as the first line in the .logout file set EXITVAL = $status and the following line as the last executable line in .logout exit $EXITVAL
Interactive Jobs:
If the -I option is specified on the command line or in a script directive, or if the "interactive" job attribute declared true via the -W option, -W interactive=true, either on the command line or in a script directive, the job is an interactive job.  The script will be processed for directives, but will not be included with the job.  When the job begins execution, all input to the job is from the terminal session in which qsub is running.
When an interactive job is submitted, the qsub command will not terminate when the job is submitted.  Qsub will remain running until the job terminates, is aborted, or the user interrupts qsub with an SIGINT (the control-C key).  If qsub is interrupted prior to job start, it will query if the user wishes to exit.  If the user response "yes", qsub exits and the job is aborted.
Once the interactive job has started execution, input to and output from the job pass through qsub.  Keyboard generated interrupts are passed to the job.  Lines entered that begin with the tilde ('~') character and contain special sequences are escaped by qsub.  The recognized escape sequences are:
~.     Qsub terminates execution.  The batch job is also terminated.
~susp  Suspend the qsub program if running under the C shell. "susp" is the suspend character, usually CNTL-Z.
~asusp Suspend the input half of qsub (terminal to job), but allow output to continue to be displayed.  Only works under the C shell.  "asusp" is the auxiliary suspend character, usually CNTL-Y.
Upon successful processing, the qsub exit status will be a value of zero.
If the qsub command fails, the command exits with a value greater than zero.
qalter(1B), qdel(1B), qhold(1B), qmove(1B), qmsg(1B), qrerun(1B), qrls(1B), qselect(1B), qsig(1B), qstat(1B), pbs_connect(3B), pbs_job_attributes(7B), pbs_queue_attributes(7B), pbs_resources_irix5(7B), pbs_resources_sp2(7B), pbs_resources_sunos4(7B), pbs_resources_unicos8(7B), pbs_server_attributes(7B), and pbs_server(8B)
EXTRACE(1)                 BSD General Commands Manual                EXTRACE(1)
extrace — trace exec() calls system-wide
extrace [-deflqtu] [-o file] [-p pid | cmd ...]
extrace traces all program executions occurring on a system.
-d      Print the current working directory of the new process.
-e      Print environment of process, or ‘-’ if unreadable.
-f      Generate flat output without indentation.  By default, the line indentation reflects the process hierarchy.
-l      Resolve full path of the executable.  By default, argv[0] is shown.
-q      Suppress printing of exec(3) arguments.
-t      Also display process exit status and duration.
-u      Also display the user running the process.
-o file Redirect trace output to file.
-p pid  Only trace exec(3) calls descendant of pid.
cmd ... Run cmd ... and only trace descendants of this command.
By default, all exec(3) calls are traced globally.
The extrace utility exits 0 on success, and >0 if an error occurs.
Check these prerequisites if you see this error:
binding sk_nl error: Operation not permitted
extrace requires special permissions to run, either root or the Linux CAP_NET_ADMIN capability.
extrace only works on Linux kernels with the kernel options
CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y
fatrace(1), ps(1), pwait(1), strace(1)
Leah Neukirchen <leah@vuxu.org>
May contain traces of code from Guillaume Thouvenin, Matt Helsley, and Sebastian Krahmer.
While process tracing is exact, looking up all information is inherently sensitive to race conditions.  In doubt, you can only trust the PID was written correctly.
extrace is licensed under the terms of the GPLv2.
SHA384SUM(1)                      User Commands                     SHA384SUM(1)
sha384sum - compute and check SHA384 message digest
sha384sum [OPTION]... [FILE]...
Print or check SHA384 (384-bit) checksums.
The sums are computed as described in FIPS-180-2.  When checking, the input should be a former output of this program.  The default mode is to print a line with: checksum, a space, a character indicating input mode ('*' for binary, ' ' for text or where binary is insignificant), and name for each FILE.
Full documentation <https://www.gnu.org/software/coreutils/sha384sum> or available locally via: info '(coreutils) sha2 utilities'
CLARIFY(1)                   General Commands Manual                  CLARIFY(1)
edgepaint - edge coloring to disambiguate crossing edges
[ options ] [ -o outfile ] [ files ]
edgepaint takes as input a graph in DOT format with node position information (the pos attribute) and colors the edges in a manner making it easier to tell them apart.
--accuracy=e Accuracy with which to find the maximally different coloring for each node with regard to its neighbors. Default e = 0.01.
--angle=a Color two edges differently if their incidence angle is less than a degrees. Default a = 15.
--random_seed=s Random seed to use. s must be an integer. If s is negative, we do |s| iterations with different seeds and pick the best.
--lightness=l1,l2 Only applies for the "lab" color scheme: l1 and l2 must integers, with 0 <= l1 <= l2 <=100. By default, we use "0,70".
--share_endpoint If this option is specified, edges that share a node are not considered in conflict if they are close to parallel but are on the opposite sides of the node (around 180 degree).
-o f   Write output to file f (default: stdout).
--color_scheme=c Specifies the color scheme.  This can be "rgb", "gray", "lab" (default); or a comma-separated list of RGB colors in hex (e.g., "#ff0000,#aabbed,#eeffaa") representing a palette; or a string specifying a Brewer color scheme (e.g., "accent7"; see https://graphviz.org/doc/info/colors.html#brewer).
-v     Turns on verbose mode.
At present, edgepaint does not handle graphs with loops or directed multiedges. So, a graph with edges a -> b and b -> a is acceptable, but not if it has edges a -> b and a -> b or a -- b and a -- b. Ports are ignored in this analysis, so having a.x -> b and a.y -> b is also not supported.
Yifan Hu <yifanhu@yahoo.com>
gvmap(1), sfdp(1), neato (1), dot(1)
GIT-COUNT-OBJECTS(1)               Git Manual               GIT-COUNT-OBJECTS(1)
git-count-objects - Count unpacked number of objects and their disk consumption
git count-objects [-v] [-H | --human-readable]
This counts the number of unpacked object files and disk space consumed by them, to help you decide when it is a good time to repack.
-v, --verbose Report in more detail:
count: the number of loose objects
size: disk space consumed by loose objects, in KiB (unless -H is specified)
in-pack: the number of in-pack objects
size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
prune-packable: the number of loose objects that are also present in the packs. These objects could be pruned using git prune-packed.
garbage: the number of files in object database that are neither valid loose objects nor valid packs
size-garbage: disk space consumed by garbage files, in KiB (unless -H is specified)
alternate: absolute path of alternate object databases; may appear multiple times, one line per path. Note that if the path contains non-printable characters, it may be surrounded by double-quotes and contain C-style backslashed escape sequences.
-H, --human-readable Print sizes in human readable format
Mono(sn)                                                                Mono(sn)
sn - Digitally sign/verify/compare strongnames on CLR assemblies.
sn [-q | -quiet] [options] [parameters]
Digitally sign, verify or compare CLR assemblies using strongnames.
You can use the sn command to create "snk files" using the -k option described below.
Configuration options are stored in the machine.config configuration file under /configuration/strongNames.
-c provider Change the default CSP (Crypto Service Provider). Currently not supported in Mono.
-m [y|n] Use a machine [y] key container or a user [n] key container. Currently not supported in Mono.
-Vl    List the verification options. The list is kept under /configuration/ strongNames/verificationSettings in machine.config.
-Vr assembly [userlist] Exempt the specified assembly from verification for the specified user list.  Currently not supported by sn. You must edit machine.config manually if you require this.
-Vu assembly Remove the exemption entry for the specified assembly. Currently not supported by sn, you must edit machine.config manually if you require this.
-Vx    Remove all exemptions entries. Currently not supported by sn, you must edit machine.config manually if you require this.
-d container Delete the keypair present in the specified key container.
-i keypair.snk container Import the specified strongname file into the specified container.
-pc container publickey Export the public key from the specified CSP container to the specified file.
-e assembly output.pub Export the assembly public key to the specified output file.
-p keypair.snk output.pub Export the public key from the specified strongname key file (SNK) or from a PKCS#12/PFX password protected file to the specified output file.
-o input output.txt Convert the input file to a CSV file (using decimal).
-oh input output.txt Convert the input file to a CSV file (using hexadecimal).
-D assembly1 assembly2 Compare if assembly1 and assembly2 are the same except for their signature.  This is done by comparing the hash of the metadata of both assemblies.
-k [size] keypair.snk Create a new strongname keypair in the specified file. The default key length is 1024 bits and MUST ALWAYS be used when signing 1.x assemblies.  Any value from 384 to 16384 bits (in increments of 8 bits) is a valid key length to sign 2.x assemblies. To ensure maximum compatibility you may want to continue using 1024 bits keys. Note that there's no good reason, even if it's possible, to use length lesser than 1024 bits.
-R assembly keypair.snk Re-sign the specified assembly using the specified strongname keypair file (SNK) or a PKCS#12/PFX password protected file. You can only sign an assembly with the private key that matches the public key inside the assembly (unless it's public key token has been remapped in machine.config).
-Rc assembly container Re-sign the specified assembly using the specified strongname container.
-t file Show the public key token from the specified file.
-tp file Show the public key and the public key token from the specified file.
-T assembly Show the public key token from the specified assembly.
-Tp assembly Show the public key and the public key token from the specified assembly.
-v assembly Verify the specified assembly signature.
-vf assembly Verify the specified assembly signature (even if disabled).
-h , -? Display basic help about this tool.
-h config , -? config Display configuration related help about this tool.
-h csp , -? csp Display Cryptographic Service Provider related help about this tool.
-h convert , -? convert Display conversion related help about this tool.
-h sn , -? sn Display strongname related help about this tool.
Strongnames configuration is kept in "machine.config" file. Currently two features can be configured.
/configuration/strongNames/pubTokenMapping This mechanism lets Mono remap a public key token, like the ECMA token, to another public key for verification. This is useful in two scenarios. First, assemblies signed with the "ECMA key" need to be verified by the "runtime" key (as the ECMA key isn't a public key). Second, many assemblies are signed with private keys that Mono can't use (e.g. System.Security.dll assembly).  A new key cannot be used because it should change the strongname (a new key pair would have a new public key which would produce a new token). Public key token remapping is the solution for both problems. Each token must be configured in a "map" entry similar to this one: <map Token="b77a5c561934e089" PublicKey="00..." />
/configuration/strongNames/verificationSettings It is often useful during development to use delay signed assemblies.  Normally* the runtime wouldn't allow delay-signed assemblies to be loaded.  This feature allows some delay-signed assemblies (based on their public key token, optionally assembly name and user name) to be used like they were fully signed assemblies. [*] Note that Mono 1.0 "runtime" doesn't validate strongname signatures so this option shouldn't be required in most scenarios.
Written by Sebastien Pouliot
Copyright (C) 2003 Motus Technologies.  Copyright (C) 2004 Novell. Released under BSD license.
Visit http://lists.ximian.com/mailman/listinfo/mono-list for details.
secutil(1)
ipcalc(1)                    General Commands Manual                   ipcalc(1)
ipcalc - An IPv4 Netmask/broadcast/etc calculator
ipcalc  [options] ADDRESS[[/]NETMASK] [NETMASK]
ipcalc takes an IPv4 address and netmask and calculates the resulting broadcast, network, Cisco wildcard mask, and host range. By giving a second netmask, you can design sub- and supernetworks. It is also intended to be a teaching tool and presents the results as easy-to- understand binary values.
--help Display help usage
-n, --nocolor Don't display ANSI color codes
-b, --nobinary Suppress the bitwise output
-c, --class Just print bit-count-mask of given address
-h, --html Display results as HTML
-v, --version Print Version
-s, --split n1 n2 n3. Split into networks of size n1, n2, n3
-r, --range Deaggregate address range
ipcalc 192.168.0.1/24
ipcalc 192.168.0.1/255.255.128.0
ipcalc 192.168.0.1 255.255.128.0 255.255.192.0
ipcalc 192.168.0.1 0.0.63.255
deaggregate address range ipcalc <ADDRESS1> - <ADDRESS2>
split network to subnets where a b c fits in ipcalc <ADDRESS>/<NETMASK> -s a b c
Written by Krischan Jodies <krischan@jodies.de>
ipsc(1) gipsc(1)
The ipcalc website: http://jodies.de/ipcalc
rig(1)                       General Commands Manual                      rig(1)
rig - Monitor a system for events and trigger specific actions
rig <RESOURCE OR SUBCOMMAND> [OPTIONS] <ACTIONS> [ACTION OPTIONS]
rig is a tool to assist in troubleshooting seemingly randomly occurring events or events that occur at times that make active monitoring by a sysadmin difficult.
rig sets-up detached processes, known as 'rigs', that watch a given resource for a trigger condition, and once that trigger condition is met takes actions defined by the user.
The following are options available to all rigs (resources).
--delay DELAY Specify the number of seconds to wait after a rig is triggered before running the configured actions. Note that the rig will still trigger and stop all watcher threads immediately - this delay comes after thread termination but before action execution in order to avoid a possible race condition where multiple watcher threads could conceivably trigger during a sufficiently high delay time.
Default 0 seconds, meaning execute actions immediately upon rig trigger condition being met.
--debug Set logging level to debug instead of the default info level.
--foreground Run the rig in the foreground, keeping stdout attached.
--interval SECONDS Specify the amount of time to wait between a rig's polling cycles. Most rigs monitor their resources in a flow of update -> compare -> wait, where wait is simply sleeping until the next needed update. Use this option to set how long a rig should wait/sleep before updating their monitors again.
Default: 1, meaning update and compare once every second.
--name NAME Give the rig a name, rather than generating a random one at deployment.
By default, rigs are given a randomly generated string as a name, which will appear in rig info output and in the rig's socket name. Using this option will use the provided name instead, and may be useful in distinguishing rigs when several are deployed at one time
--no-archive Do not create a tar archive of the collected data after a rig has been triggered.
Normally, once all data has been collected, rig will create a gzip'd tar archive under /var/tmp containing all the files created from the rig's actions - after which, the temp directory at /var/tmp/rig/<id>/ is deleted.
Using this option skips creating the archive and preserves the temp directory.
--repeat COUNT Repeat certain actions COUNT number of times after the initial execution of the action.
Actions will, unless otherwise specified by this option, only execute once. Using this option actions that support repetition will be repeated an additional COUNT number of times. For example, using --repeat 2 will result in repeatable actions being executed three (3) total times.
Not every action supports repetition - in fact most do not. See specific action's sections for information on if it can be repeated or not.
--repeat-delay SECONDS Number of seconds to wait between repetitive executions of the same action.
This can be useful when using an action like gcore when you want to get coredumps over a certain time period. For example, using --repeat 1 --repeat-delay 60 will give you two (2) coredumps taken one minute apart.
Defaults to one second.
--restart COUNT Restart a configured rig up to COUNT number of times after being triggered.
By default, a rig will trigger once and then terminate. Using this option, an individual rig may restart itself up to COUNT number of times, producing an additional archive of the requested data after the triggering event happens again.
Note that this is the number of times to restart, not the total number of times to run. Using a restart value of '2' means that there will be 3 total archives generated for a rig.
By default, this is set to 0, meaning terminate after the first trigger event.  Use a value of '-1' to have a rig perpetually restart itself without limit.
rig list Show a list of known existing rigs and their status. Status information is obtained by querying the socket created for that particular rig.
rig destroy -i [ID or 'all'] Destroy a deployed rig with id ID. If ID is 'all', destroy all known rigs. Note that if another entity kills the pid for the running rig, destroy will fail as the socket is no longer connected to the (now killed) process. In this case use the --force option to cleanup the lingering socket.
rig info -i [ID] Get detailed information on a rig. This information will include configuration options, the entire cmdline string given to launch the rig, as well as information on each action the rig is configured to take and what the expected result from those action(s) are.
Currently, this data is written to stdout in JSON format.
rig trigger -i [ID] Manually trigger rig with id ID. This will cause the specified rig to begin executing the actions configured for it, as if the trigger condition had been met.
Note that this is only effective on a single rig basis, so using a value of 'all' for the ID will not work.
These are the system resources that rig can monitor. There may be additional manpages for specific resources. Where applicable this will be noted below.
Note that 'resources', 'monitors', and referencing 'a rig' as a distinct entity all refer to the same thing.
When creating a rig, if successful the rig's ID will be printed to console.
logs   Watch a single or multiple log files and/or journald units for a specified message. When that message is matched to any watched file or journal, the trigger condition is met and configured actions are initiated.
The following options are available for the logs rig:
-m|--message STRING Define the string that serves as the trigger condition for the rig. This can be a regex string or an exact message. Be very careful in using the '*' regex character as this may cause unintended behavior such as the rig immediately triggering on the first message seen.
Note that a small amount of transformation and testing is done on the provided STRING.  First, '*' characters are converted to the python-style regex match of '.*'. After which, rig performs a test on if the provided message will regex-match itself, and if that fails the rig aborts the creation process.
Aside from the conversion noted above, regexes provided in this option must be python-style and not shell-style.
--logfile FILE A comma-delimited list of files to watch. Each FILE specified will be monitored from the current end of the file, so old entries will not set off the rig's actions.
Default: /var/log/messages
--no-files Do not monitor any log files.
--journal UNIT A comma-delimited list of journal units to watch. The journal is watched as a singular entity, and will be filtered to only read from the provided UNIT(s).  If no UNIT is specified, the whole system journal will be monitored.
Default: 'system'
--no-journal Do not monitor the journal.
--count COUNT The number of times the --message string should be matched before the rig is triggered. Default 1 - meaning match on the first occurence.
ping   Perform a simple ongoing ping test against a specified host. Pings are sent one at a time at a defined interval, and the response is evaluated. Ping-type rigs may monitor for number of lost packets and/or packets exceeding a specified RTT in milliseconds.
Packets are first evaluated for loss (including timeouts), then for RTT time.
The following options are available for the ping rig:
--host ADDRESS The target IP or hostname to ping. This is a required option in order for a ping rig to be created.
During rig creation, a 'sanity check' ping is sent to the ADDRESS to ensure that it is an address that is reachable on the network and that it will respond to ICMP packets. If this sanity check fails, rig creation is aborted.
--ping-timeout SECONDS Specify the number of SECONDS to allow for a ping response. If a ping encounters a timeout, then it is considered both a lost packet and a packet exceeding the RTT threshold (see --ping-ms-max and --ping-ms-count).
--lost-count PACKETS Specify the number of PACKETS to accept being lost or timed-out, before triggering the rig.
Default: 1 (trigger on the first lost packet)
--ping-interval SECONDS Specify the number of SECONDS to wait between ping requests sent to the target host.
--ping-ms-max MILLISECONDS Specify the RTT threshold to allow for a returned ping request. If the RTT reported by the ping command is above this value in milliseconds, it is counted against the threshold of packets exceeding this value specified by --ping-ms-count.
By default, this form of checking is disabled. Any integer value passed to this option will enable RTT monitoring.
--ping-ms-count PACKETS Specify the number of PACKETS that may exceed the defined --ping-ms-max RTT value before triggering the rig.
process Watch a single process or list of processes for state changes or resource consumption thresholds. When the process enters the specified state or the specified resource consumption threshold is met, the trigger condition is met.
The following options are available for the process rig:
--proc A PID or process name of processes to watch. If a process name is specified, then rig will attempt to convert this to a PID during rig creation. If multiple PIDs are found, the default behavior is to fail creation and exit. To have rig monitor all processes found for a process name, use the --all option.
--state STATE The state that a process needs to be in, in order to trigger the rig. The following is a list of supported states:
NAME         DESCRIPTION                      SHORTHAND dead         Dead - should never be seen         'X' disk-sleep   Uninterruptible sleep           'D' or 'UN' running      Currently running               'R' or 'run' sleeping     Interruptible sleep             'S' or 'sleep' stopped      Stopped                         'T' or 'stop' zombie       Exited, still in proc table     'Z' or 'zomb'
Users can use either the full status name, or the shorthand noted in the final column of the table above. Both the names and the shorthand values are case sensitive.
This can also be set to a "not" value by preceeding one of the above state strings with a exclaimation mark (!), e.g. '!sleeping' will match any non-sleep (S) state status for the process(es). Most shells will require you to quote the state string when using the '!' character.
Note that using '!running' will cause rig to not trigger against a state of 'sleeping', as generally speaking 'running' processes spend much of their time in S state, and it is assumed that triggering against such a process is not desired.
Process status is polled once every second.
--rss INTEGER The amount of rss (resident set size) memory usage to use as a threshold for triggering the rig. If the process' RSS usage goes above this value, trigger.
The value provided here may be suffixed with K, M, or G to denote the IEC unit.  Rig will convert the provided value and suffix into a value in bytes.
--vms INTEGER The same as --rss but monitoring Virtual Memory Size instead.
--memperc PERCENT The percentage of total system memory a process is consuming to use as a threshold for triggering the rig. If the process' %mem meets or exceeds this value, trigger.
PERCENT may be a whole integer or a float. When using a float, the process rig respects up to two (2) decimal points of precision. For example, using ´--memperc 10.25´ is the same as using ´--memperc 10.25678´.
--cpuperc PERCENT The percentage of CPU usage a process is consuming to use as a threshold for triggering the rig. If the process' %cpu meets or exceeds this value, trigger.
PERCENT may be a whole integer or a float. When using a float and monitoring for CPU usage, rig respects one (1) decimal point of precision due to how CPU usage is reported.
PERCENT may be above 100 - as CPU usage can exceed 100 when a process is running on multiple CPUs.
Watch the system's utilization of resources as a whole, e.g. total CPU or memory usage. When the utilization of a given resource is either exceeded or falls below the given threshold (determined as appropriate for each resource), the trigger condition is met.
The following options are available for the system rig:
--iowait PERCENT The amount of %iowait as reported by the kernel to use as a threshold value.
If exceeded, trigger the rig.
--steal PERCENT The amount of %steal as reported by the kernel to use as a threshold value.
--nice PERCENT The amount of %nice as reported by the kernel to use as a threshold value.
--guest PERCENT The amount of %guest as reported by the kernel to use as a threshold value.
--user The amount of %user as reported by the kernel to use as a threshold value.
--available INTEGER The amount of available memory in MiB as reported by the kernel to use as a threshold value.
If the amount of available memory falls below this threshold, trigger the rig.
--free INTEGER The amount of free memory in MiB as reported by the kernel to use as a threshold value.
If the amount of free memory falls below this threshold, trigger the rig.
--used INTEGER The amount of used memory in MiB as reported by the kernel to use as a threshold value.
If the amount of used memory exceeds this threshold, trigger the rig.
--slab INTEGER The amount of slab memory in MiB as reported by the kernel to use as a threshold value.
If the amount of slab memory exceeds this threshold, trigger the rig.
--cpuperc PERCENT The amount of total CPU usage as reported by the kernel as a percentage to use as a threshold value.
This value may be a whole integer or a float. Floats are precise out to one (1) decimal point.
--memperc PERCENT The amount of total memory usage as reported by the kernel as a percentage to use as a theshold value.
--loadavg FLOAT System load average as reported by the OS to use as a threshold value. If the reported loadavg exceeds this value, trigger the rig. This option can accept either an integer (1) or a float (1.0).
Linux returns loadavg data for the past 1, 5, and 15 minutes. The system rig will monitor only one (1) of these intervals at a time, as controlled by the --loadavg- interval option.
--loadavg-interval [1, 5, 15] Which time interval the rig should monitor when watching the system's loadavg.  Only 1, 5, and 15 are accepted values for this option, as that is what the Linux kernel returns loadavg data for.
--temp INTEGER The temperature in Celsius rig should monitor the CPU for meeting or exceeding.
This option takes an integer value, though temperature data is single decimal point sensitive, so a temperature of 50.9 degrees will not trigger a rig that sets this option to 51.
By default rig will monitor the first physical CPU package installed on the system.  This may be changed via the --cpu-id option. Note that rig will only monitor whole packages and not individual cores, and that package temperatures reported are the highest reported temperature for any core in that package.
--cpu-id ID If specified, monitor this physical CPU package. By default, rig will monitor physical CPU package 0 - meaning the first physically installed CPU.
When specifying an ID here, remember that in Linux CPU IDs are zero-indexed, so the first CPU will be ID 0, the second ID 1, and so forth.
Watch a filesystem, directory, or file for utilization changes. Currently this rig is focused on space consumption, and will trigger when the specified path or backing filesystem exceeds the defined threshold for space utilization.
The following options are available for the filesystem rig:
--path PATH Specify the filesystem, directory, or file path for the rig to monitor. The location provided must exists when the rig initializes for monitoring to be supported.
--size SIZE Specify the size threshold to trigger on for the provided --path. The size given must be an integer suffixed with either K, M, G, or T. The provided value will be converted to bytes.
--fs-size SIZE Use this option instead of --size if you want to monitor the space usage of the backing filesystem for --path rather than the size of the path alone.
Similar to --size this value must be suffixed with either K, M, G, or T.
--fs-used PERCENT Similar to --fs-size but instead provide a percentage value to trigger on, when the filesystem's %used exceeds this value.
Note that using this option is ultimately the same as --fs- size as rig will convert the specified percentage into a raw bytes value to use for comparisons.
The following actions are supported responses to triggered rigs. These may be chained together on a single rig, so deploying multiple rigs with matching trigger conditions with single, varying actions is unnecessary.
Actions are executed based on a priority weighting system, where lower values represent a higher priority action, and those actions with lower values are executed before those with higher values. This is to allow more time-sensitive actions to be taken before those that may either take a long time to execute or are otherwise unaffected by allowing other actions to run before them. Action priority values are set by the actions directly and are currently not able to be modified by users.
gcore  Collect a coredump of a given process or processes using GDB's gcore utility.
Note that this does _not_ interrupt the running process(es). Cores are saved to /tmp and will be named either core.$pid or core.$proc_name.$pid depending on if a PID or process name was provided. This action will be executed first when a rig is triggered and multiple actions are specified.
This action supports repetition via the --repeat option.
The gcore action supports the following options:
--gcore PROCESS Enables this action and takes either a PID or process name as a value. If a process name is given, the PID is determined at rig creation. If multiple PIDs are found for the same process name, the default behavior is to fail rig creation. Use the --all-pids option to instead use all PIDs discovered for a process name.
This option can be specified multiple times. E.G. --gcore 12345 --gcore myprocess will generate a coredump for PID 12345 and a process matching the name 'myprocess'.
--all-pids Tells this action to collect a coredump for all PIDs found for a provided process name.
--freeze Freeze the process(es) that will be core dumped by sending a SIGSTOP prior to calling gcore on the discovered pid(s).
If successful, then rig will send a SIGCONT after the gcore execution has completed in order to thaw the process.
kdump  Generate a vmcore by triggering a kernel crash via sysrq.
Note that this action WILL cause node disruption by triggering a kernel panic to generate the vmcore. This means your system will reboot when this action is triggered.
The kdump action does not perform any configuration checks on the system's kdump installation. It is assumed that kdump has been properly configured and tested prior to using this action.
The kdump action supports the following options:
--kdump Enables this action
--sysrq INTEGER When the rig is deployed, if this option is set, rig will set the system's /proc/sys/kernel/sysrq to the value provided. See sysrq kernel documentation for information on what values are supported.
sosreport Run a sosreport after the rig has been triggered. Select plugin enablement options as well as the --plugin-option from sosreport are supported by this rig.  This action should run after any time- sensitive actions otherwise specified by the user for a given rig.
The sosreport action supports the following options:
--sosreport Enables this action
--enable-plugins PLUGINS Specifically force the specified comma-delimited list of PLUGINS to be enabled.
--plugin-option PLUGOPT Modify a specific plugin's runtime options. This is passed directly to sosreport as the same --plugin-option value, which should take the form 'name.option=value'.  For example, to increase the podman plugin timeout use ´--plugin-option podman.timeout=600´.
If you need to pass multiple sosreport plugin options, use a comma-delimited list here instead of specifying this option multiple times.
--skip-plugins PLUGINS Do not run these specified plugins. Use a comma-delimited list to skip multiple plugins.
--only-plugins PLUGINS Only enable these specific plugins, disable all others. Use a comma-delimited list to specify multiple plugins.
tcpdump Start collecting a tcpdump when the rig is initialized, and stop the collection when the rig triggers. This action will be triggered before most other actions, but after the gcore action.
Note there will be a slight delay in configuring any rig that uses the tcpdump action as rig must verify that the tcpdump process started successfully during the initialization process.
The tcpdump action supports the following options:
--tcpdump Enables this action
--iface INTERFACE Starts the tcpdump to monitor the provided INTERFACE. In almost all situations this should likely be set to a specific interface on the system, however the value of 'any' is accepted by the tcpdump command in order to listen on all interfaces. Be wary of using this however as use of 'any' means will make it impossible to determine which interface a particular packet came in on in the resulting packet capture.
Default: eth0
--filter FILTER Provide a filter to use with tcpdump in order to reduce the amount of traffic recorded in the packet capture. This value is passed directly to the tcpdump utility, and thus can be any valid filter accepted by tcpdump.
For most shells you must quote the filter string for rig to pass it correctly.
--size SIZE Limit the size of the packet capture file(s) to SIZE in MB.
--captures CAPTURES Specify the number of packet capture files to keep. If more than one (1), then tcpdump will rotate the packet capture file when it reaches the --size value and keep CAPTURES number of files.
E.G. Using a CAPTURES of 2 and a SIZE of 5, then when the rig terminates you will have up to 2 5MB packet captures.
Default: 1 (packet capture file is replaced upon reaching SIZE limit).
Does nothing - this action runs a no-op. This is ideally used for when you need to test a rig's configuration to make sure a rig's trigger condition is set properly - e.g. a regex string for the logs' rig message option.
The noop action supports the following options:
--noop Enables this action
Jake Hunsaker <jhunsake@redhat.com>
OSAGE(1)                     General Commands Manual                    OSAGE(1)
osage - filter for drawing clustered graphs
osage [-(G|N|E)name=value] [-Tlang] [-llibfile] [-ooutfile] [-O] [-P] [-v] [-V] [files]
osage draws clustered graphs. As input, it takes any graph in the dot format. It draws the graph recursively. At each level, there will be a collection of nodes and a collection of cluster subgraphs.  The internals of each cluster subgraph are laid out, then the cluster subgraphs and nodes at the current level are positioned relative to each other, treating each cluster subgraph as a node.
At each level, the nodes and cluster subgraphs are viewed as rectangles to be packed together. At present, edges are ignored during packing. Packing is done using the standard packing functions. In particular, the graph attributes pack and packmode control the layout.  Each graph and cluster can specify its own values for these attributes.  Remember also that a cluster inherits its attribute values from its parent graph.
After all nodes and clusters, edges are routed based on the value of the splines attribute.
Osage uses an extensible plugin mechanism for its output renderers, so to see what output formats your installation of osage supports you can use ``osage -Txxx'' (where xxx is an unlikely format) and check the warning message.  Also, The plugin mechanism supports multiple implementations of the output formats.  To see what variants are available, use, for example: ``osage -Tpng:'' and to force a particular variant, use, for example: ``osage -Tpng:gd''
Traditionally, osage supports the following: -Tps (PostScript), -Tsvg -Tsvgz (Structured Vector Graphics), -Tfig (XFIG graphics), -Tmif (FrameMaker graphics), -Thpgl (HP pen plotters), and -Tpcl (Laserjet printers), -Tpng -Tgif (bitmap graphics), -Timap (imagemap files for httpd servers for each node or edge that has a non‐null "href" attribute.), -Tcmapx (client‐side imagemap for use in html and xhtml). Additional less common or more special‐purpose output formats can be found at https://www.graphviz.org/doc/info/output.html.)
digraph test123 { pack=8 subgraph cluster0 { packmode=array x y x0 y0 x1 subgraph cluster1 { m n } } b [shape=box]; c [label="hello\nworld",color=blue,fontsize=24, fontname="Palatino-Italic",fontcolor=red,style=filled]; a -> z x -> z a -> b -> c; a -> {x y}; edge [style=dashed,color=red]; b -> x; }
zfs(1M)                  System Administration Commands                  zfs(1M)
zfs - configures ZFS file systems
zfs [-?]
zfs create [[-o property=value]]... filesystem
zfs create [-s] [-b blocksize] [[-o property=value]]... -V size volume
zfs destroy [-rRf] filesystem|volume|snapshot
zfs clone snapshot filesystem|volume
zfs promote filesystem
zfs rename filesystem|volume|snapshot [filesystem|volume|snapshot]
zfs snapshot [-r] filesystem@name|volume@name
zfs rollback [-rRf] snapshot
zfs list [-rH] [-o prop[,prop] ]... [ -t type[,type]...] [ -s prop [-s prop]... [ -S prop [-S prop]... [filesystem|volume|snapshot|/pathname|./pathname ...
zfs set property=value filesystem|volume ...
zfs get [-rHp] [-o field[,field]...] [-s source[,source]...] all | property[,property]... filesystem|volume|snapshot ...
zfs inherit [-r] property filesystem|volume... ...
zfs mount
zfs mount [-o options] [-O] -a
zfs mount [-o options] [-O] filesystem
zfs unmount [-f] -a
zfs unmount [-f] filesystem|mountpoint
zfs share -a
zfs share filesystem
zfs unshare [-f] -a
zfs unshare [-f] filesystem|mountpoint
zfs send [-i snapshot1] snapshot2
zfs receive [-vnF ] filesystem|volume|snapshot
zfs receive [-vnF ] -d filesystem
The zfs command configures ZFS datasets within a ZFS storage pool, as described in zpool(1M). A dataset is identified by a unique path within the ZFS namespace. For example:
pool/{filesystem,volume,snapshot}
where the maximum length of a dataset name is MAXNAMELEN (256 bytes).
A dataset can be one of the following:
file system    A standard POSIX file system. ZFS file systems can be mounted within the standard file system namespace and behave like any other file system.
volume         A logical volume exported as a raw or block device. This type of dataset should only be used under special circumstances. File systems are typically used in most environments. Volumes cannot be used in a non-global zone.
snapshot       A read-only version of a file system or volume at a given point in time. It is specified as filesystem@name or volume@name.
ZFS File System Hierarchy A ZFS storage pool is a logical collection of devices that provide space for datasets. A storage pool is also the root of the ZFS file system hierarchy.
The root of the pool can be accessed as a file system, such as mounting and unmounting, taking snapshots, and setting properties. The physical storage characteristics, however, are managed by the zpool(1M) command.
See zpool(1M) for more information on creating and administering pools.
Snapshots A snapshot is a read-only copy of a file system or volume. Snapshots can be created extremely quickly, and initially consume no additional space within the pool. As data within the active dataset changes, the snapshot consumes more data than would otherwise be shared with the active dataset.
Snapshots can have arbitrary names. Snapshots of volumes can be cloned or rolled back, but cannot be accessed independently.
File system snapshots can be accessed under the ".zfs/snapshot" directory in the root of the file system. Snapshots are automatically mounted on demand and may be unmounted at regular intervals. The visibility of the ".zfs" directory can be controlled by the "snapdir" property.
Clones A clone is a writable volume or file system whose initial contents are the same as another dataset. As with snapshots, creating a clone is nearly instantaneous, and initially consumes no additional space.
Clones can only be created from a snapshot. When a snapshot is cloned, it creates an implicit dependency between the parent and child. Even though the clone is created somewhere else in the dataset hierarchy, the original snapshot cannot be destroyed as long as a clone exists. The "origin" property exposes this dependency, and the destroy command lists any such dependencies, if they exist.
The clone parent-child dependency relationship can be reversed by using the "promote" subcommand. This causes the "origin" file system to become a clone of the specified file system, which makes it possible to destroy the file system that the clone was created from.
Mount Points Creating a ZFS file system is a simple operation, so the number of file systems per system will likely be numerous. To cope with this, ZFS automatically manages mounting and unmounting file systems without the need to edit the /etc/vfstab file.  All automatically managed file systems are mounted by ZFS at boot time.
By default, file systems are mounted under /path, where path is the name of the file system in the ZFS namespace. Directories are created and destroyed as needed.
A file system can also have a mount point set in the "mountpoint" property. This directory is created as needed, and ZFS automatically mounts the file system when the "zfs mount -a" command is invoked (without editing /etc/vfstab). The mountpoint property can be inherited, so if pool/home has a mount point of /export/stuff, then pool/home/user automatically inherits a mount point of /export/stuff/user.
A file system mountpoint property of "none" prevents the file system from being mounted.
If needed, ZFS file systems can also be managed with traditional tools (mount, umount, /etc/vfstab). If a file system's mount point is set to "legacy", ZFS makes no attempt to manage the file system, and the administrator is responsible for mounting and unmounting the file system.
Zones A ZFS file system can be added to a non-global zone by using zonecfg's "add fs" subcommand. A ZFS file system that is added to a non-global zone must have its mountpoint property set to legacy.
The physical properties of an added file system are controlled by the global administrator. However, the zone administrator can create, modify, or destroy files within the added file system, depending on how the file system is mounted.
A dataset can also be delegated to a non-global zone by using zonecfg's "add dataset" subcommand. You cannot delegate a dataset to one zone and the children of the same dataset to another zone. The zone administrator can change properties of the dataset or any of its children. However, the "quota" property is controlled by the global administrator.
A ZFS volume can be added as a device to a non-global zone by using zonecfg's "add device" subcommand. However, its physical properties can only be modified by the global administrator.
For more information about zonecfg syntax, see zonecfg(1M).