Add Systemd Services and Units module

This PR adds a standalone Systemd Services and Units module for managing systemd units across system and user scopes.

The module keeps systemd-specific behavior separate from the legacy Bootup and Shutdown module and is implemented as standalone `strict`/`warnings` Perl code rather than depending on its existing init helpers. Those helpers intentionally smooth over multiple init systems, while this module keeps systemd-specific file handling, user-manager behavior, ACL checks, and control operations explicit, scoped, and easier to audit.

It includes:

- Tabbed views for services, timers, sockets, paths, targets, storage, resources, devices, and user units
- Guided creation and editing for common unit types, with contextual fields, validation, and help
- User-scoped unit management with linger support and safe handling of home-directory unit files
- Runtime actions for start, stop, restart, enable, disable, status, logs, properties, dependencies, and system-unit mask/unmask
- Drop-in override inventory plus create, edit, and delete flows
- Manual unit-file editing with daemon reload reminders and actions
- Configurable module behavior, visible tabs, display options, and post-create navigation
- Comprehensive ACL controls for system/user scopes, actions, manual edits, drop-ins, linger, reload, backup, and user filters
- Safe Webmin user support through a scoped safe ACL preset
- Virtualmin integration for granting domain owners access to their own systemd user units
- Tests for unit generation, safety checks, ACL behavior, user-unit handling, backup coverage, and Perl::Critic compatibility

A companion Virtualmin PR adds template integration so domain owners can be granted scoped access to their own systemd user units when this module is installed.

mod_core_list.txt

@@ -1 +1 @@
-acl apache authentic-theme backup-config bind8 change-user cron dovecot fail2ban fdisk filemin firewalld fsdump gray-theme htaccess-htpasswd init logrotate logviewer lvm mailboxes mailcap mount mysql net package-updates passwd phpini postfix proc procmail proftpd quota servers software spam sshd status system-status time updown useradmin usermin webmin webmincron webminlog xterm
+acl apache authentic-theme backup-config bind8 change-user cron dovecot fail2ban fdisk filemin firewalld fsdump gray-theme htaccess-htpasswd init systemd logrotate logviewer lvm mailboxes mailcap mount mysql net package-updates passwd phpini postfix proc procmail proftpd quota servers software spam sshd status system-status time updown useradmin usermin webmin webmincron webminlog xterm

mod_full_list.txt

@@ -1 +1 @@
-acl adsl-client apache at authentic-theme backup-config bacula-backup bandwidth bind8 bsdexports bsdfdisk change-user cluster-copy cluster-cron cluster-passwd cluster-shell cluster-software cluster-useradmin cluster-usermin cluster-webmin cpan cron custom dfsadmin dhcpd dovecot exim exports fail2ban fdisk fetchmail filemin filter firewall firewall6 firewalld format fsdump gray-theme grub2 heartbeat hpuxexports htaccess-htpasswd idmapd inetd init inittab ipfilter ipfw ipsec iscsi-client iscsi-server iscsi-target iscsi-tgtd kea-dhcp krb5 ldap-client ldap-server ldap-useradmin logrotate logviewer lpadmin lvm mailboxes mailcap man mount mysql net nftables nginx nis openslp package-updates pam pap passwd phpini postfix postgresql ppp-client pptp-client pptp-server proc procmail proftpd qmailadmin quota raid rbac samba sarg sendmail servers sgiexports shell shorewall shorewall6 smart-status smf software spam squid sshd status stunnel syslog syslog-ng system-status tcpwrappers time tunnel updown useradmin usermin webalizer webmin webmincron webminlog xinetd xterm zones
+acl adsl-client apache at authentic-theme backup-config bacula-backup bandwidth bind8 bsdexports bsdfdisk change-user cluster-copy cluster-cron cluster-passwd cluster-shell cluster-software cluster-useradmin cluster-usermin cluster-webmin cpan cron custom dfsadmin dhcpd dovecot exim exports fail2ban fdisk fetchmail filemin filter firewall firewall6 firewalld format fsdump gray-theme grub2 heartbeat hpuxexports htaccess-htpasswd idmapd inetd init systemd inittab ipfilter ipfw ipsec iscsi-client iscsi-server iscsi-target iscsi-tgtd kea-dhcp krb5 ldap-client ldap-server ldap-useradmin logrotate logviewer lpadmin lvm mailboxes mailcap man mount mysql net nftables nginx nis openslp package-updates pam pap passwd phpini postfix postgresql ppp-client pptp-client pptp-server proc procmail proftpd qmailadmin quota raid rbac samba sarg sendmail servers sgiexports shell shorewall shorewall6 smart-status smf software spam squid sshd status stunnel syslog syslog-ng system-status tcpwrappers time tunnel updown useradmin usermin webalizer webmin webmincron webminlog xinetd xterm zones

systemd/acl_security.pl

@@ -0,0 +1,81 @@
+use strict;
+use warnings;
+no warnings 'redefine';
+
+require 'systemd-lib.pl'; ## no critic
+
+our (%in, %text);
+
+# acl_security_form(options)
+# Outputs ACL controls for granting access to systemd unit management.
+sub acl_security_form
+{
+my ($o) = @_;
+my $m = $o->{'mode'} || 0;
+
+print ui_table_span(ui_tag('b', html_escape($text{'acl_section_users'})));
+print ui_table_row($text{'acl_users'},
+	ui_radio("mode", $m,
+	 [ [ 0, "$text{'acl_all'}<br>" ],
+	   [ 3, "$text{'acl_this'}<br>" ],
+	   [ 1, $text{'acl_only'}." ".
+		ui_textbox("userscan",
+			$m == 1 ? $o->{'users'} : "", 40)." ".
+		user_chooser_button("userscan", 1)."<br>" ],
+	   [ 2, $text{'acl_except'}." ".
+		ui_textbox("userscannot",
+			$m == 2 ? $o->{'users'} : "", 40)." ".
+		user_chooser_button("userscannot", 1)."<br>" ],
+	   [ 5, $text{'acl_gid'}." ".
+		ui_textbox("gid",
+		    $m == 5 ? scalar(getgrgid($o->{'users'})) : "", 13)." ".
+		group_chooser_button("gid", 0)."<br>" ],
+	   [ 4, $text{'acl_uid'}." ".
+		ui_textbox("uidmin", $o->{'uidmin'}, 6)." - ".
+		ui_textbox("uidmax", $o->{'uidmax'}, 6)."<br>" ],
+	 ]), 3, undef, undef, 1);
+print ui_table_hr();
+
+print ui_table_span(ui_tag('b', html_escape($text{'acl_section_view'})));
+foreach my $a (qw(view view_user status status_user logs logs_user)) {
+	print ui_table_row($text{'acl_'.$a},
+			   ui_yesno_radio($a, $o->{$a}), 3);
+	}
+print ui_table_hr();
+
+print ui_table_span(ui_tag('b', html_escape($text{'acl_section_runtime'})));
+foreach my $a (qw(start start_user stop stop_user restart restart_user
+		  boot boot_user mask mask_user reload linger)) {
+	print ui_table_row($text{'acl_'.$a},
+			   ui_yesno_radio($a, $o->{$a}), 3);
+	}
+print ui_table_hr();
+
+print ui_table_span(ui_tag('b', html_escape($text{'acl_section_change'})));
+foreach my $a (qw(create create_user edit edit_user delete delete_user
+		  dropin dropin_user manual manual_user backup)) {
+	print ui_table_row($text{'acl_'.$a},
+			   ui_yesno_radio($a, $o->{$a}), 3);
+	}
+}
+
+# acl_security_save(options)
+# Saves systemd ACL settings from the submitted form.
+sub acl_security_save
+{
+my ($o) = @_;
+
+my $mode = defined($in{'mode'}) && $in{'mode'} =~ /^[0-5]$/ ?
+	$in{'mode'} : 0;
+$o->{'mode'} = $mode;
+$o->{'users'} = $mode == 0 || $mode == 3 || $mode == 4 ? "" :
+		$mode == 5 ? scalar(getgrnam($in{'gid'} || "")) || "" :
+		$mode == 1 ? $in{'userscan'} || "" : $in{'userscannot'} || "";
+$o->{'uidmin'} = $mode == 4 ? $in{'uidmin'} || "" : "";
+$o->{'uidmax'} = $mode == 4 ? $in{'uidmax'} || "" : "";
+foreach my $a (systemd_acl_keys()) {
+	$o->{$a} = $in{$a} || 0;
+	}
+}
+
+1;

systemd/backup_config.pl

@@ -0,0 +1,83 @@
+use strict;
+use warnings;
+
+require 'systemd-lib.pl'; ## no critic
+
+our %access;
+
+# backup_config_files()
+# Returns local system and user unit files that should be included in backups.
+sub backup_config_files
+{
+my @rv;
+my %seen;
+return @rv if (!systemd_acl_bool(\%access, 'backup'));
+my $add_file = sub {
+	my ($file) = @_;
+	push(@rv, $file) if ($file && !$seen{$file}++);
+	};
+
+# System unit backups should only include locally managed files under /etc.
+foreach my $u (list_units()) {
+	$add_file->($u->{'file'})
+		if ($u->{'file'} && $u->{'file'} =~ m!^/etc/systemd/system/!);
+	my $name = backup_unit_name($u);
+	if ($name && dropin_exists(0, undef, $name)) {
+		$add_file->(system_dropin_file($name));
+		}
+	}
+
+# User units live under home directories and are safe to include by path.
+foreach my $u (list_all_user_units()) {
+	next if (!systemd_acl_user_allowed(\%access, $u->{'user'}));
+	$add_file->($u->{'file'}) if ($u->{'file'});
+	my $name = backup_unit_name($u);
+	if ($name && dropin_exists(1, $u->{'user'}, $name)) {
+		$add_file->(user_dropin_file($u->{'user'}, $name));
+		}
+	}
+return @rv;
+}
+
+# backup_unit_name(unit)
+# Returns the safe unit name from a listed unit row.
+sub backup_unit_name
+{
+my ($u) = @_;
+return $u->{'name'} if ($u->{'name'} && valid_unit_name($u->{'name'}));
+if ($u->{'file'} && $u->{'file'} =~ m{/([^/]+)$} &&
+    valid_unit_name($1)) {
+	return $1;
+	}
+return;
+}
+
+# pre_backup()
+# No preparation is needed before Webmin copies systemd unit files.
+sub pre_backup
+{
+return;
+}
+
+# post_backup()
+# No cleanup is needed after Webmin copies systemd unit files.
+sub post_backup
+{
+return;
+}
+
+# pre_restore()
+# No preparation is needed before Webmin restores systemd unit files.
+sub pre_restore
+{
+return;
+}
+
+# post_restore()
+# Reloads systemd after restored unit files are back on disk.
+sub post_restore
+{
+reload_manager();
+}
+
+1;

systemd/config

@@ -0,0 +1,11 @@
+desc=1
+logs_lines=200
+logs_current_boot=0
+visible_tabs=service,timer,socket,path,target,storage,resources,device,user
+show_runtime_units=1
+default_create_scope=system
+manual_vendor_units=1
+default_linger=1
+show_unit_suffixes=0
+show_dropin_inventory=1
+create_return_index=0

systemd/config.info

