chore: import upstream snapshot with attribution

2026-07-13 13:12:17 +08:00
commit cf8edb9f21
44281 changed files with 1655134 additions and 0 deletions
@@ -0,0 +1,4 @@
+<header>Return to index after creating a new unit</header>
+<p>Controls where the module goes after successfully creating a unit. When set
+to yes, it returns to the matching index tab. When set to no, it opens the
+new unit's edit page for immediate review and follow-up actions.</p>
@@ -0,0 +1,4 @@
+<header>Default scope for new units</header>
+<p>Sets the default scope used when the create-unit form is opened without an
+explicit system or user context. Links from index tabs still keep their own
+context, such as opening user-unit creation from the User units tab.</p>
@@ -0,0 +1,4 @@
+<header>Enable linger by default for new user units</header>
+<p>Controls the default linger choice when creating new user units. Linger
+allows the user's systemd manager and enabled user units to run without an
+active login session.</p>
@@ -0,0 +1,9 @@
+<header>Allow deleting packaged unit files</header>
+<p>Controls whether the module may delete unit files from package-managed
+vendor directories such as <tt>/usr/lib/systemd/system</tt> or
+<tt>/lib/systemd/system</tt>. This is disabled by default because package
+updates may restore or expect those files.</p>
+
+<p>When set to no, only local administrator-created unit files under
+<tt>/etc/systemd/system</tt> can be deleted. Packaged units can still be
+disabled, masked, or customized with drop-in overrides.</p>
@@ -0,0 +1,3 @@
+<header>Display unit descriptions</header>
+<p>Controls whether unit descriptions are shown in the index tables. Disable
+this for a denser table when names and states are enough.</p>
@@ -0,0 +1,10 @@
+<header>Allow editing packaged unit files</header>
+<p>Controls whether the module may directly save changes to package-managed
+unit files from vendor directories such as <tt>/usr/lib/systemd/system</tt>
+or <tt>/lib/systemd/system</tt>. This is disabled by default because package
+updates may overwrite or depend on those files.</p>
+
+<p>When set to no, packaged unit files can still be inspected in the manual
+editor when vendor files are included, but they are read-only. Use drop-in
+overrides or local units under <tt>/etc/systemd/system</tt> for normal
+customization.</p>
@@ -0,0 +1,4 @@
+<header>Journal log scope</header>
+<p>Controls whether the Logs action reads entries from the current boot only
+or from all journal history available on the system. Current-boot logs are
+usually faster and avoid mixing output from previous starts of the machine.</p>
@@ -0,0 +1,4 @@
+<header>Number of journal log lines to show</header>
+<p>The number of recent journal lines to read for each selected unit when using
+the Logs action. Larger values provide more history but can make log pages
+longer or slower.</p>
@@ -0,0 +1,5 @@
+<header>Include vendor unit files in the manual editor</header>
+<p>Controls whether the manual file editor includes packaged unit files from
+vendor directories such as <tt>/usr/lib/systemd/system</tt>. These files are
+useful for inspection, but normal customizations should usually be made with
+drop-in overrides or local units under <tt>/etc/systemd/system</tt>.</p>
@@ -0,0 +1,8 @@
+<header>Show drop-in override inventory</header>
+<p>Controls whether the module index displays the drop-in overrides inventory
+action view.</p>
+
+<p>The inventory lists discovered drop-in override files for scopes the
+current Webmin user can view. Edit links are shown for safe drop-ins attached
+to known units only when the matching system or user drop-in ACL permits
+management of those overrides.</p>
@@ -0,0 +1,4 @@
+<header>Show generated and transient units</header>
+<p>Controls whether index tabs include units created dynamically by systemd,
+such as transient scopes and generated units. Hiding them keeps the index
+focused on persistent unit files that administrators normally edit.</p>
@@ -0,0 +1,4 @@
+<header>Show full unit names with type suffixes</header>
+<p>Controls whether index tables display full unit names such as
+<tt>sshd.service</tt> or shorter base names such as <tt>sshd</tt>. When
+suffixes are hidden, mixed tabs add a Unit type column where needed.</p>
@@ -0,0 +1,4 @@
+<header>Tabs to show on the index page</header>
+<p>Selects which unit groups appear on the index page. At least one tab must
+remain enabled. Hiding a tab only removes it from the index view; it does not
+delete, disable, or mask any units.</p>
@@ -0,0 +1,12 @@
+<header>Introduction</header>
+<p>This module manages units controlled by systemd, including services, timers,
+sockets, paths, targets, storage units, resource-control units, devices and user
+units. The index groups units by type and shows both the unit file state, such
+as enabled, disabled, static or masked, and the runtime state reported by
+systemd.</p>
+<p>Use the unit tables to start, stop, restart, enable, disable, mask, inspect
+status or read logs. Existing units can be edited directly when their unit files
+are writable, or customized with drop-in override files when packaged base units
+should be left intact. User units are managed through the owning user's systemd
+manager, with linger controls for units that should keep running without an
+active login.</p>
@@ -0,0 +1,6 @@
+<header>Start after units</header>
+<p>Units that should be started before this unit. This writes
+<tt>After=</tt> in the <tt>[Unit]</tt> section.</p>
+<p>Enter space-separated unit names, such as <tt>network-online.target
+postgresql.service</tt>. This only controls ordering when both units are being
+started. It does not by itself start the listed units.</p>
@@ -0,0 +1,4 @@
+<header>Idle timeout</header>
+<p>Optional systemd duration after which an idle automount is unmounted, such as
+<tt>30s</tt>, <tt>5min</tt>, or <tt>1h</tt>. Leave blank to use systemd's
+default behavior.</p>
@@ -0,0 +1,3 @@
+<header>Directory mode</header>
+<p>Optional octal mode used if systemd creates the automount directory, such as
+<tt>0755</tt> or <tt>0700</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Existing mount unit</header>
+<p>Select a matching <tt>.mount</tt> unit for this automount. The automount
+unit name and path will be derived from the selected mount unit. For example,
+<tt>mnt-data.mount</tt> pairs with <tt>mnt-data.automount</tt>.</p>
+<p>If no matching mount is selected, enter an automount path instead. A matching
+<tt>.mount</tt> unit for that path must already exist.</p>
@@ -0,0 +1,4 @@
+<header>Automount path</header>
+<p>The absolute path watched by the automount unit. Accessing this path causes
+systemd to activate the matching <tt>.mount</tt> unit. The matching mount must
+use the same path in its <tt>Where=</tt> setting.</p>
@@ -0,0 +1,7 @@
+<header>Start before units</header>
+<p>Units that should be ordered after this unit. This writes
+<tt>Before=</tt> in the <tt>[Unit]</tt> section.</p>
+<p>Enter space-separated unit names, such as <tt>nginx.service
+myapp.target</tt>. Ordering alone does not cause the other unit to start; pair
+it with <tt>Wants=</tt> or <tt>Requires=</tt> when this unit should also
+pull that unit into the same start transaction.</p>
@@ -0,0 +1,9 @@
+<header>Start at boot time?</header>
+<p>Controls whether the unit is enabled. System units are enabled for the
+selected install target; user units are enabled in the selected user's systemd
+manager.</p>
+<p>For user units, enabling the unit is separate from linger. Enable linger
+when the unit should be able to start at boot or keep running after the user
+logs out.</p>
+<p>This option is not shown for unit types or unit file states that systemd
+cannot enable directly, such as transient, generated, scope, or device units.</p>
@@ -0,0 +1,9 @@
+<header>Systemd unit configuration</header>
+<p>The raw unit file or drop-in override contents. For editable units, changes
+made here are saved directly to the selected file.</p>
+<p>Use this for options that are not exposed by the form. After saving, the
+system or user systemd manager is reloaded as appropriate so it sees the
+updated unit definition.</p>
+<p>Runtime-managed units, such as transient scope units and generated units, are
+shown read-only because systemd creates those files dynamically. Use the status,
+properties, dependencies and log buttons to inspect them.</p>
@@ -0,0 +1,8 @@
+<header>Conflicts with units</header>
+<p>Units that cannot run at the same time as this unit. Starting one side
+causes systemd to stop the other.</p>
+<p>Enter space-separated unit names. This is useful for mutually exclusive
+implementations, such as two services that bind the same port or manage the
+same resource.</p>
+<p>Use <tt>After=</tt> or <tt>Before=</tt> as well if the stop/start order
+matters when switching between conflicting units.</p>
@@ -0,0 +1,5 @@
+<header>Unit description</header>
+<p>A short human-readable unit description written as <tt>Description=</tt>
+in the unit's <tt>[Unit]</tt> section.</p>
+<p>This text appears in commands such as <tt>systemctl status</tt>. It is only
+a label and does not change ordering, startup behavior, or logging.</p>
@@ -0,0 +1,9 @@
+<header>Environment variables</header>
+<p>Environment variables to pass to the service, written as
+<tt>Environment=</tt>. Use systemd's normal assignment syntax, such as
+<tt>NAME=value</tt>.</p>
+<p>Enter one or more assignments separated by spaces, for example
+<tt>NODE_ENV=production PORT=3000</tt>. Quote values that contain spaces, such
+as <tt>APP_NAME="My App"</tt>.</p>
+<p>For larger or secret-bearing sets of values, prefer an environment file and
+set permissions on that file carefully.</p>
@@ -0,0 +1,11 @@
+<header>Environment file</header>
+<p>Absolute path to a file containing environment variables for the service.
+This writes <tt>EnvironmentFile=</tt>. Prefix the path with <tt>-</tt> to
+ignore a missing file.</p>
+<p>Each line in the file should normally be a shell-style assignment such as
+<tt>NAME=value</tt>. Common examples are <tt>/etc/default/myapp</tt>,
+<tt>/etc/sysconfig/myapp</tt>, or a private file under the application's
+directory.</p>
+<p>For user units, use an absolute path to a file readable by the selected
+user, typically below that user's home directory such as
+<tt>/home/example/.config/myapp/environment</tt>.</p>
@@ -0,0 +1,8 @@
+<header>Configuration file</header>
+<p>The path to the systemd unit file or drop-in override file currently being
+edited.</p>
+<p>System units are normally stored under a system unit directory. User
+units created here are stored below the selected user's
+<tt>~/.config/systemd/user</tt> directory.</p>
+<p>Packaged vendor unit files may be shown for inspection, but normal local
+changes should usually be made with a drop-in override or a local unit file.</p>
@@ -0,0 +1,5 @@
+<header>Run as group</header>
+<p>For system services, writes <tt>Group=</tt> so the service process runs with
+the selected Unix group. This option is hidden for user units.</p>
+<p>Leave this empty to use the selected user's default group. Set it only when
+the service needs a specific primary group for file or socket access.</p>
@@ -0,0 +1,11 @@
+<header>Kill mode</header>
+<p>Controls how systemd terminates processes belonging to the service. This
+writes <tt>KillMode=</tt>.</p>
+<p><tt>control-group</tt> is the default and safest choice: systemd stops the
+main process and any remaining child processes in the service cgroup.
+<tt>mixed</tt> sends the first termination signal only to the main process,
+then later kills remaining cgroup processes if needed.</p>
+<p><tt>process</tt> stops only the main process and can leave child processes
+behind. <tt>none</tt> makes systemd run the stop command but not kill service
+processes. Avoid <tt>process</tt> and <tt>none</tt> unless you know the
+application manages its own process tree safely.</p>
@@ -0,0 +1,6 @@
+<header>Open files limit</header>
+<p>Sets the service file descriptor limit with <tt>LimitNOFILE=</tt>.</p>
+<p>Enter a number such as <tt>65535</tt>, <tt>infinity</tt>, or a
+soft:hard pair such as <tt>4096:65535</tt>. This is commonly needed by busy
+web servers, proxies, databases, and applications that keep many sockets or
+files open.</p>
@@ -0,0 +1,8 @@
+<header>Enable linger for this user?</header>
+<p>Controls systemd linger, implemented by
+<tt>loginctl enable-linger</tt> for the selected user. This allows the user's
+systemd manager and enabled user units to run after the user logs out and to
+start at boot.</p>
+<p>Without linger, a user unit normally requires an active login session or an
+already-running user manager. This is fine for desktop/session units, but
+server-style user units usually need linger enabled.</p>
@@ -0,0 +1,7 @@
+<header>Allow user units to run without login?</header>
+<p>Controls whether this user's systemd manager is allowed to continue running
+without an active login session. This is useful for user units that should keep
+running after the user logs out or start at boot.</p>
+<p>This is systemd linger for the unit owner. Enabling a user unit at boot and
+allowing it to run without login are separate settings; server-style user units
+usually need both.</p>
@@ -0,0 +1,11 @@
+<header>Standard error</header>
+<p>Destination for the service standard error stream, written as
+<tt>StandardError=</tt>. Common values include <tt>journal</tt>,
+<tt>null</tt>, <tt>inherit</tt>, <tt>journal+console</tt>,
+<tt>file:/path/to/file</tt>, <tt>append:/path/to/file</tt>, and
+<tt>truncate:/path/to/file</tt>.</p>
+<p>Advanced systemd targets such as <tt>kmsg</tt>, <tt>tty</tt>,
+<tt>socket</tt>, and <tt>fd:name</tt> are also accepted.</p>
+<p>If you enter an absolute file path, it will be written as
+<tt>append:/path/to/file</tt>. Use <tt>journal</tt> to keep errors in
+<tt>journalctl</tt>, or leave empty to inherit the systemd default.</p>
@@ -0,0 +1,11 @@
+<header>Standard output</header>
+<p>Destination for the service standard output stream, written as
+<tt>StandardOutput=</tt>. Common values include <tt>journal</tt>,
+<tt>null</tt>, <tt>inherit</tt>, <tt>journal+console</tt>,
+<tt>file:/path/to/file</tt>, <tt>append:/path/to/file</tt>, and
+<tt>truncate:/path/to/file</tt>.</p>
+<p>Advanced systemd targets such as <tt>kmsg</tt>, <tt>tty</tt>,
+<tt>socket</tt>, and <tt>fd:name</tt> are also accepted.</p>
+<p>If you enter an absolute file path, it will be written as
+<tt>append:/path/to/file</tt> so output is appended instead of replacing the
+file. Leave empty to use the systemd default.</p>
@@ -0,0 +1,6 @@
+<header>Main PID</header>
+<p>The main process ID reported by systemd for this unit. It is shown only when
+systemd reports a positive process ID.</p>
+
+<p>Use the status and properties buttons for the full process and unit state
+reported by systemd.</p>
@@ -0,0 +1,4 @@
+<header>Mount options</header>
+<p>Optional comma-separated mount options, such as <tt>defaults</tt>,
+<tt>noatime</tt>, <tt>ro</tt>, or <tt>rw,nosuid,nodev</tt>. These are written
+as the <tt>Options=</tt> directive in the <tt>[Mount]</tt> section.</p>
@@ -0,0 +1,4 @@
+<header>Filesystem type</header>
+<p>The optional filesystem type passed to systemd, such as <tt>ext4</tt>,
+<tt>xfs</tt>, <tt>nfs</tt>, or <tt>tmpfs</tt>. Leave this blank when systemd
+or the mount helper can determine the type automatically.</p>
@@ -0,0 +1,5 @@
+<header>Mount source</header>
+<p>The filesystem, block device, network export, or other source to mount.
+Examples include <tt>UUID=01234567-89ab-cdef-0123-456789abcdef</tt>,
+<tt>/dev/disk/by-label/data</tt>, <tt>/dev/mapper/vg0-data</tt>,
+<tt>server:/export/path</tt>, or <tt>tmpfs</tt>.</p>
@@ -0,0 +1,4 @@
+<header>Mount point</header>
+<p>The absolute path where this filesystem will be mounted, such as
+<tt>/mnt/data</tt>. The systemd mount unit name is derived from this path, so
+<tt>/mnt/data</tt> becomes <tt>mnt-data.mount</tt>.</p>
@@ -0,0 +1,10 @@
+<header>Unit name</header>
+<p>The systemd unit name to create or edit. When creating a new unit, the suffix
+for the selected unit type is appended if it is not already included.</p>
+<p>Use a unit name such as <tt>myapp.service</tt>, <tt>myjob.timer</tt>, or
+<tt>myapp.socket</tt>, not a filesystem path.
+This is also the name other unit fields refer to, for example in
+<tt>After=</tt> or <tt>WantedBy=</tt>.</p>
+<p>For mount and automount units, the name can be left blank when a mount path
+is entered or an existing mount unit is selected. The expected systemd name
+will be derived from the mount path.</p>
@@ -0,0 +1,6 @@
+<header>Prevent gaining new privileges?</header>
+<p>Writes <tt>NoNewPrivileges=yes</tt>, preventing the service and its child
+processes from gaining additional privileges.</p>
+<p>This is a low-risk hardening option for many services. Avoid it only when
+the application intentionally relies on setuid helpers or other privilege
+elevation after startup.</p>
@@ -0,0 +1,8 @@
+<header>On failure units</header>
+<p>Units to activate when this unit enters a failed state. This writes
+<tt>OnFailure=</tt>.</p>
+<p>Enter space-separated unit names, not commands. For example,
+<tt>alert-admin@%n.service</tt> can start a separate templated service and pass
+this unit's name as <tt>%n</tt>.</p>
+<p>For services with a restart policy, the failure unit is normally activated
+only after systemd gives up and the service becomes failed.</p>
@@ -0,0 +1,8 @@
+<header>On success units</header>
+<p>Units to activate when this unit finishes successfully. This writes
+<tt>OnSuccess=</tt>.</p>
+<p>Enter space-separated unit names, not commands. This is mainly useful for
+oneshot jobs that should trigger a follow-up unit after completing normally,
+such as <tt>publish-report.service</tt>.</p>
+<p>This directive was added in systemd 249, so older distributions may ignore
+it or log a warning.</p>
@@ -0,0 +1,7 @@
+<header>Path changed</header>
+<p>An absolute path for <tt>PathChanged=</tt>. The path unit activates its target
+unit when the file is closed after being written, or when a watched directory
+changes.</p>
+<p>For user units, this path is watched by the selected user's systemd manager.
+It should be a path that user can access, typically below the user's home
+directory or runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Directory not empty</header>
+<p>An absolute directory path for <tt>DirectoryNotEmpty=</tt>. The path unit
+activates its target unit when this directory contains at least one entry.</p>
+<p>For user units, this directory is watched by the selected user's systemd
+manager. It should be a directory that user can access, typically below the
+user's home directory or runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Path exists</header>
+<p>An absolute path for <tt>PathExists=</tt>. The path unit activates its target
+unit when this file or directory exists.</p>
+<p>For user units, this path is evaluated by the selected user's systemd
+manager. It should be a path that user can access, typically below the user's
+home directory or runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,7 @@
+<header>Path exists glob</header>
+<p>An absolute shell-style glob for <tt>PathExistsGlob=</tt>, such as
+<tt>/var/spool/app/*.ready</tt>. The path unit activates its target unit when at
+least one matching file or directory exists.</p>
+<p>For user units, the glob is evaluated by the selected user's systemd
+manager. It should match paths that user can access, typically below the user's
+home directory or runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,7 @@
+<header>Create watched directory?</header>
+<p>When enabled, <tt>MakeDirectory=yes</tt> is written. systemd will create the
+watched directory if it does not already exist. This is useful for watched
+directory paths, not for watched files or glob patterns.</p>
+<p>For user units, the directory is created by the selected user's systemd
+manager, with that user's permissions. It cannot create directories that the
+user would not otherwise be allowed to create.</p>
@@ -0,0 +1,6 @@
+<header>Path modified</header>
+<p>An absolute path for <tt>PathModified=</tt>. The path unit activates its
+target unit when the file or directory is modified.</p>
+<p>For user units, this path is watched by the selected user's systemd manager.
+It should be a path that user can access, typically below the user's home
+directory or runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,4 @@
+<header>Unit to activate</header>
+<p>The unit activated by this path unit, written as <tt>Unit=</tt>. Include the
+full unit name and suffix, such as <tt>reload-config.service</tt>. If omitted,
+systemd uses the matching service name.</p>
@@ -0,0 +1,7 @@
+<header>PID file</header>
+<p>Path to a PID file for <tt>forking</tt> services. This writes
+<tt>PIDFile=</tt>.</p>
+<p>Use an absolute path to the file written by the daemon after it forks, such
+as <tt>/run/myapp.pid</tt>. This helps systemd identify the main process.</p>
+<p>For user units, use a path writable by the selected user, typically below
+the user's runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Use private temporary directory?</header>
+<p>Writes <tt>PrivateTmp=yes</tt>, giving the service a private view of
+temporary directories such as <tt>/tmp</tt>.</p>
+<p>This helps isolate temporary files from the rest of the system. Do not use
+it when the service must share files through <tt>/tmp</tt> with other
+processes.</p>
@@ -0,0 +1,10 @@
+<header>Protect system files</header>
+<p>Restricts write access to system directories using
+<tt>ProtectSystem=</tt>. Stronger values provide stricter filesystem
+protection.</p>
+<p><tt>true</tt> makes core system directories such as <tt>/usr</tt> and
+<tt>/boot</tt> read-only. <tt>full</tt> also protects <tt>/etc</tt>.
+<tt>strict</tt> makes the filesystem broadly read-only except for API
+filesystems and paths explicitly made writable.</p>
+<p>Use <tt>ReadWritePaths=</tt> for directories the service still needs to
+modify.</p>
@@ -0,0 +1,11 @@
+<header>Writable paths</header>
+<p>Paths that remain writable when filesystem protection is enabled. This
+writes <tt>ReadWritePaths=</tt>.</p>
+<p>Enter space-separated absolute paths, such as <tt>/var/lib/myapp
+/var/log/myapp</tt>. This is typically used with <tt>ProtectSystem=full</tt>
+or <tt>ProtectSystem=strict</tt>.</p>
+<p>Advanced systemd path prefixes such as <tt>-</tt> for optional paths are
+accepted when needed.</p>
+<p>For user units, these should be paths the selected user can access,
+typically below that user's home directory. They cannot make system
+directories writable to the user.</p>
@@ -0,0 +1,7 @@
+<header>Commands to run on reload</header>
+<p>Commands run when the service is reloaded. These are written as
+<tt>ExecReload=</tt> entries.</p>
+<p>Enter one command per line. Use this for a real application reload, such as
+sending <tt>HUP</tt> to the main process or running the daemon's own reload
+command. Leave empty if the service cannot reload configuration without a
+restart.</p>
@@ -0,0 +1,5 @@
+<header>Remain active after command exits?</header>
+<p>Writes <tt>RemainAfterExit=yes</tt>. This is most useful for
+<tt>oneshot</tt> services whose command exits after changing system state.</p>
+<p>When enabled, systemd keeps the service in the active state after the start
+command exits. This lets a later stop command undo the action.</p>
@@ -0,0 +1,6 @@
+<header>Requires units</header>
+<p>Strong dependencies for this unit. If a required unit fails to start or is
+stopped, this unit is also affected.</p>
+<p>Enter space-separated unit names. Use this when the unit cannot run
+without the listed units. Add <tt>After=</tt> as well when the dependency must
+be fully started before this unit starts.</p>
@@ -0,0 +1,9 @@
+<header>Restart policy</header>
+<p>Controls when systemd restarts the service after it exits. This writes
+<tt>Restart=</tt>.</p>
+<p><tt>no</tt> disables automatic restarts. <tt>on-failure</tt> restarts after
+non-zero exits, signals, timeouts, and watchdog failures. <tt>always</tt>
+restarts after almost any exit except an explicit stop by systemd.</p>
+<p><tt>on-success</tt>, <tt>on-abnormal</tt>, <tt>on-abort</tt>, and
+<tt>on-watchdog</tt> are narrower policies. For ordinary server processes,
+<tt>on-failure</tt> is usually the practical choice.</p>
@@ -0,0 +1,6 @@
+<header>Restart delay</header>
+<p>Delay before systemd restarts the service, written as
+<tt>RestartSec=</tt>. Values may use systemd time syntax such as <tt>5s</tt>
+or <tt>1min</tt>.</p>
+<p>Use this with a restart policy to avoid tight restart loops, for example
+<tt>5s</tt> or <tt>30s</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Runtime state</header>
+<p>The active state and sub-state reported by systemd, such as
+<tt>active (running)</tt>, <tt>active (exited)</tt>, <tt>inactive (dead)</tt>
+or <tt>failed</tt>.</p>
+
+<p>Use the status and log buttons for the full systemd and journal output.</p>
@@ -0,0 +1,10 @@
+<header>Service type</header>
+<p>The systemd <tt>Type=</tt> value. Leave as default for ordinary long-running
+commands unless the service needs another startup protocol such as
+<tt>forking</tt>, <tt>oneshot</tt>, or <tt>notify</tt>.</p>
+<p><tt>simple</tt> treats the started process as the service immediately.
+<tt>exec</tt> is similar but waits until the command has been executed.
+<tt>forking</tt> is for daemons that background themselves and often needs a
+PID file. <tt>oneshot</tt> is for short tasks that exit. <tt>dbus</tt> and
+<tt>notify</tt> wait for D-Bus ownership or systemd readiness notification.
+<tt>idle</tt> delays execution until other jobs are dispatched.</p>
@@ -0,0 +1,6 @@
+<header>CPU weight</header>
+<p>An optional <tt>CPUWeight=</tt> value from <tt>1</tt> to <tt>10000</tt>.
+Higher values give this slice a larger share of CPU time when there is
+contention.</p>
+<p>For user units, this applies only within the selected user's systemd
+manager and cannot grant CPU share beyond that user's parent cgroup.</p>
@@ -0,0 +1,6 @@
+<header>I/O weight</header>
+<p>An optional <tt>IOWeight=</tt> value from <tt>1</tt> to <tt>10000</tt>.
+Higher values give this slice a larger share of I/O bandwidth when there is
+contention.</p>
+<p>For user units, this applies only within the selected user's systemd
+manager and cannot grant I/O share beyond that user's parent cgroup.</p>
@@ -0,0 +1,5 @@
+<header>Memory maximum</header>
+<p>An optional <tt>MemoryMax=</tt> limit for the slice, such as <tt>512M</tt>,
+<tt>2G</tt>, or <tt>infinity</tt>.</p>
+<p>For user units, this applies only within the selected user's systemd
+manager and cannot raise limits imposed by the user's parent cgroup.</p>
@@ -0,0 +1,5 @@
+<header>Tasks maximum</header>
+<p>An optional <tt>TasksMax=</tt> limit for the slice, such as <tt>500</tt> or
+<tt>infinity</tt>.</p>
+<p>For user units, this applies only within the selected user's systemd
+manager and cannot raise limits imposed by the user's parent cgroup.</p>
@@ -0,0 +1,7 @@
+<header>Accept each connection?</header>
+<p>When enabled, <tt>Accept=yes</tt> is written and systemd starts one service
+instance for each incoming connection. Leave disabled for the common model where
+one service handles all traffic.</p>
+<p>Per-connection sockets normally activate a template-style service that can
+handle instances. Use <tt>Accept=no</tt> when a single service should receive
+all accepted connections from the socket.</p>
@@ -0,0 +1,5 @@
+<header>Socket group</header>
+<p>The Unix group name for <tt>SocketGroup=</tt>. This controls group ownership
+of the socket node when systemd creates filesystem sockets or FIFOs.</p>
+<p>For user units, filesystem sockets and FIFOs are created by the selected
+user's systemd manager. This guided field is used only for system units.</p>
@@ -0,0 +1,4 @@
+<header>Datagram listener</header>
+<p>A <tt>ListenDatagram=</tt> endpoint for UDP or datagram sockets. Examples
+include <tt>514</tt>, <tt>127.0.0.1:10514</tt>, or an absolute filesystem
+socket path.</p>
@@ -0,0 +1,6 @@
+<header>FIFO listener</header>
+<p>An absolute path for <tt>ListenFIFO=</tt>. systemd creates or opens this FIFO
+and activates the matching service when data is written to it.</p>
+<p>For user units, the FIFO is created by the selected user's systemd manager.
+Use a path that user can create, typically below the user's home directory or
+runtime directory such as <tt>/run/user/UID</tt>.</p>
@@ -0,0 +1,3 @@
+<header>Stream listener</header>
+<p>A <tt>ListenStream=</tt> endpoint for TCP or stream sockets. Examples include
+<tt>8080</tt>, <tt>127.0.0.1:8080</tt>, or an absolute filesystem socket path.</p>
@@ -0,0 +1,4 @@
+<header>Socket mode</header>
+<p>The file mode for <tt>SocketMode=</tt>, such as <tt>0660</tt> or
+<tt>0600</tt>. This applies to filesystem sockets and FIFOs created by
+systemd.</p>
@@ -0,0 +1,8 @@
+<header>Service to activate</header>
+<p>The service unit activated by this socket, written as <tt>Service=</tt>.
+Include the full service name, such as <tt>example.service</tt>. If omitted,
+systemd uses the matching service name.</p>
+<p>For the common <tt>Accept=no</tt> model, this is usually a normal service.
+When <tt>Accept=yes</tt> is enabled, use a service that is designed to run as
+one instance per connection, typically a template such as
+<tt>example@.service</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Socket owner</header>
+<p>The Unix user name for <tt>SocketUser=</tt>. This controls ownership of the
+socket node when systemd creates filesystem sockets or FIFOs.</p>
+<p>For user units, filesystem sockets and FIFOs are created by the selected
+user's systemd manager and are owned by that user. This guided field is used
+only for system units.</p>
@@ -0,0 +1,10 @@
+<header>Commands to run on startup</header>
+<p>Commands run by systemd when a service starts. These are written as
+<tt>ExecStart=</tt> entries in the unit file and apply only to
+<tt>.service</tt> units.</p>
+<p>Enter one command per line. For ordinary long-running daemons this is
+usually a single absolute command, for example <tt>/usr/bin/node
+/home/app/server.js</tt>.</p>
+<p>Multiple start commands are best used with <tt>Type=oneshot</tt>. For other
+service types, multiple commands are combined through a shell command so
+systemd still has one main process to track.</p>
@@ -0,0 +1,5 @@
+<header>Commands to run after startup</header>
+<p>Commands run after the main start command. These are written as
+<tt>ExecStartPost=</tt> entries.</p>
+<p>Enter one command per line. These run only after systemd considers the main
+start command successful according to the selected service type.</p>
@@ -0,0 +1,6 @@
+<header>Commands to run before startup</header>
+<p>Commands run before the main start command. These are written as
+<tt>ExecStartPre=</tt> entries.</p>
+<p>Enter one command per line. Use this for quick setup checks, migrations, or
+directory preparation. Long-running background processes should not be started
+from pre-start commands.</p>
@@ -0,0 +1,11 @@
+<header>Status details</header>
+<p>The unit file state and runtime state reported by systemd. The unit file
+state shows whether the unit is enabled, disabled, static, masked or in another
+systemd state.</p>
+<p>The runtime state shows the active state and sub-state, such as
+<tt>active (running)</tt>, <tt>active (exited)</tt>, <tt>inactive (dead)</tt> or
+<tt>failed</tt>. If systemd reports a main process ID, it is shown separately.
+Use the status and log buttons for the full systemd and journal output.</p>
+<p>Units with transient or generated file state are managed by systemd at
+runtime. Their contents may be shown for inspection, but they are read-only in
+the editor.</p>
@@ -0,0 +1,7 @@
+<header>Commands to run on shutdown</header>
+<p>Optional commands run when a service is stopped. These are written as
+<tt>ExecStop=</tt> entries in the unit file and apply only to
+<tt>.service</tt> units.</p>
+<p>Use this when the application has its own graceful shutdown command. If this
+is left empty, systemd stops the service using its normal signal and
+<tt>KillMode=</tt> behavior.</p>
@@ -0,0 +1,6 @@
+<header>Commands to run after shutdown</header>
+<p>Commands run after the service stops. These are written as
+<tt>ExecStopPost=</tt> entries.</p>
+<p>Enter one command per line. These can be used for cleanup, notification, or
+removing temporary files, including cases where the service exited
+unexpectedly.</p>
@@ -0,0 +1,3 @@
+<header>Swap options</header>
+<p>Optional comma-separated swap options for <tt>Options=</tt>. These are passed
+to the swap activation tools.</p>
@@ -0,0 +1,3 @@
+<header>Swap priority</header>
+<p>An optional numeric <tt>Priority=</tt> value. Higher-priority swap areas are
+used first. Negative values are allowed by systemd.</p>
@@ -0,0 +1,3 @@
+<header>Swap timeout</header>
+<p>An optional <tt>TimeoutSec=</tt> value for swap activation, such as
+<tt>30s</tt> or <tt>2min</tt>.</p>
@@ -0,0 +1,3 @@
+<header>Swap device or file</header>
+<p>The swap device or swap file for <tt>What=</tt>. Use an absolute path such as
+<tt>/swapfile</tt> or a stable device path under <tt>/dev/disk/by-uuid</tt>.</p>
@@ -0,0 +1,5 @@
+<header>Log identifier</header>
+<p>Name used to identify log messages from this service in the systemd journal
+or syslog. This writes the systemd <tt>SyslogIdentifier=</tt> directive.</p>
+<p>Use a short stable name, such as <tt>myapp</tt>. This makes log filtering
+easier when multiple commands or wrappers write to the journal.</p>
@@ -0,0 +1,7 @@
+<header>Startup timeout</header>
+<p>Maximum time systemd waits for the service to start. This writes
+<tt>TimeoutStartSec=</tt>.</p>
+<p>Use systemd time syntax such as <tt>30s</tt>, <tt>2min</tt>, or <tt>0</tt>
+to disable the timeout. This matters most for service types where systemd waits
+for readiness, such as <tt>forking</tt>, <tt>notify</tt>, and
+<tt>oneshot</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Shutdown timeout</header>
+<p>Maximum time systemd waits for the service to stop cleanly. This writes
+<tt>TimeoutStopSec=</tt>.</p>
+<p>After this timeout, systemd may force termination according to the service
+kill settings. Increase it for applications that need time to flush data or
+shut down cleanly.</p>
@@ -0,0 +1,4 @@
+<header>Timer accuracy</header>
+<p>An optional <tt>AccuracySec=</tt> value. systemd may coalesce timer events
+within this window to reduce wakeups. Smaller values are more exact; larger
+values are more power-efficient.</p>
@@ -0,0 +1,4 @@
+<header>Delay after boot</header>
+<p>A monotonic delay for <tt>OnBootSec=</tt>. The timer will fire this long
+after the system boots, for example <tt>5min</tt>, <tt>1h</tt>, or
+<tt>30s</tt>.</p>
@@ -0,0 +1,4 @@
+<header>Calendar schedule</header>
+<p>A calendar expression for <tt>OnCalendar=</tt>. Use values such as
+<tt>hourly</tt>, <tt>daily</tt>, <tt>weekly</tt>, or a full systemd calendar
+expression such as <tt>Mon..Fri 02:30</tt>.</p>
@@ -0,0 +1,4 @@
+<header>Delay after activation</header>
+<p>A monotonic delay for <tt>OnUnitActiveSec=</tt>. The timer will run again
+this long after the activated unit last became active, for example
+<tt>15min</tt> or <tt>1h</tt>.</p>
@@ -0,0 +1,6 @@
+<header>Catch up missed runs?</header>
+<p>When enabled, <tt>Persistent=yes</tt> is written. For calendar timers, this
+lets systemd run the timer once when it becomes active again if a scheduled run
+was missed while the manager was stopped or the system was off.</p>
+<p>This does not catch up monotonic timers such as <tt>OnBootSec=</tt> or
+<tt>OnUnitActiveSec=</tt>.</p>
@@ -0,0 +1,4 @@
+<header>Randomized delay</header>
+<p>An optional <tt>RandomizedDelaySec=</tt> value. systemd will delay each run by
+a random amount up to this value, which helps avoid many timers starting at the
+same instant.</p>
@@ -0,0 +1,4 @@
+<header>Unit to activate</header>
+<p>The unit activated by this timer, written as <tt>Unit=</tt>. Include the full
+unit name and suffix, such as <tt>backup.service</tt>. If omitted, systemd uses
+the matching service name.</p>
@@ -0,0 +1,18 @@
+<header>Unit type</header>
+<p>The type of system unit to create. The selected type controls the filename
+suffix and the type-specific section written to the unit file. Created system
+units are written below <tt>/etc/systemd/system</tt>.</p>
+<p><tt>service</tt> creates a guided <tt>[Service]</tt> unit for starting and
+supervising a process. <tt>timer</tt> creates a <tt>[Timer]</tt> unit that
+activates another unit on a schedule. <tt>socket</tt> creates a
+<tt>[Socket]</tt> unit for socket activation. <tt>path</tt> creates a
+<tt>[Path]</tt> unit that reacts to filesystem changes. <tt>target</tt>
+creates a grouping or synchronization point for other units.</p>
+<p><tt>mount</tt> creates a <tt>[Mount]</tt> unit for a filesystem mount, and
+<tt>automount</tt> creates a matching <tt>[Automount]</tt> unit that activates
+a mount on demand. <tt>swap</tt> creates a <tt>[Swap]</tt> unit for swap space.
+<tt>slice</tt> creates a <tt>[Slice]</tt> unit for resource-control grouping
+and cgroup policy.</p>
+<p>Scope and device units are normally created by systemd, udev, or other
+programs at runtime. They can be inspected when listed by systemd, but they are
+not created as persistent unit files here.</p>
@@ -0,0 +1,21 @@
+<header>Unit type</header>
+<p>The type of user unit to create. The selected type controls the filename
+suffix and the type-specific section written to the unit file. Created user
+units are written below the selected user's
+<tt>~/.config/systemd/user</tt> directory.</p>
+<p><tt>service</tt> creates a guided <tt>[Service]</tt> unit for starting and
+supervising a process as this Unix user. <tt>timer</tt> creates a
+<tt>[Timer]</tt> unit that activates another user unit on a schedule.
+<tt>socket</tt> creates a <tt>[Socket]</tt> unit for user-level socket
+activation. <tt>path</tt> creates a <tt>[Path]</tt> unit that reacts to
+filesystem changes visible to this user. <tt>target</tt> creates a grouping or
+synchronization point for other user units.</p>
+<p><tt>slice</tt> creates a <tt>[Slice]</tt> unit for grouping this user's own
+units and applying resource-control settings such as <tt>CPUWeight=</tt>,
+<tt>MemoryMax=</tt>, <tt>TasksMax=</tt>, or <tt>IOWeight=</tt>. These limits
+apply only within the user's systemd manager and cannot grant control over
+system slices or other users.</p>
+<p>Mount, automount and swap units are system-manager unit types and are not
+available when creating user units. Scope and device units are created at
+runtime by systemd or other programs and are not created as persistent unit
+files here.</p>
@@ -0,0 +1,7 @@
+<header>Unit file state</header>
+<p>The unit file state reported by systemd. It shows whether the unit is
+enabled, disabled, static, masked or in another systemd state.</p>
+
+<p>Units with transient or generated file state are managed by systemd at
+runtime. Their contents may be shown for inspection, but they are read-only in
+the editor.</p>
@@ -0,0 +1,31 @@
+<header>Type-specific settings</header>
+<p>Directives for the selected non-service unit type. Enter directives only,
+without the section header; the correct section will be written, such as
+<tt>[Timer]</tt>, <tt>[Socket]</tt>, <tt>[Path]</tt>, <tt>[Mount]</tt>,
+<tt>[Automount]</tt>, <tt>[Swap]</tt>, or <tt>[Slice]</tt>.</p>
+<p>Mount and automount units have dedicated fields for their common settings.
+Use this field only for uncommon directives that are not shown elsewhere in
+the form.</p>
+<p>For a timer, examples include <tt>OnCalendar=daily</tt>,
+<tt>Persistent=true</tt>, and <tt>Unit=myjob.service</tt>. If <tt>Unit=</tt>
+is omitted, systemd activates the service with the same base name, such as
+<tt>myjob.service</tt> for <tt>myjob.timer</tt>.</p>
+<p>For a socket, examples include <tt>ListenStream=8080</tt>,
+<tt>ListenStream=/run/myapp.sock</tt>, <tt>Accept=false</tt>, and
+<tt>Service=myapp.service</tt>. For user units, filesystem socket paths should
+be below a location the selected user can write, such as
+<tt>/run/user/UID</tt>. If <tt>Service=</tt> is omitted, systemd uses the
+service with the same base name.</p>
+<p>For a path unit, examples include <tt>PathChanged=/srv/myapp</tt>,
+<tt>PathExists=/var/run/myapp.ready</tt>, and <tt>Unit=myjob.service</tt>.
+For user units, watched paths should normally be below the selected user's
+home directory or runtime directory.</p>
+<p>Target units do not need a type-specific settings body in this form.
+Dependencies such as <tt>Wants=</tt>, <tt>Requires=</tt>, <tt>Before=</tt>,
+and <tt>After=</tt> are set in the common advanced options.</p>
+<p>For a swap unit, examples include <tt>What=/swapfile</tt> and
+<tt>Priority=10</tt>. For a slice unit, use the dedicated fields for
+CPU weight, memory maximum, task maximum, and I/O weight; this field can be
+used for additional resource controls such as <tt>CPUQuota=50%</tt> or
+<tt>MemoryHigh=256M</tt>. For user units, slice resource controls apply only
+within the selected user's systemd manager.</p>
@@ -0,0 +1,5 @@
+<header>User service owner</header>
+<p>The Unix user whose home directory and systemd user manager own the user
+unit. The account is resolved with the local password database.</p>
+<p>The unit file is written below this user's home directory in
+<tt>~/.config/systemd/user</tt> and is owned by that account.</p>
@@ -0,0 +1,7 @@
+<header>Run as user</header>
+<p>For system services, writes <tt>User=</tt> so the service process runs as
+the selected Unix user. This option is hidden for user units.</p>
+<p>Use this when creating a system service that should be managed by the system
+manager but should drop privileges before running the application process.</p>
+<p>This is different from creating a user unit. A user unit is owned and
+managed by the user's systemd manager and does not need <tt>User=</tt>.</p>
@@ -0,0 +1,10 @@
+<header>Create as user unit?</header>
+<p>Creates the unit under the selected user's <tt>~/.config/systemd/user</tt>
+directory and manages it with <tt>systemctl --user</tt>.</p>
+<p>User units run inside the user's systemd manager. For service units,
+<tt>User=</tt> and <tt>Group=</tt> are not written because the user manager
+already runs as that user.</p>
+<p>Choose this for applications that belong to a user account and should use
+that user's home directory, environment, and user unit lifecycle. Choose
+No for a normal system unit, even if a service unit later uses
+<tt>User=</tt> to drop privileges.</p>
--- a/Show More
+++ b/Show More