<?xml version='1.0'?> <!--*-nxml-*-->
-<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
This file is part of systemd.
Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
+ Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see <http://www.gnu.org/licenses/>.
-->
<refentry id="systemd.snapshot">
- <refentryinfo>
- <title>systemd.snapshot</title>
- <productname>systemd</productname>
+ <refentryinfo>
+ <title>systemd.snapshot</title>
+ <productname>systemd</productname>
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
- </refentryinfo>
+ <authorgroup>
+ <author>
+ <contrib>Developer</contrib>
+ <firstname>Lennart</firstname>
+ <surname>Poettering</surname>
+ <email>lennart@poettering.net</email>
+ </author>
+ </authorgroup>
+ </refentryinfo>
- <refmeta>
- <refentrytitle>systemd.snapshot</refentrytitle>
- <manvolnum>5</manvolnum>
- </refmeta>
+ <refmeta>
+ <refentrytitle>systemd.snapshot</refentrytitle>
+ <manvolnum>5</manvolnum>
+ </refmeta>
- <refnamediv>
- <refname>systemd.snapshot</refname>
- <refpurpose>systemd snapshot units</refpurpose>
- </refnamediv>
+ <refnamediv>
+ <refname>systemd.snapshot</refname>
+ <refpurpose>Snapshot unit configuration</refpurpose>
+ </refnamediv>
- <refsynopsisdiv>
- <para><filename>systemd.snapshot</filename></para>
- </refsynopsisdiv>
+ <refsynopsisdiv>
+ <para><filename><replaceable>snapshot</replaceable>.snapshot</filename></para>
+ </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
+ <refsect1>
+ <title>Description</title>
- <para>Snapshot units are not configured via unit
- configuration files. Nonetheless they are named
- similar to filenames. A unit name whose name ends in
- <filename>.snapshot</filename> refers to a dynamic
- snapshot of the systemd runtime state.</para>
+ <para>Snapshot units are not configured via unit configuration
+ files. Nonetheless they are named similar to filenames. A unit
+ whose name ends in <literal>.snapshot</literal> refers to a
+ dynamic snapshot of the systemd runtime state.</para>
- <para>Snapshots are not configured on disk but created
- dynamically via <command>systemctl snapshot</command>
- (see
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- for details) or an equivalent command. When created
- they will automatically get dependencies on the
- currently activated units. They hence act as saved
- runtime state of the systemd manager. Later on the
- user may choose to return to the saved state via
- <command>systemctl isolate</command>. They are hence
- useful to roll back to a defined state after
- temporarily starting/stopping services or
- similar.</para>
- </refsect1>
+ <para>Snapshots are not configured on disk but created dynamically
+ via <command>systemctl snapshot</command> (see
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ for details) or an equivalent command. When created, they will
+ automatically get dependencies on the currently activated units.
+ They act as saved runtime state of the systemd manager. Later on,
+ the user may choose to return to the saved state via
+ <command>systemctl isolate</command>. They are useful to roll back
+ to a defined state after temporarily starting/stopping services or
+ similar.</para>
+ </refsect1>
- <refsect1>
- <title>See Also</title>
- <para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- </para>
- </refsect1>
+ <refsect1>
+ <title>See Also</title>
+ <para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ </para>
+ </refsect1>
</refentry>