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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-12-10 at 10:15 +0100, Olaf Hering wrote:
> > 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.

I'm not sure why we don't want to exec in both cases, making this whole
problem moot.

> > 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.

I think we should assume that socket activation is working properly, or
else what is the point of socket activation? If it is buggy then we
should fix it, not add hacks to the wrapper or unit files.

That results in a wrapper which unconditionally execs, the systemd unit
just calls that while the sysv script runs the wrapper and then does the
xenstore-read -s loop. 

>  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".

Separately from the above I wonder if it might be worth moving the
xenstore readiness check into the xen-init-dom0 helper and having most
things which currently depend on xenstore actually depend on the
"dom0-is-ready" unit, which itself depends on xenstored, qemu-dom0 and
whatever else is supposed to be ready in a dom0?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel