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 > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver