On Thu, 14.04.11 11:14, Michal Hlavinka (mhlavink@xxxxxxxxxx) wrote:
>
> Hi,
>
> I have similar question (sorry for stealing this thread). I have package
> that has 3 services (they somehow depend on each other). Based on
> configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
> handled by init script, but I don't know how to do it in systemd service
> file.
> AFAIK:
> a)
> EnvironmentFile=...
> ExecStart=[ -n "$DRIVER" ] && /start/driver/...
> ExecStart=[ -n "$BACKEND" ] && /start/backend/...
> ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
In a systemd world we try to normalize how services are maintained and
managed. Ideally that means that you have a 1:1 mapping between service
files and actual daemons. So instead of having three daemons spawned
from a single sysv init script I'd encourage you to have three unit
files spawning three daemons.
This normalizes behaviour in many ways, for example the user can
individually enable/disable them, without an extra layer of enabling in
an extra config file.
We want a single place where services can be enabled/disabled, not
multiple at different layers.
Also, stuff like automatic restart and so on can only work correctly if
you maintain each daemon in a seperate systemd service.
> won't work, because ExecStart must be path, not shell command
>
> b)
> ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver
> ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend
> ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
>
> won't work, because there ExecStart can't be used more than once,
> except with type=oneshot, which does not work here
Yes, ExecStart= is for the "main" process of a service, the one which
determines the lifetime of it.
> d) split it to more service files and make dependency there
>
> this would be incompatible change in configuration and hard to do, because
> dependency can change with configuration
Yes, d)!
Our primary goal with systemd is to get things right and
normalized. Support the exact same behaviour as in SysV is not our top
goal, because well, we aren't sysvinit and to sport 100% identical
behaviour you'd have to be sysvinit.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