@@ -0,0 +1,11 @@
+desc=Display unit descriptions,1,1-Yes,0-No
+logs_lines=Number of journal log lines to show,0
+logs_current_boot=Journal log scope,1,1-Current boot only,0-All available logs
+visible_tabs=Tabs to show on the index page,15,visible_tabs
+show_runtime_units=Show generated and transient units,1,1-Yes,0-No
+default_create_scope=Default scope for new units,1,system-System units,user-User units
+manual_vendor_units=Include vendor unit files in the manual editor,1,1-Yes,0-No
+default_linger=Enable linger by default for new user units,1,1-Yes,0-No
+show_unit_suffixes=Show full unit names with type suffixes,1,1-Yes,0-No
+show_dropin_inventory=Show drop-in override inventory,1,1-Yes,0-No
+create_return_index=Return to index after creating a new unit,1,1-Yes,0-No

systemd/config_info.pl

@@ -0,0 +1,34 @@
+use strict;
+use warnings;
+
+require './systemd-lib.pl'; ## no critic
+
+our (%in, %text);
+
+# show_visible_tabs(value)
+# Returns checkbox controls for choosing which index tabs are visible.
+sub show_visible_tabs
+{
+my ($value) = @_;
+my %enabled = map { $_, 1 } split(/\s*,\s*/, $value || default_visible_tabs());
+my @fields;
+foreach my $tab (get_index_tab_ids()) {
+	my $label = $text{'systemd_tab_'.$tab} || ucfirst($tab);
+	push(@fields, ui_checkbox(
+		"visible_tabs", $tab, $label, $enabled{$tab}));
+	}
+return join(" ", @fields);
+}
+
+# parse_visible_tabs(value)
+# Returns selected tab IDs, and rejects saving with every tab hidden.
+sub parse_visible_tabs
+{
+my @tabs = split(/\0/, $in{'visible_tabs'} || "");
+my %valid = map { $_, 1 } get_index_tab_ids();
+@tabs = grep { $valid{$_} } @tabs;
+@tabs || error($text{'systemd_evisibletabs'});
+return join(",", @tabs);
+}
+
+1;

systemd/defaultacl

@@ -0,0 +1,34 @@
+view=1
+view_user=1
+status=1
+status_user=1
+logs=1
+logs_user=1
+start=1
+start_user=1
+stop=1
+stop_user=1
+restart=1
+restart_user=1
+boot=1
+boot_user=1
+mask=1
+mask_user=1
+create=1
+create_user=1
+edit=1
+edit_user=1
+delete=1
+delete_user=1
+dropin=1
+dropin_user=1
+manual=1
+manual_user=1
+reload=1
+linger=1
+backup=1
+mode=0
+users=
+uidmin=
+uidmax=
+noconfig=0

systemd/dropins.cgi

