[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/7] xenstore-read: add support for a retry open limit on xenstored



On Sat, 2014-03-22 at 02:43 +0100, Luis R. Rodriguez wrote:
> On Fri, Mar 21, 2014 at 04:01:30PM +0000, Ian Campbell wrote:
> > On Fri, 2014-03-21 at 15:40 +0000, David Vrabel wrote:
> > > On 19/03/14 20:58, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx>
> > > > 
> > > > This adds support for a customizable retry limit on trying to open
> > > > the xenstored, each retry is separated by 1 second. This should allow
> > > > us to simplify both our LSB init scripts and eventually our systemd
> > > > service files for starting the xenstored.
> > > 
> > > 
> > > This seems odd. Surely the point of systemd is that you only start
> > > services once their dependencies are up?  It doesn't seem right to have
> > > a service poll for another.
> > 
> > Isn't this trying to decide when xenstored is up, for use in the
> > xenstored.service itself?
> > 
> > But now I think of it -- isn't this exactly what the socket activation
> > stuff is for?
> 
> Strangely enough the socket file gets systemd to kick off the socket 
> prior to xenstored activation, I was baffled by this

My understanding was that this was the whole point.

>  and since the
> documentation is shy about the details I could not trust what I assumed
> and everyone else is assuming systemd *should* be doing. We'll have to
> dive into the code and verify before knowing for sure we won't let through
> an attempt to access xenstored without the old legacy retry.

Right, please can you confirm with someone who understands systemd
socket activation what we should be doing here instead of guessing.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.