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

Re: [Xen-devel] [PATCH] libxl: prevent xl from running if xend is running.



On Tue, 2012-04-24 at 14:34 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: prevent xl from running 
> if xend  is running."):
> > On Tue, 2012-04-24 at 14:17 +0100, Ian Jackson wrote:
> > > Can we somehow limit this to commands that actually change things ?
> > > Having xl as a diagnostic tool even for xend-based systems is useful.
> > 
> > Perhaps a new flag in xl_cmdtable.h? Overriden by -f or -N (dry run).
> 
> Yes, something like that.
> 
> > > > +        if (!access(locks[i], F_OK) && !force_execution) {
> > > > +            fprintf(stderr, "xend is running, which prevents xl from 
> > > > working "
> > > > +                            "correctly. If you still want to force the 
> > > > "
> > > > +                            "execution of xl please use the -f 
> > > > option\n");
> > > > +            exit(2);
> > > > +        }
> > > 
> > > If access fails with an unexpected error code (EACCES? EIO?) this will
> > > blunder on.
> > 
> > It'll fail whether the error code is expected or not, won't it?
> 
> I think if access fails with EIO, it will return -1, and the if
> condition will not be satisfied (!-1 = 0), so the fprintf and exit
> will not be taken.

Oh, I was confused because the "good" case here is actually that access
fails...

You could consider this to be a best effort check for xend. IOW we try
and look but if we can't tell then we assume it is not.

It's not terribly robust to just blunder on, but on the other hand being
more robust has a bigger risk of false positives, e.g. failing to start
xl because /var/lock/subsys/ does not exist isn't especially helpful
either (the EACCESS return code doesn't distinguish that
from /var/lock/subsys/xend not existing).

If you are getting EIO or something like that then that's a problem, but
arguably not one which is especially related to whether xend is running
or not and you are bound to get another later on.

You could do a bunch more complex checking (e.g. check the base
directory first) but it seems like overkill for what is supposed to be a
simply sanity check.

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