Am 27.01.2015 um 19:32 schrieb Lennart Poettering:
On Tue, 27.01.15 19:26, Christian Seiler (christ...@iwakd.de) wrote:
Will send second patch after your response to my question.
Uh, which question are you precisely referring to?
Forget it, I answered that question myself and forgot to edit out the
last sentence of my mail. ;-)
I've attached git format-patch's output for the revised manpage.
Christian
From 4d251d71bfa5eb19a7d14392d34357e0e3e859cc Mon Sep 17 00:00:00 2001
From: Christian Seiler christ...@iwakd.de
Date: Sat, 24 Jan 2015 14:04:03 +0100
Subject: [PATCH] systemd.unit(5): add examples for common tasks
Add examples for (a) how to allow units to be enabled and (b)
overriding vendor settings to the man page.
---
man/systemd.unit.xml | 165 +++
1 file changed, 165 insertions(+)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index e820b33..9704d6f 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -1574,6 +1574,171 @@
/refsect1
refsect1
+titleExamples/title
+
+example
+titleAllowing units to be enabled/title
+
+paraThe following snippet (highlighted)
+allows a unit (e.g.
+filenamefoo.service/filename) to be
+enabled via
+commandsystemctl enable/command:/para
+
+programlisting[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+emphasis[Install]/emphasis
+emphasisWantedBy=multi-user.target/emphasis/programlisting
+
+paraAfter running
+commandsystemctl enable/command, a symlink
+filename/etc/systemd/system/multi-user.target.wants/foo.service/filename
+linking to the actual unit will be created. It
+tells systemd to pull in the unit when starting
+filenamemulti-user.target/filename. The
+inverse commandsystemctl disable/command
+will remove that symlink again./para
+/example
+
+example
+titleOverriding vendor settings/title
+
+paraThere are two methods of overriding
+vendor settings in unit files: copying the unit
+file from
+filename/usr/lib/systemd/system/filename
+to filename/etc/systemd/system/filename and
+modifying the chosen settings. Alternatively,
+one can create a directory named
+filenamereplaceableunit/replaceable.d//filename
+within
+filename/etc/systemd/system/filename and
+place a drop-in file
+filenamereplaceablename/replaceable.conf/filename
+there that only changes the specific settings
+one is interested in. Note that multiple such
+drop-in files are read if present./para
+
+paraThe advantage of the first method is
+that one easily overrides the complete unit,
+the vendor unit is not parsed at all anymore.
+It has the disadvantage that improvements to
+the unit file by the vendor are not
+automatically incorporated on updates./para
+
+paraThe advantage of the second method is
+that one only overrides the settings one
+specifically wants, where updates to the unit
+by the vendor automatically apply. This has the
+disadvantage that some future updates by the
+vendor might be incompatible with the local
+changes./para
+
+paraNote that for drop-in files, if one wants
+to remove entries from a setting that is parsed
+as a list (and is not a dependency), such as
+varnameConditionPathExists=/varname (or
+e.g. varnameExecStart=/varname in service
+units), one needs to first clear the list
+before re-adding all entries except the one
+that is to be removed. See below for an
+example./para
+
+paraThis also applies for user instances of
+systemd, but with different locations for the
+unit files. See the section on unit load paths
+for further details./para
+
+
