# CommandSection

title: CAVEATS
content:
<b>systemd-mount</b> typically requires root privileges to perform mount operations, as it directly interacts with kernel-level mounting facilities.<br><br>By default, units created by <b>systemd-mount</b> are <i>transient</i>. This means they are only active during the current boot session and will be automatically removed after unmounting or a system reboot. They do not persist across reboots unless explicitly managed otherwise (e.g., via <i>/etc/fstab</i> entries that can be discovered with <b>--discover</b>).<br><br>This command does <i>not</i> modify your <i>/etc/fstab</i> file. For permanent mounts, <i>/etc/fstab</i> is still the primary method, and <b>systemd-mount --discover</b> can then be used to activate them dynamically.


title: TRANSIENT UNITS
content:
Units created by <b>systemd-mount</b> are, by default, 'transient'. This means they are generated in runtime and are automatically cleaned up when they are no longer needed (e.g., after unmounting) or upon system shutdown/reboot. This behavior is ideal for temporary mounting needs, such as attaching external drives or temporary network shares. For persistent mounts, defining them in <i>/etc/fstab</i> is the standard approach, which <b>systemd-mount</b> can then interact with via the <b>--discover</b> option.


title: INTEGRATION WITH SYSTEMD-RUN
content:
While <b>systemd-mount</b> creates and starts mount units, its operations can be further integrated with <b>systemd-run</b>. For instance, one could use <b>systemd-run</b> to execute a command within a specific mount environment or to manage the lifetime of the mount unit as part of a larger service. This integration highlights <b>systemd</b>'s modular design, allowing different components to work together for complex system management tasks.


title: HISTORY
content:
<b>systemd-mount</b> emerged as part of the broader <i>systemd</i> project, which began development around 2010 and rapidly became the de-facto init system for most major Linux distributions. Its development was driven by the need for a more unified and programmatic approach to managing system resources, including filesystem mounts. Prior to <b>systemd-mount</b>, temporary mounts often involved manual <i>mount(8)</i> commands, which lacked integration with the service manager's lifecycle. <b>systemd-mount</b> addressed this by providing a way to create temporary, service-managed mount units, aligning mount operations with <i>systemd</i>'s philosophy of declarative unit management and automatic dependency resolution.


title: PARAMETERS
content:
<b>--ready</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the service has finished its startup process and is ready to accept connections or perform its main function.<br><br><b>--stopping</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that the service is gracefully shutting down. This can be used to inform <i>systemd</i> of an impending shutdown.<br><br><b>--status=STRING</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a free-form status message <i>STRING</i> to <i>systemd</i>. This message can be viewed by users via <i>systemctl status</i>.<br><br><b>--pid=PID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the process ID <i>PID</i> of the service for which the notification is intended. If omitted, the notification applies to the calling process itself.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message describing the command's options and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br>


title: DESCRIPTION
content:
<i><b>systemd-notify</b></i> is a command-line utility that allows services to send status information and readiness signals to the <i>systemd</i> init system. This mechanism is crucial for services configured with <i><b>Type=notify</b></i> in their unit files, as <i>systemd</i> expects these services to explicitly signal when they have completed their initialization and are ready to operate. By sending a <i>--ready</i> signal, services prevent <i>systemd</i> from marking them as active or starting dependent services prematurely. <br><br>Beyond readiness, <i><b>systemd-notify</b></i> enables services to send arbitrary status messages using <i>--status="..."</i>, which can be viewed via <i>systemctl status</i>, offering valuable insights into the service's current state or progress. It also supports sending watchdog reset signals, vital for maintaining service health and enabling automatic restarts if a service becomes unresponsive. This utility provides a robust and standardized way for applications to interact with <i>systemd</i>'s service management capabilities.


title: CAVEATS
content:
<i><b>systemd-notify</b></i> primarily functions for services managed by <i>systemd</i> that are configured with <i><b>Type=notify</b></i> or have appropriate <i><b>NotifyAccess</b></i> settings in their unit files. Communication relies on the <i>NOTIFY_SOCKET</i> environment variable, which <i>systemd</i> automatically sets for the service processes it manages. If this variable is not set, notifications will fail silently or with an error.


title: INTEGRATION WITH SERVICE UNITS
content:
This command is indispensable for services whose <i>systemd</i> unit files specify <i><b>Type=notify</b></i>. For such services, <i>systemd</i> waits for a <i>--ready</i> signal from the service process before considering the service fully started and proceeding with dependent unit activations, ensuring a robust startup sequence.


title: WATCHDOG FUNCTIONALITY
content:
<i><b>systemd-notify</b></i> can be used to send periodic watchdog 'keep-alive' signals if a service unit is configured with <i><b>WatchdogSec=</b></i>. If a service fails to send these signals within the specified timeout, <i>systemd</i> can automatically trigger a restart, significantly improving the resilience and availability of critical services.


title: HISTORY
content:
<i><b>systemd-notify</b></i> was introduced as part of the <i>systemd</i> project, which began development around 2010. It represents a modern approach to service management, providing a more reliable and expressive way for daemonizing services to communicate their operational state to the init system, moving beyond traditional methods like simple PID files and basic exit codes.


title: PARAMETERS
content:
<b><b>-D</b>, <b>--directory=</b><i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory of the container. This is the only mandatory argument for most uses, defining the container's filesystem.<br><br><b><b>-M</b>, <b>--machine=</b><i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific machine <i>NAME</i> to the container. This integrates the container with <b>machinectl</b>, allowing for easy management like starting, stopping, and logging in.<br><br><b><b>-b</b>, <b>--boot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i><b>nspawn</b></i> to boot a full system into the container, by looking for an <b>init</b> executable (typically <b>/sbin/init</b> or <b>/usr/lib/systemd/systemd</b>) and executing it. This runs a complete systemd instance inside the container.<br><br><b><b>-U</b>, <b>--private-users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets up a private user namespace for the container. This maps container's UIDs/GIDs to different UIDs/GIDs on the host, enhancing isolation.<br><br><b><b>--bind=</b><i>HOST_PATH</i>[:<i>CONTAINER_PATH</i>][:<i>OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bind-mounts a file or directory from the host filesystem into the container. Useful for sharing data or host-specific configurations.<br><br><b><b>--overlay=</b><i>HOST_PATH_LOWER</i>:<i>HOST_PATH_UPPER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets up an overlay filesystem for the container. Changes made inside the container are written to <i>HOST_PATH_UPPER</i>, leaving <i>HOST_PATH_LOWER</i> (the base image) untouched.<br><br><b><b>--network-veth</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a private virtual Ethernet (veth) link for the container, providing it with its own isolated network interface.<br><br><b><b>--network-bridge=</b><i>BRIDGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects the container's private network interface to a specified host bridge device (e.g., <b>br0</b>), allowing the container to share the host's network or be part of a custom network.<br><br><b><b>--read-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mounts the container's root directory read-only. Any attempts to write will fail or be redirected if an overlay filesystem is also used.<br><br><b><b>--drop-capability=</b><i>CAPABILITY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops a specific Linux capability (e.g., <b>CAP_SYS_ADMIN</b>) from the container's process, limiting what it can do inside.<br><br>


title: DESCRIPTION
content:
<i><b>systemd-nspawn</b></i> is a command-line utility that can be used to run a command or an operating system in a lightweight namespace container.<br><br>It's often described as an extended <b>chroot</b>, leveraging Linux namespaces (PID, mount, network, IPC, UTS, user) and control groups (cgroups) to provide a more isolated environment. Unlike full virtualization, <i><b>nspawn</b></i> shares the host kernel, making it very fast and resource-efficient. It's particularly useful for testing operating system installations, developing systemd services, or creating minimal, isolated development environments.<br><br>While it offers significant isolation, it's generally not considered a hardened security sandbox for untrusted applications like Docker or LXC might be when configured for stronger isolation. Its primary focus is on system-level containerization, enabling a complete operating system to run within a container, often with its own systemd instance, making it ideal for testing system upgrades or different distribution configurations without affecting the host system.


title: CAVEATS
content:
While <i><b>systemd-nspawn</b></i> provides strong isolation through Linux namespaces and cgroups, it's important to understand its limitations:<br><i><b><br>Not a Security Sandbox:</b></i> It shares the host kernel, making it inherently less isolated than full virtualization. Misconfigurations or kernel vulnerabilities could potentially affect the host system.<br><i><b><br>Root Privileges:</b></i> Most features, especially networking and resource management, require root privileges to set up and manage containers.<br><i><b><br>Resource Management:</b></i> While cgroups are used, fine-grained resource control (CPU, memory, I/O limits) often requires manual configuration of cgroup settings on the host, which can be complex.<br><i><b><br>Container Images:</b></i> <i><b>systemd-nspawn</b></i> expects a full root filesystem of a Linux distribution. It doesn't manage image layers or registries like Docker, requiring manual setup or pre-built images.


title: NETWORKING MODES
content:
<i><b>systemd-nspawn</b></i> offers several networking modes.<br>The default is 'host-network', where the container shares the host's network namespace, but this offers minimal network isolation.<br>Using <b>--network-veth</b> creates a dedicated virtual Ethernet pair, giving the container its own private network stack. This isolated interface can then be connected to a host bridge via <b>--network-bridge=</b><i>BRIDGE</i>, allowing the container to communicate with the host and other containers on the same bridge, or to gain external network access through the host's routing or NAT setup.


title: INTEGRATION WITH MACHINECTL
content:
The <b>-M</b> or <b>--machine=</b><i>NAME</i> option is key to <i><b>systemd-nspawn</b></i>'s integration with <i><b>machinectl</b></i>. When a machine name is provided, <i><b>nspawn</b></i> registers the container with <i><b>systemd-machined</b></i>. This allows <i><b>machinectl</b></i> to manage the container's lifecycle (e.g., <b>machinectl start NAME</b>, <b>machinectl stop NAME</b>, <b>machinectl shell NAME</b>), introspect its status, and manage its resources. This tight integration makes <i><b>nspawn</b></i> containers first-class citizens within the <i><b>systemd</b></i> ecosystem, providing a unified interface for managing virtual machines and containers.


title: HISTORY
content:
<i><b>systemd-nspawn</b></i> was introduced as part of the <i><b>systemd</b></i> project, designed to provide a more advanced form of containerization than traditional <b>chroot</b> environments. Its development focused on deep integration with <i><b>systemd</b></i>'s capabilities, allowing containers to run full systemd instances and be managed alongside other system services. It aimed to bridge the gap between simple chroot jails and heavier virtualization solutions, providing a lightweight, systemd-native way to run isolated Linux environments, primarily for development, testing, and system recovery scenarios.


title: PARAMETERS
content:
<b>PATHNAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> The specific symbolic name of the path to query. If omitted, all known systemd paths and their corresponding locations are listed. Examples include <b>unit</b>, <b>system-unit</b>, <b>user-unit</b>, <b>config</b>, <b>data</b>, <b>run</b>, <b>journal</b>, etc.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the systemd version string and exits.<br><br>


title: DESCRIPTION
content:
<i>systemd-path</i> is a utility included with the systemd system and service manager. Its primary purpose is to display the default installation and runtime paths used by systemd for various components. These paths include locations for systemd unit files (e.g., services, sockets, targets), configuration directories, state directories, library paths, and temporary file locations.<br><br>Administrators and developers can use <i>systemd-path</i> to programmatically query these locations, which is particularly useful for scripting, automating deployments, or debugging issues related to file placement. When invoked without arguments, it lists all known paths and their corresponding locations. If a specific <b>PATHNAME</b> is provided, it outputs only the path associated with that name, making it easy to find specific directories like where system-wide unit files (<b>system-unit</b>) or user-specific configuration files (<b>user-config</b>) are expected to reside. It provides a consistent way to determine systemd's file hierarchy based on its compilation and runtime environment.


title: CAVEATS
content:
The paths reported by <i>systemd-path</i> represent the default or compiled-in locations. Actual operational paths might be overridden by system configurations (e.g., in <i>/etc/systemd/system.conf</i>), environment variables, or specific mount points. This command reflects where systemd <i>expects</i> to find files, not necessarily where a currently running service's files are loaded from if overrides are in place. It is only available on systems that utilize systemd.


title: PATH CATEGORIES
content:
Systemd paths queried by <i>systemd-path</i> are typically categorized. For instance, <b>unit</b> refers to a general unit path, while <b>system-unit</b> and <b>user-unit</b> refer specifically to system-wide and user-specific unit file directories, respectively. Other categories include <b>config</b> (configuration files), <b>data</b> (variable state data), <b>library</b> (shared libraries), and <b>run</b> (runtime state data). Understanding these distinctions is crucial for placing custom configurations or units in the correct locations according to systemd's hierarchy.


title: USAGE SCENARIOS
content:
This command is invaluable for scripting system administration tasks where knowing systemd's expected file locations is necessary. For example:<br><ul><li>To find the path for system-wide service units: <b>systemd-path system-unit</b></li><li>To list all known systemd paths: <b>systemd-path</b></li><li>To locate the system journal directory: <b>systemd-path journal</b></li></ul>These uses help ensure that scripts interact with systemd's file system in a compliant and predictable manner.


title: HISTORY
content:
<i>systemd-path</i> is an integral part of the systemd project, which was initially released in 2010. As systemd's scope and file hierarchy grew, a standardized and programmatic way to query its various installation and runtime directories became essential for robust scripting and system administration. <i>systemd-path</i> was introduced to fulfill this need, providing a reliable interface for developers and administrators to determine systemd's internal path conventions, improving consistency and automation capabilities across different systemd-based environments.


title: SEE ALSO
content:
systemd(1), systemctl(1), systemd.unit(5), systemd.path(5), systemd.directives(7), file-hierarchy(7)


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package version and exit.<br><br><b>--root=<I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the specified root directory <I>PATH</I> instead of the host's root directory.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run with no actual changes made. Useful for testing disk layout changes safely.<br><br><b>--image=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a disk image <I>FILE</I> instead of a physical device. The image file will be mounted loopback if needed.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the configured partition types and their GUIDs that <I>systemd-repart</I> knows about.<br><br><b>--grow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically grow the last suitable partition (typically the root filesystem) to fill the remaining available space on the disk.<br><br><b>--erase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erase the existing partition table on the <I>DEVICE</I> before applying the new layout. <b>Caution: Data loss will occur.</b><br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, overriding certain safety checks or existing conditions.<br><br><b>--json=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output log data in JSON format. Supported modes include 'short', 'pretty', 'off'.<br><br><b><I>DEVICE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The disk device to operate on, e.g., <I>/dev/sda</I> or <I>/dev/nvme0n1</I>.<br><br>


title: DESCRIPTION
content:
<i>systemd-repart</i> is a powerful utility designed for managing disk partitions, primarily within a systemd-centric environment. It enables declarative partitioning, allowing systems to automatically reconfigure and resize partitions based on predefined layouts or existing images. This tool is especially useful for initial system setup, system updates, and preparing disk images for deployment. It can create and grow partitions, erase existing tables, and work with disk images or physical devices. While it can be destructive if not used carefully, its <i>--dry-run</i> option allows for safe testing. It integrates well with other systemd tools, offering a streamlined approach to disk provisioning and maintenance, supporting modern GPT partition tables and specific partition types like EFI System Partitions, root filesystems (A/B), and swap.


title: CAVEATS
content:
Using <I>systemd-repart</I> without the <I>--dry-run</I> option can be highly destructive and lead to irreversible data loss, especially when using the <I>--erase</I> or <I>--force</I> options. It primarily works with GPT (GUID Partition Table) and expects specific partition type GUIDs. It is not an interactive partitioning tool like <I>fdisk</I> or <I>parted</I>, but rather a declarative one designed for automated system provisioning and updates within the systemd ecosystem.


title: USE CASES
content:
<I>systemd-repart</I> is commonly used for:<br>1. <b>Initial OS Installation</b>: Applying a predefined disk layout from a system image onto a blank disk.<br>2. <b>A/B Root Filesystems</b>: Managing and switching between dual root partitions for robust system updates.<br>3. <b>Automated Resizing</b>: Automatically expanding the root filesystem on first boot to utilize full disk capacity.<br>4. <b>Embedded Systems</b>: Ensuring consistent and reproducible disk layouts across many devices.


title: PARTITION TYPE GUIDS
content:
Unlike traditional tools that rely on partition numbers, <I>systemd-repart</I> often identifies partitions by their specific GPT Partition Type GUIDs (e.g., <I>c12a7328-f81f-11d2-ba4b-00a0c93ec93b</I> for EFI System Partition, <I>4f68bce3-e8cd-4db1-96e7-fbcaf98b0f79</I> for Linux root A, <I>69dad710-2ce4-4e3c-b16c-21a1d49abed3</I> for Linux swap). This allows for a more robust and flexible approach to managing partitions across different systems or update scenarios.


title: HISTORY
content:
Part of the broader systemd project, <I>systemd-repart</I> was developed to address the need for automated, reproducible, and declarative disk partitioning, particularly for modern Linux installations and embedded systems. It aligns with systemd's philosophy of providing integrated solutions for system management, simplifying tasks like initial system setup, A/B updates, and disk image deployment by leveraging predefined partition layouts and GUIDs.


title: PARAMETERS
content:
<b>-s, --status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current DNS server status and resolver configuration.<br><br><b>-f, --flush-caches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flush all DNS, LLMNR, and mDNS resolver caches.<br><br><b>--interface=IFACE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to use for the query or configuration.<br><br><b>--set-dns=IP...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set DNS servers for a specific network link (e.g., --link=eth0).<br><br><b>--set-domain=DOMAIN...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set search domains for a specific network link.<br><br><b>--type=TYPE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the DNS record type to query (e.g., A, AAAA, MX, PTR).<br><br><b>[HOSTNAME|IP_ADDRESS]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a DNS lookup for the given hostname or IP address.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<b>systemd-resolve</b> is a command-line utility for interacting with the <b>systemd-resolved.service</b>, which provides network name resolution for local applications. This service acts as a caching and validating DNS/DNSSEC resolver, as well as an LLMNR (Link-Local Multicast Name Resolution) and mDNS (Multicast DNS) responder. <b>systemd-resolve</b> allows users to inspect the current DNS configuration, view active DNS servers, flush the DNS cache, and perform specific hostname or IP address lookups. It plays a crucial role in managing the system's name resolution by handling the <i>/etc/resolv.conf</i> file, typically by symlinking it to a stub resolver file provided by <b>systemd-resolved</b> itself.


title: CAVEATS
content:
<b>systemd-resolve</b> operates directly with the <b>systemd-resolved.service</b>. If this service is not running, the command will not function as expected.<br><br>While still functional, <b>systemd-resolve</b> is largely considered a legacy command. The <b>resolvectl(1)</b> command is the modern, preferred tool for interacting with <b>systemd-resolved</b> and offers a more comprehensive and user-friendly interface for configuration and queries.


title: COMMON USE CASES
content:
<i>Check the current DNS server configuration</i>: <b>systemd-resolve --status</b><br><i>Flush the DNS cache for troubleshooting</i>: <b>systemd-resolve --flush-caches</b><br><i>Resolve a specific hostname</i>: <b>systemd-resolve example.com</b><br><i>Resolve a hostname with a specific record type</i>: <b>systemd-resolve --type=MX example.com</b>


title: INTERACTION WITH /ETC/RESOLV.CONF
content:
<b>systemd-resolved</b> typically manages <i>/etc/resolv.conf</i> by creating a symlink from it to <i>/run/systemd/resolve/stub-resolv.conf</i>. This ensures that all applications querying DNS through glibc's resolver will use the local <b>systemd-resolved</b> stub listener.


title: HISTORY
content:
<b>systemd-resolve</b> emerged as part of the broader <b>systemd</b> ecosystem, aiming to consolidate and standardize various system services, including network name resolution. It was introduced to manage the <b>systemd-resolved</b> daemon, which offers a more advanced and integrated approach to DNS, LLMNR, and mDNS compared to traditional methods relying solely on <i>/etc/resolv.conf</i> and separate DNS services. Over time, the functionality of <b>systemd-resolve</b> has largely been migrated to the <b>resolvectl(1)</b> utility, which is now the recommended command-line interface for <b>systemd-resolved</b>.


title: PARAMETERS
content:
<b>--unit=<i>UNIT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name for the transient unit. If omitted, systemd-run generates one automatically.<br><br><b>--scope</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command as a <i>scope</i> unit instead of a <i>service</i> unit. Scopes typically manage externally started processes, while services manage processes started by systemd itself.<br><br><b>--slice=<i>SLICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assign the transient unit to a specific slice. This is used for hierarchical resource management.<br><br><b>--property=<i>NAME=VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific unit property for the transient unit. For example, use 'MemoryLimit=500M' to limit memory usage.<br><br><b>--wait</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the command or unit to terminate before exiting <i>systemd-run</i> itself. The exit code will be that of the executed command.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command as a user service under the invoking user's systemd instance, instead of the system-wide instance.<br><br><b>--uid=<i>UID</i>, --gid=<i>GID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the user and/or group ID that the executed command will run as.<br><br><b>--setenv=<i>VAR=VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an environment variable for the executed command.<br><br><b>--working-directory=<i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the working directory for the executed command.<br><br>


title: DESCRIPTION
content:
<i>systemd-run</i> is a versatile command-line utility used to execute commands or scripts as temporary, <b>"transient" systemd service or scope units</b>. This powerful feature allows processes to benefit from systemd's robust management capabilities, including resource control (CPU, memory, I/O), security sandboxing, logging, and dependency management, without the need to create persistent .service unit files. <br><br>It's particularly useful for running one-off tasks, testing service configurations, creating temporary background daemons with specific resource limits, or isolating processes for security and stability. By leveraging systemd's cgroup capabilities, <i>systemd-run</i> provides a controlled execution environment, making it an essential tool for system administrators and developers alike.


title: CAVEATS
content:
Transient units created by <i>systemd-run</i> are, by definition, not persistent across reboots. For permanent services, a dedicated .service unit file is required. The complexity of <i>systemd-run</i> increases with the number of properties specified, requiring familiarity with <i>systemd</i> unit configuration directives. Running commands with elevated privileges still requires appropriate permissions.


title: UNIT LIFETIME AND CLEANUP
content:
Unless the <b>--remain-after-exit</b> option is used, transient units created by <i>systemd-run</i> are automatically cleaned up and removed from <i>systemd</i>'s configuration after the executed command exits or the unit is stopped. This makes them ideal for one-off tasks that don't require persistent state.


title: JOURNAL LOGGING INTEGRATION
content:
The standard output (stdout) and standard error (stderr) of commands run via <i>systemd-run</i> are automatically captured by the <b>systemd journal</b>. This allows for centralized logging and easy retrieval of command output using <b>journalctl -u <i>&lt;unit_name&gt;</i></b>, even for short-lived processes.


title: RESOURCE CONTROL CAPABILITIES
content:
One of the most powerful aspects of <i>systemd-run</i> is its ability to apply sophisticated <b>resource limits</b> (e.g., CPU, memory, I/O bandwidth, number of processes) to the executed command using the <b>--property=</b> option. This allows for fine-grained control over how processes consume system resources without modifying system-wide configurations.


title: HISTORY
content:
<i>systemd-run</i> was introduced as an integral part of the <i>systemd</i> initialization system, which began widespread adoption in Linux distributions around 2010. Its development aimed to provide a flexible command-line interface for interacting with <i>systemd</i>'s advanced process and resource management capabilities, allowing administrators to dynamically create and manage units without the overhead of writing static configuration files. It has evolved alongside <i>systemd</i>, incorporating new features like cgroup v2 support.


title: SEE ALSO
content:
systemctl(1), journalctl(1), systemd.service(5), systemd.scope(5), systemd.slice(5), systemd.resource-control(5)


title: SYNOPSIS
content:
<code>systemd-socket-activate [<I>OPTIONS</I>...] [<I>COMMAND</I>] [<I>ARGUMENTS</I>...]</code><br><code>systemd-socket-activate --service=<I>UNIT</I></code>


title: PARAMETERS
content:
<b><code>--help</code>, <code>-h</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help text and exits.<br><br><b><code>--version</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a short version string and exits.<br><br><b><code>--quiet</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informative messages.<br><br><b><code>--listen=<I>ADDR</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a socket address to listen on. This option can be used multiple times to listen on several addresses. Addresses can be IP addresses, port numbers, or Unix domain socket paths.<br><br><b><code>--fdname=<I>NAME</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a name to the file descriptor(s) passed to the invoked command. This name can be used by the invoked program (e.g., via <code>SD_LISTEN_FDS_NAMES</code> environment variable).<br><br><b><code>--inetd</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <code>inetd</code>-style operation. For each incoming connection, <code>systemd-socket-activate</code> forks, sets up standard I/O (stdin/stdout) to the new connection, and executes the specified command.<br><br><b><code>--accept</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <code>--inetd</code> but does not fork. Instead, the main process accepts connections, and the invoked command inherits the socket and is expected to accept connections itself. Useful for single-threaded servers.<br><br><b><code>--pid-file=<I>PATH</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the PID of <code>systemd-socket-activate</code> to the specified file.<br><br><b><code>--make-setsid</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Places the invoked command into a new session before execution.<br><br><b><code>--watch-pid=<I>PID</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, <code>systemd-socket-activate</code> will monitor the specified PID and terminate itself when that PID exits.<br><br><b><code>--keep-ready</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps <code>systemd-socket-activate</code> running and listening for new connections even after the command exits. It will restart the command on the next connection.<br><br><b><code>--exec-fd=<I>FD</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an already existing file descriptor (specified by number) as the listening socket, instead of creating a new one.<br><br><b><code>--service=<I>UNIT</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specified systemd service unit (<code>.service</code>) upon an incoming connection. Instead of executing a command directly, this triggers systemd to start the service.<br><br>


title: DESCRIPTION
content:
<code>systemd-socket-activate</code> is a utility program that facilitates socket activation for systemd services. It listens on specified network or Unix domain sockets and, upon an incoming connection or datagram, launches a specified command or activates a systemd service unit. The core idea behind socket activation, which <code>systemd-socket-activate</code> embodies, is to decouple the listening socket from the service that processes connections. This allows services to be started only when they are actually needed, leading to faster boot times, reduced resource consumption (as services don't run perpetually if idle), and improved robustness (services can be restarted independently of their listening sockets).<br><br>When <code>systemd-socket-activate</code> starts a command, it passes the pre-opened file descriptors (representing the listening sockets) to the newly launched process, typically starting from file descriptor 3. The invoked program can then use these inherited file descriptors to accept connections or receive datagrams directly, without needing to bind to ports itself. This utility can emulate traditional <code>inetd</code>-style behavior using the <code>--inetd</code> or <code>--accept</code> options, where it forks a new process for each incoming connection. Alternatively, it can activate a systemd service unit via the <code>--service</code> option, leveraging systemd's full activation capabilities. It's an essential component for designing efficient, on-demand, and resilient system services under systemd.


title: CAVEATS
content:
<code>systemd-socket-activate</code> is primarily designed for use within the systemd ecosystem. While it can be used standalone, its full power and integration are realized when combined with <code>systemd.socket</code> units. It relies on the kernel's socket functionality and the ability to pass file descriptors, which might have implications for certain security contexts or containerization environments. It's not a direct, drop-in replacement for all <code>inetd</code> functionalities, as it adheres to systemd's more structured activation model. Complex service logic, like protocols that require initial data before a connection is fully established, might need careful handling by the activated application.


title: UNDERSTANDING SOCKET ACTIVATION
content:
Socket activation is a core systemd concept where a service's listening sockets are created and managed by systemd itself, rather than by the service application. When a connection arrives on such a socket, systemd (or utilities like <code>systemd-socket-activate</code>) starts the corresponding service, passing the pre-opened socket file descriptors to it. This design allows for:<br>1. <B>Parallel Startup:</B> Services don't need to wait for others to bind ports.<br>2. <B>Resource Efficiency:</B> Services only run when active, saving memory and CPU.<br>3. <B>Robustness:</B> Services can crash and restart without dropping existing connections, as the socket remains open.<br>4. <B>Dependency Management:</B> Sockets can be activated before the services themselves are fully up.


title: FILE DESCRIPTOR PASSING MECHANISM
content:
A crucial aspect of <code>systemd-socket-activate</code> (and socket activation in general) is the passing of file descriptors. When a service is activated, the listening socket(s) are handed over to the new process. These file descriptors are typically made available to the child process starting from file descriptor 3. The child process then uses standard library functions (like <code>accept()</code> or <code>recvmsg()</code>) on these inherited FDs. This method eliminates the need for services to handle <code>bind()</code> and <code>listen()</code> calls themselves, simplifying service design and enhancing security by allowing systemd to manage privileged port bindings.


title: HISTORY
content:
<code>systemd-socket-activate</code> was introduced early in the development of systemd as a fundamental component to implement its socket activation feature. This mechanism was a key innovation aimed at improving system boot times, resource management, and service robustness compared to traditional init systems. It effectively superseded the role of classic <code>inetd</code> and <code>xinetd</code> daemons within the systemd framework, providing a more integrated and flexible way to activate services on demand, particularly for network-bound applications. Its development paralleled systemd's growth as a modern init system, solidifying its position as a core utility for building resilient and efficient Linux services.


title: DESCRIPTION
content:
<i>systemd-stdio-bridge</i> is an internal utility program within the systemd suite, primarily designed to act as a robust bridge for standard input, output, and error streams (stdin, stdout, stderr). Its main purpose is to connect these I/O streams between a parent process, such as <i>systemd-run</i> or <i>systemd-nspawn</i>, and a child process that might be operating within a different control group (cgroup) or isolated namespace.<br><br>Users typically do not invoke this command directly. Instead, systemd itself spawns <i>systemd-stdio-bridge</i> to manage I/O redirection, particularly when creating transient services or scopes (e.g., via <i>systemd-run --scope</i>) or when launching lightweight containers (using <i>systemd-nspawn</i>). The bridge ensures that the I/O streams of the wrapped process are correctly linked back to the invoking terminal or parent process, even when the wrapped process's cgroup changes or it runs in a sandboxed environment. It handles complex terminal interactions, including pushing input back into the controlling terminal's buffer using <i>TIOCSTI</i> ioctl and forwarding <i>SIGWINCH</i> signals for terminal window size changes. This utility is crucial for enabling seamless and interactive integration of temporary processes and containers within the systemd ecosystem.


title: CAVEATS
content:
<i>systemd-stdio-bridge</i> is an internal utility of the systemd suite and is not intended for direct user invocation. Its behavior is tightly coupled with systemd's internal mechanisms, and it primarily relies on inheriting specific file descriptors and environment variables from its parent process. Direct use or modification of its behavior is unsupported and may lead to unexpected results or system instability.<br><br>It is mainly used by commands like <i>systemd-run --scope</i> and <i>systemd-nspawn</i> to manage I/O for transient services and containers. Debugging issues related to this bridge usually requires investigating the systemd component that spawned it.


title: ENVIRONMENT AND FILE DESCRIPTORS
content:
<i>systemd-stdio-bridge</i>'s behavior is heavily influenced by the file descriptors and environment variables it inherits from its parent process. It expects to receive standard I/O streams (stdin, stdout, stderr) as specific file descriptors, which it then bridges to the child process it manages. It also respects terminal-related environment variables for proper interaction with the controlling terminal.


title: HISTORY
content:
<i>systemd-stdio-bridge</i> was introduced as an integral part of the systemd project to address complex I/O redirection challenges that arose with the introduction of transient units and containerization features. Its development focused on ensuring seamless standard I/O (stdin, stdout, stderr) connectivity for processes managed by systemd, especially those running in transient scopes or within containers (like with <i>systemd-nspawn</i>). It specifically tackles issues related to terminal control, such as handling <i>SIGWINCH</i> signals for window resizing and pushing input back to the terminal via <i>TIOCSTI</i>. This utility has been a foundational internal component, enabling systemd's powerful process management features to maintain proper interactive terminal behavior across various process environments.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br><b><b>--root=</b><i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on a specified alternate root directory <i>PATH</i> instead of the running system's root.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation, overriding certain checks or conditions.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run without actually making any changes, useful for previewing operations.<br><br><b><b>--no-pager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b><b>--json=</b><i>MODE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output log data as JSON. <i>MODE</i> can be 'short', 'pretty', 'oneline', or 'json-pretty'.<br><br><b><b>--full</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows full details in 'status' or 'list' commands, instead of truncated output.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with 'list', shows all available extensions, including inactive ones.<br><br><b><b>--suffix=</b><i>SUFFIX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate filename suffix for extension images to consider, defaulting to '.sysext'.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the currently active system extension images and their mount points.<br><br><b><b>list</b> [<i>PATTERN...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available system extension images. An optional <i>PATTERN</i> can filter the results.<br><br><b><b>activate</b> [<i>PATH...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the specified system extension images by mounting them as overlays. If no <i>PATH</i> is given, all available extensions are activated.<br><br><b><b>deactivate</b> [<i>PATH...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates the specified system extension images by unmounting them. If no <i>PATH</i> is given, all currently active extensions are deactivated.<br><br><b><b>merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-merges the currently active system extension images. Useful after system updates or changes to the base OS that might affect the overlay.<br><br><b><b>unmerge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmerges all currently active system extension images, effectively deactivating all extensions.<br><br><b><b>shutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmerges all system extensions and cleans up any temporary mount points. Typically used during system shutdown or before a reboot.<br><br>


title: DESCRIPTION
content:
<i>systemd-sysext</i> is a command-line utility used for managing and activating/deactivating system extension images. These extensions are read-only root directory overlays, typically distributed as SquashFS images or plain directories, designed to augment the <i>/usr</i> and <i>/opt</i> hierarchies of a base operating system.<br><br>It works by mounting these images via the Linux kernel's OverlayFS feature, creating a union file system that combines the base system with the contents of the extension. This approach is particularly useful in immutable operating system designs, allowing for the flexible addition of software, development tools, or specialized configurations without modifying the underlying base system.<br><br>Extensions can be activated dynamically at runtime or automatically during boot by <i>systemd-sysext-generator</i>, providing a robust mechanism for system customization and software distribution in modern Linux environments.


title: CAVEATS
content:
<i>systemd-sysext</i> relies on the Linux kernel's OverlayFS feature, which must be enabled and available. Creating <i>.sysext</i> images is typically done with tools like <i>mkosi</i> or similar image builders, as <i>systemd-sysext</i> focuses on their management and activation rather than creation. Incorrectly structured or untrusted extension images can potentially compromise system stability or security. Extensions provide global overlays and affect all users on the system.


title: TYPICAL USAGE CONTEXT
content:
This command is primarily used in scenarios where a base operating system needs to remain immutable, but certain applications, development tools, or custom configurations must be added. Common use cases include: providing specific software stacks on container hosts, creating specialized development environments without polluting the base system, or deploying security-hardened configurations as overlays.


title: EXTENSION IMAGE LOCATIONS
content:
<i>systemd-sysext</i> looks for extension images in a predefined set of directories, typically in the order:<br><i>/var/lib/sysext/</i><br><i>/etc/sysext/</i><br><i>/run/sysext/</i><br>Images in these locations are automatically considered for activation, either manually or during boot via the <i>systemd-sysext-generator</i>.


title: HISTORY
content:
<i>systemd-sysext</i> is part of the <i>systemd</i> project, which continually evolves to manage various aspects of Linux systems. It was introduced to standardize and robustify the process of layering read-only filesystem images on top of the base operating system. This addresses a growing need for immutable system designs, container hosts, and development environments where additional software components need to be added or updated without directly modifying the core OS installation, building upon prior, less standardized methods of system augmentation.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short version string and exit.<br><br><b>--root=<I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on an alternate root directory, useful for chroot or container environments.<br><br><b>--config-root=<I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate root for configuration directories (e.g., sysusers.d).<br><br><b>--build-image[=<I>PATH</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <b>--root</b>, but also adjusts default paths for building container images.<br><br><b>--defined-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only process users and groups explicitly defined in configuration files, skipping any implicit system defaults.<br><br><b>--uid-min=<I>UID</I>, --uid-max=<I>UID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the minimum and maximum UIDs for dynamically allocated users.<br><br><b>--gid-min=<I>GID</I>, --gid-max=<I>GID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the minimum and maximum GIDs for dynamically allocated groups.<br><br><b>--first-system-uid=<I>UID</I>, --last-system-uid=<I>UID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the range for statically allocated system UIDs.<br><br><b>--first-system-gid=<I>GID</I>, --last-system-gid=<I>GID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the range for statically allocated system GIDs.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force creation of users/groups even if they conflict with existing entries (e.g., UID/GID already taken).<br><br><b>--json=pretty|short|long|json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output as JSON for programmatic parsing.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without actually creating or modifying any users or groups.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print more verbose debug output during operation.<br><br><b>--sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize the database with the configuration files, used by <b>sysusers.target</b>.<br><br>


title: DESCRIPTION
content:
systemd-sysusers is a utility that creates system users and groups based on declarative configuration files, typically located in `/usr/lib/sysusers.d/`, `/etc/sysusers.d/`, and `/run/sysusers.d/`. It processes these files, which define users and groups along with their UIDs, GIDs, home directories, and shells, and ensures their existence on the system. This mechanism is an integral part of the systemd ecosystem, providing a robust and standardized way for services and packages to declare their required runtime identities. Unlike traditional user management tools, <b>systemd-sysusers is idempotent</b>, meaning it can be run multiple times safely; it only creates entities that don't already exist. It focuses solely on the creation of system users and groups (often those with low UIDs/GIDs) and does not handle their deletion or general user account management.


title: CAVEATS
content:
<b>systemd-sysusers</b> is a creation-only tool; it will not delete or modify existing users/groups beyond their initial setup. If an entry is removed from a <i>.sysusers</i> file, the corresponding user or group will not be automatically removed from the system. It is primarily designed for managing system-level identities, not regular user accounts. Using <b>--force</b> should be done with caution, as it can lead to UID/GID conflicts if misused.


title: CONFIGURATION FILES
content:
Configuration is read from <i>.conf</i> files located in three primary directories, processed in the following order of precedence:<br><br><b>1. /etc/sysusers.d/</b>: For local overrides and custom definitions.<br><b>2. /run/sysusers.d/</b>: For volatile runtime definitions.<br><b>3. /usr/lib/sysusers.d/</b>: For definitions provided by installed packages.<br><br>Files or symlinks ending with <i>.conf.d</i> or containing other suffixes are ignored. Empty files are also ignored.


title: FILE FORMAT (SYSUSERS.D(5) SYNTAX)
content:
Each line in a <i>.sysusers</i> file defines a user or group. Lines starting with <i>#</i> are comments.<br><br><b>For Users</b>:<br><i>u &lt;name&gt; [&lt;id&gt;] [&lt;gid&gt;] [&lt;gecos&gt;] [&lt;home&gt;] [&lt;shell&gt;]</i><br><ul><li><i>&lt;name&gt;</i>: The user name.</li><li><i>&lt;id&gt;</i>: Optional UID. If omitted, a dynamic UID is allocated from the system range.</li><li><i>&lt;gid&gt;</i>: Optional primary GID. If omitted, it defaults to the UID or a dynamically allocated GID.</li><li><i>&lt;gecos&gt;</i>: Optional GECOS field (full name/comment).</li><li><i>&lt;home&gt;</i>: Optional home directory. Defaults to <i>/</i> if omitted.</li><li><i>&lt;shell&gt;</i>: Optional login shell. Defaults to <i>/sbin/nologin</i> if omitted.</li></ul><br><b>For Groups</b>:<br><i>g &lt;name&gt; [&lt;id&gt;] [&lt;members&gt;]</i><br><ul><li><i>&lt;name&gt;</i>: The group name.</li><li><i>&lt;id&gt;</i>: Optional GID. If omitted, a dynamic GID is allocated from the system range.</li><li><i>&lt;members&gt;</i>: Optional comma-separated list of user names to be added as additional group members.</li></ul><br>Dynamic UIDs/GIDs are allocated from ranges like 900-999 by default, but can be configured via command-line options or <i>/etc/systemd/system.conf.d/</i>.


title: HISTORY
content:
<b>systemd-sysusers</b> was developed as part of the systemd project to provide a declarative and robust method for creating system users and groups required by services. Before its introduction, such tasks often relied on imperative shell scripts in package pre/post-installation stages, which could be less reliable and harder to manage. It aims to standardize user/group setup, enhance security by promoting dedicated identities for services, and simplify dependency management within the systemd ecosystem.


title: SYNOPSIS
content:
<i>systemd-timedated.service</i> is a systemd service unit and is not directly executed by users from the command line. Instead, it is managed by the <b>systemctl</b> utility.<br><br>To manage the service's lifecycle:<br><b>sudo systemctl [start|stop|enable|disable|status|restart] systemd-timedated.service</b><br><br>The actual daemon executed by this service unit is <b>timedated</b>, which runs in the background and exposes its functionality via D-Bus.


title: PARAMETERS
content:
<b>N/A (Service Unit)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>systemd-timedated.service</i> is a systemd service unit and does not accept command-line parameters directly from the user. Its behavior and configuration are managed internally by systemd or through D-Bus calls from client applications like <b>timedatectl</b>. The underlying <b>timedated</b> daemon, when invoked by systemd, also typically runs without user-supplied command-line arguments.<br><br>


title: DESCRIPTION
content:
<i>systemd-timedated.service</i> is a core systemd service unit designed to manage the system's time and date settings. It provides a D-Bus interface, allowing other system components and user utilities to query and modify the system clock, time zone, and the hardware-based Real Time Clock (RTC). This service is crucial for maintaining accurate time across reboots and ensuring proper synchronization, especially when combined with Network Time Protocol (NTP) clients.<br><br>It abstracts the complexities of directly interacting with kernel time interfaces and RTC hardware, offering a unified and consistent API for time management. Users do not typically run <i>systemd-timedated.service</i> directly as a command; instead, they interact with its functionalities through the <b>timedatectl</b> command-line utility. <b>timedatectl</b> sends D-Bus messages to the <b>timedated</b> daemon (which is the actual executable run by this service) to perform operations like setting the timezone, enabling NTP synchronization, or adjusting the RTC.


title: CAVEATS
content:
<ul><li><b>Systemd Dependency</b>: This service is an integral part of the systemd ecosystem and is only available on Linux distributions that use systemd as their init system.</li><li><b>D-Bus Communication</b>: Its functionality relies entirely on D-Bus for inter-process communication, meaning the D-Bus system must be operational.</li><li><b>Privilege Requirement</b>: Modifying system time, timezone, or RTC settings via clients like <b>timedatectl</b> typically requires root privileges.</li><li><b>NTP Client Coordination</b>: While <i>systemd-timedated.service</i> can enable NTP synchronization (usually through <i>systemd-timesyncd.service</i>), direct manual time adjustments might conflict if another dedicated NTP client (e.g., <b>ntpd</b>, <b>chronyd</b>) is actively managing time.</li></ul>


title: INTERACTION WITH TIMEDATECTL
content:
The primary way users interact with the functionality provided by <i>systemd-timedated.service</i> is through the <b>timedatectl</b> command. <b>timedatectl</b> acts as a client, sending D-Bus messages to the <b>timedated</b> daemon (run by this service) to query status or apply changes.<br><i>Examples:</i><br><b>timedatectl status</b> - Shows current time and date settings.<br><b>timedatectl set-time "YYYY-MM-DD HH:MM:SS"</b> - Sets the system time.<br><b>timedatectl set-timezone Europe/Berlin</b> - Sets the system timezone.<br><b>timedatectl set-ntp true</b> - Enables NTP synchronization (often via <i>systemd-timesyncd.service</i>).


title: RTC (REAL TIME CLOCK) MANAGEMENT
content:
<i>systemd-timedated.service</i> plays a crucial role in managing the system's Real Time Clock (RTC), which is a hardware clock that maintains time even when the system is powered off. It ensures consistency between the system clock (which is software-based) and the RTC, handling configurations for whether the RTC should be kept in UTC or local time to prevent time discrepancies after system reboots.


title: SERVICE UNIT FILE LOCATION
content:
The definition of the <i>systemd-timedated.service</i> unit is typically found in the `/usr/lib/systemd/system/` or `/lib/systemd/system/` directory. This unit file specifies how the service is started, the path to its executable (usually `/usr/lib/systemd/systemd-timedated`), its dependencies, and other systemd-specific operational parameters.


title: HISTORY
content:
<i>systemd-timedated.service</i> emerged as part of the broader systemd initiative, which began development around 2010. Prior to systemd, time and date management on Linux systems was often handled by disparate utilities and scripts (e.g., <b>hwclock</b> for RTC, direct manipulation of `/etc/localtime` for timezone, and separate daemons for NTP synchronization). Systemd aimed to centralize and unify these critical system management tasks. <i>timedated</i> was introduced to provide a robust, consistent, and programmatic D-Bus API for handling time, date, and RTC settings, replacing the fragmented approaches and leading to more predictable system behavior in modern Linux distributions.


title: SEE ALSO
content:
timedatectl(1), systemctl(1), systemd(1), localtime(5), systemd-timesyncd.service(8), ntpd(8), chronyd(8)


title: SYNOPSIS
content:
<b>systemd-tmpfiles</b> [<i>OPTIONS...</i>] [<i>CONFIG_FILE...</i>]<br><b>systemd-tmpfiles</b> {<b>--create</b>|<b>--clean</b>|<b>--remove</b>} [<i>OPTIONS...</i>]<br><b>systemd-tmpfiles</b> <b>--cat-config</b> [<i>CONFIG_FILE...</i>]


title: PARAMETERS
content:
<b>--create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates and applies ownership/permissions to runtime directories and files as specified in configuration files. This is typically run at boot.<br><br><b>--clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans up old files and directories based on age settings in configuration files. This is typically run periodically.<br><br><b>--remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all files and directories specified in the configuration files, regardless of age. Use with caution.<br><br><b>--boot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--create --remove --apply-mode --tmpfs-size</b>. This option is typically used by <i>systemd-tmpfiles-setup.service</i> at boot.<br><br><b>--prefix=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only process configuration lines that affect files or directories under the specified <i>PATH</i>.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on user-specific temporary directories and configuration files (e.g., <i>~/.config/tmpfiles.d/</i>).<br><br><b>--root=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a specified alternate root directory instead of the host's root. Useful for chroot/container environments.<br><br><b>--cat-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the parsed content of the configuration files to standard output.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides certain protections, such as removing non-empty directories without an explicit <i>r+</i> type. Use with extreme care.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show more detailed output during execution.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output, only show errors.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>systemd-tmpfiles</i> is a utility that creates, deletes, and cleans up volatile and temporary files and directories, typically located in paths like <i>/run</i>, <i>/tmp</i>, and <i>/var/tmp</i>. <br><br>It reads configuration from various files (e.g., <i>/etc/tmpfiles.d/*.conf</i>, <i>/run/tmpfiles.d/*.conf</i>, <i>/usr/lib/tmpfiles.d/*.conf</i>) to apply predefined rules. These rules specify how directories should be created (with correct permissions and ownership), how files should be handled (e.g., creating specific files or symlinks), and how old files and directories should be pruned. <br><br>The primary goal is to ensure the integrity and cleanliness of these crucial system paths, which are often cleared on reboot or periodically. It's an integral part of <i>systemd</i>, automating tasks that were traditionally handled by various ad-hoc scripts, improving reliability and consistency in temporary file management.


title: CAVEATS
content:
Misconfiguring <i>systemd-tmpfiles</i> can lead to unexpected data loss, particularly with the <b>--remove</b> or <b>--force</b> options, or security vulnerabilities if permissions are set incorrectly. Always back up critical configurations and test changes in a non-production environment. Most operations require root privileges.


title: CONFIGURATION FILES
content:
<i>systemd-tmpfiles</i> reads configuration from files ending with <i>.conf</i> in the following directories, processed in order of precedence: <i>/etc/tmpfiles.d/</i> (local overrides), <i>/run/tmpfiles.d/</i> (runtime configuration), and <i>/usr/lib/tmpfiles.d/</i> (vendor-supplied defaults). Files later in the processing order or in higher-priority directories can override earlier entries.


title: SERVICE INTEGRATION
content:
On a typical <i>systemd</i> system, <i>systemd-tmpfiles</i> is invoked by two main services: <i>systemd-tmpfiles-setup.service</i> which runs at boot (using <b>--boot</b>) to create and set up initial permissions for volatile directories, and <i>systemd-tmpfiles-clean.service</i> which runs periodically (using <b>--clean</b>) to prune old temporary files based on age settings.


title: HISTORY
content:
<i>systemd-tmpfiles</i> was introduced as part of the <i>systemd</i> initialization system to provide a centralized and declarative method for managing volatile and temporary file system paths. Before <i>systemd</i>, these tasks were often handled by a collection of disparate shell scripts (e.g., in <i>/etc/rc.d</i> or <i>/etc/init.d</i>), which varied significantly across distributions and versions. <br><br>Its development aimed to standardize the cleanup and setup of critical runtime directories like <i>/run</i>, <i>/tmp</i>, and <i>/var/tmp</i>, ensuring consistent behavior, proper permissions, and timely cleanup, thereby enhancing system stability and security.


title: SEE ALSO
content:
tmpfiles.d(5), systemd(1), systemctl(1), systemd-tmpfiles-clean.service(8), systemd-tmpfiles-setup.service(8), rm(1), mkdir(1), chown(1)


title: PARAMETERS
content:
<b>--watch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continuously monitors for password requests, allowing it to handle multiple prompts without exiting. Without this option, the agent processes existing password requests and then terminates.<br><br>


title: DESCRIPTION
content:
<i>systemd-tty-ask-password-agent</i> is a component of the <i>systemd</i> init system responsible for handling password or passphrase prompts on the text-based console (TTY). It acts as an agent that listens for password requests from other <i>systemd</i> services, most notably during the early boot process when unlocking encrypted disks (e.g., LUKS volumes). When a service requires a password, this agent displays the prompt on the active TTY, securely receives the user's input, and returns it to the requesting service. This ensures that sensitive information, such as encryption passphrases, can be entered directly on the console before a graphical environment is available. It is an integral part of <i>systemd</i>'s unified approach to system management and authentication.


title: CAVEATS
content:
Operates exclusively on text-based consoles (TTYs), making it unsuitable for graphical desktop environments where dedicated graphical password agents are used.<br>Primarily designed for system-level password prompts, such as unlocking encrypted disks during boot, and is not a general-purpose password utility for arbitrary user applications.<br>Typically runs as a system service with root privileges and is not intended for direct manual user invocation to prompt for passwords.<br>As input is handled directly on the console, ensuring the physical TTY is secure is important for sensitive operations.


title: D-BUS INTEGRATION
content:
This agent communicates with other <i>systemd</i> components and clients via the D-Bus message bus. It listens for password requests on a well-known D-Bus name, providing a standardized interface for system services to request user input on the console.


title: SERVICE UNIT
content:
<i>systemd-tty-ask-password-agent</i> is commonly managed as a <i>systemd</i> service, typically enabled to run automatically during system boot. Its service unit ensures it's available to handle password prompts from other services, such as <i>systemd-cryptsetup@.service</i>, which manages encrypted volumes.


title: HISTORY
content:
Part of the <i>systemd</i> project, <i>systemd-tty-ask-password-agent</i> was developed to provide a unified and integrated mechanism for handling system-level password prompts, particularly for encrypted volumes (like LUKS) during the boot process. It became an essential component as <i>systemd</i> adopted more responsibility for early boot tasks and replaced older, less standardized methods for user interaction on the console. Its development is tied to the evolution of <i>systemd</i> itself, which debuted in 2010.


title: SYNOPSIS
content:
The <code>systemd-udevd.service</code> unit primarily manages the <code>systemd-udevd</code> daemon. While users rarely invoke the daemon directly, as it's typically started and maintained by systemd, its underlying command invocation pattern is:<br><br><code><b>systemd-udevd</b> [<I>OPTIONS</I>...]<br><br></code>However, it is predominantly managed as a systemd service, for example:<br><code><b>systemctl</b> [<I>COMMAND</I>] <b>systemd-udevd.service</b></code>


title: PARAMETERS
content:
<b><code>--debug</code>, <code>-d</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables debug logging.</i> This increases the verbosity of the daemon's output, which is useful for troubleshooting udev rules or device recognition issues.<br><br><b><code>--help</code>, <code>-h</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a short help text and exits.</i> Provides a brief overview of the available command-line options for the daemon.<br><br><b><code>--version</code>, <code>-V</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints version information and exits.</i> Shows the installed version of the <code>systemd-udevd</code> daemon.<br><br>


title: DESCRIPTION
content:
<code>systemd-udevd.service</code> is the systemd unit for the <code>systemd-udevd</code> daemon, which serves as the device manager for the Linux kernel. Its primary role is to manage device nodes in the <code>/dev</code> directory, ensuring they are created and removed dynamically as hardware is added or removed from the system.<br><br>It receives events directly from the kernel (via Netlink) when devices are discovered, connected, or disconnected. Upon receiving an event, <code>systemd-udevd</code> applies a set of rules (typically located in <code>/lib/udev/rules.d/</code> and <code>/etc/udev/rules.d/</code>) to identify the device, assign appropriate permissions and ownership, create symbolic links, and trigger further actions such as loading kernel modules or executing scripts. This dynamic device management is crucial for modern Linux systems, enabling features like hot-plugging of USB devices, automatic network interface configuration, and consistent device naming across reboots. It superseded older systems like <i>devfs</i> and <i>hotplug</i>.


title: CAVEATS
content:
<code>systemd-udevd</code> is a fundamental component of a Linux system. Stopping or restarting this service directly without careful consideration can lead to severe system instability, including issues with device recognition, network interfaces, and file system mounting, as it dynamically manages the <code>/dev</code> directory. Changes to udev rules often require reloading them via <code>udevadm control --reload-rules</code> or triggering device events, rather than restarting the service itself.


title: UDEV RULES
content:
Udev's behavior is controlled by rules files, typically located in <code>/lib/udev/rules.d/</code> (for distribution-provided rules) and <code>/etc/udev/rules.d/</code> (for local customizations). These rules are processed in lexical order (e.g., <code>10-local.rules</code> before <code>99-custom.rules</code>) and define how <code>systemd-udevd</code> should react to kernel device events, including setting device permissions, ownership, creating symlinks, and executing external programs.


title: <CODE>/DEV</CODE> FILESYSTEM
content:
<code>systemd-udevd</code> is responsible for populating the <code>/dev</code> directory, which is a virtual filesystem (<i>devtmpfs</i>) mounted at boot. It ensures that only necessary device nodes exist and are dynamically updated as hardware changes, preventing the need for a static, pre-populated <code>/dev</code> directory that was common in older Linux systems.


title: HISTORY
content:
The concept of dynamic device management in Linux evolved from simpler systems like <i>devfs</i> and <i>hotplug</i>. <i>devfs</i> was deprecated due to issues with inconsistent device naming and permissions, while <i>hotplug</i> provided event handling but lacked a centralized device database.<br><br><b>udev</b> was introduced around 2003 as a successor, providing a more robust and flexible way to manage <code>/dev</code> and handle hot-plugging. Initially, it ran as a standalone daemon. With the advent of <b>systemd</b>, <i>udev</i>'s functionality was integrated directly into the <i>systemd</i> ecosystem, resulting in the <code>systemd-udevd</code> daemon and the <code>systemd-udevd.service</code> unit. This integration streamlined device event processing and made it an integral part of the system's boot process and runtime device management.


title: SYNOPSIS
content:
<b>systemd-umount</b> <i>[OPTIONS] [MOUNTPOINT|DEVICE|UNIT]</i><br><b>systemd-umount</b> <i>[OPTIONS] --all</i>


title: PARAMETERS
content:
<b><i>-a</i>, <i>--all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmounts all filesystems specified in <i>/etc/fstab</i> that are managed by <i>systemd</i> mount units. Unmounts are performed in reverse dependency order.<br><br><b><i>-t TYPE</i>, <i>--types=TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>--all</i>, limits unmounting to filesystems of the specified comma-separated types (e.g., 'ext4,xfs').<br><br><b><i>-O OPTION</i>, <i>--options=OPTION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>--all</i>, limits unmounting to filesystems that have the specified comma-separated mount options configured in their unit or <i>/etc/fstab</i> entry.<br><br><b><i>--no-block</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not wait for the unmount operation to complete. The command returns immediately after issuing the unmount request.<br><br><b><i>-R</i>, <i>--recursive</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively unmounts specified mount points and their children.<br><br><b><i>-v</i>, <i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details about the unmount process.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>systemd-umount</i> is a low-level utility designed to unmount filesystems managed by the <i>systemd</i> init system. It primarily acts as a compatibility wrapper around the more commonly used <i>systemctl umount</i> command, offering a subset of options familiar from the traditional <i>umount(8)</i> utility. Its core function is to interact with <i>systemd</i>'s internal mount units (e.g., those generated from <i>/etc/fstab</i> entries or explicitly defined via <i>.mount</i> unit files) to gracefully shut down and unmount filesystems.<br><br>While users typically interact with mount operations via <i>systemctl umount</i>, <i>systemd-umount</i> can be invoked directly, particularly in scripts or by <i>systemd</i> itself during system shutdown or when managing service dependencies. When used with the <i>--all</i> option, it attempts to unmount all configured filesystems in reverse dependency order, ensuring a clean system state and respecting <i>systemd</i>'s dependency tree.


title: CAVEATS
content:
While <i>systemd-umount</i> offers compatibility with some <i>umount(8)</i> options, it's generally recommended to use <i><b>systemctl umount</b></i> for user-level interactions, as it provides a more robust and feature-rich interface to <i>systemd</i>'s mount management capabilities. <i>systemd-umount</i> primarily functions by communicating with the <i>systemd</i> manager, which then performs the actual unmount operations, respecting unit dependencies and states. Unmounting busy filesystems may fail unless processes accessing them are stopped or killed.


title: INTERACTION WITH SYSTEMCTL
content:
<i>systemd-umount</i> effectively translates its arguments into a <i>systemctl umount</i> command or interacts directly with the <i>systemd</i> bus. For most user-facing unmount tasks, <i><b>systemctl umount</b></i> is the preferred and more flexible command, offering features like unit status querying and more explicit control over mount units.


title: HISTORY
content:
<i>systemd-umount</i> was introduced as part of the <i>systemd</i> init system to provide a unified approach to filesystem management, integrating it with <i>systemd</i>'s concept of units and dependencies. It superseded some traditional unmounting methods by delegating the task to the <i>systemd</i> manager, ensuring that unmount operations are performed in a consistent and ordered manner, especially during system shutdown or service restarts.


title: SYNOPSIS
content:
<b>systemsettings</b> [<i>options</i>] [<i>&lt;KCMID&gt;</i>]<br><b>systemsettings</b> [<b>--show</b> <i>&lt;KCMID&gt;</i>]<br><b>systemsettings</b> [<b>--module</b> <i>&lt;KCMID&gt;</i>]


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <b>systemsettings</b> application.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of the command's available options and their usage.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available KDE Control Modules (KCMs) that can be opened directly. This is useful for discovering valid <i>&lt;KCMID&gt;</i> values.<br><br><b><b>--show</b> <i>&lt;KCMID&gt;</i> or <b>--module</b> <i>&lt;KCMID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified KDE Control Module (KCM). The <i>&lt;KCMID&gt;</i> often corresponds to a <i>.desktop</i> file name for the module (e.g., <i>kcm_lookandfeel</i>, <i>kcm_networkmanager</i>) found by using <b>--list</b>.<br><br><b><i>&lt;KCMID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When provided as a direct positional argument, it behaves identically to using <b>--show</b> <i>&lt;KCMID&gt;</i>, opening the specified KDE Control Module.<br><br>


title: DESCRIPTION
content:
<b>systemsettings</b> is the primary graphical utility for managing and configuring the KDE Plasma desktop environment and the underlying system settings. It provides a centralized and user-friendly interface for users to customize a wide array of system and user-specific preferences. This includes deeply personalizing the appearance (themes, icons, fonts, splash screens), configuring workspace behavior (desktop effects, screen locking, multiple activities), managing network connections (Wi-Fi, Ethernet, VPNs), administering user accounts, setting privacy options, controlling sound output and input, configuring power management profiles, adjusting display and monitor settings, and much more. By organizing these settings into logical categories and sub-categories, <b>systemsettings</b> simplifies the process of navigating and adjusting system preferences, eliminating the need for users to manually edit complex configuration files. It is an indispensable tool for personalizing, maintaining, and troubleshooting a KDE Plasma system.


title: CAVEATS
content:
This command is specifically designed for the KDE Plasma desktop environment. While it might be installable on other Linux distributions, its full functionality is dependent on the presence and configuration of KDE libraries and components. It will not operate effectively as a system settings utility on desktop environments like GNOME, XFCE, or LXQt.


title: KCMS (KDE CONTROL MODULES)
content:
<b>systemsettings</b> organizes its diverse functionalities into modular components known as KDE Control Modules (KCMs). Each KCM is responsible for managing a specific category of settings (e.g., 'Appearance', 'Network', 'User Accounts'). This modular design facilitates easy extension of the system settings and allows developers to integrate new configuration options seamlessly. Users can directly launch specific KCMs from the command line using the <b>--show</b> or <b>--module</b> options, which is particularly useful for scripting or quickly navigating to a specific setting section.


title: HISTORY
content:
<b>systemsettings</b> has been the central configuration utility for KDE since its early versions. It evolved from simpler configuration panels into a standalone, comprehensive application. With major releases like KDE 4 and later Plasma 5, it underwent significant redesigns to enhance user experience, improve organization, and ensure visual consistency, often adopting modern UI frameworks like QtQuick/QML. Despite these architectural and UI changes, its core purpose of providing a graphical interface for system and user settings has remained consistent.


title: SYNOPSIS
content:
<b>systool</b> [<i>options</i>] { <b>-b</b> | <b>-c</b> | <b>-d</b> | <b>-m</b> | <b>-v</b> | <b>-p</b> } [<i>sysfs_path</i> | <i>object_name</i>]


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all attributes for the selected objects. This option makes the output very verbose.<br><br><b><b>-A</b> <i>attribute</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the specified attribute(s). Can be used multiple times for several attributes. This filters the output significantly.<br><br><b><b>-b</b> [<i>bus_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List devices belonging to a specific bus type (e.g., 'usb', 'pci'). If <i>bus_name</i> is omitted, all bus types are listed.<br><br><b><b>-c</b> [<i>class_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List devices belonging to a specific class (e.g., 'net', 'sound'). If <i>class_name</i> is omitted, all classes are listed.<br><br><b><b>-d</b> [<i>device_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show device-specific information. If <i>device_name</i> is omitted, all devices are listed. Often used with <b>-v</b> for detailed output.<br><br><b><b>-D</b> <i>driver_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show devices currently using the specified <i>driver_name</i>.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show kernel driver information. Usually combined with <b>-v</b> to show driver-specific attributes.<br><br><b><b>-m</b> [<i>module_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show module-specific information. If <i>module_name</i> is omitted, all loaded modules are listed. Useful for checking module parameters and dependencies.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show bus-specific information. Provides details about the bus itself rather than devices on it.<br><br><b><b>-p</b> [<i>sysfs_path</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information for a specific sysfs path (e.g., '/sys/devices/pci0000:00/0000:00:1c.0'). This is the most direct way to query sysfs.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show attributes in raw format, without any human-readable formatting or unit conversions. Useful for scripting.<br><br><b><b>-s</b> [<i>subsystem_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information about a specific subsystem (e.g., 'block', 'net'). If <i>subsystem_name</i> is omitted, all subsystems are listed.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only devices with hotplug attributes. Useful for identifying devices that can be dynamically added or removed.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output. Includes detailed information and often all attributes for the selected object, similar to <b>-a</b> for devices/modules.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>systool</b> command is a utility from the <i>sysfsutils</i> package designed to query information exposed by the Linux kernel through the sysfs virtual filesystem. Sysfs provides a hierarchical view of the kernel's device model, including devices, drivers, buses, and modules. <b>systool</b> allows users to navigate and display attributes of these objects, making it invaluable for system introspection, hardware diagnostics, and debugging.<br><br>It can list devices by bus, class, or driver, show detailed attributes of specific devices or modules, and filter output to find relevant information quickly. While <b>udevadm info</b> also provides similar device information, <b>systool</b> offers a distinct interface for exploring the raw sysfs structure, often preferred by system administrators and developers needing a direct view into the kernel's device model.


title: CAVEATS
content:
<b>systool</b> relies on the <i>sysfs</i> filesystem being mounted, which is typically found at <i>/sys</i> on modern Linux distributions. Its output can be extremely verbose, especially when using <b>-a</b> or <b>-v</b> without specific filters, making it challenging to parse manually. While powerful for introspection, <b>systool</b> does not allow modification of kernel parameters or device states; it is strictly a read-only utility.


title: USAGE EXAMPLES
content:
Here are a few common ways to use <b>systool</b>:<br><br><i>List all USB devices with verbose details:</i><br><code>systool -b usb -v</code><br><br><i>Show details of a specific PCI device (e.g., a network card):</i><br><code>systool -d bridge:pci0000:00:1f.6 -v</code><br><i>(Note: The device path will vary on your system)</i><br><br><i>Examine a specific kernel module (e.g., 'usb_storage'):</i><br><code>systool -m usb_storage -v</code><br><br><i>List all devices within the 'net' class:</i><br><code>systool -c net</code><br><br><i>Show the 'manufacturer' attribute for all USB devices:</i><br><code>systool -b usb -A manufacturer</code>


title: HISTORY
content:
<b>systool</b> is part of the <i>sysfsutils</i> package, which was developed to provide user-space utilities for interacting with the <i>sysfs</i> virtual filesystem. Sysfs itself emerged in the Linux 2.6 kernel series as a replacement for the older `devfs` and a more structured way to expose kernel objects and their attributes. <b>systool</b> was created to offer a command-line interface to navigate this rich information source, serving as a primary tool for examining hardware and kernel device model details before <i>udevadm</i> gained its comprehensive info querying capabilities.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an <I>ASCII</I> (text) transfer, converting newline characters as appropriate for the receiving system.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a <I>binary</I> transfer (default for ZMODEM and YMODEM).<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Escape</I> all control characters. Useful when the serial line is not 8-bit clean.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Keep</I> the original filename case on the destination system.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Protect</I> existing destination files; do not overwrite them.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in <I>quiet</I> mode, suppressing verbose output and progress indicators.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Resume</I> an interrupted transfer. Applicable only for ZMODEM.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <I>verbose</I> output, showing transfer progress and status messages.<br><br><b>-w <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ZMODEM <I>window size</I> to <I>N</I> bytes, controlling the amount of data sent before acknowledgment.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <I>overwrite</I> of existing destination files (default behavior).<br><br><b>-X</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the <I>XMODEM</I> protocol for file transfer.<br><br><b>-Y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the <I>YMODEM</I> protocol for file transfer (batch mode XMODEM).<br><br><b>-Z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the <I>ZMODEM</I> protocol for file transfer (default and recommended).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<I>sz</I> is a utility from the <I>lrzsz</I> package, designed for reliable file transfers over serial lines or similar point-to-point connections, such as pseudo-terminals (e.g., when connecting via <I>ssh</I> and needing to transfer a file using a terminal emulator's ZMODEM support). It primarily uses the ZMODEM protocol, which offers error checking, crash recovery, and efficient block transfers, making it suitable for less reliable connections. It can fall back to YMODEM or XMODEM if ZMODEM is not supported by the receiving end.<br><br><I>sz</I> is typically paired with <I>rz</I> (receive ZMODEM) on the remote side. It's particularly useful in scenarios where <I>scp</I> or <I>sftp</I> might not be available or practical, such as when interacting with embedded systems, legacy devices, or during initial system setups before network services are fully configured. The command initiates a transfer, and a compatible terminal emulator on the local machine (running <I>rz</I> automatically or manually) receives the file.


title: CAVEATS
content:
File transfers with <I>sz</I> heavily rely on the capabilities of the terminal emulator on the receiving side to detect and handle ZMODEM sequences. It is generally not suitable for network file transfers where more robust and secure protocols like <I>SCP</I> or <I>SFTP</I> are available and preferred. Performance can be limited by serial line speeds or pseudo-terminal buffer sizes. Misconfiguration of terminal settings via <I>stty</I> can also interfere with transfers.


title: ZMODEM USAGE FLOW
content:
When using <I>sz</I>, the typical workflow involves:<br>1. Running <I>sz</I> on the remote Linux machine with the file(s) to send.<br>2. A compatible terminal emulator (e.g., SecureCRT, iTerm2 with an <I>iterm2-zmodem</I> plugin, minicom) on the local machine detects the ZMODEM initiation sequence.<br>3. The terminal emulator automatically or prompts to start its <I>rz</I> equivalent (or a built-in ZMODEM receiver) to begin receiving the file.<br>This allows file transfers even when standard network protocols like <I>SCP</I> or <I>SFTP</I> are not configured or available, relying purely on the terminal session.


title: HISTORY
content:
The <I>sz</I> command is part of the <I>lrzsz</I> package, which implements the ZMODEM, YMODEM, and XMODEM file transfer protocols. These protocols were developed in the 1980s by Chuck Forsberg and others, primarily for reliable data transmission over noisy analog telephone lines via modems. ZMODEM, in particular, offered significant advancements like crash recovery, larger block sizes, and efficient error checking compared to its predecessors. While originally designed for serial port communication, <I>lrzsz</I> found a new life in server administration, allowing file transfers over SSH connections through terminal emulators that support ZMODEM, even when direct <I>scp</I> or <I>sftp</I> access might be restricted or inconvenient. Its continued relevance highlights its robustness for 'last resort' or specific legacy transfer needs.


title: PARAMETERS
content:
<b><i>input_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Type 1 font file to process. If omitted, <b>t1ascii</b> reads from standard input.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds font statistics as PostScript comments to the output.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a font header suitable for a bare font program.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs <i>currentfile</i> PostScript statements for a bare font program, useful for embedding.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs PostScript for a bare font program, mapping all characters to the <i>notdef</i> glyph.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the <i>/CharStrings</i> dictionary for an existing PFA font.<br><br><b><b>-e</b> <i>encoding_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the <i>encoding</i> array from the specified <i>encoding_file</i> into the font.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes <i>currentfile</i> PostScript statements for a resident font program.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strips font statistics from the output.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts just the font program (the binary part) from the font file.<br><br><b><b>-o</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs the output to <i>output_file</i> instead of standard output.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<b>t1ascii</b> is a utility from the <i>t1utils</i> package designed to convert Adobe Type 1 font files from binary (PFB) format or an existing ASCII (PFA) format into a clean ASCII (PFA) format. This conversion makes the font data human-readable and suitable for editing, analysis, or use with tools that specifically require ASCII font descriptions. It primarily focuses on decompressing the binary font program part of a PFB file and presenting it as an ASCII PFA file. It also offers options to extract specific parts of the font or add/strip metadata, making it a valuable tool for font developers and system administrators working with Type 1 fonts.


title: CAVEATS
content:
<b>t1ascii</b> primarily processes the font data itself and does not extensively parse or validate the surrounding PostScript code within the font file. It's focused on the font program's binary-to-ASCII conversion. Issues might arise with malformed PostScript wrappers, though the core font data conversion should generally be robust.


title: PURPOSE OF PFA/PFB FORMATS
content:
PostScript Type 1 fonts can be stored in two main formats: <i>PFB (Printer Font Binary)</i>, which is compressed and binary, and <i>PFA (Printer Font ASCII)</i>, which is an ASCII representation. <b>t1ascii</b>'s primary role is to convert PFB to PFA, making the font definition human-readable and editable.


title: FONT EDITING AND ANALYSIS
content:
The ASCII PFA format produced by <b>t1ascii</b> is invaluable for inspecting the font's internal structure, character outlines, metrics, and PostScript code. This facilitates debugging, manual adjustments, or generating reports about a font's properties, especially for those involved in font development or customization.


title: HISTORY
content:
<b>t1ascii</b> is a component of the <i>t1utils</i> software package, which was developed by I. Lee Hetherington. The <i>t1utils</i> suite provides a set of command-line tools for manipulating Adobe Type 1 fonts, which were a prevalent font format in PostScript and desktop publishing environments. These utilities, including <b>t1ascii</b>, were essential for font developers, system administrators, and users who needed to convert, inspect, or modify Type 1 fonts, especially for use with systems like TeX/LaTeX or PostScript printers. Its development stems from the need to manage these fonts in a Unix-like environment.


title: DESCRIPTION
content:
<b>t1asm</b> is a utility designed to convert human-readable, ASCII-encoded PostScript Type 1 font programs (often with a <I>.pfa</I> extension) into their compact, binary representation (typically with a <I>.pfb</I> extension). Type 1 fonts were a standard for digital typography, particularly important in PostScript environments and desktop publishing workflows. This command takes the textual PostScript instructions defining a font's glyphs and metrics and compiles them into a more efficient, machine-readable binary format. The output is suitable for embedding in documents or for use by PostScript interpreters and print drivers. It serves as a crucial step in the Type 1 font development and deployment workflow, allowing font designers to work with a more accessible source format before converting it for distribution and use.


title: CAVEATS
content:
<ul><li>Exclusively handles the PostScript Type 1 font format; not compatible with TrueType, OpenType, or other modern font formats.</li><li>It is an assembler, not a font editor; it expects a syntactically correct PostScript Type 1 font program as input.</li><li>Primarily converts ASCII to binary; it does not perform font optimization, subsetting, or advanced validation beyond basic parsing.</li><li>Part of an older font technology stack; less frequently used directly in modern web or desktop environments which primarily favor OpenType fonts.</li></ul>


title: INPUT/OUTPUT FORMATS
content:
<b>t1asm</b> reads PostScript Type 1 Font ASCII (<I>PFA</I>) files and outputs PostScript Type 1 Font Binary (<I>PFB</I>) files. <I>PFA</I> files are human-readable text files containing PostScript code, while <I>PFB</I> files are a more compact binary representation, often used for embedding fonts in documents or sending them directly to printers. If no input file is specified, it reads from standard input. If no output file is specified, it writes to standard output.


title: HISTORY
content:
<b>t1asm</b> is a component of the suite of utilities for handling PostScript Type 1 fonts, which gained prominence in the 1980s and 1990s as a key technology for high-quality printing and digital publishing, particularly with Adobe PostScript and desktop publishing applications. It has long been included in distributions of Ghostscript and TeX Live, reflecting its role in preparing fonts for rendering and printing within these ecosystems. While Type 1 fonts have largely been superseded by OpenType for general use, tools like <b>t1asm</b> remain relevant for legacy systems, archiving, and specific font development workflows that still involve the Type 1 format.


title: SYNOPSIS
content:
<B>t1binary</B> [<i>-a</i> | <i>-b</i>] [<i>-l</i>] [<i>-q</i>] [<i>-v</i>] [<i>-n</i>] [<i>-u</i>] [<i>--</i>] [<i>input</i> [<i>output</i>]]


title: PARAMETERS
content:
<b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output to be in ASCII (PFA) format, even if the input is binary or if binary is the default. Useful for specific conversions.<br><br><b><i>-b</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output to be in binary (PFB) format. This is the default behavior if neither <i>-a</i> nor <i>-b</i> is specified.<br><br><b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a DOS-style form feed character (Ctrl-L, hexadecimal 0x0C) to separate sections in the output. Some older PostScript interpreters may require this.<br><br><b><i>-q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warning messages during the conversion process, providing a 'quiet' output.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the program's version information and then exits immediately.<br><br><b><i>-n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>t1binary</i> not to output the <i>eexec</i> section (the encrypted part of the font) as a binary block. This option is rarely useful for standard font operations.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the <i>eexec</i> section of the font unencrypted. This is primarily for debugging purposes and poses a security risk, as it exposes the font's internal, usually protected, data.<br><br><b><i>--</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of options. Any arguments following this are treated as filenames, even if they begin with a hyphen.<br><br><b><i>input</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the input Type 1 font file. If omitted, <i>t1binary</i> reads from standard input (stdin).<br><br><b><i>output</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output Type 1 font file. If omitted, <i>t1binary</i> writes to standard output (stdout).<br><br>


title: DESCRIPTION
content:
<i>t1binary</i> is a utility from the <B>t1utils</B> package, designed to convert Type 1 font files from their human-readable ASCII (PFA - Printer Font ASCII or AFM - Adobe Font Metrics) representation into a more compact binary (PFB - Printer Font Binary) format. This conversion is often necessary for efficient storage and faster processing by PostScript interpreters, printers, or typesetting systems. It typically preserves the encrypted sections of the font data. The command can read from standard input or a specified input file, and write to standard output or a specified output file, making it versatile for scripting and command-line operations. It primarily focuses on the font's PostScript language definition, ignoring separate font metric (AFM) information during conversion.


title: CAVEATS
content:
Using the <i>-u</i> (unencrypted output) option exposes the font's internal structure and potentially copyrighted data, which can be a security and licensing risk. The <i>-n</i> option is generally not recommended for typical font processing as it can lead to non-functional font files. This utility is specifically designed for Type 1 fonts; attempting to convert other font formats may lead to undefined behavior or errors.


title: TYPICAL USAGE
content:
<i>t1binary</i> is commonly employed when a PostScript interpreter, a specific application, or a printing system requires the compact binary PFB format instead of the ASCII PFA format. For instance, a user might convert a font received in PFA format to PFB before embedding it in a PostScript document, installing it into a system's font directories, or preparing it for a printer that prefers the binary format. This ensures compatibility and often improves processing speed.


title: HISTORY
content:
<i>t1binary</i> is a component of the <B>t1utils</B> package, a suite of tools developed by I. Lee Hetherington for manipulating Adobe Type 1 fonts. Its development stemmed from the need to process and convert font files in PostScript-centric environments. The <B>t1utils</B> package has been a crucial utility in the Unix/Linux ecosystem for desktop publishing, typesetting (especially with TeX and LaTeX systems), and graphics processing, maintaining its relevance for managing Type 1 font assets over many years.


title: SYNOPSIS
content:
<B>t1disasm</B> [<B>-a</B> | <B>-b</B>] [<B>-d</B>] [<B>-h</B>] [<B>-u</B> | <B>-U</B>] [<B>-g</B> <I>glyphs</I>] [<B>-o</B> <I>outfile</I>] [<I>fontfile</I> ...]


title: PARAMETERS
content:
<b><B>-a</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble the font programs into a PostScript ASCII (PFA) format, even if the input is PFB. This is the default if neither <B>-a</B> nor <B>-b</B> is specified for a PFB input.<br><br><b><B>-b</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble the font programs into a PostScript binary (PFB) format, primarily for binary PostScript data sections. Mutually exclusive with <B>-a</B>.<br><br><b><B>-d</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble charstrings. This option provides a detailed breakdown of the drawing commands for each glyph.<br><br><b><B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><B>-u</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undefine all PostScript commands before disassembly. This can simplify the output by showing raw PostScript instructions.<br><br><b><B>-U</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undefine all PostScript commands and operators before disassembly. A more aggressive version of <B>-u</B>, yielding even more primitive output. Mutually exclusive with <B>-u</B>.<br><br><b><B>-g</B> <I>glyphs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassemble only the specified glyphs. <I>glyphs</I> should be a comma-separated list of glyph names (e.g., 'A,B,C').<br><br><b><B>-o</B> <I>outfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the disassembled output to <I>outfile</I> instead of standard output (stdout).<br><br><b><I>fontfile</I> ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input Type 1 font files to be disassembled. If no <I>fontfile</I> is specified, <B>t1disasm</B> reads from standard input (stdin).<br><br>


title: DESCRIPTION
content:
<B>t1disasm</B> is a command-line utility from the <I>t1utils</I> suite designed to decompile or disassemble Adobe Type 1 font programs. It takes one or more Type 1 font files, typically in <B>PFA</B> (PostScript Font ASCII) or <B>PFB</B> (PostScript Font Binary) format, and outputs a human-readable representation of the font's internal structure and character drawing commands (charstrings).<br><br>This tool is invaluable for font developers, typographers, or anyone needing to inspect the low-level PostScript instructions that define glyph shapes within Type 1 fonts. It helps in debugging font rendering issues, understanding font metrics, or reverse-engineering font construction for analysis, although the output is for inspection and not directly reconstructible into an editable font file.


title: CAVEATS
content:
This command specifically targets Adobe Type 1 fonts. It is not designed for and will not work with other font formats like TrueType (<B>.ttf</B>), OpenType (<B>.otf</B>), or web fonts (<B>.woff</B>, <B>.woff2</B>).<br><br>The output is a low-level PostScript representation, which requires familiarity with PostScript language and Type 1 font structure to fully interpret. It is primarily for analysis and debugging, not for direct font editing or conversion to other formats without further processing.


title: INPUT/OUTPUT FLEXIBILITY
content:
<B>t1disasm</B> can read font data from one or multiple specified files. If no input file is given, it gracefully reads from standard input, allowing it to be used in pipes for more complex command sequences. By default, output is sent to standard output, making it easy to pipe to other commands (e.g., <I>less</I>, <I>grep</I>) or redirect to a file using the <B>-o</B> option.


title: PURPOSE AND USAGE
content:
The primary purpose of <B>t1disasm</B> is to aid in the analysis and debugging of Type 1 fonts. Font developers might use it to verify charstring definitions, debug incorrect glyph rendering, or understand how hinting instructions are applied. Users encountering issues with Type 1 fonts in PostScript-based workflows might use it to diagnose problems by inspecting the font's internal structure.


title: HISTORY
content:
<B>t1disasm</B> is part of the <I>t1utils</I> package, a collection of utilities for manipulating Adobe Type 1 fonts. These tools originated from Adobe Systems and were later released as open-source software, becoming a staple in the Unix/Linux font toolchain. Developed during a period when Type 1 fonts were dominant in desktop publishing, <B>t1disasm</B> has provided essential capabilities for inspecting and understanding these complex font structures for decades. While the importance of Type 1 fonts has waned with the rise of OpenType, <B>t1disasm</B> remains valuable for working with legacy projects or specific PostScript workflows.


title: PARAMETERS
content:
<b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints detailed information about the processing steps during execution.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all informational output, printing only error messages.<br><br><b>-o <<i>prefix</i>>, --output <<i>prefix</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base name for all generated output files (e.g., .tfm, .vf, .pl). If not provided, the base name of the input font file is used.<br><br><b>-p, --pl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a property list (PL) file for the font. This human-readable file describes the font's metrics and character mapping.<br><br><b>-k, --tfm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a TeX Font Metric (TFM) file. This file contains the essential metric information required by TeX for typesetting with the font.<br><br><b>-V, --vf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a Virtual Font (VF) file. This file provides instructions for typesetting engines on how to handle the font's characters, particularly for Type 1 fonts.<br><br><b>-e <<i>file</i>>, --enc <<i>file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an encoding file (<b>.enc</b>) to be used for the font. This file defines the mapping between character codes and glyphs.<br><br><b>-u, --unenc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes the font as unencoded, which can be useful for fonts where a specific encoding isn't necessary or desired.<br><br><b>-s, --no-synthesize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the synthesis of missing characters. By default, <b>t1mac</b> might attempt to generate approximations for characters not explicitly present in the font.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>t1mac</b> and exits.<br><br>


title: DESCRIPTION
content:
<b>t1mac</b> is a utility from the <b>lcdf-typetools</b> suite, designed to integrate PostScript Type 1 fonts into the TeX typesetting system. Its primary function is to process raw Type 1 font files, typically in <b>.pfb</b> (binary) or <b>.pfa</b> (ASCII) format, and generate the necessary font metric files (<b>.tfm</b>) and virtual font files (<b>.vf</b>) that TeX and its related tools, like <b>dvips</b>, require for correct font rendering. Additionally, it can produce property list files (<b>.pl</b>) for inspection or further manipulation.<br><br>By automating the conversion of PostScript font data into TeX-compatible formats, <b>t1mac</b> simplifies the process of using a wide range of commercially available or custom Type 1 fonts within TeX documents, ensuring proper character sizing, spacing, and ligature information is available to the typesetter. It plays a crucial role in the TeX font workflow, bridging the gap between raw font data and the highly specific requirements of TeX's font system.


title: CAVEATS
content:
<b>t1mac</b> is specifically designed for <b>PostScript Type 1</b> fonts and will not work directly with other modern font formats such as <b>TrueType</b> or <b>OpenType</b>.<br>Its primary output files (<b>.tfm</b>, <b>.vf</b>) are specific to the <b>TeX/LaTeX</b> typesetting ecosystem.<br>Correct font encoding is crucial; incorrect or missing encoding files (<b>.enc</b>) can lead to improper character display.<br>The tool relies on well-formed input font files; corrupted or malformed Type 1 fonts can cause processing errors.


title: INPUT AND OUTPUT FILES
content:
<b>t1mac</b> processes PostScript Type 1 font files, which can be either binary (<b>.pfb</b>) or ASCII (<b>.pfa</b>) format. Its primary outputs are TeX Font Metric (<b>.tfm</b>) files, essential for TeX's understanding of font dimensions, and Virtual Font (<b>.vf</b>) files, which handle character mapping and transformations. Optionally, it can generate human-readable property list (<b>.pl</b>) files for detailed inspection of font metrics.


title: HISTORY
content:
<b>t1mac</b> is a component of the <b>lcdf-typetools</b> suite, developed by Eddie Kohler, primarily for the LaTeX Project. These tools were created to provide robust and flexible methods for integrating PostScript Type 1 fonts into the TeX environment. Its development reflects the evolution of TeX usage from relying heavily on Metafont-generated bitmap fonts towards wider adoption of commercially available and open-source Type 1 fonts. <b>t1mac</b> plays a key role in bridging the gap between raw font data and the specific requirements of TeX's font system, significantly enhancing typographic capabilities within TeX documents. The suite has been consistently maintained and is a standard inclusion in modern TeX distributions like TeX Live.


title: SYNOPSIS
content:
<b>tabix</b> [<i>options</i>] <<i>file.gz</i>> [<i>region1</i> [<i>region2</i> [...]]]<br><b>tabix</b> -D <<i>file.gz</i>><br><b>tabix</b> -l <<i>file.gz</i>>


title: PARAMETERS
content:
<b><b>-p</b> <i><type></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify preset for indexing: <i>bed</i> (0-based, chr, start, end), <i>gff</i> (1-based, chr, start, end), <i>vcf</i> (1-based, chr, pos), <i>sam</i> (1-based, chr, pos). Automatically sets column indices.<br><br><b><b>-s</b> <i><seqCol></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Column number for sequence name (1-based). Default is 1.<br><br><b><b>-b</b> <i><startCol></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Column number for start coordinate (1-based). Default is 2.<br><br><b><b>-e</b> <i><endCol></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Column number for end coordinate (1-based). Default is 3.<br><br><b><b>-c</b> <i><char></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip lines beginning with this character (e.g., '#'). Default is '#'.<br><br><b><b>-S</b> <i><int></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip first <i><int></i> lines (e.g., header lines) before indexing.<br><br><b><b>-B</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable 0-based indexing (BED-like coordinates). Default is 1-based.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwrite of existing index file if it already exists.<br><br><b><b>-r</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve regions specified in a file (one region per line).<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the content of the index file to standard output for debugging.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List sequence names (chromosomes/contigs) from the index.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the header lines from the input file during query (lines before <b>-S</b> and starting with <b>-c</b>).<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress header lines from output during query.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output, showing progress and detailed information.<br><br>


title: DESCRIPTION
content:
<b>tabix</b> is a utility designed for indexing and retrieving data from large, tab-delimited files, particularly those containing genomic coordinates like BED, GFF, VCF, and SAM formats.<br><br>It creates a binary index file (<i>.tbi</i>) that allows for rapid, random access to specific regions within the compressed data file without needing to load the entire file into memory. This is crucial for bioinformatics applications dealing with massive datasets.<br><br>For optimal performance, input files should be compressed with <b>BGZF</b> (Block-Gzip) and sorted by genomic coordinate. <b>tabix</b> enables efficient extraction of lines that overlap with specified genomic regions, making it an indispensable tool for data exploration and downstream analysis in genomics.


title: CAVEATS
content:
The input file <i>must</i> be compressed with <b>BGZF</b> (Block-Gzip) for efficient indexing and querying. Standard <b>gzip</b> compression will not work effectively.<br><br>The input file also <i>must</i> be sorted by sequence name and then by start coordinate. Unsorted files will result in incorrect indexing and query results.<br><br>The <i>.tbi</i> index file must reside in the same directory as the compressed data file for <b>tabix</b> to be able to query it.


title: HISTORY
content:
<b>tabix</b> was developed by <i>Heng Li</i> as part of the <i>HTSlib</i> project, which also underpins <b>samtools</b> and <b>bcftools</b>. It emerged as a critical tool for handling the increasing size of genomic datasets, providing a standard and efficient method for indexing and querying large, coordinate-sorted, tab-delimited files. Its design, leveraging the BGZF compression format, revolutionized how researchers access and process genomic information, becoming an industry standard for formats like VCF and BED.


title: SYNOPSIS
content:
<b>tabs</b> [<I>options</I>] [<I>tabstop-list</I>]<br><br><I>tabstop-list</I> can be a comma-separated list of column numbers (e.g., `1,5,10,20`), an interval notation (e.g., `-n+m`), or a predefined type (e.g., `-8`, `-c`, `-u`).


title: PARAMETERS
content:
<b><I>tabstop-list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of explicit column numbers (e.g., `1,5,10,20`), or an interval definition (`-n+m` meaning every `n` columns starting at `m+1`).<br><br><b>-8</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Default tabs</I>. Sets tab stops at every 8 columns (1, 9, 17, ...).<br><br><b>-a, -a<I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Assembler tabs</I>. Sets tabs for assembler code (1, 10, 16, 36, 72). With `<I>N</I>`, the fourth stop is `<I>N</I>`.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>C-style tabs</I>. Sets tabs for C code (1, 9, 17, 25, ...).<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>EBCDIC tabs</I>. Sets tabs for EBCDIC code (1, 7, 15, 19, 43, 80).<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Fortran tabs</I>. Sets tabs for Fortran code (1, 7, 11, 15, 19, 23, ...).<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>PL/I tabs</I>. Sets tabs for PL/I code (1, 5, 9, 13, 17, 21, ...).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>SNOBOL tabs</I>. Sets tabs for SNOBOL code (1, 10, 55).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>TABEX tabs</I>. Sets tabs for TABEX code (1, 8, 12, 16, 20, 24, ...).<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>UNIX tabs</I>. Sets tabs for UNIX code (1, 9, 17, 25, ...).<br><br><b>+m<I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Margin offset</I>. Used with certain predefined types (e.g., `-a`) to add a left margin of `<I>N</I>` columns before applying tab stops.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Debugging output</I>. Prints debugging information to standard error.<br><br><b>-n, --newlines</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Newline control</I>. Ensures a newline is printed after each tab setting command.<br><br><b>-T <I>TERM</I>, --term=<I>TERM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify terminal type</I>. Overrides the `TERM` environment variable for tab calculations.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Version information</I>. Displays the program's version number and exits.<br><br>


title: DESCRIPTION
content:
The <b>`tabs`</b> command is a <I>curses</I> program designed to configure <I>hardware tab stops</I> on a terminal. Unlike <I>software tabs</I> (handled by applications like text editors), hardware tabs are managed directly by the terminal emulator or physical terminal using specific escape sequences defined in the <I>terminfo</I> database. When a tab character is sent, the cursor jumps directly to the next hardware tab stop.<br><br>This utility provides various methods to specify tab stops, including common predefined patterns (e.g., default every 8 columns, C-style, or Fortran-style) and custom lists of column positions. While less critical on modern graphical terminal emulators (which often just expand tabs to spaces), hardware tabs can still be useful for performance or consistent behavior in specific environments, especially on older systems or serial consoles where every character transmission is significant. It overwrites any previously set hardware tab stops.


title: CAVEATS
content:
Not all terminal emulators or physical terminals fully support hardware tab stop settings; many modern ones simply interpret tabs as spaces.<br><br>The <b>`tabs`</b> command overwrites any previously configured hardware tab stops. Be aware that settings are specific to the current terminal session.<br><br>Incorrect <I>terminfo</I> entries for your terminal type can lead to <b>`tabs`</b> not functioning as expected or not at all.


title: HARDWARE VS. SOFTWARE TABS
content:
<b>Hardware tabs</b> are settings stored and managed by the terminal itself. When a tab character is received, the terminal's internal logic moves the cursor directly to the next predefined tab stop using specific escape sequences. This is distinct from <b>software tabs</b>, where applications (like text editors) interpret a tab character and then send multiple space characters or other sequences to achieve the desired indentation. Hardware tabs are generally faster as they involve less data transmission but offer less flexibility than software tabs managed by applications.


title: TAB SPECIFICATION METHODS
content:
<b>`tabs`</b> provides several ways to define tab stops.<br><br><b>Predefined Types:</b> Options like `-8` (every 8 columns), `-c` (C-style), `-f` (Fortran-style), etc., set common patterns.<br><br><b>Explicit List:</b> A comma-separated list of column numbers (e.g., `1,10,25,50`) defines exact tab stop positions.<br><br><b>Interval Notation:</b> The format `-n+m` sets tab stops every `n` columns, with the first stop at column `m+1`.


title: HISTORY
content:
The <b>`tabs`</b> command is an integral part of the <I>ncurses</I> project, a widely used library providing a free software implementation of the <I>System V Release 4.0 curses</I> API. Its purpose has consistently been to manage terminal hardware tab stops, leveraging the comprehensive <I>terminfo</I> database to send the correct escape sequences to various terminal types.<br><br>While the prevalence of physical terminals has waned, and modern terminal emulators often handle tabs through software (e.g., inserting spaces), <b>`tabs`</b> persists as a utility. It ensures compatibility with legacy systems and offers a way to configure low-level terminal behavior where hardware-level control is desired or beneficial, such as on serial consoles or in highly optimized environments. Its development has mirrored that of the <I>ncurses</I> library, adapting to evolving terminal standards while maintaining its core functionality.


title: SYNOPSIS
content:
<i><B>Note:</B> `tabula` is not a standard, pre-installed Linux command. This synopsis refers to the command-line interface of the <B>Tabula</B> PDF extraction tool (tabula-extractor).</i><br><br><i>java -jar /path/to/tabula-extractor.jar</i> [<I>options</I>] <I>&lt;PDF_FILE&gt;</I>


title: PARAMETERS
content:
<b><i>-p PAGES</i>, <i>--pages PAGES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which pages to extract. Can be 'all', a comma-separated list (e.g., '1,3,5'), or a range (e.g., '1-5').<br><br><b><i>-a TOP,LEFT,BOTTOM,RIGHT</i>, <i>--area TOP,LEFT,BOTTOM,RIGHT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a rectangular area to extract data from, defined by coordinates in points from the top-left corner of the page (e.g., '90,60,700,500').<br><br><b><i>-o OUTPUT_FILE</i>, <i>--output OUTPUT_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output file where extracted data will be saved. If not specified, output goes to standard output.<br><br><b><i>-f FORMAT</i>, <i>--format FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format. Common formats include 'CSV', 'JSON', and 'TSV'.<br><br><b><i>-g</i>, <i>--guess</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to automatically guess the table structure within the specified area or page, particularly useful for tables without explicit ruling lines.<br><br><b><i>-r</i>, <i>--stream</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables stream mode, which is suitable for tables that do not have ruling lines between columns (e.g., text-based tables where data aligns by spaces).<br><br><b><i>-s</i>, <i>--spreadsheet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables spreadsheet mode, which is best for tables with clearly defined ruling lines between cells, attempting to use the lines for cell detection.<br><br><b><i>--silent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages and warnings during the extraction process, only printing errors.<br><br>


title: DESCRIPTION
content:
<B>Tabula</B> is an open-source tool for liberating data tables trapped inside PDF files. While not a native Linux command installed by default in most distributions, its functionality is typically accessed via a Java Archive (JAR) executable or a Python wrapper. It empowers users to automatically or manually identify and extract structured data from PDF documents, converting it into various machine-readable formats such as CSV, TSV, or JSON. This is particularly useful for extracting data from scanned documents, reports, or scientific papers where direct copying is not feasible. Its command-line interface offers powerful options for specifying pages, areas, and output formats, making it highly suitable for scripting and integrating into automated data processing workflows.


title: CAVEATS
content:
<B>Non-Standard Command:</B> The term `tabula` is not a standard, pre-installed Linux command. This analysis refers to the command-line interface of the <B>Tabula</B> PDF extraction tool (often invoked directly via <i>java -jar</i>).<br><br><B>Dependency:</B> The JAR version of Tabula requires a Java Runtime Environment (JRE) to be installed on the system. If using the Python wrapper <i>tabula-py</i>, Python and its associated dependencies are required.<br><br><B>Accuracy:</B> Extraction accuracy can vary significantly depending on the PDF's internal structure, quality, and how tables are rendered. Scanned PDFs (which are essentially images of text) are much harder to process than text-based PDFs. Complex layouts or poorly aligned data may require manual area specification for best results.


title: INSTALLATION
content:
Tabula is not typically installed via standard Linux package managers like `apt` or `dnf` as a direct command. Users usually download the Java JAR file (e.g., <i>tabula-extractor.jar</i>) from the official GitHub repository or website, and execute it using an installed Java Runtime Environment (JRE). Alternatively, the Python wrapper, <i>tabula-py</i>, can be installed via <i>pip</i>: <br><i>pip install tabula-py</i><br>which then provides an API to access Tabula's core functionality within Python scripts.


title: USE CASES
content:
Tabula is ideally suited for a wide range of data extraction tasks, including retrieving financial figures from annual reports, extracting statistical tables from academic papers or research documents, and pulling tabular information from government publications or legal documents. It automates a process that would otherwise be highly time-consuming, expensive, and susceptible to manual data entry errors.


title: HISTORY
content:
The <B>Tabula</B> project was initiated by journalists at the Knight-Mozilla OpenNews program. It emerged from a common and pressing need within journalism and research communities to extract data from government documents, reports, and other publications often distributed solely in PDF format. Historically, accessing this data was a tedious, manual process prone to errors. Tabula's development focused on creating both a user-friendly graphical interface and a robust command-line interface, making it a popular and essential tool for automating data extraction workflows and liberating information locked within PDFs.


title: SEE ALSO
content:
pdftotext(1), qpdf(1), awk(1), grep(1), sed(1), camelot (similar external tool for PDF table extraction)


title: PARAMETERS
content:
<b><b>-b</b>, <b>--before</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append the separator to the beginning of the record that <i>tac</i> reads. By default, the separator is considered part of the *preceding* record.<br><br><b><b>-r</b>, <b>--regex</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the separator string as a regular expression. This allows for more complex delimiter patterns.<br><br><b><b>-s</b>, <b>--separator</b>=<i>STRING</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>STRING</i> as the record separator instead of the default newline character. Each instance of <i>STRING</i> defines the boundary between records.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input files to process. If no <i>FILE</i> is specified, or if <i>FILE</i> is a hyphen (<i>-</i>), <i>tac</i> reads from standard input.<br><br>


title: DESCRIPTION
content:
<i>tac</i> is the reverse counterpart of the <i>cat</i> command. While <i>cat</i> concatenates and prints files to standard output starting from the first line, <i>tac</i> concatenates and prints files from the last line, then the second-to-last, and so on, until the first line. This makes it particularly useful for examining log files where the most recent entries are typically appended at the end. By default, <i>tac</i> uses the newline character as its record separator, treating each line as a distinct record. However, it provides options to specify a different separator string and even interpret that separator as a regular expression, offering flexibility for various file formats. When no file is specified, or when a hyphen (<i>-</i>) is used as a filename, <i>tac</i> reads from standard input.


title: CAVEATS
content:
When using custom separators, especially with the <i>--before</i> option, understanding how <i>tac</i> defines and includes the separator within a 'record' is crucial, as it can affect the output. Using regular expressions for separators (<i>--regex</i>) might incur a performance overhead for very large files compared to fixed string separators.


title: STANDARD INPUT/OUTPUT
content:
If no input <i>FILE</i> is provided or if <i>-</i> is used as a filename, <i>tac</i> reads from standard input (e.g., from a pipe). The processed content is always written to standard output.


title: HISTORY
content:
<i>tac</i> is a standard utility included in the GNU Core Utilities, making it widely available across most Unix-like operating systems. It was developed as a direct inverse to the ubiquitous <i>cat</i> command, addressing the common need to view files, particularly log files, in reverse chronological order. Its fundamental functionality has remained consistent since its inception.


title: PARAMETERS
content:
<b><b>-n</b> <I>NUM</I>, <b>--lines=</b><I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Output the last <I>NUM</I> lines. <I>NUM</I> can be prefixed with '+' to start outputting from the <I>NUM</I>th line of each file, rather than displaying the last <I>NUM</I> lines. A negative <I>NUM</I> is equivalent to a plain <I>NUM</I>.<br><br><b><b>-c</b> <I>NUM</I>, <b>--bytes=</b><I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Output the last <I>NUM</I> bytes. Similar to <b>-n</b>, <I>NUM</I> can be prefixed with '+' to start outputting from the <I>NUM</I>th byte.<br><br><b><b>-f</b>, <b>--follow[={name|descriptor}]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Output appended data as the file grows. If the file is renamed or rotated (e.g., by logrotate), <b>--follow=descriptor</b> (default) continues to track the original file descriptor, while <b>--follow=name</b> will reopen the file by name, thus tracking the new file after rotation.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Effectively the same as <b>--follow=name --retry</b>. This is a common and convenient option for robust log monitoring, as it continuously tries to open a file by name, even if it's currently unavailable or rotated.<br><br><b><b>-q</b>, <b>--quiet</b>, <b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Never output headers giving file names when processing multiple files.<br><br><b><b>-s</b> <I>NUM</I>, <b>--sleep-interval=</b><I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>With <b>-f</b>, sleep for approximately <I>NUM</I> seconds (default 1.0) between checks for new data. This reduces CPU usage when monitoring files that are updated infrequently.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Always output headers giving file names, even when only processing a single file.<br><br><b><b>-z</b>, <b>--decompress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Decompress gzipped files before displaying their content.<br><br><b><b>--retry</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>With <b>-f</b>, keep trying to open a file even if it is initially inaccessible or disappears. Useful for monitoring files that might not exist yet or are subject to rotation.<br><br><b><b>--pid=</b><I>PID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>With <b>-f</b>, terminate <b>tail</b> after process ID <I>PID</I> dies. Useful for monitoring logs related to a specific running process.<br><br><b><b>--max-unchanged-stats=</b><I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>With <b>-f</b>, terminate after <I>N</I> iterations of a file having unchanged size/inode. This prevents <b>tail</b> from running indefinitely on a file that has stopped being updated.<br><br>


title: DESCRIPTION
content:
The <b>tail</b> command is a fundamental Unix and Linux utility used to output the last part of files. By default, it prints the last 10 lines of each specified file to standard output. It is most commonly used for monitoring log files in real-time, as its <b>--follow</b> option allows it to continuously display new lines appended to a file as they are written. This makes <b>tail</b> indispensable for system administrators and developers for debugging, tracking system events, and observing application logs without needing to repeatedly open and close the file. It can display content by lines or by bytes and offers various options to control its output and behavior, such as displaying headers for multiple files, quiet mode, and handling file rotation.


title: CAVEATS
content:
When <b>tail</b> is used with multiple <b>FILE</b> arguments, it prefixes the output for each file with a header indicating the filename, unless <b>-q</b> is used. <br>The <b>--follow</b> option is powerful for log monitoring but needs careful consideration for how it interacts with log rotation schemes. <b>--follow=descriptor</b> (the default <b>-f</b>) will continue reading the old file after it's been rotated, which might not be desired. <b>--follow=name</b> or <b>-F</b> is generally preferred for robust log monitoring as it tracks the file by its name and automatically switches to the new log file created after rotation, often in combination with <b>--retry</b>. <br>Using <b>--bytes</b> or <b>--lines</b> with large numbers on very large files can be slow as <b>tail</b> might need to seek backward through a significant portion of the file.


title: DEFAULT BEHAVIOR
content:
<br>If no <b>FILE</b> is specified, or when <b>FILE</b> is <b>-</b>, <b>tail</b> reads from standard input. By default, without any options like <b>-n</b> or <b>-c</b>, <b>tail</b> outputs the last 10 lines.


title: NUMBERING WITH +NUM
content:
<br>When <I>NUM</I> is prefixed with <b>+</b> (e.g., <b>tail -n +100 file.log</b>), <b>tail</b> starts outputting from the specified line number (or byte number with <b>-c</b>) until the end of the file, rather than showing the last <I>NUM</I> lines/bytes. This effectively shows the file <I>from</I> a certain point.


title: HISTORY
content:
The <b>tail</b> command is a standard utility in Unix-like operating systems, part of the coreutils package on Linux. Its functionality has been a staple since the early days of Unix, providing a simple yet powerful way to inspect the end of text files. The <b>--follow</b> option, a widely used feature, was a significant enhancement, transforming <b>tail</b> into a real-time log monitoring tool, distinguishing it from simpler utilities that only display static content. Its design is aligned with the Unix philosophy of providing small, single-purpose tools that can be combined to perform complex tasks.


title: PARAMETERS
content:
<b><b>-n</b> <i>N</i>, <b>--lines=</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the last <i>N</i> lines of the <i>FILE</i> before starting to follow new data. If omitted, <i>tailf</i> typically outputs the last 10 lines by default, similar to <i>tail</i>.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information for <i>tailf</i> and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br>


title: DESCRIPTION
content:
<i>tailf</i> is a command-line utility used to monitor the growth of a file, much like <i>tail -f</i>. Its primary distinction lies in how it interacts with the file: instead of keeping the file continuously open, <i>tailf</i> periodically reopens it, reads new data, and then closes it. This approach offers several advantages, especially when dealing with log files on network file systems (NFS) or highly dynamic environments.<br><br>The intermittent file opening behavior reduces resource consumption and can prevent issues related to stale file handles that might occur on NFS. It also makes <i>tailf</i> more resilient to file truncations and certain log rotation schemes, as it will naturally pick up the 'new' file content after a truncation. While modern GNU <i>tail -f</i> implementations have evolved to handle many of these scenarios gracefully (e.g., with options like <i>--follow=name</i>), <i>tailf</i> remains a lightweight and often preferred tool for its specific, robust re-opening mechanism.


title: CAVEATS
content:
<i>tailf</i> does not inherently follow file renames; it tracks the original inode. If a file is renamed and a new file with the same name is created (a common log rotation strategy), <i>tailf</i> will continue to watch the old, renamed file unless it's explicitly restarted or the old file is removed. Modern GNU <i>tail -f</i> with <i>--follow=name --retry</i> often handles this more robustly. Additionally, <i>tailf</i>'s polling nature means it might introduce a slight delay in displaying very rapid updates compared to a continuously open file.


title: COMPARISON WITH <I>TAIL -F</I>
content:
The key difference between <i>tailf</i> and <i>tail -f</i> lies in their file handling. <i>tail -f</i> (from GNU coreutils) keeps the file descriptor open indefinitely, which is efficient but can cause issues with NFS or when the underlying file is replaced. <i>tailf</i>, by contrast, periodically closes and reopens the file. This makes it more resilient to certain file system events like truncations or when files are moved/deleted by log rotation systems (though not renames of the original file). For most general-purpose log following on local file systems, <i>tail -f</i> is often sufficient and more widely available with a richer set of options. <i>tailf</i> shines in scenarios demanding its specific re-opening behavior.


title: HISTORY
content:
The <i>tailf</i> utility has historically been part of various Linux distributions, often bundled within packages like <i>sysvinit-utils</i> or <i>util-linux</i>. It emerged as a solution to specific challenges posed by <i>tail -f</i> in older Unix/Linux environments, particularly regarding network file system (NFS) performance and the handling of log file rotations where the file might be truncated or replaced. Its design prioritizes releasing file handles, making it distinct from continuously-open approaches. While advancements in GNU <i>tail</i> have mitigated many of the issues <i>tailf</i> was designed to address, <i>tailf</i> persists as a simple, effective tool for its niche use cases.


title: SYNOPSIS
content:
<b>tailscale</b> [<i>global-options</i>] &lt;<i>command</i>&gt; [<i>command-options</i>] [<i>arguments</i>]


title: PARAMETERS
content:
<b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format, useful for scripting and programmatic parsing.<br><br><b><b>--socket</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the Tailscale daemon's control socket. Useful if the default location is not desired or multiple daemons are running.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging to standard error, providing more detailed information about the command's execution.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable extensive debugging output to standard error, providing the most detailed logs for troubleshooting (implies <b>--verbose</b>).<br><br>


title: DESCRIPTION
content:
The <b>tailscale</b> command-line tool is the primary interface for managing the Tailscale client on Linux systems. Tailscale is a zero-configuration VPN that establishes a secure mesh network using the WireGuard protocol. It connects devices, servers, and cloud instances seamlessly and securely, regardless of their location or network. Unlike traditional VPNs, Tailscale focuses on creating direct peer-to-peer connections whenever possible, enhancing performance and reducing latency. It leverages your existing identity provider (e.g., Google, Microsoft Entra ID, GitHub) for authentication, simplifying access control. The command allows users to bring their Tailscale interface up or down, view network status, manage services, generate TLS certificates, and perform various network-related diagnostics within their private Tailscale network. It automates firewall and routing configurations, making complex network setups accessible for remote work, cloud infrastructure, and personal use.


title: CAVEATS
content:
The <b>tailscale</b> command requires the Tailscale daemon (<b>tailscaled</b>) to be running in the background to function. Initial device authentication typically involves a web browser for logging in with an identity provider. Network connectivity is essential for the daemon to communicate with Tailscale's coordination servers and other peers. Proper firewall rules must allow WireGuard traffic (UDP port 4164) for peer-to-peer connections.


title: COMMON SUBCOMMANDS
content:
The <b>tailscale</b> command primarily operates through subcommands, each managing a specific aspect of the Tailscale client. Users typically interact with these subcommands to control the VPN connection and network settings.<br><br><b>up</b>: Authenticates the device and brings the Tailscale network interface up, connecting to your network.<br><b>down</b>: Shuts down the Tailscale network interface, disconnecting from your network.<br><b>status</b>: Displays the current connection status, including connected peers, their IP addresses, and network health.<br><b>ip</b>: Shows the Tailscale IP addresses assigned to the local device.<br><b>netcheck</b>: Reports on the network environment, including NAT type and connectivity to Tailscale relays.<br><b>login</b>: Initiates the web-based authentication flow to add your device to your Tailscale network.<br><b>logout</b>: Disconnects the device from the Tailscale network and logs it out.<br><b>serve</b>: Configures local services to be exposed securely on your Tailscale network.<br><b>cert</b>: Manages TLS certificates issued by Tailscale for your device.


title: HISTORY
content:
Tailscale was founded in 2019 by a team of engineers, with a vision to simplify secure network access. It quickly gained prominence by building upon the robust and efficient WireGuard protocol, adding a crucial layer of identity-aware access control and zero-configuration setup. Its focus on user experience, seamless integration with existing identity providers, and the ability to establish direct peer-to-peer connections has made it a leading solution for modern remote access and private networking, rapidly evolving its features and adoption since its inception.


title: SYNOPSIS
content:
<b>tailscale file</b> <br><br><b>Sending Files:</b><br><i>tailscale file put [options] &lt;file&gt; &lt;destination&gt;</i><br><br><b>Receiving Files:</b><br><i>tailscale file get [options] [&lt;file-id&gt;]</i><br><br><b>Listing Pending Files:</b><br><i>tailscale file ls [options]</i>


title: PARAMETERS
content:
<b>put &lt;file&gt; &lt;destination&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends the specified <i>&lt;file&gt;</i> to the <i>&lt;destination&gt;</i>. The destination can be a Tailscale device name (e.g., 'my-laptop') or a Tailscale IP address (e.g., '100.x.y.z').<br><br><b>get [&lt;file-id&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves pending files. If no <i>&lt;file-id&gt;</i> is specified, it will interactively list available files to download. If an <i>&lt;file-id&gt;</i> is provided, it downloads that specific file directly.<br><br><b>ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists files that have been sent to the current device and are awaiting retrieval. Shows file names, sizes, senders, and unique IDs.<br><br><b>-name &lt;filename&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>put</b>) Specifies the name the file will appear as on the receiving device. Useful if the local filename is long or contains special characters. Example: <i>-name 'report.pdf'</i><br><br><b>-o &lt;output-path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>get</b>) Specifies the output directory or full path for the downloaded file. If a directory is provided, the original filename is preserved. Example: <i>-o ~/Downloads/</i><br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>put</b> and <b>get</b>) Runs in quiet mode, suppressing progress indicators and non-essential output during transfer.<br><br>


title: DESCRIPTION
content:
The <b>tailscale-file</b> command facilitates secure and easy file transfers between devices connected on a Tailscale network. It allows users to send files to other Tailscale nodes by their name or IP address, and to receive files that have been sent to them. This utility abstracts away the complexities of network configuration and firewall rules, leveraging Tailscale's end-to-end encrypted connections for direct, peer-to-peer file transfer when possible, or through Tailscale's relays when direct connections are not feasible. It is particularly useful for quickly sharing documents, images, or other files without setting up traditional file sharing protocols like SCP or SMB.


title: CAVEATS
content:
File transfers require both the sending and receiving devices to have the Tailscale daemon running and be connected to the same Tailscale network. Files sent are held on Tailscale's infrastructure for a limited time (typically 24 hours) if not retrieved, after which they are automatically deleted. Ensure sufficient disk space on the receiving device before attempting to download large files. Transfers are subject to network conditions and Tailscale's relay capacity if a direct connection cannot be established.


title: HISTORY
content:
The <b>tailscale-file</b> command was introduced as part of the broader Tailscale client application to simplify secure file transfer within a Tailscale network. Its development aimed to provide a user-friendly, cross-platform alternative to traditional file sharing methods, leveraging Tailscale's existing secure mesh network capabilities. It evolved to integrate seamlessly with the Tailscale user experience, allowing for quick file exchange without complex setup or firewall considerations, directly addressing common user needs for secure data movement between their own devices.


title: PARAMETERS
content:
<b>-advertise-exit-node</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to enable/disable advertising this device as an exit node.<br><br><b>-advertise-routes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of IP addresses or CIDR ranges to advertise as subnets (e.g., '192.168.1.0/24,10.0.0.0/8').<br><br><b>-exit-node</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the IP address or hostname of a remote Tailscale device to use as an exit node.<br><br><b>-exit-node-ip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the exact IP address of the exit node to use, if multiple IPs are available for a given exit node.<br><br><b>-exit-node-allow-lan-access</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to allow/disallow access to local LAN resources when using an exit node.<br><br><b>-hostname</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the device's advertised hostname within the Tailscale network.<br><br><b>-json-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a JSON file containing configuration options to apply.<br><br><b>-key-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a key file for pre-authenticated node setup.<br><br><b>-login-server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative login server URL for authentication (e.g., for Headscale).<br><br><b>-netcheck</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to enable/disable network connectivity checks.<br><br><b>-override-hostsfile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to control if Tailscale manages /etc/hosts for MagicDNS.<br><br><b>-shields-up</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to enable/disable the 'Shields Up' firewall feature.<br><br><b>-ssh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to enable/disable the built-in Tailscale SSH server.<br><br><b>-up</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' to ensure the Tailscale interface is brought up after configuration.<br><br><b>-webclient</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set to 'true' or 'false' to enable/disable the local web UI (beta feature).<br><br><b>-wait-engine</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the Tailscale engine to be ready before executing the command.<br><br>


title: DESCRIPTION
content:
The <b>tailscale set</b> command is a crucial subcommand of the main <b>tailscale</b> client, designed for comprehensive configuration of a Tailscale node directly from the command line. It provides granular control over various aspects of the Tailscale client's operation, allowing administrators and users to customize network behavior, security features, and device visibility within their tailnet.<br><br>Users can leverage <b>tailscale set</b> to enable or disable features such as advertising the device as an exit node or advertising specific subnets (routes) to the tailnet. It can also be used to configure the device to use a remote exit node, control whether that exit node allows local LAN access, and set the device's hostname within Tailscale. Advanced configurations include specifying a custom login server, enabling or disabling the built-in Tailscale SSH server, and activating the 'Shields Up' firewall feature for enhanced security.<br><br>This command is particularly useful for scripting Tailscale deployments, automating configurations in server environments, or making quick adjustments without needing to access the web-based admin console. Changes applied with <b>tailscale set</b> are generally persistent across system reboots, ensuring that the desired configuration remains active. It acts as the primary interface for fine-tuning a Tailscale node's role and connectivity within the secure mesh network.


title: CAVEATS
content:
The command typically requires root privileges (using <b>sudo</b>) to modify system-level network configurations. Changes made with <b>tailscale set</b> are usually persistent across reboots. Note that 'tailscale-set' is not a standalone binary but a conceptual representation; the actual command is '<b>tailscale set</b>'. Incorrect configuration, especially of routes or exit nodes, can disrupt network connectivity.


title: PERSISTENCE
content:
Most configurations applied with <b>tailscale set</b> are written to the Tailscale configuration file and persist across system reboots, ensuring that your desired network behavior is maintained without manual re-configuration.


title: INTERACTION WITH DAEMON
content:
The <b>tailscale set</b> command interacts directly with the running <b>tailscaled</b> daemon. For the changes to take effect and for the command to function correctly, the Tailscale daemon must be active and accessible.


title: HISTORY
content:
The <b>tailscale set</b> command has evolved significantly as Tailscale itself has matured. Initially, some configurations might have been handled by separate commands or primarily through the web UI. As the CLI became more comprehensive, <b>set</b> emerged as the central, unified command for managing device-specific settings. Its feature set expanded to include options for newer functionalities like Tailscale SSH and 'Shields Up' as these capabilities were introduced into the Tailscale platform, making it an indispensable tool for automation and fine-grained control.


title: PARAMETERS
content:
<b><b>-p</b> <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port to connect to on the remote host, overriding the default SSH port (22).<br><br><b><b>-i</b> <i>identity_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects an identity file (private key) for public key authentication. While less common with <i>tailscale-ssh</i>'s identity-based model, it can be used for specific setups.<br><br><b><b>-o</b> <i>option</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes OpenSSH client configuration options directly, such as <i>"ProxyCommand=none"</i> for specific network scenarios.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, displaying debugging messages about the connection process.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warning and diagnostic messages.<br><br>


title: DESCRIPTION
content:
<i>tailscale-ssh</i> is a powerful command-line utility integral to the Tailscale ecosystem, enabling secure SSH connections to other devices within your Tailscale network. Unlike traditional SSH, which relies on managing individual SSH keys or passwords, <i>tailscale-ssh</i> leverages Tailscale's identity-based access control and centralizes authorization through Tailscale's ACLs (Access Control Lists).<br><br>This command simplifies infrastructure management significantly. Users are authenticated based on their Tailscale identity, and access permissions are enforced by your organization's Tailscale policy, eliminating the need for manual key distribution or complex SSH configurations on each host. It works by acting as a wrapper or proxy for the standard OpenSSH client, ensuring that all traffic is encrypted, authenticated, and routed securely over the Tailscale mesh. It's particularly valuable for environments with many machines where maintaining consistent, secure remote access without key sprawl is a priority.


title: CAVEATS
content:
For <i>tailscale-ssh</i> to function, both the client and the target machine must have the Tailscale daemon running and be connected to the same Tailnet. The target machine's SSH daemon (<i>sshd</i>) must be specifically configured to allow <i>tailscale-ssh</i> access, often by utilizing a <i>AuthorizedKeysCommand</i> directive in <i>sshd_config</i> to query Tailscale for authorized keys, or by enabling the Tailscale SSH feature on the node. Authorization is strictly governed by Tailscale ACLs.


title: CONFIGURATION ON TARGET HOST
content:
To enable <i>tailscale-ssh</i> on a target Linux machine, you typically configure its SSH daemon (<i>sshd</i>). This often involves adding a <i>"AuthorizedKeysCommand /usr/bin/tailscale ssh --authorized-keys %u"</i> line to <i>/etc/ssh/sshd_config</i>, then restarting the <i>sshd</i> service. This command dynamically generates authorized keys based on Tailscale's identity system and your ACLs.


title: SECURITY MODEL
content:
The security of <i>tailscale-ssh</i> is rooted in Tailscale's zero-trust networking model. It uses mutual TLS (mTLS) for node-to-node authentication, ensuring that only trusted devices can communicate. Authorization is then managed via fine-grained ACLs defined in your Tailscale admin console, allowing administrators to precisely control which users can SSH into which machines, effectively replacing complex SSH key distribution with a centralized, identity-aware access policy.


title: HISTORY
content:
<i>tailscale-ssh</i> was introduced as a core feature of the Tailscale product, evolving from a simple mesh VPN into a comprehensive access platform. Its development focused on integrating identity-based access control directly into the SSH workflow, simplifying key management and centralizing authorization policies for remote access within Tailscale networks.


title: SYNOPSIS
content:
<br><code>tailscale up [<I>flags</I>]</code><br><br>The <i>tailscale up</i> command initiates or updates the Tailscale connection on the current device. It accepts various flags to control authentication methods, network configuration, and feature enablement.


title: PARAMETERS
content:
<b>--accept-dns</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the node to accept and use DNS configurations pushed from the Tailscale coordination server.<br><br><b>--accept-routes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the node to accept and route traffic for subnets advertised by other Tailscale nodes.<br><br><b>--advertise-exit-node</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advertises this node as an exit node, allowing other Tailscale nodes to route their internet traffic through it.<br><br><b>--advertise-routes <IP/CIDR></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advertises specific IP routes (subnets) from this node into the Tailscale network.<br><br><b>--authkey <key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a pre-generated authentication key for unattended, non-interactive device registration.<br><br><b>--browser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a web browser for interactive authentication if required.<br><br><b>--exit-node <name|ip></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Routes all internet traffic from this device through a specified exit node on your tailnet.<br><br><b>--exit-node-allow-lan-access</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using an exit node, allows access to the local LAN (private IP ranges) in addition to routing internet traffic through the exit node.<br><br><b>--force-reauth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a re-authentication process, even if the device is already logged in.<br><br><b>--funnel</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the Tailscale Funnel service on this node, allowing public internet access to specific services running on it.<br><br><b>--hostname <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom hostname for this node within your Tailscale network.<br><br><b>--qr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a QR code in the terminal for authentication via the Tailscale mobile app.<br><br><b>--reset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the Tailscale configuration on the device before bringing it up again.<br><br><b>--shields-up</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a default firewall policy that blocks all incoming connections from outside the Tailscale network, except from other Tailscale nodes.<br><br><b>--ssh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Tailscale SSH on this node, allowing SSH access over the Tailscale network.<br><br><b>--tags <tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns tags to the node during registration, which can be used for ACLs (Access Control Lists).<br><br><b>--unattended</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <i>tailscale up</i> in unattended mode, suppressing browser launches and requiring an <i>authkey</i>.<br><br><b>--wait-engine</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Waits for the Tailscale engine to be ready before the command completes.<br><br>


title: DESCRIPTION
content:
<i>tailscale up</i> is the primary command used to bring a device onto your Tailscale network (tailnet). When executed, it initializes the Tailscale client, establishes a secure connection to the Tailscale coordination server, and configures the device's networking using WireGuard to enable peer-to-peer connectivity with other nodes in your tailnet. <br><br>The command typically requires authentication, which can be performed via a web browser (opened automatically or via QR code), or by using an authentication key (<i>--authkey</i>) for unattended deployments. It handles network configuration, including assigning an IP address from your tailnet, setting up DNS, and applying firewall rules. <br><br><i>tailscale up</i> is idempotent; running it multiple times will re-apply the configuration, making it useful for applying changes or re-authenticating. It's often the first Tailscale command executed after installation or when adding a new device to your private network.


title: CAVEATS
content:
<b>Root/Administrator Privileges:</b> The command generally requires root or administrator privileges to configure network interfaces and routing tables.<br><br><b>Network Connectivity:</b> An active internet connection is necessary for the initial connection to Tailscale's coordination servers.<br><br><b>Authentication:</b> Initial setup often requires interactive authentication via a web browser or QR code, unless an <i>--authkey</i> is provided.<br><br><b>Firewall Interactions:</b> Tailscale configures its own firewall rules (e.g., with <i>--shields-up</i>). Existing system firewalls might need adjustments to allow Tailscale's WireGuard traffic (UDP port 41641) if explicitly blocked.<br><br><b>Persistent Configuration:</b> While <i>tailscale up</i> configures the current session, many settings are persistent across reboots or service restarts. However, some flags like <i>--authkey</i> are for one-time registration and not persistent configuration.


title: PERSISTENT CONFIGURATION
content:
Many <i>tailscale up</i> flags (e.g., <i>--accept-routes</i>, <i>--advertise-routes</i>, <i>--hostname</i>, <i>--ssh</i>, <i>--shields-up</i>) configure persistent settings for the Tailscale daemon. Once set, these configurations typically persist across reboots and <i>tailscale up</i> calls, unless explicitly overridden by subsequent commands or a <i>--reset</i>.


title: AUTHENTICATION FLOW
content:
When <i>tailscale up</i> is run without an <i>--authkey</i> on a new device, it generates a unique URL. This URL must be opened in a web browser on a device where you are already logged into your Tailscale account to authorize the new node. This secure, interactive authentication process links the device to your tailnet. Flags like <i>--qr</i> and <i>--browser</i> provide alternative methods for this interactive flow.


title: HISTORY
content:
Tailscale, founded in 2019, built its network overlay solution on top of WireGuard. The <i>tailscale up</i> command has been a fundamental part of its client interface since the very beginning, serving as the primary method for users to bring a new device onto their secure network. Over time, as Tailscale introduced new features like exit nodes, subnet routing, SSH, and Funnel, the <i>tailscale up</i> command has evolved to incorporate flags for enabling and configuring these capabilities, reflecting the growing power and flexibility of the Tailscale platform while maintaining its core purpose of simple, secure connectivity.


title: SYNOPSIS
content:
<B>takeout</B> <I>&lt;command&gt;</I> <I>[arguments]</I><br><br>Common commands:<br><I>takeout list</I><br><I>takeout enable &lt;service&gt; [project_path]</I><br><I>takeout disable &lt;service&gt; [project_path]</I><br><I>takeout fresh &lt;service&gt;</I><br><I>takeout link &lt;service&gt; &lt;project_path&gt;</I><br><I>takeout unlink &lt;service&gt; &lt;project_path&gt;</I><br><I>takeout install</I><br><I>takeout self-update</I>


title: PARAMETERS
content:
<b><I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available services and their current status (enabled/disabled).<br><br><b><I>enable &lt;service&gt; [project_path]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a specified service (e.g., <I>mysql</I>, <I>redis</I>), optionally linking it to a project directory. This starts the Docker container for the service.<br><br><b><I>disable &lt;service&gt; [project_path]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables a specified service, optionally unlinking it from a project. This stops and removes the Docker container for the service.<br><br><b><I>fresh &lt;service&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops, removes, and recreates a service's container, effectively resetting its data. Useful for development when you need a clean slate.<br><br><b><I>link &lt;service&gt; &lt;project_path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Links an already enabled service to a specific project directory. This makes the service's environment variables available within the specified project.<br><br><b><I>unlink &lt;service&gt; &lt;project_path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unlinks a service from a project directory, removing its environmental linkage from that specific project.<br><br><b><I>install</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs initial setup, downloading necessary Docker images and configuring Takeout on your system.<br><br><b><I>self-update</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the Takeout CLI tool to its latest available version.<br><br><b><I>--path &lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A global option to specify a custom path for the Takeout data and configuration directory, overriding the default location.<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the overall command or a specific subcommand.<br><br><b><I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed version of the Takeout CLI tool.<br><br>


title: DESCRIPTION
content:
<B>takeout</B> is <I>not</I> a standard Linux command found in typical distributions. Instead, it refers to a third-party utility, most prominently "BeyondCode Takeout," designed to simplify the management of isolated development services (like MySQL, PostgreSQL, Redis, Memcached) using Docker. Its primary goal is to provide a clean, consistent way to enable and disable services for local projects without polluting the host system or requiring complex Docker configurations manually. It is particularly popular within the PHP and Laravel development communities for managing project dependencies, allowing developers to quickly spin up and tear down services required for different applications without environment conflicts.


title: CAVEATS
content:
<B>takeout</B> is <I>not</I> a standard Unix/Linux command. It is a third-party application, primarily used for web development environments. Its functionality and availability depend entirely on installing this specific tool. It <B>requires Docker</B> to be installed and running on your system, as it operates by managing Docker containers. It is often associated with the PHP/Laravel ecosystem and may not be relevant for general Linux administration tasks or other programming languages/frameworks.


title: INSTALLATION
content:
Takeout can typically be installed via Homebrew on macOS, or through a custom installer script on Linux, which downloads the executable and places it in your PATH. It is crucial to have Docker Desktop or Docker Engine installed and running beforehand, as Takeout acts as an orchestration layer on top of Docker.


title: PURPOSE IN DEVELOPMENT
content:
Takeout acts as an abstraction layer over Docker, allowing developers to manage services like databases (MySQL, PostgreSQL), caching systems (Redis, Memcached), or message queues (RabbitMQ) with simple commands without needing to manually write or manage complex Docker Compose files or individual containers. This significantly promotes consistency, ease of setup, and portability across different development projects and teams.


title: HISTORY
content:
BeyondCode Takeout was developed by the BeyondCode team, a prominent group known for various developer tools in the PHP/Laravel ecosystem. It emerged as a solution to simplify the setup and management of local development services, addressing the complexities of managing multiple Docker containers or conflicting local installations for different projects. Its development is relatively recent, gaining traction among developers seeking more streamlined and isolated development environments, especially since the rise of Docker in development workflows.


title: SEE ALSO
content:
<B>docker</B>(1): The foundational containerization platform that <I>takeout</I> leverages to run services., <B>laravel sail</B>: A lightweight command-line interface for interacting with a Laravel Docker development environment, serving a similar purpose to <I>takeout</I> but integrated specifically with Laravel., <B>ddev</B>: A comprehensive local PHP development environment system based on Docker, providing pre-configured environments for various PHP applications., <B>valet</B>: A minimalist Mac development environment for Laravel, offering a similar concept of local service management but specific to macOS and without Docker.


title: PARAMETERS
content:
<b><i>person</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The username of the person to initiate a conversation with. This can be a local user or a remote user specified as `<i>user@host</i>`.<br><br><b><i>tty</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Optional</i>) The specific terminal or tty device of the `<i>person</i>` if they are logged in multiple times and you wish to talk to a specific session (e.g., `<i>tty01</i>`).<br><br>


title: DESCRIPTION
content:
The `<b>talk</b>` command is a legacy Unix utility that allows two users on the same or different machines to have a real-time, interactive text conversation. It operates by splitting the terminal screen into two windows: one for the local user's input and another for the remote user's input. When one user types, the text appears simultaneously in the other user's window. `<b>talk</b>` initiates a connection by sending an invitation to the specified user. If the recipient accepts the invitation (by running `<b>talk</b>` with the inviter's username), a direct conversation channel is established. While once a popular tool for quick communication on multi-user systems, its unencrypted nature and reliance on specific network protocols have led to its replacement by modern, more secure, and feature-rich communication tools like SSH, IRC, and instant messaging clients. It requires a `<b>talkd</b>` daemon to be running on the host systems for inter-machine communication.


title: CAVEATS
content:
<I>Security</I>: Communications are unencrypted and vulnerable to eavesdropping.<br><I>Firewall Issues</I>: Often blocked by modern firewalls due to its use of specific UDP ports for `<b>talkd</b>` and conversation channels.<br><I>Legacy Tool</I>: Largely deprecated in favor of more robust, secure, and feature-rich communication methods.<br><I>Daemon Requirement</I>: Requires the `<b>talkd</b>` (talk daemon) to be running on involved machines for remote conversations.


title: HOW `<B>TALK</B>` WORKS
content:
`<b>talk</b>` operates on a client-server model. When you initiate `<b>talk</b> <i>user@host</i>`, your client contacts the `<b>talkd</b>` (talk daemon) on the target host. The `<b>talkd</b>` then notifies the target user that someone wants to talk. If the user accepts by running `<b>talk</b> <i>your_username</i>`, a direct peer-to-peer UDP connection is established between the two `<b>talk</b>` clients for the conversation, bypassing the `<b>talkd</b>` for the actual data exchange.


title: IN-CONVERSATION COMMANDS
content:
While in a `<b>talk</b>` session, specific control characters can be used:<br><I>Ctrl+L</I>: Redraws the screen, useful if the terminal gets garbled.<br><I>Ctrl+W</I>: Sends the current word (behavior may vary; less common).<br><I>Ctrl+C</I>: Terminates the conversation for the local user.


title: HISTORY
content:
The `<b>talk</b>` command emerged in the early days of Unix, providing a real-time communication method similar to instant messaging before the internet became widespread. It was developed at the University of California, Berkeley, as part of BSD Unix in the late 1970s/early 1980s. Its primary design goal was to facilitate quick, interactive text exchanges between users on multi-user systems or across networks. While its core functionality remains largely unchanged, its usage has significantly declined due to the advent of more secure and versatile communication technologies.


title: PARAMETERS
content:
<b><<i>input_archive</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Apache Tapestry application archive. This is typically a specialized <b>.tap</b> file, which contains the compiled application, its dependencies, and resources.<br><br><b>[<i>output_package_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional) The desired file name for the generated Debian package. If not provided, <i>tap2deb</i> may derive a default name from the input archive or current directory (e.g., <i>application-version.deb</i>).<br><br>


title: DESCRIPTION
content:
<i>tap2deb</i> is a specialized utility designed to package Apache Tapestry applications, often distributed as a <b>.tap</b> archive, into a Debian (<b>.deb</b>) package. This tool aims to streamline the deployment process of Tapestry web applications on Debian-based systems.<br><br>It takes a Tapestry archive as input, extracts its contents, and then wraps them into a <b>.deb</b> file, adhering to Debian packaging standards. This integration makes it significantly easier to install, manage, and uninstall the Tapestry application using standard Debian package management tools like <b>dpkg</b> or <b>apt</b>, fitting the application seamlessly into the server's package ecosystem.


title: CAVEATS
content:
<b>Obscurity and Niche Use:</b> <i>tap2deb</i> is not a standard or widely distributed Linux command-line utility. It's typically found within specific build environments or deployment scripts for Apache Tapestry applications, often implemented as a custom helper script.<br><br><b>Limited Documentation:</b> Due to its specialized and often project-specific nature, comprehensive command-line documentation (such as a man page or extensive <i>--help</i> output) is frequently absent or varies greatly between implementations.<br><br><b>Dependencies:</b> Correct operation usually requires a Java Runtime Environment (JRE) and underlying Debian packaging tools like <i>dpkg-deb</i> to be present on the system.<br><br><b>Tapestry Version Specificity:</b> The exact functionality or compatibility might be tied to specific versions of the Apache Tapestry framework (e.g., Tapestry 4 or early Tapestry 5), as well as the structure of the <b>.tap</b> archive.


title: TAPESTRY ARCHIVES (.TAP)
content:
A <b>.tap</b> file is a specialized archive format used by Apache Tapestry applications, often structured similarly to a Java <b>.jar</b> or <b>.war</b> file. It encapsulates the application's compiled code, necessary libraries, and static resources, designed for deployment within a servlet container.


title: BENEFITS OF DEBIAN PACKAGING
content:
Converting a Tapestry application into a <b>.deb</b> package provides several advantages. It allows system administrators to manage the application using familiar Debian package tools, ensuring proper file placement according to FHS, automated dependency resolution, simplified upgrades, and clean uninstallation, thereby integrating the application smoothly into existing system administration workflows.


title: HISTORY
content:
<i>tap2deb</i> emerged from the practical need to simplify the deployment of Apache Tapestry web applications on Debian-based server environments. As Tapestry applications were commonly distributed as Java archive files (like <b>.war</b> or custom <b>.tap</b> archives), integrating them into the system's native package management (<i>dpkg</i>/<i>apt</i>) offered significant advantages for installation, upgrades, and uninstallation. It typically functioned as part of deployment plugins or custom build scripts within Tapestry projects, particularly gaining traction during the Apache Tapestry 4 and early Tapestry 5 eras. Its development reflected a broader trend of 'Debianizing' Java web applications to achieve more manageable and consistent server deployments.


title: SYNOPSIS
content:
<i>tap2rpm</i> [<i>options</i>] <i><input_source></i> [<i><output_file.rpm></i>]<br><br><b>Note:</b> This command is not standard. The synopsis represents a common conceptual pattern for such a utility; actual usage depends on its specific implementation.


title: PARAMETERS
content:
<b><b>No Standard Parameters</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;As a non-standard utility, <i>tap2rpm</i> does not have a universally defined set of parameters. Any options or arguments would be specific to individual script implementations. Common conceptual options might include specifying input file paths, output RPM names, package metadata (version, release, dependencies), or specific processing flags.<br><br>


title: DESCRIPTION
content:
<i>tap2rpm</i> is not a standard, widely distributed Linux command. It is typically a custom or project-specific utility, often implemented as a Perl script, designed to encapsulate data or test results formatted according to the Test Anything Protocol (TAP) into a Red Hat Package Manager (RPM) archive. Its primary use case revolves around automated testing frameworks where test outcomes are generated in TAP format and need to be packaged or distributed as RPMs, potentially for deployment or reporting purposes.<br><br>Due to its non-standard nature, its exact functionality, syntax, and options can vary significantly between different implementations. It usually relies on Perl modules like <i>TAP::RPM</i> to perform the actual RPM creation.


title: CAVEATS
content:
<i>tap2rpm</i> is not a standard command shipped with most Linux distributions. Its availability, behavior, and options are entirely dependent on whether a specific project or user has created and installed such a script. Users should not expect to find it pre-installed or documented in standard manual pages. Its functionality will be tied to its specific Perl script or other custom implementation.


title: IMPLEMENTATION SPECIFICITY
content:
Because <i>tap2rpm</i> is not a standard command, its actual implementation (e.g., in Perl, Python, or shell script) dictates its exact behavior. Users interested in its use would typically find it within a project's build system or source code rather than as a system-wide installed binary.


title: USE CASE
content:
The primary use case for a utility like <i>tap2rpm</i> is in continuous integration/continuous deployment (CI/CD) pipelines where automated tests produce TAP output, and the results (or related artifacts) need to be bundled into an RPM for deployment to target systems or for archival.


title: HISTORY
content:
The concept of <i>tap2rpm</i> likely emerged from specific development workflows requiring the packaging of test results or other data generated via the Test Anything Protocol (TAP) into RPMs. It's not part of a historical Linux utility suite but rather a community-driven or project-specific script, often implemented using Perl modules designed for RPM creation (like <i>TAP::RPM</i>), to bridge the gap between testing frameworks and package distribution systems.


title: PARAMETERS
content:
<b><b>-f</b> <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target archive format to which the <i>input_archive</i> should be converted. This is typically a numeric format version (e.g., '3', '4').<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, printing progress messages and detailed information about the conversion process.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs version information for the <b>tapconvert</b> utility and exits.<br><br>


title: DESCRIPTION
content:
<i>tapconvert</i> is a utility program associated with the <i>Taper</i> backup system. Its primary function is to convert <i>Taper</i> archive files from one internal format to another, typically a newer version. This is crucial when a <i>Taper</i> installation is upgraded, and existing archive files created with an older version of <i>Taper</i> need to be accessible and readable by the new version. It ensures backward compatibility for your backup data, allowing you to restore files from older archives without issues after a software upgrade. <i>tapconvert</i> operates by reading the input archive and writing a new archive in the specified output format.


title: CAVEATS
content:
<b>tapconvert</b> is specific to <i>Taper</i> archive formats and cannot be used for general archive conversions (e.g., tar, zip).<br>The specified <i>format</i> must be a valid <i>Taper</i> archive format supported by the installed <b>tapconvert</b> version.<br>Sufficient disk space is required to store the new <i>output_archive</i>, which will be a complete copy of the converted data.


title: USAGE EXAMPLE
content:
To convert an old <i>Taper</i> archive named <i>old_backup.tap</i> to a new format (e.g., format 4) and save it as <i>new_backup.tap</i>, you would use:<br><i>tapconvert -f 4 old_backup.tap new_backup.tap</i>


title: HISTORY
content:
<b>tapconvert</b> is an integral part of the <i>Taper</i> backup system, developed by Peter T. Breuer. It was created to address the challenge of backward compatibility for <i>Taper</i> archives as the <i>Taper</i> software evolved and introduced new internal archive formats. Its development is directly tied to the lifecycle and upgrades of the <i>Taper</i> project, ensuring users could continue to access and restore data from older backups despite format changes in newer <i>Taper</i> versions.


title: SYNOPSIS
content:
<b>tar</b> <i>[MODE] [OPTIONS] [ARCHIVE_FILE] [FILE_OR_DIRECTORY...]</i><br><br>Common usage modes and their primary options:<br><i>Create an archive:</i><br><b>tar -c[zvfjJ] -f</b> <i>ARCHIVE_FILE [FILE_OR_DIRECTORY...]</i><br><br><i>Extract from an archive:</i><br><b>tar -x[zvfjJ] -f</b> <i>ARCHIVE_FILE [FILE_OR_DIRECTORY...]</i><br><br><i>List contents of an archive:</i><br><b>tar -t[vf] -f</b> <i>ARCHIVE_FILE</i>


title: PARAMETERS
content:
<b><b>-c</b>, <b>--create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new archive.<br><br><b><b>-x</b>, <b>--extract</b>, <b>--get</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts files from an archive.<br><br><b><b>-t</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the contents of an archive.<br><br><b><b>-u</b>, <b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends files to an archive only if they are newer than their copy in the archive or not already in the archive.<br><br><b><b>-r</b>, <b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends files to the end of an archive.<br><br><b><b>-f</b> <i>ARCHIVE</i>, <b>--file</b> <i>ARCHIVE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the archive file to work with (e.g., <i>archive.tar</i>, <i>/dev/tape</i>).<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the names of files processed in a verbose manner.<br><br><b><b>-z</b>, <b>--gzip</b>, <b>--gunzip</b>, <b>--ungzip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the archive through <i>gzip</i> for compression or decompression.<br><br><b><b>-j</b>, <b>--bzip2</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the archive through <i>bzip2</i> for compression or decompression.<br><br><b><b>-J</b>, <b>--xz</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the archive through <i>xz</i> for compression or decompression.<br><br><b><b>-C</b> <i>DIRECTORY</i>, <b>--directory</b> <i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes to the specified <i>DIRECTORY</i> before performing the operation.<br><br><b><b>--exclude</b> <i>PATTERN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files or directories that match the specified <i>PATTERN</i> from the archive.<br><br><b><b>--strip-components=</b><i>NUMBER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the specified <i>NUMBER</i> of leading directory components from file names during extraction.<br><br><b><b>-p</b>, <b>--preserve-permissions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves file permissions (and modes) during extraction.<br><br><b><b>-k</b>, <b>--keep-old-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not overwrite existing files when extracting.<br><br>


title: DESCRIPTION
content:
The <b>tar</b> (<i>tape archive</i>) command is a powerful and widely used command-line utility in Linux and Unix-like operating systems. It is primarily used for collecting multiple files and/or directories into a single archive file, often referred to as a 'tarball'. While its name originates from its historical use with tape drives, <b>tar</b> is now predominantly used to create and manipulate archives on disk.<br><br>Beyond simply bundling files, <b>tar</b> can preserve file attributes such as permissions, ownership, timestamps, and symbolic links. It doesn't inherently compress files, but it is often used in conjunction with compression utilities like <i>gzip</i>, <i>bzip2</i>, or <i>xz</i> (e.g., resulting in files like <i>.tar.gz</i>, <i>.tgz</i>, <i>.tar.bz2</i>, or <i>.tar.xz</i>). This makes <b>tar</b> an indispensable tool for backups, distributing software, or transferring collections of files.


title: CAVEATS
content:
When using <b>tar</b>, be mindful of absolute versus relative paths. Archiving with absolute paths (e.g., <i>/etc/fstab</i>) can lead to unintended overwrites if extracted at the root of a different system. It's generally safer to change into the parent directory and use relative paths.<br><br>While <b>tar</b> preserves permissions and ownership, extracting files as a regular user into areas where they lack write permissions or where UIDs/GIDs do not match can lead to permission errors or unexpected ownership changes.


title: COMMON COMPRESSION INTEGRATION
content:
<b>tar</b> does not compress files by itself, but it seamlessly integrates with various compression programs. The most common way to create a compressed tarball is to use the <b>-z</b> (for <i>gzip</i>), <b>-j</b> (for <i>bzip2</i>), or <b>-J</b> (for <i>xz</i>) flags directly with the create or extract operations. For example, <b>tar -czvf archive.tar.gz files/</b> creates a gzipped tarball, and <b>tar -xjvf archive.tar.bz2</b> extracts a bzip2 compressed tarball.


title: DIRECTORY STRUCTURE AND PATHS
content:
When archiving a directory, <b>tar</b> by default includes the directory itself and its entire contents. For instance, <b>tar -cvf backup.tar mydir/</b> will create an archive where <i>mydir/</i> is the top-level entry. If you only want the contents of <i>mydir/</i> to be at the top level of the archive, you should use the <b>-C</b> option: <b>tar -cvf backup.tar -C mydir .</b> (archiving the current directory <b>.</b> after changing into <i>mydir</i>).


title: HISTORY
content:
The <b>tar</b> command, short for "<i>tape archive</i>", originated in the early days of Unix, specifically around Version 7 Unix in 1979. Its initial purpose was to provide a simple and reliable way to store multiple files on sequential access storage devices like magnetic tape drives for backup and restoration.<br><br>Over decades, despite its 'tape' heritage, <b>tar</b> evolved significantly. It transitioned from primarily tape use to disk-based archiving, and features like integration with compression tools (<i>gzip</i>, <i>bzip2</i>, <i>xz</i>) were added, making it an incredibly versatile and ubiquitous archiving utility across Unix-like operating systems today.


title: SYNOPSIS
content:
<I>Note: 'tarcat' is an idiom, not a standalone command.</I><br><br>The common usage pattern involves piping a tar archive stream to <i>tar</i> for processing:<br><b>cat</b> <I>[SOURCE_FILE]</I> | <b>tar</b> <I>[TAR_OPTIONS]</I> <I>-</I><br><br>Or from another command's output:<br><b>curl</b> <I>[URL]</I> | <b>tar</b> <I>[TAR_OPTIONS]</I> <I>-</I>


title: PARAMETERS
content:
<b>SOURCE_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the tar archive file to be streamed by <b>cat</b>. If omitted, <b>cat</b> reads from standard input.<br><br><b>TAR_OPTIONS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options passed to the <b>tar</b> command, such as <i>-x</i> for extraction, <i>-c</i> for creation, <i>-t</i> for listing contents, and <i>-v</i> for verbose output. The <i>-f -</i> option tells <b>tar</b> to read from standard input.<br><br><b>-</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A mandatory argument for <b>tar</b> when reading from or writing to standard input/output.<br><br>


title: DESCRIPTION
content:
The term "tarcat" is not a standalone Linux command but rather a common idiom or pattern referring to the act of piping the output of the <i>cat</i> command (or any command that outputs an archive stream) directly into the <i>tar</i> command. This powerful technique allows for efficient processing of tar archives that are not necessarily stored as local files. It's frequently employed for tasks such as extracting archives downloaded from the internet, processing concatenated tar archives, or handling archives generated on-the-fly without intermediate disk storage. Essentially, it leverages standard input/output (stdin/stdout) to enable seamless streaming of archive data between different utilities, making it a cornerstone for advanced shell scripting and data manipulation in Linux environments.


title: CAVEATS
content:
<b>'Tarcat' is not a standard executable:</b> There is no single 'tarcat' binary or command shipped with typical Linux distributions. It is a conceptual term.<br><br><b>Dependency on underlying commands:</b> Its functionality relies entirely on the correct usage and capabilities of the <i>cat</i>, <i>tar</i>, and other piping commands.<br><br><b>Error Handling:</b> Debugging issues in a piped command can be more complex than with single-command operations, as errors from either side of the pipe might not always be immediately clear in their origin.<br><br><b>Performance:</b> While efficient for streaming, performance can be bottlenecked by either the producer (e.g., <i>cat</i> or network speed) or the consumer (<i>tar</i>'s processing speed).


title: COMMON USE CASES
content:
<i>Extracting remote archives:</i> <b>curl</b> <i>http://example.com/archive.tar.gz</i> | <b>tar</b> <i>-xzf -</i><br><br><i>Concatenating tar archives:</i> <b>cat</b> <i>part1.tar part2.tar</i> | <b>tar</b> <i>-xf -</i><br><br><i>Creating archives on-the-fly to remote:</i> <b>tar</b> <i>-cf - my_directory/</i> | <b>ssh</b> <i>user@remote 'cat > archive.tar'</i>


title: HISTORY
content:
The concept behind "tarcat" (piping commands) is fundamental to the Unix philosophy, which emphasizes small, single-purpose tools connected by pipes. This approach dates back to the early days of Unix development in the 1970s. While the specific term "tarcat" may be a more modern colloquialism, the practice of streaming tar archives via <i>cat</i> and pipes has been a common and powerful technique for decades, evolving as network speeds and data volumes increased, making efficient on-the-fly processing indispensable.


title: SYNOPSIS
content:
<I>targetcli</I><br><I>targetcli</I> [<B>-f</B> <I>&lt;script_file&gt;</I>] [<B>-V</B> | <B>--version</B>] [<B>--debug</B>]<br><I>targetcli</I> [<I>command</I>] [<I>argument...</I>]


title: PARAMETERS
content:
<b><I>None (interactive mode)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When invoked without options, <I>targetcli</I> enters an interactive shell, allowing step-by-step configuration of the LIO SCSI Target.<br><br><b><B>-f</B> <I>&lt;script_file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes <I>targetcli</I> commands read from the specified <I>script_file</I> in a non-interactive (batch) mode. This is useful for automating configuration tasks.<br><br><b><B>-V</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>targetcli</I> utility and exits.<br><br><b><B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output during the execution of <I>targetcli</I>.<br><br>


title: DESCRIPTION
content:
<I>targetcli</I> is a command-line interface used to configure the Linux LIO kernel-based SCSI Target. It provides a powerful and flexible way to present local storage devices (like block devices, files, or RAM disks) as SCSI LUNs (Logical Unit Numbers) to remote initiators over various transport protocols such as iSCSI, Fibre Channel (FC), FCoE, and SRP. The utility operates primarily in an interactive shell mode, presenting a hierarchical, tree-like structure for navigating and managing target objects (e.g., backstores, TPGs, LUNs, ACLs). Configurations made via <I>targetcli</I> are typically saved to a persistent JSON file (e.g., <I>/etc/target/saveconfig.json</I>) ensuring they survive system reboots. It streamlines the complex process of setting up and managing a full-featured SCSI target server on Linux, making it the de facto standard for this purpose.


title: CAVEATS
content:
<B>Root Privileges:</B> <I>targetcli</I> requires root privileges to operate, as it directly manipulates kernel-level configuration via <I>configfs</I>.<br><B>Complexity:</B> Its tree-like hierarchical structure, while powerful, can be complex for users unfamiliar with SCSI target concepts or the LIO model.<br><B>Persistence:</B> While configurations are typically saved, issues during shutdown or misconfiguration of the saving mechanism can lead to loss of target settings.<br><B>Kernel Modules:</B> Proper functioning depends on the underlying LIO kernel modules (<I>target_core_mod</I>, <I>iscsi_target_mod</I>, etc.) being loaded and operational.


title: INTERACTIVE SHELL AND TREE STRUCTURE
content:
When invoked without arguments, <I>targetcli</I> provides an interactive command-line shell. This shell uses a hierarchical, tree-like structure, similar to a filesystem, allowing users to navigate through various target components (e.g., <I>/backstores</I>, <I>/iscsi</I>, <I>/fcoe</I>) using <I>cd</I>, <I>ls</I>, <I>create</I>, <I>delete</I>, and <I>set</I> commands. This structure helps in organizing and managing complex target configurations.


title: CONFIGURATION PERSISTENCE
content:
Configurations made through <I>targetcli</I> are automatically saved to a persistent JSON file, typically located at <I>/etc/target/saveconfig.json</I>. This ensures that your SCSI target setup is automatically restored upon system reboots, eliminating the need for manual reconfiguration after every restart. The utility handles the loading and saving of this configuration file transparently.


title: BACKSTORES
content:
In the context of LIO and <I>targetcli</I>, a 'backstore' is the underlying storage resource that is presented as a Logical Unit Number (LUN) to remote initiators. <I>targetcli</I> supports various backstore types, including <B>block</B> (raw block devices), <B>fileio</B> (files on a filesystem), and <B>iblock</B> (virtual RAM disks). These backstores define the actual storage capacity and type that will be made available to clients.


title: HISTORY
content:
<I>targetcli</I> is the modern configuration utility for the Linux LIO (Linux-IO) SCSI Target, which became the standard in the Linux kernel around version 2.6.38, replacing older target solutions like STGT and IET. The utility itself, along with its predecessor <I>targetcli-fb</I>, was developed to provide a user-friendly and persistent interface to the complex <I>configfs</I>-based LIO kernel functionality. Its design focuses on a tree-like structure, making the management of storage targets intuitive despite the underlying complexity. It leverages Python for its interactive shell and backend logic, ensuring robust saving and restoration of configurations across system reboots, typically to <I>/etc/target/saveconfig.json</I>.


title: SYNOPSIS
content:
<b>tarsnap</b> [<i>OPTIONS</i>] <b>-c -f</b> <i>archive_name</i> [<i>FILE...</i>]<br><b>tarsnap</b> [<i>OPTIONS</i>] <b>-x -f</b> <i>archive_name</i> [<i>FILE...</i>]<br><b>tarsnap</b> [<i>OPTIONS</i>] <b>-t -f</b> <i>archive_name</i><br><b>tarsnap</b> [<i>OPTIONS</i>] <b>--list-archives</b><br><b>tarsnap</b> [<i>OPTIONS</i>] <b>--fsck</b><br><b>tarsnap</b> [<i>OPTIONS</i>] <b>--prune</b>


title: PARAMETERS
content:
<b><b>-c</b>, <b>--create</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new archive.<br><br><b><b>-f</b> <i>archive_name</i>, <b>--file=</b><i>archive_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the archive to operate on.<br><br><b><b>-x</b>, <b>--extract</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files from an archive.<br><br><b><b>-t</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents of an archive.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display verbose output during operation.<br><br><b><b>-k</b> <i>keyfile</i>, <b>--key-file=</b><i>keyfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the Tarsnap key file.<br><br><b><b>--list-archives</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all archives stored in your Tarsnap account.<br><br><b><b>--prune</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete old archives based on a specified pruning policy.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate an operation without making any changes.<br><br><b><b>--exclude=</b><i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files matching the specified pattern from the archive.<br><br><b><b>--include=</b><i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include files matching the pattern, overriding exclusions.<br><br><b><b>-Z</b>, <b>--lzma</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use LZMA compression (default and recommended for new archives).<br><br><b><b>-z</b>, <b>--gzip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use gzip compression.<br><br><b><b>-j</b>, <b>--bzip2</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use bzip2 compression.<br><br><b><b>--no-compression</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable compression for the archive.<br><br><b><b>--print-stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print statistics about data transfer and storage costs.<br><br><b><b>--fsck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an integrity check on the archive metadata or blocks.<br><br><b><b>--config-file=</b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative Tarsnap configuration file.<br><br>


title: DESCRIPTION
content:
Tarsnap is a highly secure, efficient, and cost-effective online backup service for various Unix-like operating systems, including FreeBSD, Linux, and OS X. <br><br>It was developed by Colin Percival, renowned for creating the scrypt key derivation function. Tarsnap operates via a command-line interface, mirroring the functionality of the standard Unix <b>tar</b> utility, making it familiar to system administrators. <br><br>Its core strengths lie in its robust security model, featuring client-side encryption (AES-256) and data integrity verification (SHA256), ensuring that all data is encrypted before leaving your machine and only you hold the decryption key. <br><br>Efficiency is achieved through block-level data deduplication across all archives within an account, compression (LZMA, bzip2, gzip), and delta encoding, which significantly reduces storage space and bandwidth usage. Users pay only for the storage consumed and bandwidth transferred, making it a cost-effective solution for incremental backups.


title: CAVEATS
content:
Tarsnap requires a paid account and pre-purchased credits to operate. <br><br>The encryption key file is paramount; losing it means permanent loss of access to your backed-up data, as Tarsnap Inc. does not hold your decryption key. <br><br>While highly efficient, initial large backups can be time-consuming due to the client-side encryption and deduplication processes. <br><br>All operations are strictly command-line based; there is no official graphical user interface.


title: SECURITY MODEL
content:
Tarsnap employs an 'encrypt-then-deduplicate' model. Data is encrypted using AES-256 before being sent to the server. The encryption key is derived from a user-provided passphrase and is never sent to Tarsnap's servers. Deduplication occurs on the encrypted blocks, meaning the server only sees opaque, encrypted data blocks, preventing any possibility of data leakage or metadata analysis by the service provider. All data integrity is verified using SHA256 hashes.


title: PRICING STRUCTURE
content:
Tarsnap operates on a 'pay-per-use' model, where users purchase credits upfront. Costs are incurred based on the amount of data stored (per gigabyte-month) and the bandwidth used for uploads and downloads. There are no recurring monthly fees, only charges for actual resource consumption. This model, combined with efficient deduplication, often results in very low costs for users with many incremental backups.


title: HISTORY
content:
Tarsnap was created by Colin Percival, a well-known security researcher and cryptographer, who also developed the <i>scrypt</i> password-based key derivation function. Its development began as a personal project for his own backup needs, aiming to build a backup system that was truly secure, efficient, and affordable. <br><br>The service first became publicly available around 2008, quickly gaining recognition in the Unix community for its strong focus on privacy through client-side encryption and its innovative deduplication technology which minimizes storage costs.


title: SYNOPSIS
content:
<b>tarsnap-keygen</b> <b>--keyfile</b> <i>&lt;path&gt;</i> <b>--user</b> <i>&lt;email&gt;</i> <b>--machine</b> <i>&lt;name&gt;</i>


title: PARAMETERS
content:
<b><b>--keyfile</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path where the newly generated Tarsnap key file will be saved. This file is crucial for all future Tarsnap operations.<br><br><b><b>--user</b> <i>&lt;email&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the email address associated with your Tarsnap account. This links the generated key to your user profile on the Tarsnap service.<br><br><b><b>--machine</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a unique identifier for the machine from which backups will be made. This helps differentiate backups originating from various systems under the same Tarsnap user account.<br><br>


title: DESCRIPTION
content:
The <i>tarsnap-keygen</i> command is used to generate a new cryptographic key file for the Tarsnap online backup service. This key is fundamental for authenticating with the Tarsnap servers and for encrypting/decrypting your backup data.<br><br>When executed, <i>tarsnap-keygen</i> establishes a secure connection with the Tarsnap service to perform a key exchange, associating the generated key with your Tarsnap account and a specific machine identifier. The resulting key file must be kept secure and confidential, as its compromise would allow unauthorized access to your backups, and its loss would prevent you from restoring your data.


title: CAVEATS
content:
The generated key file is highly sensitive. It must be kept secure and confidential. Loss of this key will make your Tarsnap backups inaccessible, while its compromise would allow unauthorized access to your encrypted data. Back up your key file securely immediately after creation.<br><br>The <i>--machine</i> name specified must be unique among all machines associated with your <i>--user</i> account. If you attempt to use a non-unique machine name, <i>tarsnap-keygen</i> will fail.<br><br>An active internet connection is required for <i>tarsnap-keygen</i> to communicate with the Tarsnap service during key generation.


title: KEY SECURITY AND MANAGEMENT
content:
The key file generated by <i>tarsnap-keygen</i> is the master key for your Tarsnap data. It should be stored in a secure location with restricted permissions (e.g., <i>chmod 600</i>). It is highly recommended to make secure, offline backups of this key file immediately after creation. For managing existing keys, including changing machine names or removing keys, the <i>tarsnap-keymgt</i> command is used.


title: HISTORY
content:
<i>tarsnap-keygen</i> is an integral part of Tarsnap, an online backup service created by Colin Percival, a FreeBSD developer and security researcher. Tarsnap was publicly launched in 2008, designed with a strong emphasis on security, efficiency, and robustness. The <i>tarsnap-keygen</i> command has been a core component since the early days, facilitating the secure, cryptographic foundation for user data on the service.


title: SYNOPSIS
content:
<b>task</b> [<I>filter</I>] <I>command</I> [<I>arguments</I>]<br><b>task</b> <I>command</I> [<I>arguments</I>]


title: PARAMETERS
content:
<b>[<I>filter</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional set of criteria used to select specific tasks based on their attributes (e.g., <b>project:work</b>, <b>due:tomorrow</b>, <b>status:pending</b>, <b>+urgent</b>). This powerful query language allows for precise task selection.<br><br><b><I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary action to perform. Common commands include <b>add</b> (create task), <b>list</b> (view tasks), <b>done</b> (complete task), <b>delete</b> (remove task), <b>modify</b> (change task attributes), and <b>sync</b> (synchronize tasks).<br><br><b>[<I>arguments</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional data or modifiers specific to the chosen command. For commands like <b>add</b> or <b>modify</b>, these often include task descriptions or attribute assignments (e.g., <b>'Buy milk' due:today priority:H</b>).<br><br><b>[<I>ID</I>|<I>UUID</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A numeric task ID (as seen in <b>task list</b>) or a Universally Unique Identifier for referencing specific tasks in commands like <b>task 123 done</b> or <b>task <UUID> delete</b>.<br><br>


title: DESCRIPTION
content:
<i>Taskwarrior</i>, commonly invoked as <b>task</b>, is a free, open-source, and cross-platform command-line todo list manager. It empowers users to efficiently track, manage, and prioritize tasks directly from the terminal.<br><br>It offers a robust set of features including comprehensive filtering with a powerful query language, support for projects, tags, due dates, and priorities. Taskwarrior stores all task data in plain text files, ensuring portability and scriptability, and can synchronize tasks across multiple devices via a dedicated <i>Taskserver</i>. Its design emphasizes speed, unobtrusiveness, and flexibility, making it a favorite tool for developers and power users seeking to enhance their productivity through a highly customizable workflow.


title: CAVEATS
content:
<b>Taskwarrior</b> requires a comfortable understanding of command-line interfaces. While powerful, its comprehensive query language might have a slight learning curve for new users. Task data is stored locally in plain text files, which requires proper file system permissions to ensure security and privacy.


title: CONFIGURATION
content:
<b>Taskwarrior</b> is highly customizable through the <i>.taskrc</i> configuration file, typically located in the user's home directory. This file allows users to define default behaviors, aliases, custom reports, and color schemes, tailoring the application to individual preferences and workflows.


title: HOOKS
content:
The command supports a powerful <i>hook</i> system, allowing users to execute custom shell scripts before or after specific task operations (e.g., adding, modifying, or completing a task). This enables advanced automation, integration with other tools, and custom notification systems.


title: SYNCHRONIZATION
content:
For multi-device or collaborative task management, <b>Taskwarrior</b> provides robust synchronization capabilities with a dedicated <i>Taskserver</i>. This allows tasks to be securely synced and shared, maintaining consistency across different machines or with other users.


title: HISTORY
content:
<b>Taskwarrior</b> was originally created by Paul Beckingham, with the first version released in 2008. It was developed to be a fast, simple, and powerful command-line task management tool. Over the years, it has evolved with contributions from a vibrant open-source community, adding features like synchronization, hooks, and advanced reporting, establishing itself as a widely-used and respected productivity tool in the Linux and Unix-like ecosystems.


title: SYNOPSIS
content:
<b>tasksel</b> [<I>options</I>] [<I>task</I>]<br><b>tasksel --list-tasks</b><br><b>tasksel --install</b> <I>task</I><br><b>tasksel --remove</b> <I>task</I>


title: PARAMETERS
content:
<b>--list-tasks or -t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all available tasks with their current installation status (installed or not).<br><br><b>--task-desc <task> or -s <task></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a detailed description of the specified task, explaining what it includes.<br><br><b>--install <task> or -i <task></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs the specified task, including all associated packages and their dependencies.<br><br><b>--remove <task> or -r <task></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the specified task, along with packages that are no longer required by other installed software.<br><br><b>--new-install or -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>tasksel</b> in a special mode primarily used during initial system installation to prompt for task selection.<br><br><b>--task-packages <task> or -p <task></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all individual packages that constitute the specified task, without installing them.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>tasksel</b> command.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message with a summary of available options and usage examples.<br><br>


title: DESCRIPTION
content:
<b>tasksel</b> is a high-level command-line utility for Debian and Ubuntu-based systems that simplifies the installation of predefined groups of related software packages, known as "tasks" or "collections". These tasks represent common server roles or desktop environments, such as a LAMP server, Mail server, or a GNOME desktop environment.<br><br>It streamlines the setup of complex environments by automatically handling the selection and installation of all necessary components and their dependencies. Instead of manually installing numerous individual packages, users can select a task, and <b>tasksel</b>, in conjunction with <i>apt</i>, manages the entire process. It is particularly valuable during the initial system installation phase to quickly configure a functional system, but it can also be used post-installation to add or remove functionalities. This abstraction significantly reduces complexity for users seeking to deploy common configurations without deep knowledge of individual package dependencies, ensuring all required components for a specific function are installed coherently.


title: CAVEATS
content:
<b>tasksel</b> is specifically designed for Debian and Ubuntu-based systems and is not available on other Linux distributions like Red Hat or Fedora. While it simplifies installation, it offers less granular control over individual package choices compared to lower-level tools like <i>apt</i> or <i>dpkg</i>. Removing a task does not necessarily uninstall all packages installed by that task if they are still dependencies for other installed software or if they were manually marked for installation. Users should still have a basic understanding of the underlying <i>apt</i> package management system for advanced scenarios or troubleshooting.


title: INTERACTIVE MODE
content:
When executed without any command-line arguments (e.g., just <b>tasksel</b>), it launches an ncurses-based interactive interface. This graphical menu allows users to visually browse through available tasks, read their descriptions, and easily select or deselect tasks using arrow keys and the spacebar. This mode is often preferred for desktop users or during interactive system installations.


title: TASKS CONCEPT
content:
A 'task' in <b>tasksel</b> represents a logical grouping of packages that collectively provide a specific functionality or environment. These tasks are defined in special `.desc` files located typically in <i>/usr/share/tasksel/</i>. These files specify the packages to be installed, their priority, and a human-readable description. This modular approach makes it easy for maintainers to define and update common software configurations and for users to quickly deploy them.


title: HISTORY
content:
<b>tasksel</b> originated within the Debian project as a crucial utility to simplify the selection and installation of common software collections during the operating system installation process. Its development aimed to provide an intuitive interface, especially for new users, to set up specific system roles (e.g., web server, desktop environment) without requiring extensive knowledge of individual package names and their dependencies. It has been a standard and integral component of Debian and its derivatives, including Ubuntu, for many years, evolving alongside the <i>apt</i> package management system to streamline and automate common deployment scenarios.


title: SYNOPSIS
content:
<b>taskset</b> [<i>options</i>] [<i>mask</i> | <i>list</i>] [<i>pid</i>]<br><b>taskset</b> [<i>options</i>] <i>mask</i>|<i>list</i> <i>command</i> [<i>arguments...</i>]<br><b>taskset</b> <i>-p</i> [<i>options</i>] [<i>mask</i> | <i>list</i>] <i>pid</i><br><b>taskset</b> <i>-c</i> [<i>options</i>] [<i>mask</i> | <i>list</i>] <i>pid</i>


title: PARAMETERS
content:
<b>-p, --pid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on an existing <i>PID</i> (Process ID). When used, <b>taskset</b> queries or sets the affinity of the specified process.<br><br><b>-c, --cpu-list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the affinity argument as a numerical list of CPUs instead of a hexadecimal bitmask. For example, '0,1,5-7' refers to CPUs 0, 1, 5, 6, and 7.<br><br><b>-a, --all-tasks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on all tasks (threads) associated with the given <i>PID</i>. This option requires either <i>-p</i> or <i>-c</i> to be specified, as it's only relevant for existing processes.<br><br><b>-s, --status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query the current CPU affinity of the specified <i>PID</i> and exit. This option requires either <i>-p</i> or <i>-c</i>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit, showing usage information for the command.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b>mask</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A hexadecimal bitmask representing the allowed CPUs. Each bit corresponds to a CPU, starting from the rightmost bit for CPU 0. For example, <i>0x00000001</i> for CPU 0, <i>0x00000003</i> for CPUs 0 and 1.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of CPU numbers or ranges (e.g., '0,1,4-6'). This format is used when the <i>-c</i> or <i>--cpu-list</i> option is active.<br><br><b>pid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Process ID of the target process when querying or setting the affinity of an already running process.<br><br><b>command</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to execute with the specified CPU affinity. This is used when launching a new process.<br><br><b>arguments...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments passed directly to the <i>command</i> being executed.<br><br>


title: DESCRIPTION
content:
<b>taskset</b> allows users to control which CPUs a process or command can run on. This is known as CPU affinity, a scheduler property that dictates which physical or logical processors a task can execute on.<br><br>By assigning a specific set of CPUs to a process, one can optimize performance for CPU-bound tasks, reduce context switching overhead, or isolate critical processes to specific cores to avoid interference. It uses either a hexadecimal bitmask or a comma-separated list of CPU IDs to define the allowed processors. <b>taskset</b> can be used to query the current affinity of a running process (using the <i>-p</i> or <i>--pid</i> option) or to launch a new command with a predefined affinity. This capability is particularly useful in multi-core and NUMA systems for performance tuning, real-time applications, and managing resource contention.


title: CAVEATS
content:
Using <b>taskset</b> can sometimes degrade performance if not used carefully, especially if it leads to an imbalance in CPU utilization or prevents the scheduler from optimizing task placement.<br><br>CPU affinity settings are inherited by child processes unless explicitly changed by the child or a subsequent <b>taskset</b> command.<br><br>Setting affinity on a multi-threaded application often requires using the <i>--all-tasks</i> (<i>-a</i>) option to apply the affinity to all individual threads (tasks) within the process.<br><br>The specified <i>mask</i> or <i>list</i> must correspond to available CPUs on the system. Specifying non-existent CPUs will result in an error and the operation failing.


title: CPU AFFINITY VS. SCHEDULING PRIORITY
content:
While both CPU affinity (<b>taskset</b>) and scheduling priority (e.g., using <b>nice</b> or <b>chrt</b>) influence how processes run, they serve different purposes.<br><br>Affinity dictates <i>which</i> CPUs a process is allowed to run on, effectively partitioning the available CPU resources. Priority, on the other hand, determines <i>when</i> a process runs relative to others on its assigned or available CPUs. They can be used together for comprehensive process management.


title: BITMASK VS. CPU LIST
content:
Older versions of <b>taskset</b> primarily used hexadecimal bitmasks to specify CPU affinity. The introduction of the <i>-c</i> or <i>--cpu-list</i> option provided a more human-readable and convenient way to specify CPU affinity, especially for systems with a large number of CPUs.<br><br>A bitmask of 0x1 corresponds to CPU 0, 0x2 to CPU 1, 0x4 to CPU 2, and so on. The CPU list format (e.g., '0,1,4-6') is often simpler to understand and manage for users working with individual CPU IDs.


title: HISTORY
content:
The concept of CPU affinity has been a core part of operating system schedulers for optimizing performance on multi-processor systems. The <b>taskset</b> utility provides a user-space interface to the underlying <i>sched_setaffinity</i> system call, which has been present in Linux since its early multi-processor days.<br><br>Its usage became more prevalent with the widespread adoption of multi-core processors, enabling fine-grained control over process execution on specific cores. This control is particularly useful for high-performance computing (HPC), real-time applications, and isolating critical services to dedicated CPU resources, ensuring predictable performance.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>tb</b> or a specific <i>command</i>.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the current version of <b>tb</b>.<br><br><b><b>--init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <b>tb</b> data file if it doesn't exist. Useful for first-time setup.<br><br><b><b>--clear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears all tasks and notes. <i>Use with caution, as this action is irreversible.</i><br><br><b><b>add</b> <i><item></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new task (prefixed with <code>-t</code> or <code>--task</code>) or note (prefixed with <code>-n</code> or <code>--note</code>).<br>Example: <code>tb add -t "Buy groceries"</code> or <code>tb add -n "Meeting notes"</code>.<br><br><b><b>list</b> [<i>filters</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all active tasks and notes. Can be filtered by various criteria like board, priority, or type.<br>Example: <code>tb list @work</code> or <code>tb list --priority 1</code>.<br><br><b><b>check</b> <i><id></i> [<i>id...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks off or unchecks tasks by their numerical ID. Toggles completion status.<br>Example: <code>tb check 1 3</code>.<br><br><b><b>bookmark</b> <i><id></i> [<i>id...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bookmarks or unbookmarks tasks/notes by their ID. Toggles bookmark status.<br>Example: <code>tb bookmark 2</code>.<br><br><b><b>delete</b> <i><id></i> [<i>id...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes tasks or notes by their numerical ID. <i>This action is irreversible.</i><br>Example: <code>tb delete 4</code>.<br><br><b><b>move</b> <i><id></i> [<i>id...</i>] <i><board></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves specified tasks/notes to a different board. Creates the board if it doesn't exist.<br>Example: <code>tb move 1 2 @home</code>.<br><br><b><b>priority</b> <i><id></i> [<i>id...</i>] <i><level></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the priority level for tasks/notes (0: none, 1: low, 2: medium, 3: high).<br>Example: <code>tb priority 5 3</code>.<br><br><b><b>archive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Archives all completed tasks. Archived items are hidden from the default <b>list</b> view.<br><br><b><b>restore</b> <i><id></i> [<i>id...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores archived tasks by their ID, moving them back to active.<br>Example: <code>tb restore 7</code>.<br><br><b><b>boards</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available boards and the number of items in each.<br><br><b><b>find</b> <i><query></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for tasks or notes containing the specified query string.<br><br><b><b>edit</b> <i><id></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a task or note in the default text editor for modification.<br><br>


title: DESCRIPTION
content:
<i>Taskbook</i> (<code>tb</code>) is a free and open-source command-line utility designed for efficient management of tasks, todos, and notes. Written in Node.js, it offers a minimalistic yet powerful interface for organizing your daily activities. Users can create, check off, prioritize, and delete tasks, as well as create and manage notes. It supports organizing items into boards, making it suitable for personal project management. All data is stored in a simple JSON file, ensuring portability and ease of backup. Its intuitive syntax and quick response time make it an excellent tool for developers and power users who prefer to stay within the terminal environment for productivity.


title: CAVEATS
content:
<i>Taskbook</i> (<b>tb</b>) is not a standard pre-installed Linux command. It requires Node.js and must be installed separately, typically via npm (<code>npm install --global taskbook</code>).<br><br>Data is stored in a single JSON file (<code>~/.taskbook/storage/storage.json</code> by default), which is great for portability but not ideal for multi-user or highly concurrent environments.<br><br>Its simple design means it lacks advanced features found in more comprehensive project management tools like calendar integration or sophisticated reporting.


title: INSTALLATION
content:
To install <i>Taskbook</i>, Node.js and npm must be pre-installed on your system. Then, run the following command in your terminal: <code>npm install --global taskbook</code>.<br>After successful installation, the <b>tb</b> command becomes available in your shell.


title: CONFIGURATION
content:
<i>Taskbook</i> can be configured via a JSON file typically located at <code>~/.taskbook/config.json</code>. This allows customization of colors, symbols used for different item types (tasks, notes, priorities, boards), default board, and the storage file location. For example, you can set your preferred text editor for the <code>edit</code> command.


title: DATA STORAGE
content:
By default, <i>Taskbook</i> stores all your tasks and notes in a single JSON file: <code>~/.taskbook/storage/storage.json</code>. This file is human-readable and can be easily backed up or manually edited (though not recommended while <b>tb</b> is running). The location of this storage file can be customized in the configuration file if desired.


title: HISTORY
content:
<i>Taskbook</i> (<b>tb</b>) was created by Klauss Fray and first released in 2018. It quickly gained popularity in the developer community for its elegant command-line interface and minimalist approach to task management. Developed in Node.js, it leverages the widespread availability of npm for easy installation across various operating systems. Its open-source nature has allowed for community contributions and steady development, focusing on stability and user-friendly features, establishing itself as a go-to terminal productivity tool.


title: PARAMETERS
content:
<b><b>-TX</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate <b>troff</b> output that is suitable for devices that use TeX, primarily for DVI output.<br><br><b><b>-ms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inform <b>tbl</b> that the <I>ms</I> macro package is being used. This affects certain default settings for table formatting.<br><br><b><b>-mm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inform <b>tbl</b> that the <I>mm</I> macro package is being used, similar to <I>-ms</I>.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print warning messages to standard error regarding potential issues in table descriptions.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version number of <b>tbl</b> to standard error and exit.<br><br>


title: DESCRIPTION
content:
<b>tbl</b> is a specialized preprocessor designed to format tables for the <b>groff</b> typesetting system (or its predecessor <b>troff</b>). It reads input files containing table descriptions, which are delimited by <I>.TS</I> (Table Start) and <I>.TE</I> (Table End) macros. Within these delimiters, users can specify table layouts, column definitions, data, and various formatting options using a simple, intuitive syntax.<br><br><b>tbl</b> then translates these high-level descriptions into a series of <b>groff</b> (or <b>troff</b>) commands that precisely control the layout, alignment, spacing, and appearance of the table. It is typically used as part of a <b>groff</b> pipeline, where the output of <b>tbl</b> is piped to <b>groff</b> along with other text. This allows for complex, multi-column tables to be easily embedded and formatted within <b>roff</b> documents, making it an essential tool for creating professional-quality documentation, manuals, and reports. Its strength lies in abstracting away the complex <b>troff</b> primitives required for table layout, providing a much simpler, declarative syntax.


title: CAVEATS
content:
Mastering <b>tbl</b>'s table description language can be challenging for complex or highly customized table layouts. <br><br>While powerful for text and numeric data, it does not inherently support embedding graphical elements or images directly within table cells. <br><br>Its reliance on the <b>groff</b>/<b>troff</b> ecosystem means that a full understanding of the document processing pipeline is often required for effective use and troubleshooting.


title: TABLE STRUCTURE AND WORKFLOW
content:
Tables are defined within input files by placing the table description between <I>.TS</I> (Table Start) and <I>.TE</I> (Table End) macros. The lines immediately following <I>.TS</I> specify global table options and column formats, followed by the table data itself.<br><br>A common workflow involves piping the output of <b>tbl</b> to <b>groff</b>:<br><I>tbl document.roff | groff -mandoc > document.ps</I><br>This command first processes the tables, then formats the entire document, and finally outputs it to a PostScript file.


title: HISTORY
content:
<b>tbl</b> originated from the original Bell Labs <b>troff</b> system developed by Joe F. Ossanna and later enhanced by Brian W. Kernighan. It was one of the earliest specialized preprocessors for <b>troff</b>, designed specifically to simplify the creation of complex tables, a task notoriously difficult with raw <b>troff</b> commands. Its declarative approach to table layout greatly improved productivity. It has since become a standard component of Unix-like systems, with the GNU version being maintained as part of the <b>groff</b> suite, ensuring its continued relevance in document formatting.


title: SYNOPSIS
content:
<i>This utility is not designed for direct user invocation from the command line and does not accept standard command-line options or arguments.</i><br><br>It operates internally as a helper script for <b>dpkg-buildpackage</b> and similar <b>dpkg</b> tools, processing <i>debian/control</i> file content as required by the build system.


title: PARAMETERS
content:
<b><i>(None)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This utility does not accept any command-line parameters or options. Its operation is driven by internal logic and the context provided by calling <b>dpkg</b> tools.<br><br>


title: DESCRIPTION
content:
<i>tbl-dctrl</i> is an internal utility script, part of the <b>dpkg-dev</b> package, primarily used in the context of Debian package building.<br><br>Its core function is to assist in managing the <b>tbl</b> field within a Debian source package's <i>debian/control</i> file. The <b>tbl</b> field lists files (typically <i>troff</i>-based documentation like man pages) that require preprocessing with the <b>tbl(1)</b> utility to correctly format tables. <i>tbl-dctrl</i> helps ensure that this field is correctly structured and processed during package build operations.<br><br>It is not intended for direct interactive use by users, but rather invoked internally by tools like <b>dpkg-buildpackage</b> or <b>dpkg-source</b> as part of the automated build process to handle documentation preprocessing.


title: CAVEATS
content:
<b>Internal Use:</b> <i>tbl-dctrl</i> is an internal helper script and not meant for direct user interaction. Attempting to run it directly from the shell will likely not produce useful output or may lead to errors without the proper environment set up by <b>dpkg</b> tools.<br><br><b>Perl Dependency:</b> As a Perl script, it requires a Perl interpreter to run.<br><br><b>No Man Page:</b> It does not have its own dedicated man page, as its functionality is typically documented within <b>dpkg-buildpackage(1)</b> or the Debian Policy Manual.


title: ROLE IN DEBIAN PACKAGING
content:
The <b>tbl</b> field in <i>debian/control</i> is a crucial part of ensuring that <i>troff</i>-based documentation (especially man pages) with embedded tables is correctly processed during the Debian package build. <i>tbl-dctrl</i> serves as the internal mechanism that handles the parsing and validation of this field, directing the build system to apply the <b>tbl</b> preprocessor when necessary. This automation reduces the burden on package maintainers and helps maintain consistency across Debian packages.


title: LOCATION
content:
The <i>tbl-dctrl</i> script is typically found at <i>/usr/share/dpkg/tbl-dctrl.pl</i> on Debian-based systems. This location, outside of typical <b>PATH</b> directories, reinforces its nature as an internal utility rather than a directly executable command for end-users.


title: HISTORY
content:
<i>tbl-dctrl</i> has been a part of the <b>dpkg-dev</b> toolchain for a long time, assisting Debian package maintainers with the proper handling of <i>troff</i>-based documentation, specifically tables, within their packages.<br><br>Its existence is tied to the evolution of Debian's packaging standards and the widespread use of <i>troff</i>/<i>groff</i> for Unix-like system documentation (man pages). It reflects the efforts to automate and standardize the documentation build process within the Debian ecosystem.


title: SYNOPSIS
content:
<b>tc</b> [ <i>OPTIONS</i> ] <i>OBJECT</i> { <i>COMMAND</i> | <b>help</b> }<br><i>OBJECT</i> := { <b>qdisc</b> | <b>class</b> | <b>filter</b> | <b>action</b> | <b>monitor</b> | <b>resource</b> }<br><i>OPTIONS</i> := { <b>-s</b> | <b>-d</b> | <b>-o</b> | <b>-n</b> | <b>-r</b> | <b>-p</b> | <b>-t</b> | <b>-B</b> | <b>-I</b> | <b>-V</b> | <b>-h</b> | <b>-force</b> }<br><i>COMMAND</i> := { <b>add</b> | <b>change</b> | <b>replace</b> | <b>del</b> | <b>show</b> | <b>get</b> | <b>monitor</b> }


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show statistics for objects (e.g., packet counts, bytes, errors).<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show default values for objects, which can be useful for debugging.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One shot operation; the command exits immediately upon the first error encountered.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not resolve network addresses or service names; display numeric values instead.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace an existing object if it already exists; otherwise, add it. This is a shorthand for '<i>add</i>' with the '<i>replace</i>' keyword.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty print statistics, converting byte and bit rates into human-readable formats (e.g., KBps, Mbps).<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display timestamps for operations, showing when a command was processed.<br><br><b><b>-B</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read and execute <b>tc</b> commands from the specified batch file, one command per line.<br><br><b><b>-I</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore errors for specified operations, allowing subsequent commands in a batch script to continue.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information for the <b>tc</b> utility.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message for the <b>tc</b> command.<br><br><b><b>-force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, overriding certain sanity checks that <b>tc</b> might otherwise perform.<br><br>


title: DESCRIPTION
content:
<b>tc</b> (Traffic Control) is the command-line utility used to configure Quality of Service (QoS) and traffic shaping for the Linux kernel. It allows administrators to manage network packet queues, classify packets, apply various scheduling algorithms (qdiscs), and implement rate limiting, policing, and prioritization. <b>tc</b> operates by manipulating the queuing discipline (qdisc) attached to network interfaces, which then manages how packets are buffered and transmitted. It's a powerful tool for optimizing network performance, managing congestion, and ensuring fair bandwidth allocation across different applications or users. Its extensive capabilities make it essential for advanced network management but also contribute to its significant complexity.


title: CAVEATS
content:
<b>tc</b> is notoriously complex due to its hierarchical structure of qdiscs, classes, and filters, and the wide array of available algorithms. Misconfigurations can severely impact network connectivity, performance, or even render a network interface unusable. A deep understanding of networking concepts (queuing, scheduling, packet classification) is essential for effective use. Order of operations for adding and deleting components is critical.


title: CORE <B>TC</B> OBJECTS
content:
The <b>tc</b> command operates on several types of objects, each representing a different aspect of traffic control:<br><ul><li><i><b>qdisc (queuing discipline)</b></i>: The core component, attached to a network device, that manages packet queues and determines how packets are sent out the interface. Examples include <b>htb</b>, <b>hfsc</b>, <b>fq_codel</b>, <b>tbf</b>, <b>prio</b>.<br></li><li><i><b>class</b></i>: Subdivisions within a qdisc, allowing for hierarchical structuring of traffic, where different types of traffic can be managed independently.<br></li><li><i><b>filter</b></i>: Rules that classify incoming packets and direct them to specific classes within a qdisc for further processing. Filters use match criteria (e.g., source/destination IP, port, protocol) to identify traffic.<br></li><li><i><b>action</b></i>: Operations applied to packets once they are classified by a filter, such as dropping, marking, or redirecting.<br></li></ul>


title: COMMON COMMANDS
content:
For each object type, <b>tc</b> supports various commands:<br><ul><li><i><b>add</b></i>: Adds a new object (qdisc, class, filter).<br></li><li><i><b>change</b></i>: Modifies an existing object's parameters.<br></li><li><i><b>replace</b></i>: Atomically replaces an object if it exists, otherwise adds it.<br></li><li><i><b>del</b></i>: Deletes an object and its associated sub-objects.<br></li><li><i><b>show</b></i>: Displays the current configuration of objects on a network device.<br></li></ul>


title: HISTORY
content:
The <b>tc</b> command is part of the <i>iproute2</i> utilities, which replaced the older <i>net-tools</i> suite for network configuration in Linux. Developed largely by Alexey Kuznetsov, <i>iproute2</i> (including <b>tc</b>) was designed to leverage the advanced networking capabilities of the Linux kernel, particularly Netlink sockets, providing a more powerful and flexible framework for network management compared to its predecessors. It has been the standard tool for Linux traffic control for many years, evolving with new kernel features.


title: SYNOPSIS
content:
<b>tc qdisc</b> { <b>add</b> | <b>change</b> | <b>replace</b> | <b>get</b> } <b>dev</b> <i>DEV</i> { <b>root</b> | <b>parent</b> <i>HANDLE</i> } <b>bfifo</b> [ <b>limit</b> <i>BYTES</i> ]


title: PARAMETERS
content:
<b><b>dev</b> <i>DEV</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device to which the queueing discipline should be attached. <i>DEV</i> is the device name, e.g., <i>eth0</i>.<br><br><b><b>root</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the qdisc to the root of the device's traffic control tree.<br><br><b><b>parent</b> <i>HANDLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the qdisc as a child of an existing class or qdisc identified by <i>HANDLE</i>. This allows for hierarchical traffic control setups.<br><br><b><b>limit</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum size of the queue in bytes. If this limit is exceeded, incoming packets are dropped. This is the core parameter for <b>bfifo</b>.<br><br>


title: DESCRIPTION
content:
The <b>tc-bfifo</b> command configures a <i>Byte-FIFO</i> queueing discipline for traffic control in Linux. It is one of the simplest queueing disciplines available, operating on a <i>First-In, First-Out</i> (FIFO) principle. This means packets are processed in the exact order they arrive.<br><br>The primary characteristic of <b>bfifo</b> is that its capacity is defined by a <i>byte limit</i>. Once the total size of queued packets exceeds this specified limit, any new incoming packets are dropped until space becomes available. This is often referred to as "tail drop." It offers no advanced features like prioritization, fairness, or explicit bandwidth shaping. Its main use is for basic buffering and preventing excessive queue buildup beyond a certain byte threshold, making it suitable for simple links where only capacity limiting is required. It is an alternative to <b>pfifo</b>, which limits by number of packets rather than bytes.


title: CAVEATS
content:
<b>bfifo</b> is an extremely simple queueing discipline. It provides no mechanism for prioritization, fairness, or explicit bandwidth control. It implements "tail drop," meaning packets are dropped from the end of the queue when the limit is reached, potentially leading to TCP global synchronization if many TCP flows share the same queue and drop packets simultaneously. For more sophisticated traffic management, other queueing disciplines like <b>HTB</b> or <b>SFQ</b> should be considered.


title: <I>BFIFO VS. PFIFO</I>
content:
While both <b>bfifo</b> and <b>pfifo</b> are simple FIFO queueing disciplines, their key difference lies in how they measure their capacity. <b>bfifo</b> uses a <i>byte limit</i>, ensuring that the total size of queued data does not exceed a specified number of bytes. In contrast, <b>pfifo</b> uses a <i>packet limit</i>, restricting the number of packets in the queue. The choice between them depends on whether you want to control queue depth by the amount of data or by the number of individual packets.


title: HISTORY
content:
The <b>bfifo</b> queueing discipline has been a fundamental part of the Linux traffic control system since its inception, integrated within the <i>iproute2</i> suite of utilities. It provides one of the most basic and efficient buffering mechanisms, serving as a building block for understanding more complex queueing behaviors. Its primary role has remained consistent: a straightforward FIFO queue limited by byte capacity, essential for basic link capacity management.


title: SEE ALSO
content:
<b>tc(8)</b>: Traffic control utility., <b>tc-pfifo(8)</b>: Packet-based FIFO queueing discipline., <b>tc-sfq(8)</b>: Stochastic Fair Queueing discipline., <b>tc-htb(8)</b>: Hierarchical Token Bucket queueing discipline.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <I>DEV</I> <b>root | parent</b> <I>HANDLE</I> <b>cbq</b> [ <I>QDISC_OPTIONS</I> ]<br><b>tc class add dev</b> <I>DEV</I> <b>parent</b> <I>HANDLE</I> <b>classid</b> <I>CLASSID</I> <b>cbq</b> [ <I>CLASS_OPTIONS</I> ]


title: PARAMETERS
content:
<b><I>dev</I> <I>DEV</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The network device on which the qdisc or class operates.<br><br><b><I>root | parent</I> <I>HANDLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies whether this is the root qdisc or a child of an existing qdisc identified by <I>HANDLE</I>.<br><br><b><I>classid</I> <I>CLASSID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique identifier for a specific class within the CBQ hierarchy.<br><br><b>bandwidth <I>RATE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc)</I> Total bandwidth of the interface or parent qdisc, e.g., '100mbit'.<br><br><b>avpkt <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Average packet size, used for internal calculations, e.g., '1000'.<br><br><b>cell <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Cell size for packet data, affects granularity of shaping, e.g., '8'.<br><br><b>maxburst <I>PACKETS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Maximum allowed burst of packets before shaping takes effect.<br><br><b>minburst <I>PACKETS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Minimum burst of packets allowed.<br><br><b>ewma <I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Exponentially Weighted Moving Average factor for utilization calculation.<br><br><b>offtime <I>TIME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc)</I> How long a class should remain throttled after exceeding its limit, e.g., '1ms'.<br><br><b>split <I>HANDLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Creates an internal classifier for sub-classes.<br><br><b>defmap <I>MAP</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Qdisc/Class)</I> Default priority map, defines how priorities map to classes.<br><br><b>rate <I>RATE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> The maximum rate allowed for this specific class, e.g., '10mbit'.<br><br><b>prio <I>PRIORITY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> The priority of the class; lower values indicate higher priority.<br><br><b>bounded</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> Prevents this class from borrowing bandwidth from its parent.<br><br><b>isolated</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> Prevents this class from lending bandwidth to its sibling classes.<br><br><b>weight <I>WEIGHT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> Specifies the weight for proportional bandwidth sharing among classes.<br><br><b>mtu <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>(Class)</I> Maximum Transmission Unit for the class, defaults to interface MTU.<br><br>


title: DESCRIPTION
content:
<p><b>CBQ (Class Based Queueing)</b> is a queuing discipline (qdisc) used with the Linux <I>tc</I> (traffic control) command to manage and shape network traffic. It enables hierarchical bandwidth allocation, allowing administrators to divide available bandwidth among different classes of traffic based on various criteria like source/destination IP, port, or protocol.<br><br>CBQ operates by attempting to provide a specific share of the link's bandwidth to each class, borrowing bandwidth when a class is idle and distributing excess bandwidth to busy classes. While powerful, CBQ is known for its complexity in configuration and can be resource-intensive. It creates a tree-like structure where a root qdisc distributes traffic to child classes, which can further have their own children. Each class can define its own rate, priority, and borrowing behavior.</p>


title: CAVEATS
content:
<p>CBQ is known for its significant configuration complexity and can be challenging to fine-tune for optimal performance. It can be CPU-intensive, especially on high-speed interfaces, due to its intricate packet scheduling and borrowing/lending mechanisms.<br><br>For many modern traffic shaping needs, <I>HTB (Hierarchical Token Bucket)</I> is often preferred over CBQ due to its simpler configuration, better performance, and more predictable behavior, making CBQ less commonly used in new deployments.</p>


title: WORKING WITH FILTERS
content:
CBQ classes are typically populated by using <I>tc filters</I>. Filters classify incoming packets based on various criteria (e.g., source/destination IP, port, protocol) and direct them to specific CBQ classes. Without proper filter configuration, traffic will not flow into the intended classes, bypassing the shaping rules.


title: HIERARCHICAL STRUCTURE
content:
CBQ creates a tree-like hierarchy of classes. A root CBQ qdisc manages the entire interface bandwidth, and child classes can further subdivide and manage their allocated share. This allows for very granular control over traffic flow, where a parent class can define an aggregate limit for its children, and children can define their own rates and priorities within that limit.


title: HISTORY
content:
<p>CBQ was one of the foundational and most powerful traffic shaping disciplines introduced early in Linux's network stack development. It aimed to provide flexible, hierarchical bandwidth management. However, due to its inherent configuration complexity and the later development of more streamlined and performant alternatives like <I>HTB</I>, its usage has become less prevalent in modern network deployments, though it remains a robust option for those who master its intricacies.</p>


title: SYNOPSIS
content:
<b>silentcast</b> [<I>options</I>] [<I>output_file</I>]<br><br><b>Examples:</b><br><I>silentcast</I> -r -o <I>my_screencast.webm</I><br><I>silentcast</I> -g 1280x720+100+50 -f 25 -a default -o <I>presentation.mp4</I>


title: PARAMETERS
content:
<b>-o, --output <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file path for the recorded video (e.g., <I>video.webm</I>). If not specified, a default filename might be used or output written to stdout depending on the backend.<br><br><b>-r, --region</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows interactive selection of the screen area to record using an external tool like <I>xrectsel</I>. This option pauses execution until a region is selected graphically.<br><br><b>-g, --geometry <I>WxH+X+Y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually defines the recording area's dimensions and position (e.g., <I>1920x1080+0+0</I> for a full HD screen starting at top-left). Overrides <I>--region</I> if both are used.<br><br><b>-f, --framerate <I>fps</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the frames per second for the recording (e.g., <I>30</I> for 30 FPS). Default is often 25 or 30, affecting smoothness and file size.<br><br><b>-a, --audio <I>source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an audio input source to include sound in the recording (e.g., <I>hw:0,0</I> or <I>default</I>). Requires appropriate audio backend setup and permissions.<br><br><b>-c, --codec <I>codec</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the video codec to use for encoding (e.g., <I>libvpx-vp9</I> for WebM, <I>libx264</I> for MP4). The availability depends on the installed backend encoder.<br><br><b>-q, --quality <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the video quality level, typically a numerical value or preset where higher means better visual fidelity but potentially larger file size.<br><br><b>-d, --display <I>display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to capture from (e.g., <I>:0.0</I>), useful in multi-monitor setups or remote X sessions.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message with all available options and examples for <b>silentcast</b>.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <I>silentcast</I> utility and exits.<br><br>


title: DESCRIPTION
content:
<b>silentcast</b> is a minimalistic yet powerful screen recording utility designed for Linux systems. It provides a straightforward way to capture screen activity, including mouse movements, clicks, and window interactions. Unlike more complex screencasting software, <b>silentcast</b> focuses on simplicity and efficiency, making it ideal for creating quick tutorials, demonstrations, or bug reports.<br><br>It typically integrates with backend video encoders like <I>FFmpeg</I> or <I>avconv</I> to produce high-quality, compressed video files, often in formats like WebM or MP4. Users can define a specific recording area, set the frame rate, and optionally include audio input from a microphone. Its command-line interface, combined with the ability to select regions graphically, offers flexibility for various screen capture needs without an overwhelming set of features.


title: CAVEATS
content:
<b>silentcast</b> relies heavily on external dependencies for its core functionality. It requires a powerful multimedia framework like <I>FFmpeg</I> or <I>avconv</I> for video encoding and typically <I>xrectsel</I> (or a similar tool) for interactive screen region selection. These dependencies must be installed and properly configured on the system for <b>silentcast</b> to function correctly. It is primarily designed for X11 environments; Wayland support might be limited or require specific workarounds.


title: DEPENDENCIES
content:
To use <b>silentcast</b>, ensure you have <I>FFmpeg</I> (or <I>avconv</I>) installed for video encoding. For interactive region selection with the <I>-r</I> option, a utility like <I>xrectsel</I> is also typically required. Missing dependencies will prevent <b>silentcast</b> from operating correctly.


title: RECORDING FLOW
content:
The typical usage flow involves executing the <b>silentcast</b> command, often with the <I>-r</I> (region) option. You then interactively select the desired screen area using your mouse. Once the selection is made, recording begins immediately. To stop recording, you usually press <I>Ctrl+C</I> in the terminal where <b>silentcast</b> is running, or it might automatically stop after a predefined duration depending on the version or options used. The recorded video file will then be saved to the specified output path.


title: HISTORY
content:
<b>silentcast</b> emerged as a lightweight alternative for screencasting on Linux, focusing on a minimal interface and leveraging existing powerful multimedia tools like <I>FFmpeg</I>. Its development aimed to provide a quick, no-frills method for capturing desktop activity without the overhead of more complex GUI-based applications. While not as feature-rich as some contemporaries, its strength lies in its simplicity and effectiveness for basic screen recording tasks, making it popular among users who prefer command-line workflows or need a reliable, low-resource option. It fills a niche for users valuing simplicity over extensive features.


title: SYNOPSIS
content:
<b>snowsql</b> [<i>options</i>] [<i>arguments</i>]<br><br>Examples:<br><br><b>snowsql</b> -a <i><account_identifier></i> -u <i><username></i><br><b>snowsql</b> -f <i><script_file.sql></i> -o <i>exit_on_error=true</i><br><b>snowsql</b> -q "<i>SELECT CURRENT_VERSION();</i>"


title: PARAMETERS
content:
<b><b>-a</b>, <b>--account</b> <i><identifier></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Snowflake account identifier to connect to.</i><br><br><b><b>-u</b>, <b>--username</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The Snowflake username for authentication.</i><br><br><b><b>-w</b>, <b>--warehouse</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the default virtual warehouse for the session.</i><br><br><b><b>-d</b>, <b>--database</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the default database for the session.</i><br><br><b><b>-s</b>, <b>--schema</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the default schema within the database for the session.</i><br><br><b><b>-r</b>, <b>--role</b> <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the role to use for the session.</i><br><br><b><b>-P</b>, <b>--password</b> <i><password></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides the password directly (not recommended for security). Use <b>--prompt-for-password</b> instead.</i><br><br><b><b>--prompt-for-password</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prompts the user for their password securely.</i><br><br><b><b>-f</b>, <b>--filename</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Executes SQL commands from the specified file.</i><br><br><b><b>-q</b>, <b>--query</b> <i><query_string></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Executes a single SQL query and then exits.</i><br><br><b><b>-o</b>, <b>--option</b> <i><key=value></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets a SnowSQL configuration option (e.g., <b>exit_on_error=true</b>).</i><br><br><b><b>-D</b>, <b>--define</b> <i><variable=value></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines a variable that can be used within SQL scripts.</i><br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the SnowSQL version information and exits.</i><br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the help message and exits.</i><br><br>


title: DESCRIPTION
content:
<i>SnowSQL</i> is the powerful command-line client provided by Snowflake, enabling users to connect to and interact with their Snowflake accounts directly from a terminal. It serves as an essential tool for executing SQL queries, loading and unloading data, and performing various administrative tasks. Built on Python, SnowSQL supports both interactive and non-interactive modes, making it versatile for scripting, automation, and ad-hoc query execution. It provides features like command history, tab completion, and customizable options through a configuration file, enhancing productivity for data professionals. Users can manage databases, schemas, tables, warehouses, and roles, facilitating comprehensive control over their Snowflake environment.


title: CAVEATS
content:
<i>Security:</i> Avoid passing sensitive credentials like passwords directly on the command line, as they might be visible in process lists. Use environment variables (e.g., <code>SNOWSQL_PWD</code>), a configuration file (<code>~/.snowsql/config</code>), or the <b>--prompt-for-password</b> option for better security.<br><br><i>Performance:</i> For extremely large data loading or unloading scenarios, consider using Snowflake's bulk loading features (e.g., <code>PUT</code>/<code>GET</code> commands or Snowpipe) which might offer better performance than simple SQL inserts or selects through SnowSQL.<br><br><i>Dependencies:</i> SnowSQL requires a compatible Python environment to run. Ensure Python and necessary libraries are correctly installed.


title: CONFIGURATION FILE
content:
<i>SnowSQL can be configured via a file located at <b>~/.snowsql/config</b>. This file allows users to store default connection parameters, credentials (encrypted), and various SnowSQL options, streamlining the connection process and enhancing security by avoiding command-line arguments for sensitive information.</i>


title: INTERACTIVE VS. NON-INTERACTIVE MODE
content:
<i><b>SnowSQL</b> operates in two primary modes. In <i>interactive mode</i>, it provides a shell for executing SQL queries sequentially, with features like command history and tab completion. In <i>non-interactive mode</i> (e.g., using <b>-q</b> or <b>-f</b>), it executes specified queries or scripts and exits, making it suitable for automation and scripting within CI/CD pipelines or scheduled jobs.</i>


title: HISTORY
content:
<i>SnowSQL</i> has been a core component of the Snowflake ecosystem since its early days, designed to provide a robust command-line interface for interacting with the Snowflake Data Cloud. While Snowflake was founded in 2012 and launched its service in 2014, SnowSQL has continuously evolved, incorporating new features and optimizations in parallel with the growth and expansion of the Snowflake platform itself. It maintains backward compatibility while adapting to new authentication methods, query capabilities, and data management features offered by Snowflake.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information and exits.<br><br><b>-n, --numeric</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not resolve service names. Display port numbers instead of service names.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all sockets (default: only connected sockets).<br><br><b>-l, --listening</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only listening sockets.<br><br><b>-p, --processes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show process using socket. Requires root privileges for most processes.<br><br><b>-t, --tcp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display TCP sockets.<br><br><b>-u, --udp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display UDP sockets.<br><br><b>-x, --unix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display Unix domain sockets.<br><br><b>-s, --summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display summary statistics.<br><br><b>-e, --extended</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show extended socket information (UID, GID, SECLABEL).<br><br><b>-o, --options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show timer information.<br><br><b>-m, --memory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show socket memory usage.<br><br><b>-i, --info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show internal TCP information (e.g., RTT, retransmits).<br><br><b>-r, --resolve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resolve numeric host addresses and port numbers to their symbolic names.<br><br><b>-4, --ipv4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only IPv4 sockets.<br><br><b>-6, --ipv6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only IPv6 sockets.<br><br><b>-K, --kill</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to forcibly close sockets. <b>Use with extreme caution!</b> Requires root privileges.<br><br>


title: DESCRIPTION
content:
The <b>ss</b> command is a powerful and highly efficient utility for examining network sockets on Linux. It serves as a modern and faster replacement for the traditional <b>netstat</b> command, leveraging the Netlink socket interface in the kernel for superior performance and more detailed information retrieval. <b>ss</b> can display a wealth of information about open sockets, including TCP, UDP, RAW, and Unix domain sockets, along with their states (e.g., ESTABLISHED, LISTEN, TIME-WAIT), associated processes, and various connection details like send/receive queues, timer information, and memory usage. Its design allows it to quickly query kernel space for socket information, making it particularly useful on systems with a large number of connections. Administrators and developers use <b>ss</b> for network troubleshooting, performance monitoring, and security auditing, providing insights into active network connections and listening services.


title: CAVEATS
content:
Some options, such as displaying process information (<b>-p</b>) or forcefully closing sockets (<b>-K</b>), require root privileges to function correctly. Without appropriate permissions, <b>ss</b> may not show all details or may fail to execute certain actions. While more efficient than <b>netstat</b>, its output can be dense and requires familiarity with networking concepts for full interpretation.


title: FILTERING SOCKETS
content:
The <b>ss</b> command supports powerful filtering capabilities to narrow down the output. You can filter by state (e.g., <b>ss -t state established</b>), source/destination address and port (e.g., <b>ss -t dst 192.168.1.1:80</b>), or by user/group. This allows for highly specific queries to quickly find relevant connection information.


title: OUTPUT FIELDS EXPLAINED
content:
Typical output columns include <b>Netid</b> (protocol), <b>State</b> (connection state), <b>Recv-Q</b> (bytes received but not yet read), <b>Send-Q</b> (bytes sent but not yet acknowledged), <b>Local Address:Port</b>, and <b>Peer Address:Port</b>. Understanding these fields is crucial for effective network diagnostics.


title: HISTORY
content:
The <b>ss</b> command is part of the <b>iproute2</b> utility suite, which was developed to provide a more robust and efficient set of networking tools for Linux. Unlike older utilities like <b>netstat</b> that parse pseudo-files in <b>/proc/net</b>, <b>ss</b> directly queries the kernel's Netlink socket interface. This design choice grants <b>ss</b> significant performance advantages, especially on systems with a large number of active network connections, and allows it to retrieve more detailed and up-to-date information directly from the kernel. Its development reflects the Linux kernel's evolution towards more modern and efficient interfaces for network management.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information about the command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of <i>standard-version</i>.<br><br><b><b>-r</b>, <b>--release-as</b> <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the release type (e.g., <i>major</i>, <i>minor</i>, <i>patch</i>, <i>premajor</i>, <i>preminor</i>, <i>prepatch</i>, <i>prerelease</i>) to force a version bump.<br><br><b><b>--prerelease</b> <I>identifier</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a prerelease version (e.g., <i>beta</i>, <i>alpha</i>) with the specified identifier.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run without making any actual changes to the file system or Git repository. Shows what would happen.<br><br><b><b>--first-release</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes the changelog by generating entries for all previous commits, useful for the very first release.<br><br><b><b>--skip.tag</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>standard-version</i> from creating a Git tag for the new version.<br><br><b><b>--skip.commit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>standard-version</i> from creating a Git commit for the version bump and changelog update.<br><br><b><b>--skip.changelog</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>standard-version</i> from generating or updating the <i>CHANGELOG.md</i> file.<br><br><b><b>--no-verify</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses Git commit-hook verification during the commit step.<br><br><b><b>--preset</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a conventional commit preset (e.g., <i>angular</i>) for commit message parsing.<br><br><b><b>--tag-prefix</b> <I>prefix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Customizes the prefix for Git tags (default is 'v', e.g., <i>v1.0.0</i>). Set to empty string for no prefix.<br><br><b><b>--commit-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all staged and untracked files in the release commit, not just the version files and changelog.<br><br>


title: DESCRIPTION
content:
<i>standard-version</i> is a command-line utility designed to automate the release process for software projects following Semantic Versioning. It streamlines bumping the project's version, generating a <i>CHANGELOG.md</i> file based on Conventional Commits, and creating annotated Git tags. By analyzing your Git commit history, it intelligently determines the next version (patch, minor, or major) and populates the changelog with features, bug fixes, and breaking changes. This automation helps maintain consistent release notes, reduces manual errors, and simplifies the overall software delivery workflow, making it an invaluable tool for continuous integration and deployment pipelines.


title: CAVEATS
content:
<i>standard-version</i> relies heavily on the Git repository and the Conventional Commits specification. It requires Node.js and is typically installed via npm or yarn. Improper usage or a malformed commit history can lead to unexpected version bumps or incorrect changelog entries. Always use <b>--dry-run</b> first, especially in production environments, to preview changes. It makes permanent changes to your Git history and files.


title: CONVENTIONAL COMMITS
content:
<i>standard-version</i> expects Git commit messages to adhere to the Conventional Commits specification. This standard provides a lightweight convention on top of commit messages, enabling automated tools to determine the semantic version bump (patch, minor, major) and generate changelogs. Examples: 'feat(scope): add new feature', 'fix(auth): correct login bug', 'BREAKING CHANGE: API updated'.


title: TYPICAL WORKFLOW
content:
A common workflow involves: <br>1. Making code changes and committing them using Conventional Commits. <br>2. Ensuring all desired changes are committed. <br>3. Running <b>standard-version</b>. This command will: <br>&nbsp;&nbsp;&nbsp;&nbsp;a. Determine the next version based on commit messages. <br>&nbsp;&nbsp;&nbsp;&nbsp;b. Update <i>package.json</i> (or other configured files) with the new version. <br>&nbsp;&nbsp;&nbsp;&nbsp;c. Generate or update <i>CHANGELOG.md</i>. <br>&nbsp;&nbsp;&nbsp;&nbsp;d. Create a Git commit with the version bump and changelog changes. <br>&nbsp;&nbsp;&nbsp;&nbsp;e. Create an annotated Git tag for the new version. <br>4. Pushing the new commit and tag to the remote repository (e.g., <b>git push --follow-tags origin master</b>).


title: HISTORY
content:
Born from the JavaScript ecosystem's need for automated release processes, <i>standard-version</i> emerged as a popular tool building upon the success of the <i>conventional-changelog</i> project. It simplifies the often-manual and error-prone tasks of semantic versioning and changelog generation. Its development focused on integrating seamlessly with Git and the Conventional Commits specification, providing a single command to handle the full release lifecycle from version bump to tag creation. It has evolved with the community's adoption of standardized commit message formats.


title: SYNOPSIS
content:
start-pulseaudio-x11<br><i>(Note: This command typically takes no direct options, but executes the pulseaudio daemon internally.)</i>


title: PARAMETERS
content:
<b>None</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>start-pulseaudio-x11</b> command itself typically does not accept any direct command-line parameters. It is a wrapper script designed to start the underlying <i>pulseaudio</i> daemon with specific configurations suitable for an X11 session. Any options or arguments you might encounter when troubleshooting PulseAudio are usually passed to the <i>pulseaudio</i> daemon by this script, rather than being options of <b>start-pulseaudio-x11</b> itself.<br><br>


title: DESCRIPTION
content:
The <b>start-pulseaudio-x11</b> command is a utility script primarily invoked by desktop environments (such as GNOME, KDE, XFCE) to initiate the PulseAudio sound server within an X11 graphical session. Its core purpose is to ensure that PulseAudio is running and properly configured to interact seamlessly with the X Window System. This involves loading essential PulseAudio modules, including <i>module-x11-bell</i> (for X11 system bell sounds), <i>module-x11-cork-request</i> (allowing X11 applications to request audio stream pausing), and <i>module-x11-publish</i> (for advertising PulseAudio's presence over X11). The script typically checks if a PulseAudio daemon is already active for the current user and, if not, proceeds to start one. It acts as a convenient wrapper, abstracting the complexities of starting the PulseAudio daemon with the necessary X11-specific configurations, thereby facilitating smooth audio integration for X11 applications.


title: CAVEATS
content:
<b>Wrapper Script:</b> This command is a helper script, not the core PulseAudio daemon. Troubleshooting audio issues typically requires interacting with the <i>pulseaudio</i> command directly or its configuration files.<br><b>Automatic Startup:</b> In most modern desktop environments, <b>start-pulseaudio-x11</b> (or an equivalent mechanism) is invoked automatically during session startup, so manual execution is rarely needed for normal operation.<br><b>Distribution Specifics:</b> While widely used, some Linux distributions or specific setups might use alternative methods to start PulseAudio, or might not include this exact script.<br><b>X11 Dependency:</b> This command is specifically designed for X11 environments. It is not relevant for Wayland-only sessions, which handle audio integration differently.


title: PURPOSE IN DESKTOP ENVIRONMENTS
content:
<b>start-pulseaudio-x11</b> is primarily utilized by desktop environment session managers (e.g., <i>gnome-session</i>, <i>startkde</i>). It ensures that PulseAudio is initialized correctly with X11 support when a user logs into a graphical session. This setup allows X11 applications to leverage PulseAudio's capabilities, including proper sound output and input, and X11-specific audio events like the system bell.


title: MODULE LOADING
content:
One of the key functions of this wrapper script is to instruct the <i>pulseaudio</i> daemon to load specific X11-related modules. These modules include <i>module-x11-bell</i> (for X11-generated bell sounds), <i>module-x11-cork-request</i> (for X11 clients to request pausing of other streams), and <i>module-x11-publish</i> (for advertising the PulseAudio server to X11 clients). Without these modules, X11 applications might not fully integrate with PulseAudio or could miss out on specific X11 audio features.


title: HISTORY
content:
PulseAudio, initially named Polypaudio, was conceived around 2004 by Lennart Poettering with the goal of providing a modern sound server for Linux and other Unix-like operating systems. It was designed to replace older, simpler sound systems like ESD (Enlightened Sound Daemon) by offering advanced features such as network transparency, per-application volume control, and dynamic device switching. The integration with the X Window System was crucial for its widespread adoption in desktop environments. <b>start-pulseaudio-x11</b> emerged as a standard way to ensure that PulseAudio started correctly within an X session, loading the necessary X11-specific modules to provide system bell sounds and other X11-related audio functionalities. Its development paralleled the growth of desktop environments that relied on X11 for their graphical interface, making it an integral part of the desktop audio stack for many years.


title: PARAMETERS
content:
<b>-s <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run for a specified duration in <i>seconds</i>.<br><br><b>-M <MB></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allocate <i>MB</i> megabytes of memory for testing.<br><br><b>-m <threads></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of memory copy threads to run concurrently.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable CPU stress testing using integer and floating-point operations.<br><br><b>-j <threads></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of CPU stress threads to run.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable disk I/O testing. Requires specifying files with -f.<br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified <i>file</i> (or directory) for disk I/O testing.<br><br><b>-p <threads></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of I/O threads per disk file.<br><br><b>-W</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write and read pseudo-random data patterns to memory for enhanced error detection.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop on the first detected memory or data integrity error.<br><br><b>-x <errors></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit after a specified number of detected <i>errors</i>.<br><br><b>-v <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set verbosity level for output (e.g., 0=quiet, 1=default, 2=verbose).<br><br><b>-t <testname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run a specific test suite, e.g., 'long' or 'memory'.<br><br><b>-o <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write test results and logs to the specified <i>file</i> instead of stdout.<br><br>


title: DESCRIPTION
content:
stressapptest is a powerful, open-source diagnostic tool designed by Google to rigorously test and validate the stability and reliability of system hardware components. It focuses on pushing CPU, cache, memory, and disk I/O subsystems to their limits, simulating heavy workloads that reveal underlying hardware issues. By allocating large amounts of memory, performing complex computations, and executing intensive disk operations, stressapptest can uncover defects such as faulty RAM modules, overheating CPUs, unstable power supplies, or problematic disk drives that might not manifest under normal usage.<br><br>The tool includes robust error detection mechanisms, performing data integrity checks after operations to identify and report any discrepancies. This makes it invaluable for "burn-in" testing new hardware, diagnosing intermittent system crashes, or validating system stability after upgrades. Its comprehensive approach to stress testing helps ensure that systems are robust and reliable even under extreme load conditions.


title: CAVEATS
content:
Using stressapptest can push your system to its absolute limits, potentially leading to system instability, crashes, or even data loss if underlying hardware is faulty.<br><br>It is crucial to run this command on systems where you can afford downtime and data loss, ideally in a controlled testing environment. Monitor system temperatures and performance closely during testing to prevent overheating or other damage. Results interpretation requires technical understanding of hardware health and error messages.


title: <I>ERROR DETECTION MECHANISMS</I>
content:
stressapptest implements sophisticated error detection by writing known data patterns to memory or disk, and then verifying their integrity after operations. This allows it to detect bit flips, corruption, and other anomalies indicative of hardware failures. It logs errors with details like address and expected/actual values, aiding in diagnosis.


title: <I>TYPICAL USAGE SCENARIOS</I>
content:
<br>1. <b>New Hardware Burn-in</b>: Validate the stability of new servers or components before deployment.<br>2. <b>Debugging Intermittent Issues</b>: Uncover elusive crashes or performance problems often caused by unstable hardware.<br>3. <b>Overclocking Stability Testing</b>: Verify system stability after changes to CPU or memory clock speeds.<br>4. <b>System Upgrade Validation</b>: Ensure new RAM or storage devices are functioning correctly and stably with existing hardware.<br>5. <b>Thermal Stress Testing</b>: Identify overheating issues under prolonged heavy load.


title: HISTORY
content:
stressapptest was originally developed by Google engineers as an internal tool to rigorously validate the stability and robustness of server hardware in their data centers. Its primary purpose was to identify subtle hardware defects, particularly in memory and I/O subsystems, that might evade detection during standard quality assurance procedures.<br><br>Recognizing its utility beyond their internal needs, Google subsequently open-sourced stressapptest, making it available to the wider Linux community. This initiative allowed system administrators, hardware developers, and enthusiasts to leverage Google's expertise in hardware validation for their own systems, contributing to more reliable and stable computing environments globally. Its development continues to focus on comprehensive error detection and system stress.


title: SYNOPSIS
content:
strip-nondeterminism [<i>OPTIONS</i>] [<i>FILE...</i>]<br><i>COMMAND</i> | strip-nondeterminism [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b>--remove-timestamps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes timestamps from supported file formats and archive members. This is a common and often default behavior.<br><br><b>--keep-timestamps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the removal of timestamps. Useful when specific timestamps are intended to be preserved.<br><br><b>--sort-entries</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts the entries within archives (e.g., tar, zip) to ensure consistent internal ordering.<br><br><b>--dont-sort-entries</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the sorting of entries within archives.<br><br><b>--remove-locale</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes locale-specific information that might vary between build environments.<br><br><b>--source-date-epoch=<i>DATE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a fixed timestamp (DATE can be an epoch or a date string) for all affected elements, instead of removing them. This can be useful for versioning or auditing.<br><br><b>--list-options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive list of all available options for removing/keeping specific types of non-determinism.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>strip-nondeterminism</i> is a utility designed to help achieve reproducible builds by removing elements from files and archives that can introduce variations between builds. These non-deterministic elements often include file timestamps, user/group IDs, locale information, and the internal ordering of entries within archives (like .zip, .tar, .deb, .rpm files). By standardizing or removing these varying attributes, the command ensures that the same source code processed by the same build tools produces identical binary outputs, regardless of when or where the build occurs. It's a crucial component of the reproducible builds initiative, particularly prominent in Debian and other Linux distributions, enabling verification that distributed binaries precisely match their source code. While it can be used directly on files, <i>strip-nondeterminism</i> is primarily invoked by build automation tools like <i>dpkg-buildpackage</i> to process package components before their final assembly.


title: CAVEATS
content:
<i>strip-nondeterminism</i> can modify files in-place, which can be irreversible. It is primarily intended for use within automated build processes rather than direct interactive use by end-users. Care must be taken when applying it to signed archives, as modifications will invalidate existing digital signatures.


title: PURPOSE OF REPRODUCIBLE BUILDS
content:
This command is a foundational element in the effort to make software builds deterministic. Reproducible builds allow users to verify that the binaries they receive from a distribution were compiled directly from the published source code, without any hidden modifications or backdoors.


title: INTEGRATION WITH BUILD SYSTEMS
content:
Although it can be run manually, <i>strip-nondeterminism</i> is most commonly invoked automatically by package build tools (e.g., <i>dpkg-buildpackage</i> for Debian) during the final stages of package creation, before signing and archiving.


title: HISTORY
content:
<i>strip-nondeterminism</i> emerged as a key utility within the broader "Reproducible Builds" initiative, which gained significant traction in the Debian project around the mid-2010s. The goal was to ensure that any two people building the same source code with the same tools would produce bit-for-bit identical output binaries. This enhances trust, security, and verification. <i>strip-nondeterminism</i> was developed to address common sources of non-determinism, particularly timestamps and archive entry order, which often varied due to build time or system specifics. It is now widely integrated into Debian's package building tools.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the STUN process.<br><br><b>--port=<port>, -p <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the STUN server port. The default is usually 3478.<br><br><b>--bind=<address>, -b <address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bind to a specific local IP address for outgoing connections.<br><br><b>--interface=<interface>, -i <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bind to a specific network interface.<br><br><b>--full-nat-test, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a comprehensive NAT behavior test, which might involve multiple queries to determine the exact NAT type (e.g., Full Cone, Restricted Cone, Port Restricted Cone, Symmetric NAT).<br><br><b>--username=<username>, -u <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a username for STUN authentication.<br><br><b>--password=<password>, -w <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a password for STUN authentication.<br><br>


title: DESCRIPTION
content:
STUN (Session Traversal Utilities for NAT) is a protocol that allows applications operating behind a Network Address Translator (NAT) to discover their public IP address and the type of NAT they are behind. The <b>stun</b> command (typically implemented as <b>stunclient</b>) facilitates this discovery by sending requests to a STUN server.<br><br>The server responds with the client's observed public IP address and port, enabling the client to understand how the NAT modifies its connections. This information is crucial for establishing direct peer-to-peer communication, especially in Voice over IP (VoIP), video conferencing, and online gaming, where endpoints need to know each other's reachable addresses. Without STUN, applications behind complex NATs might struggle to establish direct connections, often resorting to relay servers, which add latency and consume bandwidth.


title: CAVEATS
content:
<br>The "stun" command is most commonly implemented as <b>stunclient</b> on Linux systems. It requires a functioning STUN server to query.<br><br>While STUN helps in many NAT scenarios, it is less effective with Symmetric NATs, which change the mapped port for each new destination. For such complex NATs, TURN (Traversal Using Relays around NAT) might be required, which involves relaying media through a server.<br><br>The exact options and their behavior might vary slightly depending on the specific <b>stunclient</b> implementation or version installed (e.g., from <i>libnice-tools</i> or <i>stuntman</i> packages).


title: EXAMPLE USAGE
content:
To test your NAT type against a public STUN server (e.g., <i>stun.l.google.com:19302</i>), you would typically run: <br> <b>stunclient</b> <i>stun.l.google.com</i> <br>Or, for a more detailed test: <br> <b>stunclient</b> <i>-f stun.l.google.com</i> <br>The output will usually show your observed external IP address and the detected NAT type.


title: OUTPUT INTERPRETATION
content:
The <b>stunclient</b> output typically indicates the 'Mapped Address' (your public IP and port) and the 'NAT Type' (e.g., 'Full Cone', 'Restricted Cone', 'Port Restricted Cone', or 'Symmetric NAT'). Understanding your NAT type helps in configuring applications for optimal peer-to-peer connectivity.


title: HISTORY
content:
<br>The Session Traversal Utilities for NAT (STUN) protocol was originally specified in RFC 3489 in 2003, with an updated, more robust version defined in RFC 5389 in 2008. Its development was driven by the increasing need for applications like VoIP and peer-to-peer file sharing to function reliably behind NAT devices, which became ubiquitous with the rise of broadband internet. Early implementations of STUN clients and servers emerged to address these connectivity challenges, making it a fundamental component in many real-time communication protocols like SIP and WebRTC. The <b>stunclient</b> utility became a common command-line tool for developers and network administrators to test and understand NAT traversal behavior.


title: PARAMETERS
content:
<b>-d <domain></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target domain for subdomain enumeration. This is a mandatory parameter.<br><br><b>-p <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port for HTTP/HTTPS connectivity checks. Default is 80, 443.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during the scan.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the brute-force module, requiring a wordlist to be specified or using a default one.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of all enumeration modules, including potentially slower ones.<br><br><b>-e <engine></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects specific search engines or services to query. Example: google,yahoo,bing.<br><br><b>-o <output_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the discovered subdomains to the specified output file.<br><br><b>-t <threads></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the number of threads for DNS resolution and brute-force tasks.<br><br><b>--no-bruteforce</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly disables the brute-force module (default behavior).<br><br><b>--no-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents saving results to a file, even if <I>-o</I> is used (useful for piping output).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and available options.<br><br>


title: DESCRIPTION
content:
<I>sublist3r</I> is a Python-based tool designed to enumerate subdomains of websites using various search engines and services, as well as an optional brute-force approach. It's widely used by penetration testers, bug bounty hunters, and security researchers to discover potential attack surface extensions. <br><br>The tool leverages passive sources like Google, Yahoo, Bing, Baidu, Ask, Netcraft, DNSdumpster, Virustotal, ThreatCrowd, and Crt.sh to gather subdomains without sending direct requests to the target domain's DNS servers, making it stealthier. Additionally, it offers a brute-force module that can be used with a custom wordlist to identify subdomains that might not be publicly indexed. Its multi-threaded nature allows for efficient and fast scanning. The results can be displayed in real-time or saved to a file for further analysis.


title: CAVEATS
content:
<I>sublist3r</I>'s reliance on public search engines means it can be subject to rate limiting, CAPTCHAs, or IP blocking by these services, especially during intensive or repeated use. The effectiveness of passive enumeration depends heavily on the indexing quality of the search engines. Brute-forcing, while effective, can be noisy and time-consuming, and its success depends entirely on the quality of the provided wordlist. Users should be aware of ethical hacking guidelines and obtain proper authorization before scanning any domain.


title: INSTALLATION
content:
<I>sublist3r</I> is a Python-based tool and can typically be installed by cloning its repository and installing dependencies:<br><br> `git clone https://github.com/aboul3la/Sublist3r.git`<br> `cd Sublist3r`<br> `pip install -r requirements.txt`<br> `python sublist3r.py -d example.com`<br><br>Some distributions might offer it through their package managers as well.


title: OUTPUT FORMAT
content:
By default, <I>sublist3r</I> outputs the discovered subdomains to standard output, one subdomain per line. When the <I>-o</I> option is used, the output file will contain the subdomains in a similar newline-separated format.


title: HISTORY
content:
<I>sublist3r</I> was developed by Ahmed Aboul-Ela as a fast and simple tool to enumerate subdomains. It gained popularity in the security community due to its efficiency and ability to combine various passive reconnaissance techniques with an optional active brute-force approach. Its open-source nature and Python implementation made it easy to integrate into broader security workflows and contribute to its ongoing development and maintenance by the community.


title: SYNOPSIS
content:
As <b>sui</b> is not a standard command in modern Linux, a direct synopsis for <b>sui</b> does not exist. If referring to <b>sudo</b>, a concise synopsis is: <br><b>sudo</b> [<i>options</i>] <i>command</i> [<i>arguments...</i>]<br>or for listing permissions: <br><b>sudo</b> [<i>-lLAnvV</i>]


title: PARAMETERS
content:
<b>-u <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command as the specified <i>user</i> instead of the default target user (usually <b>root</b>).<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the target user's password database entry as a login shell. This simulates a full login session.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the <b>SHELL</b> environment variable of the calling user. Often used for running a sub-shell with elevated privileges.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the commands allowed for the current user on the current host. Can be combined with <b>-U</b> to check another user's permissions.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Revoke the user's cached credentials. The next <b>sudo</b> command will require a password.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in the background. The user's password may be required before the command is run.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the <b>HOME</b> environment variable to the target user's home directory instead of leaving it as the invoking user's <b>HOME</b>.<br><br><b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to be executed with elevated or specified user privileges.<br><br><b><i>arguments...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any arguments that are passed to the <i>command</i> being executed.<br><br>


title: DESCRIPTION
content:
The command <b>sui</b> is <i>not</i> a standard or widely recognized utility in modern Linux distributions. Its appearance in contexts often points to a typographical error, most commonly for <b>sudo</b>. <b>sudo</b> (<i>superuser do</i>) is a crucial command that allows a permitted user to execute a command as the superuser or another user, as specified by the system's security policy. It provides a more granular and secure method for privilege elevation compared to directly using <b>su</b> or logging in as <b>root</b>, by enforcing accountability and logging of privileged operations. While <b>sui</b> has been historically linked to obscure "Start Up Interface" utilities in very old Unix systems (like System V Release 4), this usage is obsolete and irrelevant to contemporary Linux. For the purpose of this analysis, the information provided below pertains to <b>sudo</b>, which is the likely intended command when <b>sui</b> is encountered.


title: CAVEATS
content:
The command <b>sui</b> is <i>not</i> a standard Linux utility. Attempting to use it will likely result in a "command not found" error. All information provided in this analysis regarding functionality, synopsis, and parameters refers to the `<b>sudo</b>` command, which is often mistakenly typed as `<b>sui</b>`. Proper configuration of `<b>sudo</b>` through the `<b>/etc/sudoers</b>` file (using `<b>visudo</b>`) is critical for security and system stability; incorrect entries can lead to serious security vulnerabilities or prevent legitimate users from performing necessary tasks.


title: CONFIGURATION (SUDOERS)
content:
The behavior of `<b>sudo</b>` is controlled by the `<b>/etc/sudoers</b>` file. This file specifies which users or groups can execute which commands, from which terminals, and under what conditions (e.g., without a password). It is strongly recommended to edit this file using the `<b>visudo</b>` command, which provides syntax checking and prevents common errors that could lock out privileged users.


title: SECURITY AND LOGGING
content:
`<b>sudo</b>` enhances security by allowing administrators to grant specific users only the necessary privileges for specific tasks, rather than giving them full `<b>root</b>` access. It also logs all commands executed via `<b>sudo</b>`, providing an audit trail of privileged operations, which is crucial for accountability and security monitoring.


title: HISTORY
content:
As <b>sui</b> is not a standard command, it has no direct development history within modern Linux. The `<b>sudo</b>` command, which `<b>sui</b>` often refers to due to typo, was originally written by Robert Coggeshall and Cliff Spencer in 1980 at the Department of Computer Science at SUNY Buffalo. It was significantly rewritten by Todd C. Miller starting in 1993, evolving into the ubiquitous tool it is today. Its development has focused on providing granular control over privileged access, extensive logging, and robust security features, making it an indispensable part of Unix-like operating systems for secure administration.


title: SYNOPSIS
content:
sui-client [GLOBAL_OPTIONS] <SUBCOMMAND> [SUBCOMMAND_OPTIONS] [ARGS]<br><br>Examples of common subcommands:<br><i>sui-client active-address</i><br><i>sui-client gas</i><br><i>sui-client object <OBJECT_ID></i><br><i>sui-client call --function <FUNCTION_NAME> --module <MODULE_NAME> --package <PACKAGE_ID> --args <ARGS...> --gas-budget <AMOUNT></i><br><i>sui-client transfer --to-address <ADDRESS> --amount <AMOUNT> --sui-coin <SUI_OBJECT_ID> --gas-budget <AMOUNT></i>


title: PARAMETERS
content:
<b>--client.config <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the path to the client configuration file, typically a YAML file.</i><br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output results in JSON format, which is useful for scripting and programmatic parsing.</i><br><br><b>--rpc <URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the default RPC server URL to connect to a specific Sui network endpoint.</i><br><br><b>--faucet <URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the default faucet server URL for requesting test SUI tokens.</i><br><br><b>--gas-budget <AMOUNT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the maximum gas budget for a transaction in MIST (1 SUI = 1,000,000,000 MIST).</i><br><br><b>--sign</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sign the transaction without executing it, returning the signed transaction data.</i><br><br><b>--serialize-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Serialize the output for programmatic use, often in conjunction with --json.</i><br><br><b>--to-address <ADDRESS></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The recipient's Sui address for transfer operations.</i><br><br><b>--sui-coin <OBJECT_ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The object ID of the SUI coin to be used for gas payment or transfer.</i><br><br><b>--amount <AMOUNT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The amount of SUI or other asset to transfer or interact with.</i><br><br><b>--package <PACKAGE_ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The package ID of the Move smart contract to interact with (e.g., for calling functions).</i><br><br>


title: DESCRIPTION
content:
The <b>sui-client</b> command-line interface (CLI) is an essential tool for developers and users to interact with the Sui blockchain. It provides comprehensive functionalities for managing Sui addresses, querying the blockchain state (including objects, transactions, and events), publishing and executing Move smart contracts, and securely transferring assets. It connects to a Sui RPC endpoint, enabling a wide range of operations such as gas management, object manipulation, transaction signing, and network synchronization. With its modular design, supporting various subcommands for specific tasks, <b>sui-client</b> serves as a pivotal component for participation and development within the Sui ecosystem.


title: CAVEATS
content:
<b>Network Connectivity:</b> Requires a stable internet connection to communicate with Sui RPC endpoints.<br><b>Configuration:</b> Proper client configuration, typically in `client.yaml`, is crucial for connecting to the correct network (devnet, testnet, mainnet) and managing cryptographic keys.<br><b>Gas Fees:</b> All transactions on the Sui network incur gas fees, which must be managed through your wallet. Insufficient gas will lead to transaction failures.<br><b>Key Management:</b> Secure handling of private keys and mnemonic phrases is paramount, as they control access to your funds and assets on the Sui network.


title: NETWORKS AND CONFIGURATION
content:
<b>sui-client</b> typically reads its configuration from a `client.yaml` file, which specifies the RPC endpoint, faucet URL, and the active keypair. Users can switch between different Sui networks (e.g., devnet, testnet, mainnet) by modifying this configuration file or by using specific command-line flags like `--rpc` and `--faucet`.


title: MOVE LANGUAGE INTERACTION
content:
A core capability of <b>sui-client</b> is its deep integration with the Move programming language. It allows users to compile, publish, and interact with Move smart contracts deployed on the Sui network, facilitating the development and deployment of decentralized applications (dApps) and custom assets.


title: HISTORY
content:
The <b>sui-client</b> command is an integral part of the Sui blockchain ecosystem, originally developed by Mysten Labs. It was introduced alongside the initial releases of the Sui network, evolving significantly with the network's development from its early devnet and testnet phases to its mainnet launch. Its design prioritizes ease of interaction for both developers building on Sui and users managing their digital assets within the ecosystem.


title: SEE ALSO
content:
curl(1): <i>Used for direct interaction with RPC endpoints.</i>, jq(1): <i>Useful for parsing JSON output from `sui-client --json`.</i>, git(1): <i>Often used to clone Sui source code or Move projects.</i>


title: PARAMETERS
content:
<b><I>SUBCOMMANDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific action to perform related to Programmable Transaction Blocks. Common PTB-related subcommands typically include:<br><br><B>build</B>: Used to construct a PTB from a high-level plan or a sequence of commands, which can then be serialized.<br><B>execute</B>: Submits a previously built (and potentially signed) PTB to the Sui network for execution.<br><B>dry-run</B>: Simulates the execution of a PTB without committing it to the network. This provides an estimate of gas costs and potential outcomes, useful for debugging.<br><B>sign</B>: Generates a digital signature for a transaction digest or a serialized PTB, often required before submission to the network.<br><br><b>--gas-budget <I>amount</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum gas budget (in SUI units) that can be spent on the transaction. The transaction will fail if its actual gas consumption exceeds this amount.<br><br><b>--gas-payment <I>object_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the object ID of a SUI coin to be used as payment for gas fees. If omitted, the client will automatically select a suitable SUI coin from the active address's wallet.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the command's result in a structured JSON format, making it easier for scripts and other programs to parse the output.<br><br><b>--rpc <I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the Sui RPC (Remote Procedure Call) endpoint to connect to. This overrides the default or configured RPC URL.<br><br><b>--ws <I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the Sui WebSocket endpoint, typically used for real-time subscription services. This overrides the default or configured WS URL.<br><br><b>--sender <I>address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the sender address for the transaction. If not provided, the command defaults to the active address configured in the Sui client's configuration file.<br><br><b>--profile <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific profile from the Sui client configuration. Profiles can contain different RPC URLs, active addresses, and keypairs.<br><br>


title: DESCRIPTION
content:
The <B>sui-client-ptb</B> command-line utility provides a specialized interface for interacting with the Sui blockchain network, with a primary focus on <I>Programmable Transaction Blocks</I> (PTBs). PTBs are a core feature of Sui, enabling users to bundle multiple operations (e.g., asset transfers, object mutations, contract function calls) into a single, atomic, and deterministic transaction. This command empowers developers and advanced users to construct, simulate, sign, and execute complex transaction sequences, leveraging Sui's unique Move object model and efficient gas mechanics. It is an essential tool for building sophisticated decentralized applications, automating blockchain interactions, and managing Sui assets with granular control over transaction logic.


title: CAVEATS
content:
The <B>sui-client-ptb</B> command is an application-specific utility of the Sui blockchain ecosystem and is not a standard Linux system command. It requires a connection to a running Sui network (e.g., local, devnet, testnet, or mainnet). Effective use of this command demands familiarity with Sui's object model, the Move programming language, and the intricate structure of Programmable Transaction Blocks. The exact set of available subcommands and options may vary based on the specific version and build of the Sui client software.


title: PROGRAMMABLE TRANSACTION BLOCKS (PTBS)
content:
PTBs on Sui are a sequence of commands that are executed atomically and deterministically. They allow for highly intricate logic to be performed in a single transaction, encompassing actions like transferring objects, calling arbitrary Move functions, creating new objects, and manipulating existing ones. This design enables highly expressive and efficient interactions with the Sui blockchain, significantly simplifying the development of complex decentralized applications by reducing the need for multiple, independent transactions.


title: GAS AND TRANSACTION FEES
content:
All operations on the Sui network consume 'gas,' which is paid in SUI tokens. PTBs enable precise gas budgeting, allowing users to set a maximum limit for transaction costs. It is crucial for users to ensure their account has sufficient SUI to cover the estimated gas fees. The <B>dry-run</B> subcommand is an invaluable tool for estimating the gas consumption of a PTB before its actual execution, helping to prevent failed transactions due to insufficient funds.


title: HISTORY
content:
Programmable Transaction Blocks (PTBs) were introduced as a foundational and differentiating feature of the Sui blockchain early in its development. They represent Sui's innovative approach to achieving atomic, composable transactions, offering developers unprecedented flexibility in defining complex interactions. The <B>sui-client-ptb</B> (or its integrated functionality within the broader <I>sui client</I> command) was developed to provide a direct command-line interface for interacting with and leveraging this powerful capability, evolving continuously alongside the Sui network itself.


title: PARAMETERS
content:
<b>-c <I>CONFIG_FILE</I> | --configuration=<I>CONFIG_FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the configuration file. Default is usually <i>/etc/supervisord.conf</i> or <i>supervisord.conf</i> in the current directory.<br><br><b>-n | --nodaemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>supervisord</b> in the foreground instead of daemonizing. Useful for debugging or when running under a process manager like <i>systemd</i>.<br><br><b>-d | --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging, providing more verbose output to the console or log file.<br><br><b>-h | --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v | --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version number of <b>supervisord</b> and exits.<br><br><b>--minfds=<I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum number of file descriptors that <b>supervisord</b> requires to run.<br><br><b>--minprocs=<I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum number of processes that <b>supervisord</b> requires to run.<br><br><b>--username=<I>USER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user to run <b>supervisord</b> as after startup. Requires root privileges to start.<br><br><b>--identifier=<I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a unique identifier for the <b>supervisord</b> instance, useful when running multiple instances.<br><br><b>--noreload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>supervisord</b> from reloading its configuration upon receiving a SIGHUP signal.<br><br><b>--pidfile=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the PID file where <b>supervisord</b> will write its process ID.<br><br><b>--logfile=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the log file for <b>supervisord</b>'s own logging.<br><br><b>--loglevel=<I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level for <b>supervisord</b> (e.g., <i>CRITICAL</i>, <i>ERROR</i>, <i>WARN</i>, <i>INFO</i>, <i>DEBUG</i>, <i>BLATHER</i>).<br><br><b>--strip-section-headers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used internally, removes section headers from configuration output.<br><br>


title: DESCRIPTION
content:
<b>supervisord</b> is the daemon component of the Supervisor process control system. It allows users to monitor and control a number of processes on UNIX-like operating systems. Its primary purpose is to keep long-running programs running reliably by automatically restarting them if they crash or exit unexpectedly. <b>supervisord</b> manages processes as "programs" defined in its configuration file, typically <i>supervisord.conf</i>.<br><br>Key features include the ability to group processes, handle process events, and provide a command-line client (<i>supervisorctl</i>) and an HTTP web interface for interaction. It also exposes an XML-RPC interface for programmatic control. <b>supervisord</b> runs as a single process and forks child processes for each configured program, managing their lifecycle and ensuring they remain in the desired state. It's widely used in web development and backend services to ensure application stability and uptime without manual intervention. It excels at managing non-daemonizing processes, allowing them to run reliably in the background.


title: CAVEATS
content:
While <b>supervisord</b> is excellent for managing application processes, it is generally <I>not</I> intended to be the primary init system or a replacement for <i>systemd</i>, <i>Upstart</i>, or traditional <i>init</i> scripts. It should be started by one of these system-level tools at boot. It is also primarily designed for controlling non-daemonizing programs; programs that daemonize themselves (<i>fork()</i> and <i>exit()</i>) can be managed but require specific configuration (e.g., <i>redirect_stderr=true</i>, <i>stdout_logfile=</i>) to prevent <b>supervisord</b> from losing track of them.


title: CONFIGURATION FILE (<I>SUPERVISORD.CONF</I>)
content:
The core of <b>supervisord</b>'s operation lies in its configuration file. This INI-like file defines the programs to be managed, their startup commands, working directories, environment variables, auto-restart behavior, logging settings, and more. It also specifies <b>supervisord</b>'s own settings, such as PID file location, log file, and <i>[inet_http_server]</i> details for the web UI.


title: INTERACTION WITH <I>SUPERVISORCTL</I>
content:
<b>supervisorctl</b> is the essential command-line client used to interact with a running <b>supervisord</b> instance. It allows users to start, stop, restart, and get the status of individual programs or entire groups of programs. It also supports commands for reloading the configuration, shutting down <b>supervisord</b>, and displaying logs, providing full control over the managed processes without directly interacting with the daemon.


title: HISTORY
content:
Supervisor, including <b>supervisord</b>, was originally developed by Chris McDonough and is written in Python. It emerged as a solution for reliably running and monitoring long-lived processes, especially in the context of web application servers (like Gunicorn, uWSGI) and worker processes (like Celery). Its development aimed to provide a simpler, more robust alternative to complex shell scripts or relying solely on <i>init</i> systems for application-level process management. Its popularity grew due to its ease of configuration, cross-platform compatibility (within UNIX-like systems), and the flexibility offered by its client and API interfaces. It has become a de facto standard for process management in many Python, Node.js, and PHP environments.


title: PARAMETERS
content:
<b><b>-browser</b> <i>&lt;browser&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the web browser to use (e.g., <i>firefox</i>, <i>chromium</i>, <i>lynx</i>, <i>w3m</i>). This overrides the default browser set by environment variables.<br><br><b><b>-text-browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <i>surfraw</i> to use a text-based web browser, ignoring any default graphical browser settings.<br><br><b><b>-graphical-browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <i>surfraw</i> to use a graphical web browser, ignoring any default text-based browser settings.<br><br><b><b>-q</b>, <b>--quick</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a quick search without prompting for additional options, if the selected ELVI supports it. Useful for non-interactive use.<br><br><b><b>-u</b>, <b>--unsafe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow unsafe (non-URL-encoded) characters in the query string. Use with caution, as it may break some searches.<br><br><b><b>-w</b>, <b>--url</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the generated URL to standard output instead of opening a web browser. Useful for debugging or scripting.<br><br><b><b>-elvi</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available <i>Surfraw</i> ELVIs (search engines/modules) that can be used.<br><br><b><b>-elvi-info</b> <i>&lt;elvi&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about a specific ELVI, including its usage and supported options.<br><br><b><b>-dmenu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>dmenu</i> (or a similar tool) to interactively select an ELVI from a list. Requires <i>dmenu</i> to be installed.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief usage message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information about <i>surfraw</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>Surfraw</i> (Surf Raw Access to the Web) is a powerful collection of shell scripts designed to provide a quick and efficient way to query various online services directly from your terminal. It acts as a front-end to a wide range of search engines, encyclopedias, news sites, and other web resources, allowing users to perform searches without manually opening a browser and navigating to a search page.<br><br>When you invoke <i>surfraw</i> with a specific "elvi" (<i>Surfraw</i> ELVIs are its search engines/modules), it constructs the appropriate URL and then opens it in your preferred web browser (graphical or text-based). This makes it ideal for rapid information retrieval, scripting, and for users who prefer a command-line centric workflow. It supports hundreds of "elvi" out-of-the-box, from popular search engines like Google and DuckDuckGo to specialized sites like Wikipedia, IMDb, and various package managers.


title: CAVEATS
content:
<i>Surfraw</i> requires a web browser (graphical or text-based) to be installed and configured on your system. Its functionality depends on the stability of the target websites' URL structures; changes on the website's side might break an ELVI. Configuration often involves setting environment variables or editing shell scripts.


title: ELVIS (EXTERNAL LINKS, VIA INTERFACING)
content:
The core strength of <i>Surfraw</i> lies in its 'elvi', which are modular shell scripts, each designed to interface with a specific online service (e.g., Google, Wikipedia, IMDb). Users can easily discover existing elvi using <b>surfraw -elvi</b> or create custom ones to extend functionality to any web service that uses predictable URL patterns for searches.


title: CONFIGURATION
content:
<i>Surfraw</i>'s behavior can be extensively customized. Users can set default browsers, preferred ELVIs, and other options through environment variables (like <b>SR_BROWSER</b>, <b>SR_TEXT_BROWSER</b>, <b>SR_GRAPHICAL_BROWSER</b>) or by creating a personal configuration file (typically <i>~/.surfrawrc</i> or <i>~/.config/surfraw/conf</i>), which allows for persistent settings across sessions.


title: HISTORY
content:
<i>Surfraw</i> was originally created by Greg Ward in 2000, aiming to provide a lightweight and fast command-line interface to web search engines. Its design emphasized extensibility through "elvi" (External Links, Via Interfacing), which are individual scripts for each search resource. Over the years, it has been actively maintained and expanded by a community of contributors, incorporating new search engines and improving functionality, making it a staple for command-line power users.


title: SYNOPSIS
content:
svn <b>changelist</b> [--remove] [--depth <i>ARG</i>] [--targets <i>ARG</i>] [--xml] [--quiet] [--changelist <i>ARG</i>] <i>PATH...</i>


title: PARAMETERS
content:
<b>--remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disassociates the specified <i>PATHs</i> from any changelist they are currently associated with.<br><br><b>--depth <i>ARG</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the depth of the operation for directory targets. Possible values include <i>empty</i>, <i>files</i>, <i>immediates</i>, and <i>infinity</i>.<br><br><b>--targets <i>ARG</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads target paths from the specified file, one path per line, instead of from the command line.<br><br><b>--xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces output in XML format, suitable for programmatic parsing.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output, showing only errors.<br><br><b>--changelist <i>ARG</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the changelist to associate files with. This option is required when adding files to a changelist.<br><br><b><i>PATH...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths (files or directories) in the working copy to apply the changelist operation to.<br><br>


title: DESCRIPTION
content:
The <b>svn-changelist</b> command refers to the functionality provided by the <b>svn changelist</b> subcommand within the Subversion (SVN) version control system. It is used to logically group files and directories in a working copy into named changelists. This allows users to organize related modifications for different tasks or features, improving the clarity and granularity of subsequent operations like commits.<br><br>Changelists are local to the working copy and do not affect the repository until the files within them are committed. Files can only belong to one changelist at a time, providing a flexible way to manage complex local changes.


title: CAVEATS
content:
Changelists are a local-only feature of Subversion working copies and are not versioned or transmitted to the repository. They serve solely to organize local changes before committing. A file can belong to only one changelist at any given time.


title: WORKFLOW INTEGRATION
content:
Changelists are primarily used to filter the scope of other SVN operations. For instance, the <b>svn commit</b> command can be used with the <b>--changelist</b> option to commit only those files associated with a specific changelist, e.g., <i>svn commit --changelist 'my-feature-changes'</i>. Similarly, <b>svn status</b> can display or filter by changelist associations, providing a clear overview of grouped modifications.


title: HISTORY
content:
The changelist feature was introduced in Subversion 1.5.0, released in 2008. It was a significant addition designed to help users manage and organize their local working copy changes more effectively, especially for complex development workflows or when dealing with large sets of modifications. Before its introduction, users had to manually keep track of related changes, which could lead to errors or less granular commits. The design decision to keep changelists local to the working copy prioritized flexibility and ease of use over repository-level tracking.


title: PARAMETERS
content:
<b>--fido2-device=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the FIDO2 device path (e.g., <I>auto</I> or <I>/dev/hidrawX</I>).<br><br><b>--fido2-with-client-pin=BOOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require a client PIN for FIDO2 authentication.<br><br><b>--fido2-with-user-verification=BOOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require user verification (e.g., fingerprint, PIN) for FIDO2.<br><br><b>--fido2-with-hmac-secret=BOOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use HMAC-Secret extension for FIDO2 (recommended for disk encryption).<br><br><b>--fido2-with-user-presence=BOOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require user presence (e.g., touch) for FIDO2.<br><br><b>--tpm2-device=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the TPM2 device path (e.g., <I>auto</I> or <I>/dev/tpmrm0</I>).<br><br><b>--tpm2-pcrs=PCRS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List of PCRs (Platform Configuration Registers) to seal to (e.g., <I>0+2+7</I>).<br><br><b>--tpm2-set-pkcs11-token=BOOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a PKCS#11 token for the TPM2-protected key slot.<br><br><b>--recovery-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate and enroll a new recovery key.<br><br><b>--wipe-slot=SLOT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wipe a specific key slot by its number.<br><br><b>--wipe-fido2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wipe all FIDO2 credentials from the LUKS volume.<br><br><b>--wipe-tpm2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wipe all TPM2 credentials from the LUKS volume.<br><br><b>--wipe-recovery-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wipe all recovery keys from the LUKS volume.<br><br><b>--wipe-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wipe all credentials (all FIDO2, TPM2, recovery keys, and optionally passwords).<br><br><b>--unlock-key-slot=SLOT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a key slot to unlock the LUKS volume for enrollment (e.g., for password-based keys).<br><br><b>--password</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a password for enrollment (prompts for it).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without making any actual changes.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b>--no-legend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the column legend.<br><br><b>--json=MODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in JSON format for scripting.<br><br>


title: DESCRIPTION
content:
systemd-cryptenroll is a command-line utility designed to manage security credentials for <I>LUKS2 encrypted volumes</I>, particularly integrating with the <I>systemd</I> ecosystem. Its primary function is to enroll or remove advanced unlock methods such as <B>FIDO2 security tokens</B>, <B>TPM2 (Trusted Platform Module) devices</B>, and <B>recovery keys</B>. This allows for unlocking encrypted disks at boot time, either manually or automatically (e.g., using TPM2 sealing with specific PCRs linked to Secure Boot policies).<br><br>While it can technically add password-based keys, `cryptsetup luksAddKey` is generally preferred for that purpose. systemd-cryptenroll excels in scenarios requiring hardware-backed authentication or dedicated recovery mechanisms, simplifying the management of these complex unlock methods within a systemd-managed environment. It supports both adding new credentials and selectively wiping existing ones from LUKS key slots.


title: CAVEATS
content:
systemd-cryptenroll specifically supports <I>LUKS2 volumes</I>; it will not work with LUKS1. It relies on the presence of underlying libraries like <I>libfido2</I> and <I>tpm2-tools</I> for its advanced functionalities. While it can manage password-based keys, `cryptsetup luksAddKey` is generally the more direct and traditional tool for that purpose. Ensure the specified FIDO2 or TPM2 device is accessible and correctly configured.


title: SECURITY CONSIDERATIONS
content:
Using TPM2 with PCRs provides strong binding to the system's boot state, preventing unauthorized decryption if the system configuration changes. FIDO2 tokens offer robust multi-factor authentication. Always store recovery keys securely in an offline location.


title: DEVICE SPECIFICATION
content:
The <I>DEVICE</I> argument can be a path to a block device (e.g., <I>/dev/sda1</I>) or a UUID (e.g., <I>UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</I>).


title: KEY SLOT MANAGEMENT
content:
LUKS volumes have multiple key slots. `systemd-cryptenroll` can use an existing key (e.g., a password) to unlock the volume and then add a new credential into an available slot, or wipe specific slots.


title: HISTORY
content:
systemd-cryptenroll emerged as part of the broader <I>systemd</I> initiative to streamline and integrate system-level functionalities, including disk encryption. Its development reflects a move towards more robust and automated boot processes, particularly for systems utilizing hardware security modules like TPMs and FIDO2 devices. It provides a more modern and systemd-aware approach to managing LUKS key material compared to the traditional `cryptsetup` commands, focusing on advanced cryptographic token integration.


title: SYNOPSIS
content:
<b>systemd-hwdb</b> [<i>OPTIONS...</i>] [<i>COMMAND</i>] [<i>ARGUMENTS...</i>]<br><br>Common commands include:<br><b>systemd-hwdb</b> <B>update</B> [<i>--usr</i>|<i>--etc</i>] [<i>--root=PATH</i>]<br><b>systemd-hwdb</b> <B>query</B> [<i>MODALIAS...</i>]<br><b>systemd-hwdb</b> <B>print-all</B>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information and exits.<br><br><b><b>--usr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with the <B>update</B> command, compiles the database to <B>/usr/lib/udev/hwdb.bin</B>.<br><br><b><b>--etc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with the <B>update</B> command, compiles the database to <B>/etc/udev/hwdb.bin</B>. This is the default location for local modifications.<br><br><b><b>--root=PATH</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative root directory for searching source <I>.hwdb</I> files and compiling the database.<br><br><b><b>-p</b>, <b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the output of the <B>query</B> command into human-readable key=value pairs.<br><br><b><b>-s</b>, <b>--separator=CHARACTER</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom character to separate properties when querying. Defaults to a newline character (<B>\n</B>).<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug messages during execution.<br><br>


title: DESCRIPTION
content:
The <I>systemd-hwdb</I> command is a utility used to manage the hardware database (hwdb) employed by <I>udev</I> and, consequently, <I>systemd</I>.<br><br>Its primary functions include compiling the source <I>.hwdb</I> files into a binary database, <B>hwdb.bin</B>, and querying this database for specific hardware properties. This database is crucial for identifying various hardware components and applying configuration settings such as keyboard layouts, accelerometer orientations, or touchscreen calibrations.<br><br>Source files are typically found in <B>/usr/lib/udev/hwdb.d/</B> and <B>/etc/udev/hwdb.d/</B>. When <I>systemd-hwdb</I> is used to update the database, it compiles these text files, which contain rules matching hardware identifiers (like PCI IDs or USB IDs) to property key-value pairs. The resulting <B>hwdb.bin</B> file is then used by <I>udev</I> to automatically configure devices as they are detected.<br><br>Any modifications to the <I>.hwdb</I> source files necessitate running <I>systemd-hwdb update</I> to recompile the database. For these changes to take effect on already-plugged-in devices, a <I>udevadm trigger</I> or <I>udevadm control --reload-rules</I> command is often required.


title: CAVEATS
content:
After modifying <I>.hwdb</I> source files, it is crucial to run <B>systemd-hwdb update</B> to recompile the database.<br><br>For changes to take effect on devices that are already plugged in, you often need to instruct <I>udev</I> to re-process events or reload its rules, typically using <B>udevadm trigger</B> or <B>udevadm control --reload-rules</B>.<br><br>Custom <I>.hwdb</I> files placed in <B>/etc/udev/hwdb.d/</B> will override or extend system-provided files in <B>/usr/lib/udev/hwdb.d/</B>, allowing for local customizations.


title: COMMANDS
content:
Beyond its options, <I>systemd-hwdb</I> supports several commands to perform specific actions:<br><br><b><I>update</I></b>: Compiles the hardware database from all <I>.hwdb</I> source files found in configured directories (e.g., <B>/usr/lib/udev/hwdb.d/</B> and <B>/etc/udev/hwdb.d/</B>) into a binary <B>hwdb.bin</B> file.<br><br><b><I>query</I></b> <I>[MODALIAS...]</I>: Queries the compiled hardware database for properties matching the provided <I>MODALIAS</I> strings. <I>MODALIAS</I> is a string representing a device's hardware identification.<br><br><b><I>print-all</I></b>: Dumps the entire contents of the compiled hardware database to standard output, showing all stored properties for all matched hardware identifiers.


title: HARDWARE DATABASE FILES (.HWDB)
content:
The hardware database is populated by text files with the <B>.hwdb</B> extension. These files contain rules that map hardware identifiers (such as vendor/product IDs for PCI, USB, or DMI) to device properties. Each entry typically starts with a matching rule, followed by key-value pairs. For instance, a rule might identify a specific keyboard model and assign properties like <B>KEYBOARD_KEY_a=a_new_scan_code</B> or <B>ACCEL_MOUNT_MATRIX=...</B> to correct sensor orientations. These files are processed by <I>systemd-hwdb</I> during the update process to create the efficient binary database.


title: HISTORY
content:
The <I>systemd-hwdb</I> utility is an integral part of the <B>systemd</B> ecosystem. It was introduced as part of <B>systemd</B>'s broader efforts to unify and standardize Linux system management, particularly its hardware device management components inherited from <B>udev</B>. Its development aligns with the evolution of <B>udev</B> from a separate project into a core component of <B>systemd</B>, providing a consistent mechanism for handling hardware properties and configuration.


title: PARAMETERS
content:
<b>start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the <b>systemd-logind.service</b>.<br><br><b>stop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the <b>systemd-logind.service</b>. Use with caution as it will disrupt user sessions.<br><br><b>restart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts the <b>systemd-logind.service</b>.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current status of the <b>systemd-logind.service</b>, including its activity and recent logs.<br><br><b>enable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the <b>systemd-logind.service</b> to start automatically at boot.<br><br><b>disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the <b>systemd-logind.service</b> from starting automatically at boot.<br><br><b>reload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads the <b>systemd-logind.service</b> configuration (if applicable without restarting the service).<br><br><b>mask</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Masks the <b>systemd-logind.service</b>, preventing it from being started manually or by other services.<br><br><b>unmask</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unmasks the <b>systemd-logind.service</b>, allowing it to be started again.<br><br>


title: DESCRIPTION
content:
The <b>systemd-logind.service</b> is a core systemd service responsible for managing user logins, sessions, and seat devices. It acts as an intermediary between the kernel's TTY and input layer and higher-level userland components like desktop environments and display managers.<br><br>Its primary functions include tracking logged-in users and their active sessions, managing multi-seat environments, and providing mechanisms for session control such as screen locking, suspend, and hibernate actions. It integrates deeply with the system's power management features, allowing for graceful shutdown, reboot, or suspend/hibernate operations initiated by users or other system components. Through its D-Bus interface, <b>logind</b> exposes critical functionality that enables various applications and services to interact with user sessions and system power states, making it an indispensable part of modern Linux desktop and server environments.


title: CAVEATS
content:
<b>systemd-logind.service</b> is a critical component for most modern Linux desktop environments. Stopping or restarting this service can severely disrupt active user sessions, leading to logout, frozen applications, or system instability. It is generally not recommended to manually stop this service unless you understand the full implications and are prepared for potential session termination.


title: D-BUS INTERFACE
content:
<b>systemd-logind</b> exposes a comprehensive D-Bus API, which is the primary method for other system components (like display managers, desktop environments, and power managers) to query and manipulate user sessions, seat assignments, and power management states. This allows for a standardized and robust inter-process communication.


title: SEAT MANAGEMENT
content:
<b>logind</b> manages 'seats', which are logical groupings of input and output devices (e.g., keyboard, mouse, monitor) associated with a physical user. This is crucial for environments with multiple users simultaneously logged in on different sets of hardware, such as multi-seat systems or virtual consoles.


title: HISTORY
content:
<b>systemd-logind</b> was introduced as part of the <b>systemd</b> project, which began development around 2010 with the goal of replacing the traditional SysVinit and Upstart init systems. It emerged from the need for a more centralized and robust session and login management system in Linux. Its integration with <b>systemd</b> brought a unified approach to user session tracking and power management that was previously fragmented across various display managers and utilities, solidifying its role as a fundamental component in many contemporary Linux distributions.


title: PARAMETERS
content:
<b>infile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Macintosh Type 1 font file to be converted.<br><br><b>outfile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> The name for the output PFB or PFA file. If not provided, <i>t1unmac</i> typically derives a name from the input file or prints to standard output with <i>--stdout</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information and exits.<br><br><b><b>-b</b>, <b>--binary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the font in PFB (binary) format. This is usually the default behavior.<br><br><b><b>-a</b>, <b>--ascii</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the font in PFA (ASCII) format.<br><br><b><b>-o</b>, <b>--output=</b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the output file name.<br><br><b><b>-s</b>, <b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the output font data to standard output.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages and warnings during processing.<br><br><b><b>-D</b>, <b>--decode-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes the MacBinary wrapper only, without attempting to parse or validate the Type 1 font data within.<br><br><b><b>-i</b>, <b>--ignore-errors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues processing even if errors are encountered in the input font data.<br><br>


title: DESCRIPTION
content:
<i>t1unmac</i> is a utility designed to convert Macintosh-specific Type 1 font files into a standard, platform-independent Type 1 format, typically PFB (Printer Font Binary) or PFA (Printer Font ASCII). Macintosh Type 1 fonts often embed their data within resource forks or MacBinary wrappers, making them inaccessible or unusable on non-Macintosh operating systems like Linux or Windows.<br><br>This command extracts the PostScript font data from these Mac-specific containers, allowing them to be used with TeX distributions, Ghostscript, or other applications that consume standard Type 1 font formats. It effectively "unmacifies" the font, making it universally compatible and ready for use in environments that expect standard Type 1 font files.


title: CAVEATS
content:
<i>t1unmac</i> is specifically designed for Type 1 PostScript fonts. It will not work with other font formats like TrueType (.ttf), OpenType (.otf), or Type 3 fonts. The input file must be a valid Macintosh Type 1 font, potentially encased in a MacBinary wrapper or resource fork structure, for successful conversion.


title: DEFAULT OUTPUT NAMING
content:
When <i>outfile</i> is not specified and <i>--stdout</i> is not used, <i>t1unmac</i> typically creates an output file by appending <i>.pfb</i> (for binary output) or <i>.pfa</i> (for ASCII output) to the input file name. For example, an input file named <i>MyFont.dfont</i> might be converted to <i>MyFont.pfb</i>.


title: HISTORY
content:
<i>t1unmac</i> is part of the <i>lcdf-typetools</i> suite, developed by Eddie Kohler. This collection of utilities was created to provide robust tools for manipulating and converting Type 1 fonts, primarily to support TeX distributions and ensure cross-platform compatibility for font usage. Its development addressed the challenge of using Macintosh-specific font formats on non-Apple systems, a common issue in the early days of desktop publishing and digital typography.


title: SYNOPSIS
content:
<b>task</b> [<i>&lt;global_options&gt;</i>] <i>&lt;command&gt;</i> [<i>&lt;command_arguments&gt;</i>] [<i>&lt;filters&gt;</i>]<br><br>Examples:<br><b>task</b> add "Review pull request" project:dev due:tomorrow priority:H<br><b>task</b> list project:dev status:pending<br><b>task</b> 123 done


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Taskwarrior version information and exits.<br><br><b><b>--rc</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default.<br><br><b><b>--config</b> <i>&lt;name&gt;</i>=<i>&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides a specific configuration setting directly from the command line.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all interactive confirmation prompts, proceeding automatically.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages, showing more details.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides extensive debugging information for troubleshooting issues.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-essential output messages, providing a minimal output.<br><br><b><b>--color</b> <i>&lt;mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the colorization of output (e.g., 'on', 'off', 'no_pager').<br><br><b><b>--report</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a specific custom report for displaying task data.<br><br><b><b>--read-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents any modifications or additions to the task database for the current command.<br><br>


title: DESCRIPTION
content:
Taskwarrior is a free, open-source, and cross-platform command-line utility designed for efficient task management. It allows users to add, modify, delete, search, prioritize, tag, and track the progress of their tasks directly from the terminal. Built for speed and flexibility, Taskwarrior supports complex queries using filters, enabling users to quickly find and act on specific subsets of tasks. It embraces the Getting Things Done (GTD) methodology, providing features like projects, contexts, due dates, and recurring tasks. Its plain-text data storage ensures portability and easy integration with other tools. Furthermore, Taskwarrior is highly customizable through configuration files, user-defined attributes (UDAs), and hooks, allowing for extensive automation and reporting capabilities. It also offers synchronization features to keep tasks consistent across multiple devices via a Taskserver. Its robust feature set and scriptability make it an indispensable tool for developers, system administrators, and anyone who prefers a minimalist yet powerful approach to personal productivity.


title: CAVEATS
content:
Taskwarrior has a relatively <i>steep learning curve</i> for new users, especially when delving into advanced features like custom reports or hooks. Its command-line nature means it <i>lacks a graphical user interface</i>, which might not suit all users. While powerful, its plain-text data storage does not include built-in encryption, requiring external solutions if sensitive task data needs to be secured.


title: CORE CONCEPTS
content:
Taskwarrior leverages several core concepts for its powerful functionality:<br><b>Filters</b>: Used to select specific subsets of tasks based on various criteria (e.g., project, status, tags, UDA values).<br><b>Attributes</b>: Properties associated with tasks, including standard ones (<i>project</i>, <i>tags</i>, <i>due</i>, <i>wait</i>) and <i>User Defined Attributes</i> (UDAs) for custom data.<br><b>Hooks</b>: Executable scripts triggered by specific Taskwarrior events, enabling extensive automation and integration.<br><b>Reports</b>: Customizable views of task data, allowing users to define how tasks are displayed and what information is included.<br><b>Synchronization</b>: The ability to sync task data with a Taskserver, facilitating cross-device consistency and collaboration.


title: HISTORY
content:
Taskwarrior was created by Paul Beckingham, with its first public release in 2008. Written in C++, it has evolved significantly over the years, steadily adding features such as synchronization, hooks, and recurring tasks, while maintaining its core philosophy of efficiency and customizability. It benefits from an active open-source community, ensuring continuous development and support.


title: SYNOPSIS
content:
<b>tc qdisc show dev</b> <i>&lt;device&gt;</i><br><b>tc class show dev</b> <i>&lt;device&gt;</i><br><br><i>Note: "tc-cbq-details" is not a direct command, but refers to the details displayed by the 'tc' utility for CBQ configurations.</i>


title: PARAMETERS
content:
<b>rate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum rate for a class, in bytes/sec or a data unit (e.g., 100kbit).<br><br><b>bandwidth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The total bandwidth of the interface or parent qdisc/class, used for rate calculations.<br><br><b>mpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Minimum Packet Unit. Packets smaller than this are counted as MPU bytes.<br><br><b>avpkt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Average Packet Size. Used by the estimator to convert rates into packet counts.<br><br><b>maxburst</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum burst size, in bytes. The maximum amount of data that can be sent in a burst.<br><br><b>minburst</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Minimum burst size, in bytes. The amount of data below which no control is exercised.<br><br><b>ewma</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exponentially Weighted Moving Average factor for the rate estimator. Larger values mean slower response to changes.<br><br><b>offtime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;How long a class stays off after sending a burst above its rate, in jiffies.<br><br><b>split</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, a class can borrow bandwidth from its parent even if it is not empty, allowing for better resource utilization.<br><br><b>defmap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A bitmask used for default classification of unclassified packets or packets with no specific filter match.<br><br><b>estimator</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Type of rate estimator used (e.g., 'ewma').<br><br><b>allok</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set, this class can always borrow bandwidth from its parent, even if the parent considers itself busy.<br><br><b>isolate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If set, this class cannot borrow or lend bandwidth to/from sibling classes.<br><br><b>lss</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Least Slack Share (LSS) allows classes with lower slack to get more service if they have data ready to send.<br><br><b>rtscell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Real-Time Slice Cell size, in bytes. Defines the minimum amount of data to be sent for a real-time class during its turn.<br><br>


title: DESCRIPTION
content:
<i>tc-cbq-details</i> is not a standalone executable command but refers to the detailed information displayed by the <b>tc</b> utility when managing or inspecting Class-Based Queueing (CBQ) disciplines. CBQ is a sophisticated queuing discipline in Linux traffic control used for bandwidth management, allowing for hierarchical classification of traffic and allocation of bandwidth to different classes based on priority and sharing rules.<br><br>When you use commands like <b>tc qdisc show</b> or <b>tc class show</b> on a CBQ-configured interface, the output includes various parameters that define the CBQ behavior, such as configured rates, burst sizes, and mapping rules. Understanding these details is crucial for diagnosing network performance issues, verifying Quality of Service (QoS) policies, and fine-tuning traffic shaping configurations. The 'details' encompass how bandwidth is shared, how overlimit behavior is handled, and how different traffic classes interact within the CBQ hierarchy.


title: CAVEATS
content:
The term <i>"tc-cbq-details"</i> does not correspond to a direct, executable command in standard Linux distributions. It refers to the output and parameters related to the Class-Based Queueing discipline when configured or inspected using the <b>tc</b> utility.<br><br>CBQ can be complex to configure and debug due to its many parameters and hierarchical nature. Its CPU overhead is generally higher compared to simpler qdiscs. For most modern use cases, newer and often more efficient queuing disciplines like <b>HTB</b> (Hierarchical Token Bucket) are preferred over CBQ due to their simpler configuration and better performance characteristics.


title: <B>CBQ OPERATION</B>
content:
CBQ operates by classifying incoming packets into different traffic classes. Each class can have its own defined bandwidth limits (rate), priority, and rules for borrowing or lending bandwidth to other classes within the hierarchy. It utilizes a token bucket mechanism for rate limiting and a sophisticated scheduling algorithm to determine which class gets to transmit next. The 'details' displayed by <b>tc</b> commands reflect the current state of these mechanisms, including tokens available, actual rates observed, and the various configured parameters that govern their behavior.


title: HISTORY
content:
Class-Based Queueing (CBQ) was one of the earliest and most comprehensive hierarchical queuing disciplines available in Linux traffic control. Developed to provide advanced traffic shaping capabilities, it allowed network administrators to define complex rules for bandwidth allocation and prioritization. While highly capable for its time, its inherent complexity and CPU overhead, especially on high-speed links, led to the development of alternative and often simpler qdiscs like HTB (Hierarchical Token Bucket). Despite being largely superseded in new deployments, CBQ remains available and understood for specific legacy systems or highly nuanced traffic management requirements where its unique features are still leveraged.


title: SYNOPSIS
content:
<b>tc qdisc add dev <i><DEV></i> parent <i><ID></i> [handle <i><ID></i>] choke [limit <i><BYTES></i>] [min <i><BYTES></i>] [max <i><BYTES></i>] [avpkt <i><BYTES></i>] [burst <i><PACKETS></i>] [ecn | noecn] [probability <i><PROB></i>] [bandwidth <i><RATE></i>] [time <i><TIME></i>] [drop-force-min-pkt <i><BYTES></i>] [drop-force-max-pkt <i><BYTES></i>] [drop-force-burst-pkt <i><PACKETS></i>] [drop-force-prob <i><PROB></i>]</b>


title: PARAMETERS
content:
<b><b>dev <i><DEV></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device to attach the qdisc to (e.g., eth0).<br><br><b><b>parent <i><ID></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines where in the qdisc hierarchy this choke instance is attached. Use 'root' to attach it as the main qdisc on a device.<br><br><b><b>handle <i><ID></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional identifier for this qdisc instance, typically in the format <i>major:minor</i>, used for referencing it later.<br><br><b><b>limit <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum size of the queue in bytes or packets (e.g., 100kb, 500packets).<br><br><b><b>min <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The minimum threshold for the average queue size. Below this, no packets are dropped/marked by the RED component.<br><br><b><b>max <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum threshold for the average queue size. Above this, all packets are dropped/marked.<br><br><b><b>avpkt <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The estimated average packet size. This value helps calculate other parameters like burst and time.<br><br><b><b>burst <i><PACKETS></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum number of packets that can be sent in a burst without significantly affecting the calculated average queue size.<br><br><b><b>ecn | noecn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables Explicit Congestion Notification. When enabled, ECN-capable packets are marked instead of dropped to signal congestion.<br><br><b><b>probability <i><PROB></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum drop/mark probability for the RED component when the average queue size is between 'min' and 'max' (a value from 0.0 to 1.0).<br><br><b><b>bandwidth <i><RATE></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The estimated average rate of traffic through the qdisc (e.g., 100Mbit). Used in conjunction with <i>avpkt</i> to calculate the <i>time</i> parameter.<br><br><b><b>time <i><TIME></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum time a packet can spend in the queue (e.g., 100ms). It's typically computed automatically if <i>bandwidth</i> and <i>avpkt</i> are provided.<br><br><b><b>drop-force-min-pkt <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum packet size for consideration in the CHOKE-specific 'drop-force' mechanism.<br><br><b><b>drop-force-max-pkt <i><BYTES></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum packet size for consideration in the CHOKE-specific 'drop-force' mechanism.<br><br><b><b>drop-force-burst-pkt <i><PACKETS></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Burst parameter specifically for the 'drop-force' mechanism, influencing how aggressively CHOKE penalizes dominant flows.<br><br><b><b>drop-force-prob <i><PROB></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The probability used by the 'drop-force' mechanism to drop/mark packets from aggressive flows when a match is found in the internal FIFO.<br><br>


title: DESCRIPTION
content:
The <b>tc-choke</b> command is a queuing discipline (qdisc) used in Linux for advanced traffic control, specifically for Active Queue Management (AQM). It implements the CHOKE (CHannel Optimized KEeping track of congestion) algorithm, which is an enhancement over the traditional RED (Random Early Detection) algorithm.<br><br>While RED aims to prevent congestion by probabilistically dropping packets before a queue overflows, CHOKE adds a mechanism to identify and penalize 'unresponsive' or 'dominant' flows that contribute disproportionately to congestion. It does this by maintaining a small internal FIFO queue of recently dropped or marked packets. When a new packet arrives and the queue is congested, CHOKE checks if this new packet matches any in its internal FIFO. If a match is found, the incoming packet is dropped or marked with a higher probability.<br><br>Like RED, CHOKE also supports Explicit Congestion Notification (ECN), allowing routers to mark packets instead of dropping them to signal congestion to ECN-aware endpoints, thereby avoiding unnecessary packet loss. The primary goal of <b>tc-choke</b> is to reduce average queueing delay, prevent global synchronization of TCP flows, and improve fairness among competing traffic flows.


title: CAVEATS
content:
Configuring <b>tc-choke</b> requires a deep understanding of network traffic patterns and AQM principles. Improper tuning of parameters like <i>min</i>, <i>max</i>, and <i>probability</i> can lead to suboptimal network performance, including excessive packet drops or increased latency. The effectiveness of ECN also depends on both ends of the connection supporting it. CHOKE's ability to identify and penalize unresponsive flows is designed to improve fairness but might not be universally effective in all complex network scenarios.


title: HOW CHOKE PENALIZES FLOWS
content:
CHOKE maintains a small FIFO buffer (typically of a few packets) of recently dropped or ECN-marked packets. When a new packet arrives and the queue is congested, CHOKE checks if the new packet's flow ID (e.g., based on source/destination IP and port) matches any flow ID of packets currently in this small FIFO buffer. If a match is found, the probability of dropping or marking the incoming packet is significantly increased, thereby penalizing the aggressive flow more heavily than a standard RED algorithm would.


title: COMPARISON TO RED
content:
While both RED and CHOKE are AQM algorithms, CHOKE extends RED by introducing a 'drop-forceless' or 'force-drop' mechanism. RED's dropping probability is solely based on the average queue size. CHOKE adds an additional layer where, if a packet belongs to a flow that has recently caused a drop/mark (as indicated by the small FIFO buffer), it faces a higher probability of being dropped/marked, thus aiming for better fairness against dominant, unresponsive flows.


title: HISTORY
content:
The core concept of Random Early Detection (RED) was introduced in the early 1990s as a mechanism to alleviate network congestion before queues become full. The CHOKE algorithm emerged later, building upon RED, with the specific goal of addressing fairness issues where RED might not adequately penalize aggressively behaving flows. It was developed to specifically target and penalize flows that frequently cause congestion, thus promoting more equitable sharing of network resources.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <i>DEV</i> <b>root | parent</b> <i>HANDLE</i> <b>codel [limit</b> <i>PACKETS</i><b>] [target</b> <i>TIME</i><b>] [interval</b> <i>TIME</i><b>] [ecn | noecn] [quantum</b> <i>BYTES</i><b>] [drop_batch</b> <i>PACKETS</i><b>] [ce_threshold</b> <i>TIME</i><b>]</b><br><br><b>tc qdisc change dev</b> <i>DEV</i> <b>root | parent</b> <i>HANDLE</i> <b>codel [limit</b> <i>PACKETS</i><b>] [target</b> <i>TIME</i><b>] [interval</b> <i>TIME</i><b>] [ecn | noecn] [quantum</b> <i>BYTES</i><b>] [drop_batch</b> <i>PACKETS</i><b>] [ce_threshold</b> <i>TIME</i><b>]</b><br><br><b>tc qdisc replace dev</b> <i>DEV</i> <b>root | parent</b> <i>HANDLE</i> <b>codel [limit</b> <i>PACKETS</i><b>] [target</b> <i>TIME</i><b>] [interval</b> <i>TIME</i><b>] [ecn | noecn] [quantum</b> <i>BYTES</i><b>] [drop_batch</b> <i>PACKETS</i><b>] [ce_threshold</b> <i>TIME</i><b>]</b><br><br><b>tc qdisc delete dev</b> <i>DEV</i> <b>root | parent</b> <i>HANDLE</i>


title: PARAMETERS
content:
<b>limit <i>PACKETS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum number of packets that can be enqueued. Defaults to 1000 packets.<br><br><b>target <i>TIME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The acceptable minimum queueing delay. If the minimum delay exceeds this target for a sustained period, <i>CoDel</i> starts dropping/marking. Defaults to 5ms. Specified in time units like 'ms', 'us'.<br><br><b>interval <i>TIME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The time interval used to measure the minimum delay. The minimum delay is periodically sampled over this interval. Defaults to 100ms. Specified in time units.<br><br><b>ecn | noecn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables Explicit Congestion Notification (ECN). When enabled, <i>CoDel</i> marks packets instead of dropping them if the ECN bits are set in the IP header.<br><br><b>quantum <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A byte-oriented version of <i>CoDel</i> (known as Byte Queue Limits or BQL) uses this parameter. It specifies the number of bytes that can be dequeued at once. Defaults to the interface's Tx queue length.<br><br><b>drop_batch <i>PACKETS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of packets <i>CoDel</i> drops in a single batch during a congestion event. This helps to quickly reduce the queue size. Defaults to 64.<br><br><b>ce_threshold <i>TIME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Explicit Congestion (CE) marking threshold for ECN-capable flows. If the queue delay exceeds this threshold, packets are marked with CE. This provides an earlier signal for congestion than dropping. Only applies if ECN is enabled. Defaults to <i>target</i>.<br><br>


title: DESCRIPTION
content:
<i>CoDel</i> (Controlled Delay) is an Active Queue Management (AQM) algorithm implemented as a queuing discipline (qdisc) in the Linux kernel. Its primary purpose is to address the "bufferbloat" problem, where excessive buffer sizes in network devices lead to high latency and poor interactive performance. <i>CoDel</i> works by monitoring the minimum queueing delay of packets passing through the queue. When this delay exceeds a configured <i>target</i> time for a sustained <i>interval</i>, <i>CoDel</i> begins dropping or marking packets (if ECN is enabled) to signal congestion, thereby keeping latency low while maintaining high throughput. It aims to achieve low latency without starving flows.


title: CAVEATS
content:
<i>CoDel's</i> effectiveness heavily depends on correctly setting <i>target</i> and <i>interval</i> parameters for your specific network conditions. Incorrect tuning can lead to excessive drops or still high latency. It's designed to work best on bottleneck links where it has full control over the queue. While <i>CoDel</i> addresses delay, for scenarios requiring fair bandwidth allocation among flows, a flow-queuing discipline like FQ-CoDel might be more appropriate.


title: <B>AQM AND BUFFERBLOAT</B>
content:
<i>CoDel</i> is a prime example of an Active Queue Management (AQM) algorithm. AQM techniques aim to prevent queues from growing too large by signaling congestion early, rather than waiting for buffers to overflow. Bufferbloat refers to the problem of excessively large buffers in network devices, which can cause high latency, jitter, and reduce effective throughput, even when the network is not truly congested. <i>CoDel</i> directly tackles this by actively managing queue delays.


title: <B>DEFAULT PARAMETERS</B>
content:
While <i>tc-codel</i> provides tunable parameters, its default settings (target=5ms, interval=100ms, limit=1000 packets) are often robust enough for many common network scenarios, making it relatively easy to deploy without extensive tuning. These defaults are chosen to provide good performance for typical broadband connections.


title: HISTORY
content:
<i>CoDel</i> (Controlled Delay) was developed by Kathleen Nichols and Van Jacobson and first published in 2012. It emerged as a response to the "bufferbloat" problem, a pervasive issue in network devices where excessively large buffers led to high latency and degraded performance, especially for interactive applications. Unlike earlier AQM algorithms like RED, <i>CoDel</i> focuses on controlling the <i>minimum</i> queueing delay rather than average queue size, making it more robust and easier to tune for various network conditions. Its design emphasizes simplicity, efficacy, and resilience against misconfiguration.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <i>&lt;DEV&gt;</i> { <b>root</b> | <b>parent</b> <i>&lt;HANDLE&gt;</i> } <b>drr</b> [ <b>quantum</b> <i>&lt;BYTES&gt;</i> ] [ <b>default</b> <i>&lt;CLASSID&gt;</i> ]


title: PARAMETERS
content:
<b>quantum <i>&lt;BYTES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the amount of bytes a flow or class is allowed to transmit in one round. This value influences the granularity of fairness. A larger quantum can lead to higher throughput but potentially less fairness over very short time scales for small packets. The default value is typically the interface's MTU.<br><br><b>default <i>&lt;CLASSID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the default class to which packets are sent if they do not match any explicit filter or class. This is important for ensuring that all traffic is handled, even if not specifically classified. If no default class is specified, traffic that doesn't match any filter might be dropped.<br><br>


title: DESCRIPTION
content:
The <b>tc-drr</b> command, more accurately, refers to the <i>Deficit Round Robin (DRR)</i> queuing discipline (qdisc) used with the Linux traffic control utility (<b>tc</b>). DRR is an algorithm designed to provide fair bandwidth allocation among multiple flows or classes of traffic.<br><br>Unlike Strict Priority (SP) queuing, DRR aims to give each class a 'fair' share of the bandwidth, preventing a single busy flow from monopolizing the network link. It achieves this by maintaining a 'deficit counter' for each class. When it's a class's turn, it can transmit packets up to its quantum (a specified byte limit) plus any accumulated deficit. If a packet exceeds the remaining deficit, it's transmitted in the next round, and the deficit counter is updated.<br><br>This mechanism ensures that even large packets don't cause starvation for other classes, as they are effectively handled over multiple rounds. <b>tc-drr</b> is particularly useful in environments where fair sharing of bandwidth is crucial, such as between different applications, users, or services. It's a foundational component for building robust Quality of Service (QoS) policies on Linux systems.


title: CAVEATS
content:
DRR is a fair queuing algorithm; it does not provide strict priority. While it aims for fairness, a class might still experience some delay if other classes are very busy, especially if its quantum is small relative to its packets.<br><br>Effective use of DRR often requires proper classification of traffic into different classes using <b>tc filters</b>. Without filters, all traffic might flow into a single default class, negating the benefits of DRR.<br><br>The `quantum` value needs careful tuning based on network characteristics (MTU, typical packet sizes) and desired fairness granularity. An inappropriately small quantum can lead to increased CPU overhead due to more frequent scheduling decisions.


title: HOW DEFICIT WORKS
content:
In DRR, each active class maintains a 'deficit counter', initialized to zero. In each round, when it's a class's turn, its 'quantum' is added to its deficit counter. The class can then send packets as long as the packet size is less than or equal to its current deficit. After sending a packet, the deficit counter is reduced by the packet size. If a packet is too large, it's held until the next round, and the deficit counter is not decremented for that packet, allowing it to accumulate more 'credit'. This mechanism ensures fairness even with varying packet sizes, preventing large packets from consuming more than their fair share in a single turn.


title: INTEGRATION WITH TC HIERARCHY
content:
DRR is a classful queuing discipline, meaning it can have child classes. This allows for complex hierarchical QoS setups. You can attach different qdiscs (e.g., HTB, PRIO, FQ-CoDel) as children to DRR classes, enabling fine-grained control over how traffic within each DRR class is further managed and prioritized. For example, you might use DRR to fairly distribute bandwidth among three departments, and within one department's class, use HTB to prioritize specific applications.


title: HISTORY
content:
The concept of Deficit Round Robin was introduced by M. Shreedhar and George Varghese in 1995 as an improvement over traditional Round Robin scheduling, specifically to address the issue of variable packet sizes. It was designed to provide fair service for variable-sized packets without requiring a complicated sorting of packets by finish times (as in WFQ).<br><br>Its implementation in the Linux kernel's `tc` framework has been a long-standing feature, contributing to Linux's capabilities as a robust network router and firewall, enabling detailed Quality of Service (QoS) management since the early days of advanced traffic control in the kernel. DRR is a well-established and widely used algorithm in network devices.


title: SYNOPSIS
content:
The <b>ematch</b> syntax is used as part of the <I>tc filter add</I> command. The general structure for adding an <b>ematch</b> filter is:<br><br><I>tc filter add dev DEV parent PARENT_ID protocol PROTOCOL prio PRIORITY ematch [EM_CLASSID] [EM_OPTIONS] &lt;match_type&gt; &lt;match_options&gt;</I><br><br>Where:<br><I>match_type</I> can be <I>bpf</I> or <I>u32</I> (most commonly).<br><I>match_options</I> are specific to the chosen <I>match_type</I>, e.g., <I>file FILENAME</I> for BPF programs.


title: PARAMETERS
content:
<b><b>match</b> <I>LABEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;References an existing <I>ematch</I> filter by its unique <I>LABEL</I>, allowing for reuse or chaining of match expressions.<br><br><b><b>result</b> <I>LABEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a unique <I>LABEL</I> to the current <I>ematch</I> filter, making it referencable by other filters.<br><br><b><b>index</b> <I>INDEX</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific, numerical <I>INDEX</I> to the <I>ematch</I> filter. This can be used for explicit management or replacement.<br><br><b><b>donotdisturb</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When specified with an <I>INDEX</I>, prevents the current command from replacing an existing filter with the same <I>INDEX</I>.<br><br><b><b>noinline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specific to BPF, this option prevents the BPF program from being inlined into the kernel's filter chain, potentially useful for debugging or specific performance tuning.<br><br><b><b>prio</b> <I>PRIORITY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a numeric <I>PRIORITY</I> to the <I>ematch</I> filter. Filters with lower priority numbers are evaluated first.<br><br><b><b>bpf</b> <I>file FILENAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that a Berkeley Packet Filter (BPF) program, loaded from <I>FILENAME</I>, should be used for packet matching. This enables highly custom and complex classification logic.<br><br><b><b>u32</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that universal 32-bit matching logic should be used. While <I>u32</I> is a separate filter type, <I>ematch</I> can wrap its functionality to integrate it into more complex <I>ematch</I> expressions.<br><br>


title: DESCRIPTION
content:
The <b>tc-ematch</b> component is an advanced filtering mechanism within the Linux traffic control (<I>tc</I>) framework. It allows administrators to define highly flexible and powerful packet classification rules by extending beyond the capabilities of standard filters like <I>u32</I> or <I>fw</I>.<br><br>While <I>tc</I> provides a variety of filter types, <b>ematch</b> specializes in leveraging external matching logic. Its primary power comes from its ability to integrate with Berkeley Packet Filter (BPF) programs. This means that complex packet inspection and classification rules can be written in a BPF program (often compiled from C code) and then loaded into the kernel via <b>ematch</b>, providing an unparalleled level of customizability.<br><br>Beyond BPF, <b>ematch</b> can also act as a wrapper for other match types, such as <I>u32</I>, providing a unified interface for defining complex filter expressions. It is not a standalone command but rather an option used within the <I>tc filter add</I> command, allowing administrators to direct packets to specific qdiscs or classes based on custom criteria.


title: CAVEATS
content:
Using <b>tc-ematch</b>, especially with BPF programs, requires a good understanding of network packet structures and BPF programming. Errors in BPF programs can lead to unexpected behavior or performance issues. Kernel support for BPF and <b>ematch</b> is essential. Debugging complex <b>ematch</b> filters can be challenging, often requiring tools like <I>bpftool</I> or kernel tracing capabilities.


title: <B>BPF INTEGRATION</B>
content:
The core strength of <b>tc-ematch</b> lies in its seamless integration with Berkeley Packet Filter (BPF). This allows users to write highly specialized packet analysis and classification logic in a high-level language (like C, then compiled to BPF bytecode) and load it directly into the kernel's data path. This provides unparalleled flexibility for matching based on complex header fields, payload content, or even custom state.


title: <B>FILTER CHAINING</B>
content:
<b>ematch</b> filters can be combined with other <I>tc</I> filters and chained together. The <I>match</I> and <I>result</I> labels provide a mechanism to create intricate logical flows, where the result of one <I>ematch</I> filter can influence the evaluation of subsequent filters in the chain, enabling multi-stage classification.


title: HISTORY
content:
The <b>ematch</b> functionality was introduced into the <I>iproute2</I> suite to address the growing need for more flexible and powerful packet classification within the Linux kernel's traffic control subsystem. While basic filters like <I>u32</I> were powerful for fixed-offset matching, they lacked the expressiveness for dynamic, protocol-aware, or stateful matching. The integration of Berkeley Packet Filter (BPF) capabilities via <b>ematch</b> revolutionized traffic classification, allowing custom C-compiled BPF programs to be loaded into the kernel, enabling complex matching logic previously unattainable. Its development paralleled the increasing prominence and capabilities of BPF within the Linux kernel, becoming a cornerstone for advanced network policy enforcement.


title: SYNOPSIS
content:
<I>tc qdisc</I> { <I>add</I> | <I>change</I> | <I>replace</I> | <I>del</I> } <I>dev</I> <B>DEV</B> { <I>root</I> | <I>parent</I> <B>CLASSID</B> } <I>fq_codel</I> [ <I>limit</I> <B>PACKETS</B> ] [ <I>flows</I> <B>NUM_BUCKETS</B> ] [ <I>target</I> <B>TIME</B> ] [ <I>interval</I> <B>TIME</B> ] [ <I>ecn</I> | <I>noecn</I> ] [ <I>ce_threshold</I> <B>TIME</B> ] [ <I>drop_batch</I> <B>PACKETS</B> ] [ <I>quantum</I> <B>BYTES</B> ] [ <I>pacing</I> | <I>nopacing</I> ]


title: PARAMETERS
content:
<b>limit PACKETS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of packets that can be enqueued. Default is 1024 packets.<br><br><b>flows NUM_BUCKETS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the number of hash buckets used to classify flows. Must be a power of 2. Default is 1024.<br><br><b>target TIME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the acceptable minimum queueing delay. If delay consistently exceeds this, CoDel takes action. Default is 5ms.<br><br><b>interval TIME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the interval for CoDel's internal state updates and decision making. Should be at least 4x the target. Default is 100ms.<br><br><b>ecn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Explicit Congestion Notification (ECN). Marks packets instead of dropping them when congestion is detected.<br><br><b>noecn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables ECN. Packets will be dropped when congestion is detected, even if ECN is supported.<br><br><b>ce_threshold TIME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;CoDel's CE (Congestion Experienced) mark threshold. Specifies the minimum average queue delay before ECN marking begins. Default is 0 (ECN marking starts whenever CoDel detects congestion).<br><br><b>drop_batch PACKETS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of packets to drop in a single burst when CoDel enters a dropping state. Default is 64 packets.<br><br><b>quantum BYTES</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The amount of bytes a flow is allowed to dequeue during its turn. This affects how fairly small vs. large packets are treated. Default is 1514 bytes (typical Ethernet MTU).<br><br><b>pacing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables pacing of packet transmission. This smooths out bursts and improves overall network stability. Enabled by default.<br><br><b>nopacing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables pacing. Packets are sent without smoothing, potentially leading to more burstiness.<br><br>


title: DESCRIPTION
content:
<code>fq_codel</code> is a powerful Linux traffic control queueing discipline (qdisc) that combines Fair Queueing (FQ) with the Controlled Delay (CoDel) active queue management (AQM) algorithm. Its primary goal is to prevent "bufferbloat" – excessive buffering of packets that leads to high latency and reduced throughput – while ensuring fair bandwidth allocation among different network flows. <br><br> Fair Queueing works by categorizing network traffic into individual flows and then ensuring each flow gets an equitable share of the available bandwidth, preventing a single bursty flow from monopolizing the link. CoDel, on the other hand, actively monitors the queueing delay for packets. If this delay consistently exceeds a predefined "target" time, CoDel will drop packets or mark them with ECN (Explicit Congestion Notification) to signal congestion, rather than allowing buffers to grow indefinitely. <br><br> By integrating these two mechanisms, <code>fq_codel</code> provides per-flow queue management and intelligent congestion control, leading to significantly lower latency for interactive traffic, better responsiveness for web browsing, and overall improved network performance, even under heavy load. It's particularly effective for heterogeneous traffic mixes and can pace output for a smoother flow.


title: CAVEATS
content:
Care must be taken when configuring <code>fq_codel</code> parameters, as inappropriate values can lead to suboptimal network performance, including increased latency or reduced throughput. While generally robust, its effectiveness depends on proper tuning for specific network conditions and traffic patterns. Its integration with more complex hierarchical qdiscs like HTB or HFSC requires a thorough understanding of traffic control principles to avoid unintended interactions.


title: DEFAULT PARAMETERS AND TUNING
content:
While <code>fq_codel</code> works well with its default parameters for most home and small office networks, advanced users might want to fine-tune <code>target</code> and <code>interval</code> based on their link's RTT (Round Trip Time). A <code>target</code> of around 5ms is generally suitable for typical broadband, and <code>interval</code> should be at least four times the <code>target</code> to give CoDel enough time to react.


title: PACING EXPLAINED
content:
The <code>pacing</code> feature, enabled by default, plays a crucial role in <code>fq_codel</code>'s effectiveness. Instead of sending packets in bursts as quickly as the hardware allows, pacing smooths out the transmission rate. This reduces the likelihood of creating new queues downstream, minimizes jitter, and can significantly improve the performance of latency-sensitive applications like VoIP and gaming.


title: HISTORY
content:
The <code>fq_codel</code> queueing discipline emerged from the broader effort to combat 'bufferbloat,' a phenomenon where excessively large network buffers lead to high latency and poor interactive performance. CoDel (Controlled Delay) itself was designed by Kathleen Nichols and Van Jacobson and introduced around 2012 as an active queue management algorithm to address this. Fair Queueing (FQ) principles, aiming for equitable bandwidth distribution, were combined with CoDel to create <code>fq_codel</code>, offering a robust solution that gained widespread adoption in the Linux kernel and other network devices. Its development marked a significant step towards achieving low-latency, high-throughput network performance by default.


title: SYNOPSIS
content:
<I>To add or modify the HFSC qdisc on an interface:</I><br><b>tc qdisc [ add | change | replace ] dev</b> <I>DEV</I> <b>root | parent</b> <I>CLASSID</I> <b>[ handle</b> <I>MINOR:</I> <b>] hfsc [ default</b> <I>CLASSID</I> <b>] [ r2q</b> <I>BPS_VALUE</I> <b>]</b><br><br><I>To add or modify an HFSC class within a qdisc:</I><br><b>tc class [ add | change | replace ] dev</b> <I>DEV</I> <b>parent</b> <I>CLASSID</I> <b>[ classid</b> <I>MAJOR:MINOR</I> <b>] hfsc [ ls</b> <I>QUANTUM</I> <b>[</b> <I>RATE</I> <b>] | rt</b> <I>QUANTUM</I> <b>[</b> <I>RATE</I> <b>] | ul</b> <I>QUANTUM</I> <b>[</b> <I>RATE</I> <b>] ]


title: PARAMETERS
content:
<b><I>Qdisc Options (for tc qdisc add ... hfsc):</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b>default <I>CLASSID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the default child class for packets that do not match any explicit filter. If not set, non-classified packets are dropped.<br><br><b>r2q <I>BPS_VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Real-time to quantum parameter. Specifies the maximum rate in bytes per second for automatic `rt` (real-time) service curve creation if no explicit quantum is defined and a link layer doesn't report bandwidth.<br><br><b><I>Class Options (for tc class add ... hfsc):</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b>ls <I>QUANTUM</I> [ <I>RATE</I> ]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Link Share (LS) service curve. This curve specifies the amount of bandwidth a class receives when its parent is congested and its sibling classes are also demanding bandwidth. <I>QUANTUM</I> is the number of bytes allowed per scheduling opportunity. <I>RATE</I> (optional) is the rate in bytes per second for this curve, setting its slope.<br><br><b>rt <I>QUANTUM</I> [ <I>RATE</I> ]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Real-Time (RT) service curve. This curve provides a guaranteed minimum rate and bounded delay, making it suitable for latency-sensitive traffic. <I>QUANTUM</I> is the number of bytes allowed per scheduling opportunity. <I>RATE</I> (optional) is the rate in bytes per second for this curve, setting its slope.<br><br><b>ul <I>QUANTUM</I> [ <I>RATE</I> ]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Upper Limit (UL) service curve. This curve imposes an absolute maximum rate for the class, regardless of available bandwidth, effectively shaping traffic. <I>QUANTUM</I> is the number of bytes allowed per scheduling opportunity. <I>RATE</I> (optional) is the rate in bytes per second for this curve, setting its slope.<br><br>


title: DESCRIPTION
content:
HFSC is a sophisticated queueing discipline (qdisc) for Linux's traffic control subsystem, designed to provide precise control over bandwidth allocation and latency. Unlike simpler qdiscs, HFSC uses "service curves" to define how much bandwidth a traffic class can expect over time, even under contention. It supports hierarchical structures, allowing for intricate traffic management policies by nesting classes within parent classes.<br><br>HFSC aims to achieve fair sharing of bandwidth while providing strict guarantees for real-time traffic and setting upper limits for other traffic types. It achieves this through three types of service curves: Link Share (LS), Real-Time (RT), and Upper Limit (UL). LS ensures a fair share when there's demand, RT guarantees a minimum rate and bounded delay crucial for latency-sensitive applications, and UL imposes a maximum bandwidth limit. Its complexity makes it powerful but requires careful configuration.


title: CAVEATS
content:
HFSC is significantly more complex to configure and understand than simpler qdiscs like HTB, leading to a steeper learning curve. Incorrect configuration can lead to unexpected behavior or inefficient bandwidth utilization. Its per-packet scheduling logic can be CPU-intensive, especially on systems with very high packet rates or a large number of classes, potentially impacting overall system performance. Debugging HFSC setups can also be challenging due to the intricate interactions of its service curves and hierarchical structure.


title: SERVICE CURVE CONCEPTS
content:
HFSC's core lies in its service curves, which define the traffic flow. The three types are:<br><b>Link Share (LS)</b>: Ensures a fair share of a parent's bandwidth among competing children. It's active when the class has data to send and its parent's capacity is constrained.<br><b>Real-Time (RT)</b>: Guarantees a minimum rate and bounded delay, making it suitable for latency-sensitive applications like VoIP or gaming. It schedules packets to meet a specified deadline.<br><b>Upper Limit (UL)</b>: Imposes a strict maximum rate on a class, effectively shaping its traffic. It ensures a class never exceeds this rate, regardless of available bandwidth or its parent's capacity.


title: HIERARCHY AND CLASS IDS
content:
HFSC supports a hierarchical structure, meaning a qdisc can have multiple classes, and each class can in turn be a parent to further child classes, forming a tree-like structure. Traffic flows down this hierarchy, being shaped and prioritized at each level. Class IDs are typically in the format <I>MAJOR:MINOR</I>, where <I>MAJOR</I> is derived from the parent qdisc's handle and <I>MINOR</I> identifies the specific class.


title: HISTORY
content:
HFSC was developed by Peter J. G. O'Donnell at the University of Cambridge and was introduced into the Linux kernel around version 2.6.7 (around 2004). It was designed to provide a more robust and flexible traffic control mechanism than existing fair queuing algorithms, particularly focusing on fulfilling service rate guarantees and bounding delays under diverse network conditions. While powerful, its complexity often leads administrators to opt for HTB for simpler bandwidth sharing needs.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <i>&lt;DEV&gt;</i> <b>root | parent</b> <i>&lt;CLASSID&gt;</i> [<b>handle</b> <i>&lt;QDISC_HANDLE&gt;</i>:] <b>htb</b> [<b>default</b> <i>&lt;CLASSID&gt;</i>] [<b>r2q</b> <i>&lt;VALUE&gt;</i>]<br><b>tc class add dev</b> <i>&lt;DEV&gt;</i> <b>parent</b> <i>&lt;PARENT_CLASSID&gt;</i> [<b>classid</b> <i>&lt;CLASSID&gt;</i>] <b>htb</b> [<b>rate</b> <i>&lt;RATE&gt;</i>] [<b>ceil</b> <i>&lt;CEIL&gt;</i>] [<b>burst</b> <i>&lt;BURST&gt;</i>] [<b>cburst</b> <i>&lt;CBURST&gt;</i>] [<b>prio</b> <i>&lt;PRIORITY&gt;</i>] [<b>quantum</b> <i>&lt;QUANTUM&gt;</i>]


title: PARAMETERS
content:
<b><b>dev</b> <i>&lt;DEV&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device (e.g., <i>eth0</i>) to which the qdisc or class applies.<br><br><b><b>root | parent</b> <i>&lt;CLASSID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates whether the HTB qdisc is attached to the root of the device (<i>root</i>) or as a child of an existing class (<i>parent &lt;CLASSID&gt;</i>).<br><br><b><b>handle</b> <i>&lt;QDISC_HANDLE&gt;</i>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unique identifier for the HTB qdisc, often in <i>MAJOR:0</i> format. Required for root qdiscs.<br><br><b><b>default</b> <i>&lt;CLASSID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For an HTB qdisc, specifies the default class to which unclassified packets are sent. Packets not matched by any filter will go here.<br><br><b><b>r2q</b> <i>&lt;VALUE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rate to quantum ratio. Influences the scheduling precision and fairness between classes, particularly when using inner queuing disciplines like SFQ. A higher value means HTB tries to dequeue more bytes from a class per round.<br><br><b><b>classid</b> <i>&lt;CLASSID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unique identifier for the specific HTB class, often in <i>MAJOR:MINOR</i> format. Must be unique under its parent.<br><br><b><b>rate</b> <i>&lt;RATE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The guaranteed minimum bandwidth for this class. Specified in various units (e.g., <i>100kbit</i>, <i>1mbit</i>, <i>10mbit</i>). HTB ensures this class receives at least this much bandwidth if it has data to send.<br><br><b><b>ceil</b> <i>&lt;CEIL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum bandwidth this class can consume, including borrowed bandwidth from its parent or siblings. Specified in units similar to <i>rate</i>. A class can never exceed its <i>ceil</i>.<br><br><b><b>burst</b> <i>&lt;BURST&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum amount of bytes that can be sent at <i>rate</i> above the average for a short period. This defines the token bucket size for the <i>rate</i> limit.<br><br><b><b>cburst</b> <i>&lt;CBURST&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum amount of bytes that can be sent at <i>ceil</i> above the average for a short period. This defines the token bucket size for the <i>ceil</i> limit.<br><br><b><b>prio</b> <i>&lt;PRIORITY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Priority level for sharing bandwidth among siblings when they are below their <i>rate</i> but could still borrow. Lower numerical value means higher priority (e.g., <i>0</i> is highest priority).<br><br><b><b>quantum</b> <i>&lt;QUANTUM&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of bytes the HTB scheduler will try to dequeue from this class in one turn. Automatically calculated based on <i>rate</i> if not specified, usually <i>rate</i> / <i>r2q</i>.<br><br>


title: DESCRIPTION
content:
<i>tc-htb</i> refers to the Hierarchical Token Bucket (HTB) queuing discipline, a powerful component of the Linux traffic control system. HTB is designed to provide robust and flexible bandwidth management for network interfaces. It allows administrators to create a hierarchical structure of traffic classes, enabling precise control over bandwidth allocation, sharing, and prioritization for different types of network traffic. Unlike simpler queuing disciplines, HTB can guarantee minimum bandwidths (<i>rate</i>) while also allowing classes to borrow unused bandwidth up to a specified maximum (<i>ceil</i>). This makes it ideal for scenarios requiring intricate bandwidth partitioning, such as prioritizing VoIP traffic over bulk downloads, or sharing a limited internet connection among multiple users or applications fairly, yet with defined limits. It's a key tool for ensuring quality of service (QoS) on Linux systems.


title: CAVEATS
content:
HTB configuration can be complex and requires a good understanding of its hierarchical model, token bucket mechanism, and interaction with other queuing disciplines and filters. Incorrect configuration can lead to unintended traffic shaping, poor performance, or even traffic drops. Performance can be impacted by a very deep hierarchy or an excessively large number of classes. Kernel support for HTB is required, which is standard in modern Linux kernels. The actual rates and ceilings achieved can vary slightly based on packet size distribution and burst traffic.


title: HTB HIERARCHY AND BANDWIDTH SHARING
content:
HTB organizes traffic into a tree-like structure. The root qdisc distributes bandwidth to its direct children, which can in turn distribute to their children. Each class can have a guaranteed minimum bandwidth (<i>rate</i>) and a maximum (<i>ceil</i>). If a class is not using its full <i>rate</i>, the unused bandwidth can be borrowed by its siblings (if they are below their <i>ceil</i>) or its parent. This borrowing mechanism is controlled by priorities (<i>prio</i>) among siblings, ensuring that higher-priority classes get bandwidth first from the shared pool.


title: TOKEN BUCKET MECHANISM
content:
HTB implements traffic shaping using a token bucket mechanism for both <i>rate</i> and <i>ceil</i>. Imagine two virtual buckets for each class: one for the <i>rate</i> and one for the <i>ceil</i>. Tokens are added to these buckets at a steady rate corresponding to their respective bandwidths. To send data, a class must 'pay' with tokens from these buckets. If a bucket is empty, the class must wait until more tokens arrive, thus enforcing the specified bandwidth limit. <i>burst</i> and <i>cburst</i> parameters define the maximum number of tokens that can accumulate in these buckets, allowing for short bursts of traffic above the average rate.


title: HISTORY
content:
HTB was developed as a more efficient and simpler alternative to the earlier Class-Based Queuing (CBQ) discipline, which often suffered from configuration complexity and performance issues. Created by Martin Devera, HTB aimed to provide robust hierarchical bandwidth management with clear guarantees and fair sharing, becoming a staple for QoS implementation in Linux environments. Its design emphasizes performance and predictability, making it a widely adopted solution for various traffic shaping needs since its introduction into the Linux kernel.


title: SYNOPSIS
content:
tc qdisc add dev <I>DEV</I> root pfifo_fast [ <I>limit</I> <I>PACKETS</I> ]<br>tc qdisc change dev <I>DEV</I> root pfifo_fast [ <I>limit</I> <I>PACKETS</I> ]


title: PARAMETERS
content:
<b>dev <I>DEV</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device (e.g., `eth0`, `ens33`) to which the `pfifo_fast` queuing discipline will be attached.<br><br><b>root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates that `pfifo_fast` should be installed as the main (root) queuing discipline for the specified device. `pfifo_fast` is a <b>classless</b> qdisc and cannot contain other qdiscs.<br><br><b>limit <I>PACKETS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of packets that the `pfifo_fast` qdisc can hold across all its bands. If this option is omitted, the default limit is typically <b><I>1000</I></b> packets.<br><br>


title: DESCRIPTION
content:
The `pfifo_fast` (Priority First-In, First-Out) queuing discipline is the <b>default</b> qdisc for many Linux network interfaces. It implements a basic but effective priority-based queuing mechanism. It divides incoming packets into three distinct bands (priorities): <b>band 0</b> (highest priority), <b>band 1</b> (medium priority), and <b>band 2</b> (lowest priority).<br><br>Packets are assigned to these bands primarily based on their IP precedence bits found in the Type of Service (ToS) field of the IP header, or, if ToS is not utilized, based on the `SO_PRIORITY` socket option set by applications. The `pfifo_fast` discipline always dequeues packets from the highest priority band that is not empty. It only proceeds to dequeue from <b>band 1</b> when <b>band 0</b> is empty, and similarly to <b>band 2</b> only when both <b>band 0</b> and <b>band 1</b> are empty. Within each individual band, packets are processed in a strict FIFO manner.<br><br>This mechanism ensures that high-priority traffic (e.g., interactive SSH sessions, DNS queries) receives preferential treatment over lower-priority traffic (e.g., bulk data transfers), providing a rudimentary level of Quality of Service (QoS) without complex configuration. It is valued for its simplicity and low overhead.


title: CAVEATS
content:
<ul><li>`pfifo_fast` is a <b>classless</b> qdisc, meaning it cannot host or classify traffic into child qdiscs.</li><li>It provides a very basic level of QoS based on fixed IP precedence or socket priority mappings and does not support advanced traffic shaping, rate limiting, or more granular classification rules.</li><li>The mapping of IP precedence bits to priority bands is fixed and cannot be reconfigured by the user.</li><li>While it prioritizes traffic, heavy constant high-priority traffic can starve low-priority traffic, and it doesn't inherently prevent bufferbloat as effectively as modern qdiscs like FQ-CoDel or CAKE.</li></ul>


title: PRIORITY BANDS AND PACKET CLASSIFICATION
content:
`pfifo_fast` internally manages three priority bands:<ul><li><b>Band 0:</b> Highest priority.</li><li><b>Band 1:</b> Medium priority.</li><li><b>Band 2:</b> Lowest priority.</li></ul>Packets are assigned to these bands based on their IP precedence bits (from the Type of Service field) or the `SO_PRIORITY` socket option:<br><ul><li><b>IP Precedence (ToS):</b> Packets with IP precedence bits 0x00 (`Normal Service`, `Interactive`) are mapped to <b>Band 0</b>. Packets with precedence 0x20 (`Expedited Forwarding`, `Background`) are mapped to <b>Band 1</b>. Packets with precedence 0x40 (`Default`, `Best Effort`) and above (up to 0xE0) are mapped to <b>Band 2</b>.</li><li><b>SO_PRIORITY:</b> If the ToS field is zero, the `SO_PRIORITY` socket option (set by an application using `setsockopt`) can be used to assign a packet to a specific band. For example, a `SO_PRIORITY` value of 0 will typically map to <b>Band 0</b>, 1 to <b>Band 1</b>, and so on.</li></ul>


title: HISTORY
content:
`pfifo_fast` has served as the <b>default</b> queuing discipline in Linux for many years due to its simplicity, low overhead, and reasonable performance for general-purpose network traffic. Its design predates many modern congestion control algorithms and bufferbloat mitigation techniques. While it remains a fundamental component of Linux networking, newer, more advanced queuing disciplines like `fq_codel` and `cake` are often adopted as defaults in modern Linux distributions to provide better performance under congestion, lower latency, and more robust fairness guarantees. Despite this, `pfifo_fast` is still widely used and understood for its straightforward operation.


title: SYNOPSIS
content:
<b>tc qdisc add dev</b> <i>DEV</i> <b>root</b> | <b>parent</b> <i>CLASSID</i> <b>prio</b> [<b>bands</b> <i>NUMBER</i>] [<b>priomap</b> <i>A B C ...</i>] [<b>handle</b> <i>X</i>:]<br><b>tc qdisc change dev</b> <i>DEV</i> <b>root</b> | <b>parent</b> <i>CLASSID</i> <b>prio</b> [<b>bands</b> <i>NUMBER</i>] [<b>priomap</b> <i>A B C ...</i>]


title: PARAMETERS
content:
<b>dev DEV</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device (e.g., <i>eth0</i>) to which the qdisc is attached.<br><br><b>root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the <b>prio</b> qdisc as the root qdisc for the specified device.<br><br><b>parent CLASSID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches the <b>prio</b> qdisc as a child of an existing qdisc or class specified by <i>CLASSID</i>.<br><br><b>bands NUMBER</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of priority bands (internal queues) to create. The default is 3 bands (0, 1, 2).<br><br><b>priomap A B C ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a mapping from internal Linux priorities (0-15) to specific <b>prio</b> bands. It requires 16 space-separated integers, where each integer indicates the band for the corresponding internal priority. For example, '<i>priomap 0 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2</i>' maps internal priorities 0, 1, 2 to bands 0, 1, 2 respectively, and all higher internal priorities to band 2. The default is '<i>0 1 2 3 4 5 6 7 7 7 7 7 7 7 7 7</i>' (mapping internal priorities 0-7 to bands 0-7, and 8-15 to band 7), but if only 3 bands are present, priorities > 2 will be mapped to band 2.<br><br><b>handle X:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a unique handle to the <b>prio</b> qdisc, allowing it to be referenced by other <i>tc</i> commands or child qdiscs. The format is '<i>major:minor</i>' or just '<i>major:</i>' if minor is 0.<br><br>


title: DESCRIPTION
content:
The <b>prio</b> queuing discipline (qdisc) is a simple yet powerful traffic control mechanism in Linux that provides strict priority queuing. It operates by maintaining multiple internal queues, known as 'bands'. By default, it creates three bands (0, 1, and 2), with band 0 having the highest priority and band 2 the lowest. <br><br>Packets are directed into these bands based on their internal priority, which can be set by various classifiers, most commonly using <i>tc filters</i> like <i>u32</i> or <i>fwmark</i>. Without explicit filters, all traffic defaults to the highest priority band (band 0). <br><br>The <b>prio</b> qdisc serves packets from the highest priority band (band 0) until it is empty, then moves to the next highest priority band (band 1), and so on. This strict priority ensures that high-priority traffic, such as interactive SSH sessions or VoIP, gets preferential treatment over lower-priority traffic like bulk data transfers or file downloads, preventing latency and ensuring responsiveness. <br><br>Each band can have its own child qdisc attached, allowing for more complex traffic shaping within each priority level. For instance, band 0 might use <i>fq_codel</i> for low-latency interactive traffic, while band 1 might use <i>tbf</i> for rate-limiting bulk traffic.


title: CAVEATS
content:
The <b>prio</b> qdisc itself does not classify packets. Without <i>tc filters</i> (e.g., <i>u32</i>, <i>fw</i>), all traffic will default to the highest priority band (band 0). This effectively turns <b>prio</b> into a simple FIFO qdisc if no filters are applied. <br><br>As a strict priority qdisc, lower priority bands can experience 'starvation' if there's a continuous stream of traffic in higher priority bands. It is crucial to manage traffic appropriately to avoid this, potentially by attaching bandwidth-limited child qdiscs to higher priority bands or by using other qdiscs like <i>HTB</i> for more flexible sharing.


title: PACKET CLASSIFICATION
content:
For <b>prio</b> to function effectively, packets must be classified and assigned an internal priority or explicitly directed to a specific band. This is typically achieved using <i>tc filters</i>. For example, a <i>u32 filter</i> can match packets based on IP addresses, ports, or protocol types and then use the '<i>set_tc_index</i>' or '<i>classid</i>' action to direct them to a specific band. Alternatively, the '<i>fw</i>' filter can use firewall marks set by <i>iptables</i> to classify packets.


title: CHILD QDISCS ON BANDS
content:
Each band of the <b>prio</b> qdisc (e.g., <i>prio:0</i>, <i>prio:1</i>) can have a separate child qdisc attached to it. This allows for very flexible and powerful configurations. For instance, band 0 (highest priority) might have a <i>fq_codel</i> qdisc for interactive traffic, ensuring low latency, while band 1 might have a <i>tbf</i> (Token Bucket Filter) qdisc to rate-limit bulk downloads, and band 2 might simply use a default <i>sfq</i> for fairness among remaining traffic.


title: HISTORY
content:
The <b>prio</b> qdisc is one of the fundamental and earliest queuing disciplines implemented in the Linux kernel's traffic control subsystem. Its design is based on the traditional concept of strict priority queuing, making it a cornerstone for basic QoS implementations. It has been a standard part of the <i>iproute2</i> suite (which includes the <i>tc</i> command) for a long time, providing a simple, efficient way to prioritize network traffic based on administrator-defined rules.


title: SYNOPSIS
content:
<b>tc qdisc [add|change|replace|delete] dev</b> <i>&lt;DEV&gt;</i> <b>[parent</b> <i>&lt;HANDLE&gt;</i><b>] red [OPTIONS]</b>


title: PARAMETERS
content:
<b><b>limit</b> <i>&lt;BYTES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum size of the RED queue in bytes. Packets are dropped if adding them would exceed this limit, regardless of RED thresholds.<br><br><b><b>min</b> <i>&lt;BYTES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Minimum threshold for the average queue size. Below this, no packets are dropped by RED.<br><br><b><b>max</b> <i>&lt;BYTES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum threshold for the average queue size. Above this, all incoming packets are dropped by RED.<br><br><b><b>avpkt</b> <i>&lt;BYTES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Average packet size in bytes. Used by RED to calculate the time constants for the average queue size and for burst calculations.<br><br><b><b>burst</b> <i>&lt;PACKETS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of packets used to initialize the exponential weighted moving average (EWMA) calculation of the average queue size. A larger value makes the average queue size more resistant to short bursts.<br><br><b><b>ecn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <i>Explicit Congestion Notification</i>. Instead of dropping packets, RED will mark them with an ECN bit if both endpoints support it. This avoids packet loss for congestion signaling.<br><br><b><b>noecn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables ECN. This is the default behavior if neither <b>ecn</b> nor <b>harddrop</b> is specified explicitly.<br><br><b><b>harddrop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces RED to always drop packets when congestion occurs, even if <b>ecn</b> is enabled. This overrides ECN marking.<br><br><b><b>bandwidth</b> <i>&lt;RATE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Estimated bandwidth of the interface (e.g., '100mbit', '1gbit'). This parameter is crucial for accurate calculation of the average queue size by influencing the time constants.<br><br><b><b>probability</b> <i>&lt;PROBABILITY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum probability (0 to 1) of dropping a packet when the average queue size is at the <b>max</b> threshold. Defaults to 0.02 (1/50).<br><br><b><b>nodrop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Rarely used) If specified, RED will never drop packets. It will only perform ECN marking when congestion thresholds are met. Requires <b>ecn</b> to be effective.<br><br>


title: DESCRIPTION
content:
The <b>tc-red</b> command is part of the Linux <b>traffic control (tc)</b> framework, implementing the <i>Random Early Detection (RED)</i> active queue management (AQM) algorithm.<br><br>Unlike traditional <i>tail-drop</i> queues that only drop packets when the queue is completely full, RED proactively monitors the average queue size and starts dropping packets probabilistically before the queue becomes saturated. This helps to prevent global synchronization of TCP flows and improves overall network throughput and fairness.<br><br>RED operates by maintaining two thresholds: a minimum (<b>min</b>) and a maximum (<b>max</b>). Below the <b>min</b> threshold, no packets are dropped. Above the <b>max</b> threshold, all incoming packets are dropped. Between <b>min</b> and <b>max</b>, packets are dropped with a probability that increases linearly as the average queue size approaches <b>max</b>.<br><br>It also supports <i>Explicit Congestion Notification (ECN)</i>, allowing routers to mark packets instead of dropping them, signaling congestion to ECN-capable endpoints. This can reduce retransmissions and improve performance in some scenarios. <b>tc-red</b> is a crucial tool for advanced network congestion avoidance strategies.


title: CAVEATS
content:
Tuning <b>tc-red</b> can be complex; incorrect parameters can lead to underutilization or continued congestion. The <b>bandwidth</b> parameter is critical for correct average queue size calculation. <i>ECN</i> requires support from both network endpoints to be effective.


title: ACTIVE QUEUE MANAGEMENT (AQM)
content:
<i>Active Queue Management (AQM)</i> refers to techniques that manage the length of network queues by dropping or marking packets before the queue becomes full. This is in contrast to traditional <i>tail-drop</i> queues, which only drop packets when the buffer is completely exhausted. <b>RED</b> is a foundational AQM algorithm designed to provide early feedback to TCP senders, prompting them to reduce their sending rates and preventing the queue from overflowing.


title: GLOBAL SYNCHRONIZATION
content:
<i>Global synchronization</i> is a phenomenon where multiple TCP flows simultaneously reduce their sending rates due to packet loss at a congested router, and then simultaneously increase them again. This leads to oscillating link utilization (periods of underutilization followed by periods of severe congestion). <b>RED</b> mitigates this by dropping packets probabilistically and randomly, staggering the congestion signals received by different TCP flows and thus desynchronizing their congestion control mechanisms.


title: HISTORY
content:
The <i>Random Early Detection (RED)</i> algorithm was primarily developed by Sally Floyd and Van Jacobson in the early 1990s as a significant advancement in <i>Active Queue Management (AQM)</i>. Its purpose was to address the limitations of simple <i>tail-drop</i> queues, particularly the issues of global synchronization and inefficient link utilization.<br><br>RED was quickly adopted and integrated into operating systems' networking stacks, including Linux. It became a core component of the <b>iproute2</b> utility suite's <b>traffic control (tc)</b> module, providing network administrators with a powerful tool for proactive congestion avoidance and improved network performance.


title: SYNOPSIS
content:
tc qdisc add dev <I>DEV</I> root | parent <I>CLASSID</I> [handle <I>MAJOR</I>:] sfb [<I>OPTIONS</I>]<br>tc qdisc change dev <I>DEV</I> root | parent <I>CLASSID</I> [handle <I>MAJOR</I>:] sfb [<I>OPTIONS</I>]<br>tc qdisc replace dev <I>DEV</I> root | parent <I>CLASSID</I> [handle <I>MAJOR</I>:] sfb [<I>OPTIONS</I>]<br>tc qdisc show dev <I>DEV</I> sfb


title: PARAMETERS
content:
<b>limit <I>PACKETS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum queue length for the entire SFB qdisc, specified in packets. The default is 2048 packets.<br><br><b>max_depth <I>PACKETS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the maximum queue depth for each individual hash bucket (cell) within SFB, in packets. The default is 128 packets.<br><br><b>target <I>TIME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired target queueing delay that SFB aims to maintain, in milliseconds (e.g., '5ms'). The default is 5ms.<br><br><b>min_toks <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum token bucket size for a cell, in bytes. This is part of the rate estimation mechanism. The default is 1000 bytes.<br><br><b>max_toks <I>BYTES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum token bucket size for a cell, in bytes. The default is 2000 bytes.<br><br><b>scell_log <I>LOG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the logarithmic base-2 size for the number of cells (hash buckets) SFB will use. For example, 'scell_log 7' means 2^7 = 128 cells. The default is 7.<br><br><b>p_log <I>LOG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a logarithmic base-2 value used in the probability calculation for dropping or marking packets when congestion is detected. The default is 11.<br><br><b>e_log <I>LOG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a logarithmic base-2 value used in the exponent calculation, influencing the aggressiveness of packet drops. The default is 11.<br><br><b>sfb_dont_log</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A flag that disables SFB's internal logging. This can be useful during debugging or to slightly reduce overhead in production environments.<br><br>


