From: Bjoern Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Wed 22 Dec 2004 - 00:18:05 GMT
On 2004.12.21 23:26:06 +0100, Helmut Toplitzer wrote:
> Hi!
>
> Nice to hear(read) something about the patch.
>
> Maybe I can tell you what I've thougth when coding the patch.
> Maybe I'm completely wrong with this.
>
> The basic problem was that 2 different vservers with
> dynamic CTXs MAY get the same CTX-Numbers on the
> timeline of successive restarts. Never at the same time,
> but e.g. on the first vserver restart (2,3)
> and on the second (3,x). When starting the second
> vserver on the second restart (3,x) the vserver-script
> looks for a ctx file and assigns the second vserver
> the context of 3 (already used for the first server)
> from the first start (2,3) (saved in the 2nd .ctx).
> Looking for running processes in the context returns
> true and now the vserver script thinks it's already running.
>
> vserver-init script may not start the second vserver.
> vserver script is not able to start the second vserver.
> (already running?)
>
> Even worst, vserver-stat script may think (show) that
> the first vserver isn't running while the second is
> (Thats completely wrong). This is reproducible and not
> a good thing to the admin who might get a wrong
> view of his/her system.
>
> I supposed the /var/run/.ctx files as "representation of the
> current state of the system" are wrong. (That's how I
> understand the /var/run-things to be interpreted, as it
> is cleared on restart, but /var/run/vservers isn't)
>
> Your view is, if I understand that correctly, that vserver and
> vserver-stat are buggy. My view is it's the state representation.
>
Both are 'buggy' in some way. The lookup mechanism provided using
/var/run/vservers entries is not able to handle multiple files
containing the same context id and the entries are not consistent with
the real state of the vservers. While your patch fixes the latter and as
a side effect also removes the results the former, it also causes more
work then necessary, as it has to check each and every file.
Having a forward and a reverse lookup as described in my last mail
should avoid all problems (and make vserver-stat faster and more
intuitive IMHO). The next step would be cleaning up /var/run/vservers on
startup and removing the lookup entries on 'vserver ... stop'. And then
make vserver-stat show all vservers which have entries in
/var/run/vservers and as a second table all context that don't have a
associated vserver configuration.
But this is far too much of a change for the stable tools and i guess
alpha tools already handle this in a superior way...
I guess there was some misunderstanding regarding the patch caused by
your statement about the check for a running vserver on vserver start, I
thought of some strange kind of context sharing since i assumed that
you're using static context ids...
> So, maybe this was the cause of the confusion. So at
> first we have to find a common view.
>
> My patch fixes (hopefully) exactly what I described as my
> view above (by the time the whole vserver-system is restarted).
>
Cleaning /var/run/vservers on startup and removing entries on 'vserver
... stop' should do the same, right?
Consider a vserver that died off since all processes in the context
terminated, but it was not stopped using the tools. You may f.e. have
some lines in the post-stop script to remove some mount that is needed
by that vserver. Now the remaining /var/run/vservers entry can tell you
that you need to call 'vserver ... stop' to remove that mount. Your
patch would remove that file, if any other vserver is started.
... Of course the situation with the current /var/run/vservers behaviour
is just as bad, as there are not too few, but too many files ;)
> > Maybe the tools should enforce it. Advanced stuff, like disk limits
> > won't work with dynamic ids anyway.
> >
>
> Maybe you are right, and this should be noticed on
> installing vserver-tools.
>
> > > > And even if there's another vserver running in the same context, do you
> > > > really want a second vserver to be started in that context? I doubt it.
> > > > So IMHO checking if the vserver is running before starting it is fine
> > > > in the way it is done right now.
>
> No. Not two ctx-sharing vservers. Only the correct reply on
> "vserver-stat" or "vserver <vserver2> start" and vserver-init
> scripts. (As described above)
IIRC the forwarded mail just said something like 'checking if a vserver is
running on vserver start makes no sense', and that makes no sense, as
you most likely want a check whether the vserver is already running, you
just want it to be done right ;) Probably I misunderstood that one...
>
> So the target of my patch is quite "low level" :-)
> It's just to get the admin smiling.
>
> Not considered static ctxs. Not considered
> sharing contexts. etc. Just representation and
You should not consider sharing contexts, would probably only cause
trouble ;)
> working scripts. This (hopefully) works also for static ctxs, though
> I didn't tested this, as I supposed the dynamic ctxs to be a good
> default. It looks like I'm wrong at least with this.
>
Dynamic contexts are nice to put some processes in another context to
test things out without risking the system to die hard, but for vservers
they're not such a good choice.
> Does it break something?
The patch shouldn't break anything, just didn't look like
The Right Way(tm) to me.
> Please tell me the situation as it's intention was to be a fix
> and not a "worst" as you noted.
Did I say that? (too lazy to look up my exact words ;) Regarding my last
mail, I said that it _would_ make it worse if the situation was as Ola
described it, but this can't happen with dynamic context ids.
>
>
> Cheers
> Helmut
>
> PS: There was another situation, not in the BTS because not
> reproducible. So only for documentation purposes:
>
> I expirienced something strange on a "not patched" vserver.
> Since I can't reproduce it I haven't filed a bug report.
> I'm just curious if someone reported something simmilar.
>
> vserver A and B. Only A is shown to be started.
> Login by users of vserver A is working (password ok on shadow of A).
> But showing a ps -ef, apt-show-versions, ls, etc. is showing
> processes/state of vserver B.
>
> restart of vservers fixed the problem. keeping a strange feeling
> in my stomach... (had no time for digging into)
>
> My only explanation is a mixed up context. maybe you got
> a better idea. while the login-system was in chroot of
> A the new instance of bash etc. came up in chroot of B.
> only guessing....
Absolutely no idea... Herbert?
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver