From: Bjoern Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Tue 21 Dec 2004 - 20:37:21 GMT
On 2004.12.21 20:20:12 +0100, Ola Lundqvist wrote:
> On Tue, Dec 21, 2004 at 07:25:35PM +0100, Bjoern Steinbrink wrote:
> > > Some analysis:
> > >
> > > /usr/sbin/vserver script:
> > >
> > > Context of new vserver is set
> > > - by /etc/vservers/name.conf
> > > - or by /var/run/vservers/name.ctx
> > > - or by the chcontext script itself
> > >
> > > "running" is evaluated by:
> > > - /var/run/vservers/name.ctx lockfile exists?
> > > - (vps ax | grep context | wc -l) >0 ?
> > >
> > > 1) Checking for running vserver in "start" makes
> > > no sense because .ctx files are never deleted
> > > and it's possible that other vserver has same
> > > context and is already running.
> > > So the result of "running" is running even
> > > if other vserver is started in this context.
> > What's the sense in having two or more vservers sharing the same
> > context? It may occur with vserver's having a dynamic context id that a
> > context id gets reused, but you should use static context ids anyway.
> Two vservers should never share them. The problem is (as you already know)
> is when you use dynamic contexts and when they get reused. The problem
> occur on power-failure and in some cases when vservers are restarted.
> I agree that this problem do not happen when you use static contexts but
> that is as far as I know not mandatory.
Maybe the tools should enforce it. Advanced stuff, like disk limits
won't work with dynamic ids anyway.
> > 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.
> I thought so too until Helmut Toplitzer <helmut_at_ifit.uni-klu.ac.at>
> convinced me. I think it is better to ask him, so I cc him with this mail.
> > >
> > > 2) Deleting vservers .ctx file makes no sense
> > > either because it can be missed by a hard reboot,
> > > kill, etc.
> > >
> > And it's not necessary, if no process is actually running in the context
> > whose id is stored in the .ctx file, the vserver is considered "not
> > runnning".
> This is not always true.
> Consider the following lines in the vserver script:
> elif [ "$2" = "running" ] ; then
> if [ ! -f /var/run/vservers/$1.ctx ] ; then
> echo Server $1 is not running
> exit 1
> ... the good check ...
> So if this server is not started before at all (no ctx file) and
> another vserver is running with the same ctx id you may get a problem.
> I think this is the reason he got his problem.
Then the patch would actually make it worse, as it deletes the .ctx file
whenever the vserver is not running, so it won't be there whenever the
vserver is not running and not only if the vserver has never run. But
the kernel will never give a used context id to a newly created dynamic
context, so this won't happen anyway.
If your configuration assigns the same context id to more than one
vserver then it is your fault ;)
> > > 3) Solution: before starting any vserver test
> > > for ALL vservers if they are running and remove
> > > remaining .ctx files of not running ones.
> > > Once booted into the schema everything should work.
> > > (hopefully *sigh*)
> > Now where's the difference, apart from the fact that all outdated .ctx
> > files are removed? Your patch removes exactly those files that would not
> > lead to the result that a vserver is considered running...
> The problem is that you can get wrong hostname set when a context
> file with same ctx id is in that directory.
> Other solutions are of course appriciated. I'm just interested
> in that the problem that Helmut has presented a reproducable
> test case to go away. :)
I guess somekind of reverse lookup would be nice. Like:
/var/run/vservers/rev/65000.ctx contains the name of the last vserver
started in that context (65000). Using the forward lookup (vserver->ctx)
you can determine whether a vserver is running, using the reverse lookup
(ctx->vserver) you can tell the name of the vserver currently running in
For dynamic contexts you'd need confirm that the forward lookup matches
the reverse lookup to avoid accidently claiming a vserver to be running,
although another vserver just happens to use its old context id.
This would also allow to modify vserver-stat in a way to lookup vserver
names without scanning the whole /var/run/vservers directory, but as
util-vserver is frozen, it might be too much of a change.
> // Ola
> > Regards
> > Bjoern
> --------------------- Ola Lundqvist ---------------------------
> / opal_at_debian.org Annebergsslingan 37 \
> | opal_at_lysator.liu.se 654 65 KARLSTAD |
> | +46 (0)54-10 14 30 +46 (0)70-332 1551 |
> | http://www.opal.dhs.org UIN/icq: 4912500 |
> \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
> Vserver mailing list
Vserver mailing list