On Tue, 26.05.15 14:12, Steven Noonan (ste...@uplinklabs.net) wrote:

> Hi there,
> 
> I'm wondering what the functional difference is between doing:
> 
> ExecStartPre=/bin/foo
> ExecStart=/bin/bar
> 
> and
> 
> ExecStart=/bin/foo
> ExecStart=/bin/bar

As mentioned in Christian's reply: multiple ExecStart= lines are only
available for Type=oneshot services. Other service types do not
support that.

> From my read of the systemd.service man page, they appear to have the
> same behavior in the common use case.

For services that do not have Type=oneshot it is the
ExecStart= process that defines the runtime of the service unit. Only
when it signalled that its initialization is complete systemd
considers the service fully up, and when it dies it takes that as
indication that the service is terminating now. 

Also, each time an ExecStartPre= service dies systemd will kill all
remaining processes in the cgroup. However, especially for
Type=forking services this is different for ExecStart=.

Then, among other things, while the process invoked with ExecStart= is
up things like watchdog support and so on are active, while on
ExecStartPre= and so on a timeout is applied.

> The only difference I can see is that groups of ExecStartPre and
> ExecStart groups can be rearranged. That is, you could have an
> ExecStartPre line *after* the ExecStart line in the file, and the
> ExecStartPre would still be executed first. But the ordering of
> multiple ExecStart (or ExecStartPre) lines in a single systemd.service
> file matters, because it has explicit ordering as written in the file.
> 
> Why would someone choose one over the other? What differences am I missing?

ExecStart= should be the main process of a daemon. Defining its
life-time, be long-lived. ExecStartPre= however should only be
short-lived, preparatory processes.

Lennart

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

Reply via email to