@@ -0,0 +1,122 @@
+#!/usr/local/bin/perl
+# Show an inventory of discovered systemd drop-in override files.
+
+use strict;
+use warnings;
+
+require './systemd-lib.pl'; ## no critic
+
+our (%access, %config, %text);
+
+ReadParse();
+
+has_command("systemctl") || error($text{'systemd_esystemctl'});
+systemd_can_enter_module(\%access) || systemd_acl_error('penter');
+$config{'show_dropin_inventory'} || error($text{'dropins_disabled'});
+
+my $can_system = systemd_can_view_system(\%access);
+my $can_user = systemd_can_view_user_scope(\%access);
+
+my @system_units = $can_system ? list_units() : ( );
+my %system_units = map { $_->{'name'}, $_ } @system_units;
+my @user_units = $can_user ?
+	grep { systemd_acl_user_allowed(\%access, $_->{'user'}) }
+	     list_all_user_units() : ( );
+my %user_units = map { $_->{'user'}."\t".$_->{'name'}, $_ } @user_units;
+
+my @dropins;
+push(@dropins, list_system_dropin_override_files()) if ($can_system);
+if ($can_user) {
+	foreach my $dropin (list_all_user_dropin_override_files()) {
+		next if (!systemd_acl_user_allowed(\%access, $dropin->{'user'}));
+		push(@dropins, $dropin);
+		}
+	}
+@dropins = sort { $a->{'scope'} cmp $b->{'scope'} ||
+		  ($a->{'user'} || "") cmp ($b->{'user'} || "") ||
+		  $a->{'unit'} cmp $b->{'unit'} ||
+		  $a->{'file'} cmp $b->{'file'} } @dropins;
+
+ui_print_header(undef, $text{'dropins_title'}, "", "intro", undef, 1,
+		undef, action_links());
+
+print ui_tag('p', $text{'dropins_desc'});
+if (!@dropins) {
+	print ui_tag('p', $text{'dropins_empty'});
+	}
+else {
+	print_dropin_table(\@dropins, \%system_units, \%user_units);
+	}
+
+ui_print_footer("index.cgi", $text{'index_return'});
+
+# print_dropin_table(dropins, system-units, user-units)
+# Outputs the discovered drop-in inventory table.
+sub print_dropin_table
+{
+my ($dropins, $system_units, $user_units) = @_;
+print ui_columns_start([
+	$text{'systemd_name'},
+	$text{'dropins_scope'},
+	$text{'systemd_owner'},
+	$text{'dropins_file'},
+	$text{'dropins_actions'},
+	]);
+foreach my $dropin (@$dropins) {
+	print ui_columns_row([
+		ui_tag('tt', html_escape($dropin->{'unit'})),
+		html_escape(dropin_scope_label($dropin)),
+		$dropin->{'scope'} eq 'user' ?
+			ui_tag('tt', html_escape($dropin->{'user'})) :
+			html_escape("-"),
+		ui_tag('tt', html_escape($dropin->{'file'})),
+		dropin_action_link($dropin, $system_units, $user_units),
+		]);
+	}
+print ui_columns_end();
+}
+
+# dropin_scope_label(dropin)
+# Returns a human-readable scope label for a drop-in descriptor.
+sub dropin_scope_label
+{
+my ($dropin) = @_;
+return $dropin->{'scope'} eq 'user' ?
+	$text{'dropins_scope_user'} : $text{'dropins_scope_system'};
+}
+
+# dropin_action_link(dropin, system-units, user-units)
+# Returns an edit action when the discovered drop-in belongs to a known unit.
+sub dropin_action_link
+{
+my ($dropin, $system_units, $user_units) = @_;
+if ($dropin->{'scope'} eq 'user') {
+	my $user = $dropin->{'user'};
+	my $unit = $dropin->{'unit'};
+	return ui_tag('i', html_escape($text{'dropins_unit_missing'}))
+		if (!$user_units->{$user."\t".$unit});
+	return ui_tag('i', html_escape($text{'dropins_view_only'}))
+		if (!systemd_can_dropin(\%access, 1, $user));
+	my $url = "edit_unit.cgi?scope=user&unituser=".urlize($user).
+		  "&name=".urlize($unit)."&dropin=1".
+		  dropin_file_arg($dropin);
+	return ui_link($url, $text{'dropins_edit'});
+	}
+my $unit = $dropin->{'unit'};
+return ui_tag('i', html_escape($text{'dropins_unit_missing'}))
+	if (!$system_units->{$unit});
+return ui_tag('i', html_escape($text{'dropins_view_only'}))
+	if (!systemd_can_dropin(\%access, 0));
+return ui_link("edit_unit.cgi?name=".urlize($unit)."&dropin=1".
+	       dropin_file_arg($dropin),
+	       $text{'dropins_edit'});
+}
+
+# dropin_file_arg(dropin)
+# Returns an exact drop-in file query argument for non-standard drop-ins.
+sub dropin_file_arg
+{
+my ($dropin) = @_;
+return "" if ($dropin->{'standard'});
+return "&dropfile=".urlize($dropin->{'file'});
+}

systemd/edit_manual.cgi

