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
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 @@
+Examples
+
+
+Allowing units to be enabled
+
+The following snippet (highlighted)
+allows a unit (e.g.
+foo.service) to be
+enabled via
+systemctl enable:
+
+[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+[Install]
+WantedBy=multi-user.target
+
+After running
+systemctl enable, a symlink
+/etc/systemd/system/multi-user.target.wants/foo.service
+linking to the actual unit will be created. It
+tells systemd to pull in the unit when starting
+multi-user.target. The
+inverse systemctl disable
+will remove that symlink again.
+
+
+
+Overriding vendor settings
+
+There are two methods of overriding
+vendor settings in unit files: copying the unit
+file from
+/usr/lib/systemd/system
+to /etc/systemd/system and
+modifying the chosen settings. Alternatively,
+one can create a directory named
+unit.d/
+within
+/etc/systemd/system and
+place a drop-in file
+name.conf
+there that only changes the specific settings
+one is interested in. Note that multiple such
+drop-in files are read if present.
+
+The 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.
+
+The 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.
+
+Note 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
+ConditionPathExists= (or
+e.g. ExecStart= 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.
+
+This 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.
+
+Suppose there is a vendor-supplied unit
+/usr/lib/systemd/system/httpd.service
+with the following contents:
+
+[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service
+Requires=sqldb.service
+AssertPathExists=/srv/webserver
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+Nice=5
+
+[Install]
+WantedBy=multi-user.target
+
+
