Adding upstream version 4.23.0.upstream/4.23.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 15 insertions, 2 deletions

diff --git a/upstream/mageia-cauldron/man5/systemd.service.5 b/upstream/mageia-cauldron/man5/systemd.service.5
index 19597a2e..8b68b9b5 100644
--- a/upstream/mageia-cauldron/man5/systemd.service.5
+++ b/upstream/mageia-cauldron/man5/systemd.service.5
@@ -1737,7 +1737,7 @@ T}
 T{
 ":"
 T}:T{
-If the executable path is prefixed with ":", environment variable substitution (as described by the "Command Lines" section below) is not applied\&.
+If the executable path is prefixed with ":", environment variable substitution (as described below this table) is not applied\&.
 T}
 T{
 "+"
@@ -2166,7 +2166,7 @@ for this\&. A typical service file for such a daemon would look like this:
 Description=Simple notifying service
 
 [Service]
-Type=notify
+Type=notify\-reload
 ExecStart=/usr/sbin/simple\-notifying\-service
 
 [Install]
@@ -2182,6 +2182,14 @@ Note that the daemon has to support systemd\*(Aqs notification protocol, else sy
 Please see
 \fBsystemd.kill\fR(5)
 for details on how you can influence the way systemd terminates the service\&.
+.PP
+To avoid code duplication, it is preferable to use
+\fBsd_notify\fR(3)
+when possible, especially when other APIs provided by
+\fBlibsystemd\fR(3)
+are also used, but note that the notification protocol is very simple and guaranteed to be stable as per the
+\m[blue]\fBInterface Portability and Stability Promise\fR\m[]\&\s-2\u[4]\d\s+2, so it can be reimplemented by services with no external dependencies\&. For a self\-contained example, see
+\fBsd_notify\fR(3)\&.
 .SH "SEE ALSO"
 .PP
 \fBsystemd\fR(1),
@@ -2209,3 +2217,8 @@ Control Group v2
 .RS 4
 \%https://docs.kernel.org/admin-guide/cgroup-v2.html
 .RE
+.IP " 4." 4
+Interface Portability and Stability Promise
+.RS 4
+\%https://systemd.io/PORTABILITY_AND_STABILITY/
+.RE