@@ -0,0 +1,70 @@
+#!/usr/local/bin/perl
+# Show a page for manually editing discovered systemd unit files.
+
+use strict;
+use warnings;
+
+require './systemd-lib.pl'; ## no critic
+
+our (%access, %in, %text);
+
+ReadParse();
+error_setup($text{'manual_edit_err'});
+
+systemd_acl_bool(\%access, 'manual') ||
+	systemd_acl_bool(\%access, 'manual_user') ||
+	systemd_acl_error('pmanual');
+
+# File choices are constrained to discovered system and local user unit files.
+my @files = grep { systemd_can_manual(\%access, $_) } list_manual_unit_files();
+@files || error(manual_empty_message());
+my %allowed = map { $_->{'file'}, $_ } @files;
+my $info = $allowed{$in{'file'}} || $files[0];
+my $file = $info->{'file'};
+my $data = read_manual_unit_file($info);
+defined($data) || error($text{'manual_eread'});
+
+ui_print_header(undef, $text{'manual_title'}, "");
+my $desc = $info->{'scope'} eq 'user' ?
+	text('manual_desc_user',
+	     ui_tag('tt', html_escape($info->{'user'}))) :
+	$text{'manual_desc'};
+print ui_div($desc);
+
+# Keep the selector separate so changing files does not submit edits.
+print ui_form_start("edit_manual.cgi");
+print ui_tag('b', html_escape($text{'manual_select'}));
+print ui_select("file", $file,
+	[ map { [ $_->{'file'}, manual_unit_file_label($_) ] } @files ]);
+print " ", ui_submit($text{'manual_ok'});
+print ui_form_end();
+
+# The editor preserves raw unit text; validation is limited to the file path.
+print ui_form_start("save_manual.cgi", "form-data");
+print ui_hidden("file", $file);
+print ui_table_start(undef, undef, 2);
+print ui_table_row(undef, ui_textarea("data", $data, 35, 120), 2);
+print ui_table_end();
+print ui_form_end([ [ "save", $text{'save'} ] ]);
+
+ui_print_footer("index.cgi", $text{'index_return'});
+
+# manual_unit_file_label(info)
+# Returns the selector label for a manual-edit unit file.
+sub manual_unit_file_label
+{
+my ($info) = @_;
+return html_escape($info->{'file'});
+}
+
+# manual_empty_message()
+# Returns an empty-state message for the current manual-edit ACL scope.
+sub manual_empty_message
+{
+my $user = systemd_acl_default_user(\%access);
+return text('manual_enone_user',
+	    ui_tag('tt', html_escape($user)))
+	if ($user && systemd_acl_bool(\%access, 'manual_user') &&
+	    !systemd_acl_bool(\%access, 'manual'));
+return $text{'manual_enone'};
+}

systemd/help/config_create_return_index.html

@@ -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>

systemd/help/config_default_create_scope.html

@@ -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>

systemd/help/config_default_linger.html

@@ -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>

systemd/help/config_desc.html

@@ -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>

systemd/help/config_logs_current_boot.html

@@ -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>

systemd/help/config_logs_lines.html

@@ -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>

systemd/help/config_manual_vendor_units.html

@@ -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>

systemd/help/config_show_dropin_inventory.html

@@ -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>

systemd/help/config_show_runtime_units.html

@@ -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>

systemd/help/config_show_unit_suffixes.html

@@ -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>

systemd/help/config_visible_tabs.html

@@ -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>

systemd/help/intro.html

@@ -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>

systemd/help/systemd_after.html

@@ -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>

systemd/help/systemd_automountidle.html

@@ -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>

systemd/help/systemd_automountmode.html

@@ -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>

systemd/help/systemd_automountmount.html

@@ -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>

systemd/help/systemd_automountwhere.html

@@ -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>

systemd/help/systemd_before.html

@@ -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>

systemd/help/systemd_boot.html

@@ -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>

systemd/help/systemd_conf.html

@@ -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>

systemd/help/systemd_conflicts.html

@@ -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>

systemd/help/systemd_desc.html

@@ -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>

systemd/help/systemd_env.html

@@ -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>

systemd/help/systemd_envfile.html

@@ -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>

systemd/help/systemd_file.html

@@ -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>

systemd/help/systemd_group.html

@@ -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>

