Merge branch 'master' into dbus-update

1 files changed, 51 insertions, 4 deletions

diff --git a/doc/guix.texi b/doc/guix.texi
index 9956887b96..fd0adfd203 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -6983,6 +6983,36 @@ KVM kernel module should be loaded, and the @file{/dev/kvm} device node
 must exist and be readable and writable by the user and by the daemon's
 build users.
 
+The @command{guix system} command has even more to offer!  The following
+sub-commands allow you to visualize how your system services relate to
+each other:
+
+@anchor{system-extension-graph}
+@table @code
+
+@item extension-graph
+Emit in Dot/Graphviz format to standard output the @dfn{service
+extension graph} of the operating system defined in @var{file}
+(@pxref{Service Composition}, for more information on service
+extensions.)
+
+The command:
+
+@example
+$ guix system extension-graph @var{file} | dot -Tpdf > services.pdf
+@end example
+
+produces a PDF file showing the extension relations among services.
+
+@anchor{system-dmd-graph}
+@item dmd-graph
+Emit in Dot/Graphviz format to standard output the @dfn{dependency
+graph} of dmd services of the operating system defined in @var{file}.
+@xref{dmd Services}, for more information and for an example graph.
+
+@end table
+
+
 @node Defining Services
 @subsection Defining Services
 
@@ -7015,6 +7045,7 @@ collects device management rules and makes them available to the eudev
 daemon; the @file{/etc} service populates the system's @file{/etc}
 directory.
 
+@cindex service extensions
 GuixSD services are connected by @dfn{extensions}.  For instance, the
 secure shell service @emph{extends} dmd---GuixSD's initialization system,
 running as PID@tie{}1---by giving it the command lines to start and stop
@@ -7035,6 +7066,9 @@ as arrows, a typical system might provide something like this:
 
 At the bottom, we see the @dfn{boot service}, which produces the boot
 script that is executed at boot time from the initial RAM disk.
+@xref{system-extension-graph, the @command{guix system extension-graph}
+command}, for information on how to generate this representation for a
+particular operating system definition.
 
 @cindex service types
 Technically, developers can define @dfn{service types} to express these
@@ -7304,10 +7338,23 @@ setuid-root programs on the system (@pxref{Setuid Programs}).
 The @code{(gnu services dmd)} provides a way to define services managed
 by GNU@tie{}dmd, which is GuixSD initialization system---the first
 process that is started when the system boots, aka. PID@tie{}1
-(@pxref{Introduction,,, dmd, GNU dmd Manual}).  The
-@var{%dmd-root-service} represents PID@tie{}1, of type
-@var{dmd-root-service-type}; it can be extended by passing it lists of
-@code{<dmd-service>} objects.
+(@pxref{Introduction,,, dmd, GNU dmd Manual}).
+
+Services in dmd can depend on each other.  For instance, the SSH daemon
+may need to be started after the syslog daemon has been started, which
+in turn can only happen once all the file systems have been mounted.
+The simple operating system defined earlier (@pxref{Using the
+Configuration System}) results in a service graph like this:
+
+@image{images/dmd-graph,,5in,Typical dmd service graph.}
+
+You can actually generate such a graph for any operating system
+definition using the @command{guix system dmd-graph} command
+(@pxref{system-dmd-graph, @command{guix system dmd-graph}}).
+
+The @var{%dmd-root-service} is a service object representing PID@tie{}1,
+of type @var{dmd-root-service-type}; it can be extended by passing it
+lists of @code{<dmd-service>} objects.
 
 @deftp {Data Type} dmd-service
 The data type representing a service managed by dmd.