1216166806 M * Bertl nah, seems to be space related ... 1216167483 Q * Aiken Quit: Leaving 1216167937 Q * infowolfe Quit: Leaving 1216167994 J * doener ~doener@i577B8DFA.versanet.de 1216168085 M * Bertl daniel_hozac: okay, here is my version of the defspace stuff, please give it a short check ... http://vserver.13thfloor.at/Experimental/delta-defspace-feat01.diff 1216168100 Q * doener_ Ping timeout: 480 seconds 1216168151 J * infowolfe ~infowolfe@c-67-160-149-42.hsd1.or.comcast.net 1216168159 Q * infowolfe 1216168223 J * infowolfe ~infowolfe@c-67-160-149-42.hsd1.or.comcast.net 1216168414 M * Bertl hmm, why do we need to get the nid from the socket in the unix sequencer code? 1216168525 M * Bertl I mean, why do we compare the socket to the nid stored in the iter? 1216168557 M * Bertl do we assume that the open happened in a different network context than the read? 1216171259 Q * fatgoose Ping timeout: 480 seconds 1216171600 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216173513 Q * fatgoose Ping timeout: 480 seconds 1216173705 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216174657 Q * fatgoose Ping timeout: 480 seconds 1216174849 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216175706 M * Bertl okay, off to bed now .. have a good one everyone! cya! 1216175711 N * Bertl Bertl_zZ 1216179490 M * infotron Can I permit guests complete access to a specific network device? eg, eth3. They'll have eth1 configured with a ip for reachability, but they possibly need access to a complete nic for lab/networking purposes 1216179745 M * micah infotron: what do you mean by 'complete access' 1216179784 M * infotron tcpreplay, tcpdump, etc 1216180598 M * micah infotron: I believe so, you just have to enable the right capabilities for that guest 1216180664 M * micah infotron: http://linux-vserver.org/util-vserver:Capabilities_and_Flags#Setting_network_capabilities_.28ncaps.29 1216180685 M * micah and http://linux-vserver.org/Capabilities_and_Flags#Network_context_flags_.28nflags.29 1216184410 J * micah_ ~micah@micah.riseup.net 1216184428 Q * micah Read error: Connection reset by peer 1216186500 J * Slydder ~chuck@194.59.17.53 1216187757 J * ntrs ~ntrs@77.29.75.77 1216188570 J * yarihm ~yarihm@62.65.128.217 1216188617 Q * infowolfe Quit: Leaving 1216188709 J * infowolfe ~infowolfe@c-67-160-149-42.hsd1.or.comcast.net 1216188856 M * Slydder morning all 1216189417 Q * pmenier_off Quit: Konversation terminated! 1216190128 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1216190145 Q * infowolfe Read error: Connection reset by peer 1216190234 M * infotron greetings Slydder 1216190327 J * cryptronic ~oli@p54A3B38E.dip0.t-ipconnect.de 1216190701 J * infowolfe ~infowolfe@c-67-160-149-42.hsd1.or.comcast.net 1216191203 J * z0d ~z0d@fw.wonderline.hu 1216191209 M * z0d good day 1216192306 J * dna ~dna@236-227-dsl.kielnet.net 1216192513 J * Moser ~chatzilla@Xae7e.x.pppool.de 1216192975 N * DoberMann[ZZZzzz] DoberMann 1216193735 Q * yarihm Quit: This computer has gone to sleep 1216193809 Q * ntrs Ping timeout: 480 seconds 1216193946 J * yarihm ~yarihm@62.65.128.217 1216194258 M * infotron goooddddd.... night! zZZZzz :) 1216194885 J * jehan ~jehan@pat7414.micro.int-evry.fr 1216195406 Q * jehan Quit: Leaving 1216195571 N * Bertl_zZ Bertl 1216195576 M * Bertl morning folks! 1216195777 M * matti Morning :) 1216195778 M * matti Hi Bertl ;] 1216196020 M * z0d hello 1216196789 M * matti Bertl: :)) 1216197527 M * pmjdebruijn lo 1216197528 M * pmjdebruijn mornin 1216197798 Q * yarihm Quit: This computer has gone to sleep 1216198348 M * pmjdebruijn I see there are multiple ways to break out of a chroot 1216198360 M * pmjdebruijn to which should vserver-development+xfs be "vulnerable" 1216198505 M * Bertl pmjdebruijn: none 1216198534 M * Bertl (given that the barrier is intact and properly placed) 1216198579 M * pmjdebruijn well, how can I check that? 1216198796 M * pmjdebruijn oh wait 1216198803 M * Bertl with the various chroot escape tools 1216199083 J * ReaCT ~ReaCT@75.141.193.228 1216199122 M * ReaCT anyone having any issues with vserver 2.6.22-3-vserver-amd64 on debian? 1216199139 M * ReaCT i build the vserver then when I attempt to start i get no output, and no vserver started 1216199391 M * nenolod this is on debian lenny, for what it's worth 1216199642 M * Bertl ReaCT: did you update util-vserver to at least 0.30.215? 1216199722 M * laptopnenolod ii util-vserver 0.30.215-4 user-space tools for Linux-VServer virtual p 1216199771 M * matti Bertl: Do you have patch for latest kernel? .26? 1216199782 J * squat ~squat@85-10-210-61.clients.your-server.de 1216199787 M * matti Bertl: Not mentioned on the web site ;p 1216199862 M * Bertl matti: nope, no patch for 2.6.26 yet 1216199901 M * Bertl laptopnenolod: okay, what does 'vserver --debug start' give? (please use paste.linux-vserver.org for everything longer than 3 lines) 1216199976 M * matti Bertl: I see. You recon that it is safe to try apply current one againt latest kernel? 1216199983 M * laptopnenolod Bertl, http://nenolod.net/~nenolod/stuff/vserver-log 1216200120 M * Bertl matti: won't work 1216200158 M * Bertl laptopnenolod: stty: standard input: Inappropriate ioctl for device 1216200185 M * Bertl laptopnenolod: something in your /etc/init.d/rc seems to fail with that 1216200202 M * laptopnenolod Bertl, inside the vserver? 1216200215 M * Bertl yup, in the rc script as it seems 1216200262 M * laptopnenolod still nothing 1216200308 M * matti Bertl: OK, thanks. 1216200375 Q * localghost Server closed connection 1216200377 J * localghost anders@ies57-061.ies.luth.se 1216200403 Q * opuk Quit: leaving 1216200422 J * opuk ~kupo@2001:16d8:ffbd:100::10 1216200425 M * laptopnenolod Bertl, removing it had no effect. fairly certain it's unrelated. 1216200476 M * ReaCT ls 1216201125 Q * C14r Server closed connection 1216201128 J * C14r ~C14r@h58173.serverkompetenz.net 1216201248 J * friendly ~friendly@ppp59-167-145-230.lns4.mel6.internode.on.net 1216201805 Q * Moser Remote host closed the connection 1216202286 J * Cantacuzenus ~cantacuze@82-171-147-213.ip.telfort.nl 1216202399 M * ReaCT looks like the vserver package is broken 1216202399 J * yarihm ~yarihm@84-74-147-84.dclient.hispeed.ch 1216202409 M * ReaCT cant build any new vservers on any of my other vserver boxes as well 1216202427 Q * Cantacuzenus 1216202467 M * Bertl ReaCT: could be, try with building from the source 1216202494 M * Bertl ReaCT: make sure to uninstall the debian packages first 1216202535 M * laptopnenolod ReaCT, try building an etch vserver instead of a lenny vserver. 1216202535 Q * fatgoose Read error: Connection reset by peer 1216202540 M * laptopnenolod ReaCT, i have a hunch 1216202541 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216202681 M * ReaCT ok etch is building 1216202681 M * Bertl could be that lenny guests break in some way (regarding the stty stuff) 1216203251 Q * kir Ping timeout: 480 seconds 1216203569 J * Aiken ~james@ppp121-45-243-126.lns2.bne4.internode.on.net 1216203900 M * laptopnenolod Bertl, yes. we have confirmed it by using snapshot.debian.net 1216203910 M * laptopnenolod Bertl, i've filed a bug against initscripts :) 1216203985 M * Bertl okay, make sure to get micah_ involved 1216203997 J * kir ~kir@swsoft-msk-nat.sw.ru 1216203999 M * laptopnenolod yeah 1216204003 M * laptopnenolod i work with him elsewhere ;p 1216204027 M * laptopnenolod infact, he's the one who told me about vserver i think 1216204027 Q * kir Read error: Connection reset by peer 1216204132 J * kir ~kir@swsoft-msk-nat.sw.ru 1216204492 Q * kir Read error: Connection reset by peer 1216204525 J * jsambrook ~jsambrook@aelfric.plus.com 1216204566 J * kir ~kir@swsoft-msk-nat.sw.ru 1216204810 J * lilalinux ~plasma@80.69.41.3 1216205436 Q * kir Read error: Connection reset by peer 1216205495 J * kir ~kir@swsoft-msk-nat.sw.ru 1216205675 Q * kir Read error: Connection reset by peer 1216205715 J * kir ~kir@swsoft-msk-nat.sw.ru 1216205805 Q * kir Read error: Connection reset by peer 1216205839 J * kir ~kir@swsoft-msk-nat.sw.ru 1216205929 Q * kir Read error: Connection reset by peer 1216205980 J * kir ~kir@swsoft-msk-nat.sw.ru 1216206112 Q * kir 1216206764 M * ReaCT was tagxid removed in the new vserver kernel? 1216206774 M * ReaCT my /home doesnt seem to mount on the 2.6.25-2-vserver-amd64 kernel with tagxid flag 1216206801 M * opuk it's called tag now 1216206817 M * ReaCT ah ok so just "tag" then 1216206849 M * ReaCT thanks :) 1216206854 M * opuk :) 1216206862 M * Bertl well, it is called tag for a long time ... tagxid is legacy 1216206878 M * Bertl i.e. legacy compatibility was removed 1216206909 M * ReaCT anywhere i can see the changes in the new kernel, the linux-vserver.org seems to still show only .19 1216206942 Q * yarihm Quit: This computer has gone to sleep 1216207329 M * pmjdebruijn Bertl: if I enable a barrier, my vserver doesn't start anymore (using development patch) 1216207332 M * pmjdebruijn http://pastebin.com/m72b8b916 1216207353 M * Bertl how do you enable the barrier? 1216207552 M * pmjdebruijn setattr --barrier I1234-TestSchool 1216207561 M * pmjdebruijn in /opt/vservers (which we keep the vservers) 1216207572 M * Bertl well, that's simply wrong :) 1216207583 M * pmjdebruijn oh :s 1216207586 M * Bertl you want to set the barrier on /path/to/guest/.. 1216207596 M * Bertl note the '..' which is literally 1216207605 M * pmjdebruijn ok 1216207670 M * pmjdebruijn indeed, that works 1216207930 M * pmjdebruijn Bertl: however... is /path/to/guest/.. somehow different from /path/to 1216208265 J * Moser ~chatzilla@Xae7e.x.pppool.de 1216208307 M * Bertl depends, it can be 1216208401 J * kir ~kir@swsoft-msk-nat.sw.ru 1216209059 J * yarihm ~yarihm@62.65.128.217 1216209156 J * moemoe moemoe@kuschelhoelle.netzhure.de 1216209164 P * moemoe 1216209700 M * pmjdebruijn we keep all the vservers in the same spot... 1216209861 Q * ReaCT 1216210540 Q * phedny Remote host closed the connection 1216210785 Q * yarihm Quit: This computer has gone to sleep 1216211523 J * phedny ~mark@2001:610:656::115 1216211826 Q * friendly Quit: Leaving. 1216212327 J * yarihm ~yarihm@whitehead2.nine.ch 1216212868 M * daniel_hozac Bertl: looks fine. 1216213035 M * Bertl ah, great! 1216213058 M * Bertl for the socket stuff, I decided to go with 'current' checks insted of the iter->nid 1216213079 M * Bertl *instead, or do you see any case where open context != read context? 1216213108 M * daniel_hozac not really, it was just more consistent with what the kernel's already doing. 1216213138 M * daniel_hozac (http://people.linux-vserver.org/~dhozac/p/k/delta-unix-fix01.diff) 1216213139 M * Bertl yeah, we know, the kernel folks are very straight forward (and sometimes more complicated than necessary) 1216213193 M * Bertl http://vserver.13thfloor.at/Experimental/delta-sock-fix03.diff 1216213251 M * Bertl for the exit fix, I decided to make a 'cheap' version now, as I'm not sure whether we want to pass vxi or xid into the exit inlines 1216213266 M * daniel_hozac hmm? 1216213285 M * Bertl i.e. I haven't decided what we should or should not pass there 1216213289 M * Bertl http://vserver.13thfloor.at/Experimental/delta-exit-fix01.diff 1216213311 M * Bertl funny thing I stumbled upon is this one: 1216213315 M * Bertl http://vserver.13thfloor.at/Experimental/delta-netns-fix01.diff 1216213330 M * Bertl without that, and network namespaces enabled, the kernel oopses quite fast 1216213466 M * daniel_hozac presumably due to the nsproxy mixing routines. 1216214363 M * Bertl hmm ... sec 1216214521 M * Bertl yeah, that might turn out to be more a problem than we think right now 1216214542 M * Bertl it seems that _any_ nsproxy needs to have a network namespace atm (mainline) 1216214572 M * Bertl so we probably blow up pretty soon when creating a context specific nsproxy without the network namespace 1216214630 M * daniel_hozac we'll probably have to handle that like the pidspaec. 1216214838 M * Bertl I think we should init it with the host space or so 1216214860 M * Bertl btw, I have a bunch of questions to the pidspace patch :) 1216214882 M * Bertl got a few minutes? 1216214888 M * daniel_hozac sure. 1216214896 M * Bertl + if (current->nsproxy->pid_ns == &init_pid_ns) 1216214897 M * Bertl + goto error; 1216214906 M * Bertl what's the purpose of that? 1216214917 M * daniel_hozac forcing pid namespaces. 1216214964 M * Bertl hmm, why? 1216214976 M * daniel_hozac it's, umm, what the patch is for :) 1216214999 M * Bertl okay, but a) what if you disable pid spaces? 1216215006 M * daniel_hozac you can't. 1216215015 M * daniel_hozac they'd be select'ed in Kconfig. 1216215022 M * daniel_hozac just like IPC, UTS, etc. 1216215026 M * Bertl and b) why is the init_pid_ns evil? 1216215052 M * daniel_hozac because then there'd be no pid separation. 1216215083 M * daniel_hozac if that's a "feature" you want, feel free to remove the check... :) 1216215103 M * Bertl okay, so no specific reason not to do so 1216215154 M * daniel_hozac other than process contexts not behaving anything like in the past, that's correct. 1216215210 M * Bertl next one: you remove the reaper and init process entries (from vx_info), because they get replaced by the (now mandatory) pid space, but what about the vcmd* stuff related to init/reaper? 1216215264 M * daniel_hozac you mean vx_set_init and vx_set_reaper? 1216215283 M * daniel_hozac the first should probably return -ENOSYS, and the second is implemented. 1216215312 M * Bertl okay, we do not hit any tool issues with the first being disabled? 1216215336 M * daniel_hozac we probably do :) 1216215358 M * daniel_hozac or, well, the migrate flags aren't really used right now. 1216215366 M * Bertl okay, so we probably need to be a little smarter there for backwards compatibility 1216215390 M * daniel_hozac backwards compatibility is broken by necessity. 1216215404 M * daniel_hozac i.e. you now _need_ a pid space. 1216215438 M * Bertl okay, but does it need tool interaction? 1216215449 M * daniel_hozac sure, the pid space has to be created. 1216215466 M * daniel_hozac and entering changes too. 1216215484 M * Bertl okay, so everything <0.30.216 will stop working? 1216215510 M * daniel_hozac yes. 1216215521 M * Bertl do you consider this a good idea? 1216215552 M * daniel_hozac i don't really see any other way around it. 1216215596 M * daniel_hozac i mean, sure, we could hack up some function to take care of entering, but that's not exactly easy. 1216215600 M * Bertl can you describe me the 'old' way to create a guest with init? 1216215615 M * Bertl (from the tool PoV) 1216215630 M * daniel_hozac vc_set_cflags with mask=VXF_STATE_INIT. 1216215673 M * Bertl I mean, what is running inside the guest at this point? 1216215686 J * darkfly ~locoputo@bl4-240-218.dsl.telepac.pt 1216215692 M * daniel_hozac vcontext. 1216215745 M * Bertl what if we keep the pid=1 from getting allocated at this phase (in the pid space)? 1216215766 A * darkfly >>>FREE MP3,FILM, XXX, HACKING, FULL PROGRAM, FULL GAME DOWNLOADS, XXX PASSWORDS, OTHER PASSWORDS, SERIALS, HIGHLY ELITE PROXIES, FREE CPANELS, AND MORE AT http://locoputo1234.100webspace.net/ TRY NOW<<>>REQUESTS? POST AT MY SITE<<< 1216215773 Q * darkfly Remote host closed the connection 1216215849 M * daniel_hozac and at what point do you suggest it gets allocated? 1216215865 M * Bertl at the point where we (for now) did set init 1216215890 M * Bertl and we assign it to that specific process (potentially freeing the existing one) 1216215912 M * Bertl would that work or confuse the hell out of the tools? 1216215912 Q * Aiken Remote host closed the connection 1216215940 M * daniel_hozac it would probably work, but, that's rather non-trivial to do in the kernel. 1216215971 M * Bertl why? 1216216029 M * daniel_hozac it's touching practically every pid related structure in the current process. 1216216115 M * daniel_hozac it just seems like a maintenance nightmare. but if you get it working cleanly, more power to you. 1216216120 M * Bertl what else except detach/attach_pid would that involve? 1216216159 Q * opuk Remote host closed the connection 1216216171 J * opuk ~kupo@alla.beundrar.kupo.se 1216216194 M * Bertl I mean, I don't see a problem with anything kept in the process of the tools, as it execs away the new init anyways 1216216226 M * daniel_hozac the tools don't mind, they're used to it. 1216216254 M * daniel_hozac i'm just saying you'd need to change p->pid, p->tgid, etc. too, when you alloc_pid. 1216216269 M * daniel_hozac similar to what copy_process does after it. 1216216325 M * daniel_hozac i suppose we could just do it the ugly way and modify the upid.nr... don't know if that would actually work though. 1216216425 Q * [PUPPETS]Gonzo Server closed connection 1216216437 J * [PUPPETS]Gonzo gonzo@fellatio.deswahnsinns.de 1216216485 M * Bertl seems to be the only thing used in find+ friends 1216216532 M * Bertl that might actually make a set_init work too (given there is no init left) 1216216666 M * daniel_hozac we'd have to update the pidmap too, so it'd be easy to check. 1216216668 Q * Hollow Remote host closed the connection 1216216681 J * Hollow ~hollow@proteus.croup.de 1216217329 Q * opuk Ping timeout: 480 seconds 1216217399 M * Bertl okay, I think we should investigate this. note: I don't have a problem if the new tools use a different way of setting/creating init (even a new version of context create/migrate) would be fine 1216217448 M * Bertl but I think we should not break all but most recent tools if it isn't really necessary 1216217465 M * Bertl (although it is tempting to force debian to update :) 1216217481 J * fatgoose_ ~samuel@26.80.modemcable.oricom.ca 1216217611 M * Bertl okay, next question: the reference count on vxi->vs_fs ? 1216217635 M * Bertl did that show up as problem (enter_space) 1216217702 M * daniel_hozac those hunks should've been part of the locking. 1216217735 M * Bertl okay, so any evidence that it is needed? 1216217769 M * daniel_hozac well, other than, without a reference count, it can go away if another process is calling set_space? 1216217785 M * Bertl how so? 1216217810 M * Bertl IMHO, vxi is ref-locked, and vxi keeps a ref on vx_nsproxy 1216217828 M * Bertl same is true for vx_fs, no? 1216217828 M * daniel_hozac process A calls enter_space, gets past the fs_struct and nsproxy from the context part, and gets interrupted. 1216217850 M * daniel_hozac at this point, process B calls set_space with CLONE_FS, dropping the reference to the fs_struct, and thus freeing it. 1216217883 M * daniel_hozac (the old fs_struct, i should say) 1216217892 Q * fatgoose Ping timeout: 480 seconds 1216217959 M * Bertl do you agree that vx_info holds a reference to vx_proxy and one to vx_fs? 1216217979 M * daniel_hozac yes. 1216218004 M * Bertl okay, you also agree that when vc_set_space is called, the vxi is referenced too? 1216218037 M * daniel_hozac sure. 1216218057 M * Bertl so why should vx_fs or vx_proxy go away then? 1216218084 M * daniel_hozac as i said, two processes, one in enter space, one in set space. 1216218097 M * daniel_hozac set_space puts the old ones when it's merged the new ones. 1216218134 M * Bertl ah, okay, well, that should be better handled with locking the vxi at that point 1216218160 M * Bertl i.e. while we are doing changes to vx_info 1216218178 M * daniel_hozac my locking patch does that... :) 1216218202 M * Bertl okay, but at that point, there is no need to ref the proxy or fs 1216218217 M * daniel_hozac there is. we're using them for longer than the lock is held. 1216218249 M * daniel_hozac we can't hold the lock across vs_mix_nsproxy, as that can sleep. 1216218362 M * Bertl well, depends on the lock, but I see what you mean 1216218397 Q * Slydder Quit: Leaving. 1216218407 M * Bertl okay, let's move that to the locking patch then 1216218489 M * Bertl and what is the new create/migrate actually used for? 1216218523 M * Bertl I mean it seems to call the very same functions, no? 1216218543 M * daniel_hozac yes. but it's a new API, since the pid space has to have been created before hand. 1216218593 M * Bertl but it does the same as the old one, no? 1216218630 M * daniel_hozac as i said, yes. 1216218632 Q * bzed Server closed connection 1216218637 J * bzed ~bzed@devel.recluse.de 1216218646 M * Bertl okay, we probably get that resolved when we manage to implement backwards compatibility 1216218927 M * Bertl btw, I'm pretty sure we should avoid char path[PATH_MAX >> 2] 1216218951 M * Bertl especially in the face of 4k stacks :) 1216219071 M * daniel_hozac well, malloc sleeps, so with the locking, it had to go. 1216219138 M * Bertl not an option, besides kmalloc should be fine with ATOMIC if really needed 1216219277 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216219514 M * Bertl in the worst case, put a lock around it and make it static :) 1216219643 Q * fatgoose_ Ping timeout: 480 seconds 1216219813 M * Bertl but we should move that to the locking patch too, as it is not pid related, or? 1216219881 M * daniel_hozac sure... 1216219949 M * Bertl in the context of the locking improvements, we probably want to call it outside any locks with reference to proxy/fs 1216220080 M * Bertl I'm going to focus on the 2.6.26 port now, if you find the time it would be great to break it down into the following changes: 1216220087 M * Bertl - locking improvements 1216220103 M * Bertl - pid virtualization removal 1216220121 M * Bertl - pid space incorporation 1216220143 M * Bertl this way it should be a lot easier to review 1216220814 N * micah_ micah 1216220925 J * hparker ~hparker@linux.homershut.net 1216221448 Q * hparker Quit: Quit 1216221452 J * hparker ~hparker@linux.homershut.net 1216222029 M * z0d bye 1216222033 Q * z0d Remote host closed the connection 1216222210 J * docelic ~docelic@78.134.201.183 1216223287 Q * fatgoose Quit: fatgoose 1216224838 N * DoberMann DoberMann[PullA] 1216225582 M * Bertl okay, off for now .. bbl 1216225586 N * Bertl Bertl_oO 1216226535 N * pmenier pmenier_off 1216226671 J * fatgoose ~samuel@82.80.modemcable.oricom.ca 1216226982 Q * magus Ping timeout: 480 seconds 1216227111 J * kiwiuk kiwiuk@89.243.169.116 1216227118 M * kiwiuk hi 1216227158 M * kiwiuk anyone here? 1216227174 M * arachnist maybe 1216227192 M * kiwiuk is everyine busy? 1216227202 M * kiwiuk everyone even 1216227221 Q * kiwiuk 1216227231 J * fatgoose_ ~samuel@82.80.modemcable.oricom.ca 1216227289 M * arachnist maybe 1216227384 Q * yarihm Ping timeout: 480 seconds 1216227502 Q * fatgoose Ping timeout: 480 seconds 1216227872 Q * lilalinux Remote host closed the connection 1216227872 J * yarihm ~yarihm@84-74-147-84.dclient.hispeed.ch 1216227904 Q * yarihm 1216229636 J * fdooo ~fdooo@125.128.185.182 1216231386 N * DoberMann[PullA] DoberMann 1216231578 J * ntrs ~ntrs@77.29.77.249 1216231969 Q * fdooo Read error: Connection reset by peer 1216231983 J * fdooo ~fdooo@125.128.185.182 1216232503 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1216232916 J * simon ~simon@ip-83-99-89-81.dyn.luxdsl.pt.lu 1216232946 N * simon sim0n 1216233055 M * sim0n kernel: 2.6.22.18-vs2.3.0.32 util-vserver: 0.30.215 arch:amd64 I can't stop or enter my vservers anymore 1216233065 M * sim0n when I try to do so I get this error: vnamespace: execvp("/usr/sbin/vserver"): No such file or directory 1216233082 M * sim0n my setup hasn't changed in a long, besides new kernel + patch maybe 1216233089 M * sim0n any idea what the problem could be ? 1216233109 M * sim0n the vservers are happily running though.... 1216233161 M * micah sim0n: nenolod encountered this last night and suggested it was a problem with an initscript, he said he filed a bug, but I am not aware of what the bug number or solution is 1216233187 M * sim0n micah: hmm an initscript on the host or guest ? 1216233195 M * micah sim0n: guest 1216233223 M * sim0n micah: are you sure as the guests "should" be independant of the host hmmm 1216233233 M * sim0n micah: host is gentoo, guest is 32bit debian 1216233247 M * micah sim0n: #491072 1216233258 M * micah (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491072) 1216233273 M * sim0n micah: I'll check it out thanks ! 1216233279 Q * fdooo Remote host closed the connection 1216233283 Q * hparker Quit: Quit 1216233393 M * daniel_hozac uh... that's not a bug report :) 1216233416 M * daniel_hozac sim0n: and you have /usr/sbin/vserver? is /usr a separate mount point? 1216233443 M * sim0n first of all the reported bug is about lenny/sid....I am running etch 1216233461 M * sim0n second, on one of my hosts with the same host system and syme guests, it doesn't show those problems 1216233476 M * sim0n so I'm not really sure this is a bug in debian 1216233500 M * sim0n daniel_hozac: I do have /usr/sbin/vserver but not in the guest 1216233500 M * micah nenolod: yeah, what kind of bug report is that? heh 1216233524 M * daniel_hozac the guest shouldn't have it. 1216233527 M * sim0n daniel_hozac: /usr is a separate mount point yes 1216233544 M * daniel_hozac did you have the utils in /sbin previously? like when you started the guest? 1216233551 M * sim0n daniel_hozac: on the host I do have it :-) 1216233573 M * daniel_hozac vnamespace -e cat /proc/mounts doesn't show /usr, right? 1216233584 M * sim0n daniel_hozac: uhm you mean /usr/sbin ? ... 1216233588 M * sim0n daniel_hozac: sec I'll check 1216233617 M * sim0n daniel_hozac: it doesn't ... :-D .. thanks ! 1216233636 M * sim0n daniel_hozac: do you know how I could fix this without rebooting all vservers ? 1216233668 M * daniel_hozac mount /usr in the guests' namespaces. 1216233696 M * daniel_hozac e.g. vmount --running -- -t ext3 /dev/sdXY /usr 1216233706 M * daniel_hozac (i think --running is supposed to work...) 1216233801 M * sim0n --running does not work 1216233843 M * sim0n using the guest name works... but I still get the error and stopping/entering still does not work ...and cat /proc/mounts still doesn not show /usr 1216233844 M * sim0n hmm 1216233898 M * sim0n using vnamespace ...... works 1216233948 M * daniel_hozac vmount should do that... 1216233988 M * sim0n the command didn't give an error, but it didn't mount anything either 1216234030 M * daniel_hozac weird. 1216234036 M * sim0n :-) 1216234056 M * sim0n anyway thanks a lot ! 1216234080 M * sim0n i'll add this to the wiki in case anyone else hits this problem :-) 1216234579 Q * sim0n Remote host closed the connection 1216234688 J * hparker ~hparker@linux.homershut.net 1216235850 Q * Medivh Server closed connection 1216235867 J * yarihm ~yarihm@84-74-147-84.dclient.hispeed.ch 1216235912 J * Medivh ck@dolphin.serverbox.de 1216235916 J * independence independen@titan.blinkenshell.org 1216235931 Q * weasel Quit: Reconnecting 1216235935 J * weasel weasel@weasel.chair.oftc.net 1216235941 M * independence is there going to be a stable release for 2.6.26? 1216235971 M * daniel_hozac probably. 1216236028 M * independence ok, cool 1216236171 Q * _er Quit: Leaving. 1216239399 Q * bonbons Quit: Leaving 1216240407 N * Bertl_oO Bertl 1216240413 M * Bertl back now ... 1216241421 Q * yarihm Ping timeout: 480 seconds 1216241535 M * nenolod micah, one written when i was very tired and frustrated 1216241643 Q * ntrs Ping timeout: 480 seconds 1216241909 J * Aiken ~james@ppp121-45-243-126.lns2.bne4.internode.on.net 1216241924 M * Bertl morning Aiken! 1216241941 M * Aiken hello 1216242202 M * Bertl how's going? 1216242398 M * laptopnenolod daniel_hozac, fact is. latest initscripts do fail with vserver. /etc/init.d/rc 3 exits somewhere. 1216242415 M * Bertl the stty thingy? 1216242418 M * laptopnenolod daniel_hozac, this was not the case in 5/04 1216242429 M * laptopnenolod Bertl, no. fairly certain it outright exits somewhere 1216242444 M * Bertl interesting, could you strace -fF it? 1216242466 M * laptopnenolod the vserver start? 1216242493 M * laptopnenolod not at the moment, we wound up installing off of snapshot.debian.net/archive/2008/05/04 1216242504 Q * Djinh Quit: Leaving 1216242641 M * Bertl nah, the rc script run 1216242655 M * Bertl i.e. wrap it into another script and strace -fF 1216243172 J * derjohn_mob ~aj@e180201149.adsl.alicedsl.de 1216243476 Q * docelic Quit: http://www.spinlocksolutions.com/ 1216243911 Q * infowolfe Quit: Leaving 1216244775 Q * tokkee Server closed connection 1216244776 J * tokkee tokkee@ssh.faui2k3.org 1216245262 Q * Guy- Server closed connection 1216245267 J * Guy- ~korn@elan.rulez.org 1216245504 Q * m_o_d_ Server closed connection 1216245515 J * m_o_d ~m_o_d@host-80.54.30.252.ltv.pl 1216245688 J * dna_ ~dna@236-227-dsl.kielnet.net 1216245786 Q * fafa_ Ping timeout: 480 seconds 1216246020 Q * cryptronic Quit: Leaving. 1216246068 Q * dna Ping timeout: 480 seconds 1216246723 Q * dna_ Quit: Verlassend 1216247250 N * DoberMann DoberMann[ZZZzzz] 1216247272 Q * derjohn_mob Ping timeout: 480 seconds 1216249378 Q * eyck Remote host closed the connection 1216249380 J * eyck uTPbSiMz@nat03.nowanet.pl 1216249561 M * Bertl hey eyck! LTNS! 1216250734 J * mib_jb5j0njd 52525e30@67.207.141.120 1216250742 Q * fatgoose_ Ping timeout: 480 seconds 1216250809 P * mib_jb5j0njd 1216251896 J * daniel_hozac_ ~daniel@ssh.hozac.com 1216251979 Q * phedny Ping timeout: 480 seconds 1216252000 Q * daniel_hozac Ping timeout: 480 seconds