1 files changed, 266 insertions, 0 deletions
diff --git a/upstream/debian-bookworm/man8/systemd-soft-reboot.service.8 b/upstream/debian-bookworm/man8/systemd-soft-reboot.service.8
new file mode 100644
index 00000000..6f3ed23d
--- /dev/null
+++ b/upstream/debian-bookworm/man8/systemd-soft-reboot.service.8
@@ -0,0 +1,266 @@
+'\" t
+.TH "SYSTEMD\-SOFT\-REBOOT\&.SERVICE" "8" "" "systemd 254" "systemd-soft-reboot.service"
+.\" -----------------------------------------------------------------
+.\" * Define some portability stuff
+.\" -----------------------------------------------------------------
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" http://bugs.debian.org/507673
+.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\" -----------------------------------------------------------------
+.\" * set default formatting
+.\" -----------------------------------------------------------------
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.\" -----------------------------------------------------------------
+.\" * MAIN CONTENT STARTS HERE *
+.\" -----------------------------------------------------------------
+.SH "NAME"
+systemd-soft-reboot.service \- Userspace reboot operation
+.SH "SYNOPSIS"
+.PP
+systemd\-soft\-reboot\&.service
+.SH "DESCRIPTION"
+.PP
+systemd\-soft\-reboot\&.service
+is a system service that is pulled in by
+soft\-reboot\&.target
+and is responsible for performing a userspace\-only reboot operation\&. When invoked, it will send the
+\fBSIGTERM\fR
+signal to any processes left running (but does not follow up with
+\fBSIGKILL\fR, and does not wait for the processes to exit)\&. If the
+/run/nextroot/
+directory exists (which may be a regular directory, a directory mount point or a symlink to either) then it will switch the file system root to it\&. It then reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot transaction as in a normal reboot\&.
+.PP
+Such a userspace\-only reboot operation permits updating or resetting the entirety of userspace with minimal downtime, as the reboot operation does
+\fInot\fR
+transition through:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The second phase of regular shutdown, as implemented by
+\fBsystemd-shutdown\fR(8)\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The third phase of regular shutdown, i\&.e\&. the return to the initrd context
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The hardware reboot operation
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The firmware initialization
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The boot loader initialization
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The kernel initialization
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The initrd initialization
+.RE
+.PP
+However this form of reboot comes with drawbacks as well:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The OS update remains incomplete, as the kernel is not reset and continues running\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Kernel settings (such as
+/proc/sys/
+settings, a\&.k\&.a\&. "sysctl", or
+/sys/
+settings) are not reset\&.
+.RE
+.PP
+These limitations may be addressed by various means, which are outside of the scope of this documentation, such as kernel live\-patching and sufficiently comprehensive
+/etc/sysctl\&.d/
+files\&.
+.SH "RESOURCE PASS\-THROUGH"
+.PP
+Various runtime OS resources can passed from a system runtime to the next, through the userspace reboot operation\&. Specifically:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+File descriptors placed in the file descriptor store of services that remain active until the very end are passed to the next boot, where they are placed in the file descriptor store of the same unit\&. For this to work, units must declare
+\fIDefaultDependencies=no\fR
+(and avoid a manual
+\fIConflicts=shutdown\&.target\fR
+or similar) to ensure they are not terminated as usual during the system shutdown operation\&. Alternatively, use
+\fIFileDescriptorStorePreserve=\fR
+to allow the file descriptor store to remain pinned even when the unit is down\&. See
+\fBsystemd.service\fR(5)
+for details about the file descriptor store\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Similar to this, file descriptors associated with
+\&.socket
+units remain open (and connectible) if the units are not stopped during the transition\&. (Achieved by
+\fIDefaultDependencies=no\fR\&.)
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+The
+/run/
+file system remains mounted and populated and may be used to pass state information between such userspace reboot cycles\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Service processes may continue to run over the transition, if they are placed in services that remain active until the very end of shutdown (which again is achieved via
+\fIDefaultDependencies=no\fR)\&. They must also be set up to avoid being killed by the aforementioned
+\fBSIGTERM\fR
+spree (as per
+\m[blue]\fBsystemd and Storage Daemons for the Root File System\fR\m[]\&\s-2\u[1]\d\s+2)\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+File system mounts may remain mounted during the transition, and complex storage attached, if configured to remain until the very end of the shutdown process\&. (Also achieved via
+\fIDefaultDependencies=no\fR, and by avoiding
+\fIConflicts=umount\&.target\fR)
+.RE
+.PP
+Even though passing resources from one soft reboot cycle to the next is possible this way, we strongly suggest to use this functionality sparingly only, as it creates a more fragile system as resources from different versions of the OS and applications might be mixed with unforeseen consequences\&. In particular it\*(Aqs recommended to
+\fIavoid\fR
+allowing processes to survive the soft reboot operation, as this means code updates will necessarily be incomplete, and processes typically pin various other resources (such as the file system they are backed by), thus increasing memory usage (as two versions of the OS/application/file system might be kept in memory)\&. Leaving processes running during a soft\-reboot operation requires disconnecting the service comprehensively from the rest of the OS, i\&.e\&. minimizing IPC and reducing sharing of resources with the rest of the OS\&. A possible mechanism to achieve this is the concept of
+\m[blue]\fBPortable Services\fR\m[]\&\s-2\u[2]\d\s+2, but make sure no resource from the host\*(Aqs OS filesystems is pinned via
+\fIBindPaths=\fR
+or similar unit settings, otherwise the old, originating filesystem will remain mounted as long as the unit is running\&.
+.SH "NOTES"
+.PP
+Note that because
+\fBsystemd-shutdown\fR(8)
+is not executed, the executables in
+/lib/systemd/system\-shutdown/
+are not executed either\&.
+.PP
+Note that
+systemd\-soft\-reboot\&.service
+(and related units) should never be executed directly\&. Instead, trigger system shutdown with a command such as
+"systemctl soft\-reboot"\&.
+.SH "SEE ALSO"
+.PP
+\fBsystemd\fR(1),
+\fBsystemctl\fR(1),
+\fBsystemd.special\fR(7),
+\fBsystemd-poweroff.service\fR(8),
+\fBsystemd-suspend.service\fR(8),
+\fBbootup\fR(7)
+.SH "NOTES"
+.IP " 1." 4
+systemd and Storage Daemons for the Root File System
+.RS 4
+\%https://systemd.io/ROOT_STORAGE_DAEMONS
+.RE
+.IP " 2." 4
+Portable Services
+.RS 4
+\%https://systemd.io/PORTABLE_SERVICES
+.RE