From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 22 Dec 2004 - 10:04:37 GMT
On Wed, Dec 22, 2004 at 01:18:05AM +0100, Bjoern Steinbrink wrote:
> 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?
need more input, what kernel, what patches, what config ...
but sounds strange to me ...
best,
Herbert
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver