[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |