Re: [PATCH 5/5] tools/hotplug: support XENSTORED_TRACE in systemd

[Olaf Hering <olaf@aepfle.de>]

On Tue, Dec 09, Ian Jackson wrote:

> Bottom line: as relevant maintainer, I'm afraid I'm going to insist
> that this script be in /etc.

I dont agree with the reasoning, but to get this done:
Which place would that be, XEN_SCRIPT_DIR?

> > > I don't think this script wants to contain an option parser!
> > 
> > How should it handle exec vs. no-exec? Just a single yes/no knob, so
> > essentially sysv vs systemd?
> 
> I was imagining a "named parameter" as SuS calls them.  One or both
> the sites which run this wrapper script would pass an environment
> variable.  Something like this in the script:
> 
>   $xenstored_do_exec $XENSTORED "$@" $XENSTORED_TRACE_ARGS $XENSTORED_ARGS
> 
> where the systemd unit simply sets `xenstored_do_exec=exec'.

Ok, I will implement this.

> In this case that means I think you should find out whether the lack
> of this xenstore-read polling loop is actually a bug in the existing
> systemd unit.  If (as I suspect) this is not a bug, then your code
> motion should not change this aspect of the operation under systemd.

I think any daemon needs some time until its operational. In case of
xenstored there are users which expect its functionality right away,
such as xen-init-dom0 and the other tools launched by xencommons. Thats
likely the reason why the loop is there, and the commit msg of f706d9e9a
confirms that. With systemd we can only hope that it handles this
properly with its socket passing functionality. If not, the startup code
could be done like I did in my patch do avoid code duplication in a
to-be-added ExecStartPost=.

And the "is xenstored ready?" check in my current implementation would
not work anyway because once the shell does exec it will not run the
following code which does the "xenstore-read -s".

Olaf