From: Helmut Toplitzer (helmut_at_ifit.uni-klu.ac.at)
Date: Tue 21 Dec 2004 - 22:26:06 GMT
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.
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).
> 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)
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
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.
Does it break something?
Please tell me the situation as it's intention was to be a fix
and not a "worst" as you noted.
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....
-- My GNUpg fingerprint http://www.gnupg.org 4563 F4FB 0B7E 8698 53CD 00E9 E319 35BD 6A91 1656 _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver