nixos: nixos/doc/manual/administration typo fix

Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>

Changed files
+16 -15
nixos
doc
manual
+2 -3
nixos/doc/manual/administration/rebooting.chapter.md
···
# systemctl kexec
```
-
The machine can be suspended to RAM (if supported) using `systemctl
-
suspend`, and suspended to disk using `systemctl
-
hibernate`.
+
The machine can be suspended to RAM (if supported) using `systemctl suspend`,
+
and suspended to disk using `systemctl hibernate`.
These commands can be run by any user who is logged in locally, i.e. on
a virtual console or in X11; otherwise, the user is asked for
+6 -5
nixos/doc/manual/administration/service-mgmt.chapter.md
···
](#sect-nixos-systemd-nixos) explains NixOS specific things worth
knowing.
-
Without any arguments, `systmctl` the status of active units:
+
Without any arguments, `systemctl` the status of active units:
```ShellSession
$ systemctl
···
*User* systemd services on the other hand, should be treated
differently. Given a package that has a systemd unit file at
-
`#pkg-out#/lib/systemd/user/`, using [](#opt-systemd.packages) will
+
`#pkg-out#/lib/systemd/user/`, using
+
[`systemd.packages`](options.html#opt-systemd.packages) will
make you able to start the service via `systemctl --user start`, but it
won\'t start automatically on login. However, You can imperatively
-
enable it by adding the package\'s attribute to [
-
`systemd.packages`](#opt-environment.systemPackages) and then do this
-
(e.g):
+
enable it by adding the package\'s attribute to
+
[`systemd.packages`](options.html#opt-systemd.packages)
+
and then do this (e.g):
```ShellSession
$ mkdir -p ~/.config/systemd/user/default.target.wants
+8 -7
nixos/doc/manual/from_md/administration/service-mgmt.chapter.xml
···
explains NixOS specific things worth knowing.
</para>
<para>
-
Without any arguments, <literal>systmctl</literal> the status of
+
Without any arguments, <literal>systemctl</literal> the status of
active units:
</para>
<programlisting>
···
<emphasis>User</emphasis> systemd services on the other hand,
should be treated differently. Given a package that has a systemd
unit file at <literal>#pkg-out#/lib/systemd/user/</literal>, using
-
<xref linkend="opt-systemd.packages" /> will make you able to
-
start the service via <literal>systemctl --user start</literal>,
-
but it won't start automatically on login. However, You can
-
imperatively enable it by adding the package's attribute to
-
<link linkend="opt-environment.systemPackages">
-
<literal>systemd.packages</literal></link> and then do this (e.g):
+
<link xlink:href="options.html#opt-systemd.packages"><literal>systemd.packages</literal></link>
+
will make you able to start the service via
+
<literal>systemctl --user start</literal>, but it won't start
+
automatically on login. However, You can imperatively enable it by
+
adding the package's attribute to
+
<link xlink:href="options.html#opt-systemd.packages"><literal>systemd.packages</literal></link>
+
and then do this (e.g):
</para>
<programlisting>
$ mkdir -p ~/.config/systemd/user/default.target.wants