systemd/help/systemd_killmode.html

@@ -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>

systemd/help/systemd_limitnofile.html

@@ -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>

systemd/help/systemd_linger.html

@@ -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>

systemd/help/systemd_linger_user.html

@@ -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>

systemd/help/systemd_logerr.html

@@ -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>

systemd/help/systemd_logstd.html

@@ -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>

systemd/help/systemd_main_pid.html

@@ -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>

systemd/help/systemd_mountoptions.html

@@ -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>

systemd/help/systemd_mounttype.html

@@ -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>

systemd/help/systemd_mountwhat.html

@@ -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>

systemd/help/systemd_mountwhere.html

@@ -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>

systemd/help/systemd_name.html

@@ -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>

systemd/help/systemd_nonewprivs.html

@@ -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>

systemd/help/systemd_onfailure.html

@@ -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>

systemd/help/systemd_onsuccess.html

@@ -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>

systemd/help/systemd_pathchanged.html

@@ -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>

systemd/help/systemd_pathdirectorynotempty.html

@@ -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>

systemd/help/systemd_pathexists.html

@@ -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>

systemd/help/systemd_pathexistsglob.html

@@ -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>

systemd/help/systemd_pathmakedirectory.html

@@ -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>

systemd/help/systemd_pathmodified.html

@@ -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>

systemd/help/systemd_pathunit.html

@@ -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>

systemd/help/systemd_pidfile.html

@@ -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>

systemd/help/systemd_privatetmp.html

@@ -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>

systemd/help/systemd_protectsystem.html

@@ -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>

systemd/help/systemd_readwritepaths.html

@@ -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>

systemd/help/systemd_reload.html

@@ -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>

systemd/help/systemd_remain.html

@@ -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>

systemd/help/systemd_requires.html

@@ -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>

systemd/help/systemd_restart.html

@@ -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>

systemd/help/systemd_restartsec.html

@@ -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>

systemd/help/systemd_runtime_state.html

@@ -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>

systemd/help/systemd_servicetype.html

@@ -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>

systemd/help/systemd_slicecpuweight.html

@@ -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>

systemd/help/systemd_sliceioweight.html

@@ -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>

systemd/help/systemd_slicememorymax.html

@@ -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>

systemd/help/systemd_slicetasksmax.html

@@ -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>

systemd/help/systemd_socketaccept.html

@@ -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>

systemd/help/systemd_socketgroup.html

@@ -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>

systemd/help/systemd_socketlistendatagram.html

@@ -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>

systemd/help/systemd_socketlistenfifo.html

@@ -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>

systemd/help/systemd_socketlistenstream.html

@@ -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>

systemd/help/systemd_socketmode.html

@@ -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>

systemd/help/systemd_socketservice.html

@@ -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>

systemd/help/systemd_socketuser.html

@@ -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>

systemd/help/systemd_start.html

@@ -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>

systemd/help/systemd_startpost.html

@@ -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>

systemd/help/systemd_startpre.html

@@ -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>

systemd/help/systemd_status.html

@@ -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>

systemd/help/systemd_stop.html

@@ -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>

systemd/help/systemd_stoppost.html

@@ -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>

systemd/help/systemd_swapoptions.html

@@ -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>

systemd/help/systemd_swappriority.html

@@ -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>

systemd/help/systemd_swaptimeoutsec.html

@@ -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>

systemd/help/systemd_swapwhat.html

@@ -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>

systemd/help/systemd_syslogid.html

@@ -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>

systemd/help/systemd_timeout.html

@@ -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>

systemd/help/systemd_timeoutstop.html

@@ -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>

systemd/help/systemd_timeraccuracysec.html

@@ -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>

systemd/help/systemd_timeronbootsec.html

@@ -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>

systemd/help/systemd_timeroncalendar.html

@@ -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>

systemd/help/systemd_timeronunitactivesec.html

@@ -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>

systemd/help/systemd_timerpersistent.html

@@ -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>