Re: [systemd-devel] [PATCH v2 2/2] systemd.service(5): add some simple examples

2015-01-27 Thread Lennart Poettering
On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote:

> +Examples
> +
> +
> +Simple service
> +
> +The following unit file creates a service
> +that will execute
> +/usr/sbin/foo-daemon.
> +Since no Type= is specified,
> +the default
> +Type=simple
> +will be assumed. systemd will assume the unit
> +to be started immediately after the program has
> +begun executing.
> +
> +[Unit]
> +Description=Foo
> +
> +[Service]
> +ExecStart=/usr/sbin/foo-daemon
> +
> +[Install]
> +WantedBy=multi-user.target
> +
> +Note that systemd assumes here that the
> +program will continue running in the foreground
> +as long as it's active. If the program

I think "foreground" vs. "background" here is probably something to
avoid. These are services after all, and hence kinda "background" in
all cases. I am not sure how to explain this better though... Maybe
clarify that the program does not fork on its own, and that the
process systemd starts stays running until the very end of the
daemon, or so.

> +Note that systemd will consider the unit
> +to be in the state 'starting' until the program
> +has terminated, so ordered dependencies will
> +wait for the program to finish before starting
> +themselves. The unit will revert to the
> +'inactive' state after the execution is
> +done. That means another request to start the
> +unit will perform the action again.

It might be worth also mentioning here that the the unit this way will
never actually be "active". It will go directly from "activating" to
"inactive", which might be surprising!

> +
> +
> +
> +Stoppable oneshot service
> +
> +Similarly to the oneshot services, there
> +are sometimes units that need to execute a
> +program to set up something and then execute
> +another to shut it down, but no process remains
> +active while they are considered
> +'started'. Network configuration can sometimes
> +fall into this category.

Another reason to use RemainAfterExit= are services that shall not
execute again and again when they are pulled in, but only the first
time...

> +
> +DBus services
> +
> +For services that acquire name on the
> +DBus system bus, use
> +
> RemainAfterExit=dbus

Typo. Should be Type=, not RemainAfterExit=

> +
> +Deferred (idle) services

Hmm, I wonder if we maybe should remove this part. Idle services are
kinda exotic, and I figure people might be tempted to misuse them. I
think this might be something to document at the description of Type=,
but not push people towards using this beyond that.

Looks great otherwise! Thanks a ton for putting this together, much appreciated!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH v2 2/2] systemd.service(5): add some simple examples

2015-01-27 Thread Christian Seiler
Add a couple of exampels, at least one for each service type that
include some explanations and pointers to various relevant options.
---
 man/systemd.service.xml | 332 
 1 file changed, 332 insertions(+)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 4c890df..5ccbba0 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -1358,6 +1358,338 @@ ExecStart=/bin/echo $ONE $TWO $THREE
 
 
 
+Examples
+
+
+Simple service
+
+The following unit file creates a service
+that will execute
+/usr/sbin/foo-daemon.
+Since no Type= is specified,
+the default
+Type=simple
+will be assumed. systemd will assume the unit
+to be started immediately after the program has
+begun executing.
+
+[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+[Install]
+WantedBy=multi-user.target
+
+Note that systemd assumes here that the
+program will continue running in the foreground
+as long as it's active. If the program
+backgrounds/daemonizes/forks itself, please use
+Type=forking
+instead.
+
+Since no ExecStop= was
+specified, systemd will send SIGTERM to all
+processes started from this service, and after
+a timeout also SIGKILL. This behavior can be
+modified, see
+
systemd.kill5
+for details.
+
+Note that this unit type does not include
+any type of notification when a service has
+completed initialization. For this, you should
+use other unit types, such as
+Type=notify
+if the service understands systemd's
+notification protocol,
+Type=forking
+if the service can background itself or
+Type=dbus
+if the unit acquires a DBus name once
+initialization is complete. See below.
+
+
+
+Oneshot service
+
+Sometimes units should just execute an
+action without keeping active processes, such
+as a filesystem check or a cleanup action on
+boot. For this,
+Type=oneshot
+exists. Units of this type will wait until the
+process specified terminates and then fall back
+to being inactive. The following unit will
+perform a clenaup action:
+
+[Unit]
+Description=Cleanup old Foo data
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/foo-cleanup
+
+[Install]
+WantedBy=multi-user.target
+
+Note that systemd will consider the unit
+to be in the state 'starting' until the program
+has terminated, so ordered dependencies will
+wait for the program to finish before starting
+themselves. The unit will revert to the
+'inactive' state after the execution is
+done. That means another request to start the
+unit will perform the action again.
+
+
+
+Stoppable oneshot service
+
+Similarly to the oneshot services, there
+are sometimes units that need to execute a
+program to set up something and then execute
+another to shut it down, but no process remains
+active while they are considered
+'started'. Network configuration can sometimes
+fall into this category.
+
+For this, systemd knows the setting
+
RemainAfterExit=yes,
+which causes systemd to consider the unit to be
+active if the start action exited successfully.
+This directive can be used with all types, but
+is most useful with
+Type=oneshot
+and
+Type=simple.
+With
+