[systemd-devel] how to properly control the daemons or run advanced cmds

[Flavio Leitner]

On Mon, Dec 01, 2014 at 12:52:50AM +0100, Lennart Poettering wrote:
> On Tue, 25.11.14 00:09, Flavio Leitner (fbl at redhat.com) wrote:
> 
> > 
> > Hello,
> > 
> > The Open vSwitch is comprised by two daemons. One is a database and
> > another is the switch itself.
> > 
> > Currently we have the openvswitch.service which start/stop/reload the
> > service (both daemons) just fine.
> 
> In general we strongly recommend to expose daemons 1:1 as systemd
> services. systemd is all about keeping track of daemons, and it does
> those by watching the main process of them. If you now stick many
> daemons in the same systemd service then you make the whole excercise
> moot. This is not only missing the point of systemd, but also makes
> the whole system much less transparent for admins.

It makes sense, yes.  However, in the Open vSwitch case, the
"switching" service is provided by two daemons.  So, it made
sense to have a single systemd service to manage both.


> > However, we need to support hot-upgrade which means to stop the
> > vswitch daemon first, run a few special commands, reload the db
> > daemon and only then start the vswitch daemon.
> > 
> > I know about creating shell helpers for non-standard commands, but
> > since that needs to mess up with the daemons in a particular order,
> > I think systemd won't like the above external actions at all.
> > 
> > Any suggestion on how to handle this with systemd properly?
> 
> My recommendation would be something like this:
> 
> a) make it two units
> 
> b) assuming the switch daemon is client to the db daemon, add deps 
>    to the switch daemon for After= and Requires= on the db daemon.
> 
> c) Add the "special commands" to the ExecStartPre= of the db daemon,
>    and make them idempotent so that they can run any time, even if the
>    package is already upgraded (in which case thy should to degrade to
>    NOPs...)
> 
> Now, on upgrades just do "systemctl restart" for the db daemon. This
> should stop the switch daemon first, the stop the db daemon, then
> start the db daemon again (executing the ExecStartPre= first), then
> start the switch again.
> 
> Hope that makes sense?

Sort of.  This special restart is only need on few cases when
hot-upgrading, otherwise users expect full restart which is already
accomplished by the current service unit.

It seems to me that the solution is a mix of making two units and wrap
the special upgrade in a separate script which would manage each
daemon properly. Does that make sense to you?

I am worried with the usability too, because I don't want the admin to
worry about each daemon.  I would rather have a single unit
controlling both at the same time.  It might be possible to have this
'front-end' unit to be one of the daemons and make it work as you
described in (b) using Requires=.

I will do some experiments later on.

Thanks Lennart!
fbl