1169683301 M * Guy- can I use vserver unify if my /vservers directory is nfs mounted from a server that doesn't have the vserver patch? 1169683437 M * Guy- btw, what happened to the flood kiddies? I'm ignoring quits/leaves/joins, so I didn't see :) 1169683598 Q * m`m`h Ping timeout: 480 seconds 1169683677 Q * dna Quit: Verlassend 1169683854 Q * meandtheshel1 Quit: Leaving. 1169684116 M * Guy- ah, unify doesn't work for not-running vservers at all. what a pity. 1169684153 M * mugwump what? 1169684166 M * mugwump it should 1169684242 M * Guy- # vserver mail unify -n -v 1169684242 M * Guy- Initializing exclude-list for /var/lib/vservers/mail (mail) 1169684242 M * Guy- 'vserver ... suexec' is supported for running vservers only; aborting... 1169684242 M * Guy- failed to determine configfiles 1169684294 M * Guy- maybe building the exclude list requires the vserver to be running? 1169684314 M * Guy- the trouble is, I can't really start it now, because the vserver has a different architecture :) 1169684317 M * mugwump yeah, it tries to do package manager aware stuff, which I always considered pointless 1169684335 M * Guy- OK, so 'manual' mode should work then 1169684338 M * mugwump sure 1169684376 M * mugwump the script I originally wrote just traversed the directory structures in parallel looking for files that might be the same, then carefully just linked them together and set the immulink bits 1169684386 M * doener_ hashify should work anyway 1169684386 M * mugwump simple. fast. 1169684389 M * Guy- is then a path relative to the vserver root? 1169684411 M * Guy- does setting the immulink bits work over nfs? 1169684414 M * doener_ but if the nfs server isn't patched, I'm not sure that it will do the expected thing 1169684436 M * doener_ setting: probably, do the right thing: probably not 1169684440 M * Guy- OK, I'll leave it then 1169684454 M * Guy- vunify can wait 1169684495 M * mugwump doener_'s right, vhashify also manages to work without package manager awareness 1169684532 M * Guy- isn't the package manager stuff just supposed to find out which files not to hardlink even if they are the same? 1169684541 M * Guy- (because they are conffiles?) 1169684578 J * juggo ~lemur@h-68-166-181-4.sttnwaho.covad.net 1169684585 M * Guy- I'm not sure I see how hashify can do a better job there 1169684591 M * mugwump it shouldn't matter, because the madcow patch will split them up later 1169684616 M * doener_ yep. Because the IUNLINK stuff will make your life really hard otherwise. But with recent vserver patches, you got CoW, which can deal with any file being unified transparently 1169684619 M * mugwump it mattered with my script because there was no automatic link breaking, so I just ran it on /lib, /sbin, /bin and /usr 1169684670 M * Guy- alas, I don't have automatic link breaking now because this is a stock debian kernel 1169684683 M * Guy- and it uses vserver 2.0.x 1169684696 M * Guy- I'll roll my own later 1169684742 M * Guy- btw, the CoW link breaking only breaks links that cross vserver boundaries, I hope? 1169684771 M * Guy- i.e. if I have an inode with three links in vserver A and three links in vserver B 1169684780 M * Guy- and then modify the file in vserver A 1169684800 M * Guy- then vserver A gets a new copy, and all three of its links point to that? 1169684825 M * Guy- or will A get a new copy with one link, and the original will be preserver with two links in A and three in B? 1169684835 M * Guy- *preserved 1169684892 M * doener_ the latter case 1169684936 M * Guy- that's not so good then (but I realize it would be very difficult to do any other way) 1169684965 M * doener_ hardlinks you create yourself don't have the cow flag, so they are not broken 1169684982 M * doener_ no idea if vhashify might mess with them though 1169684995 M * Guy- ah - but didn't you just say they would be broken? 1169685010 M * doener_ assuming that they have the cow flag set 1169685030 M * Guy- but they must have 1169685034 M * doener_ (which happens to be the same as IUNLINK IIRC) 1169685046 M * Guy- because vserver A might decide to modify any of the three 1169685055 M * Guy- so all must have the cow flag 1169685067 M * Guy- (besides, isn't that the property of the inode rather than the directory entry?) 1169685104 M * doener_ I think so 1169685138 M * Guy- well, if it's a property of the inode, then naturally all directory entries that reference it (i.e. hardlinks) must have the same set of flags 1169685193 M * Guy- so it looks like CoW will break hardlinks inside a vserver too 1169685202 M * Guy- (unless I'm missing something, of course) 1169685217 M * doener_ let me try to explain better... You can generate hardlinks yourself, e.g. cp -la kernelA/ kernelB/, those will not be broken and you get the usual hardlink semantics 1169685241 M * mugwump but what if you hardlink a CoW file yourself? 1169685248 M * Guy- exactly 1169685256 M * Guy- like /bin/gzip - /bin/gunzip 1169685268 M * juggo so I'm creating some vservers to test services on an i386 etch machine, but eventually they need to be setup on an amd64 etch machine and at that time I'd prefer to keep the vservers I'm working on but would like to upgrade them to the amd64 architecture, so my question is whether people have done this successfully using debootstrap or some other method? 1169685274 M * doener_ good point 1169685299 M * Guy- juggo: this is almost what I'm doing 1169685354 M * Guy- juggo: let me get this straight; you have some configured i386 vservers, and want them to become amd64 vservers? 1169685359 M * doener_ I'd assume vhashify to ignore files that have a hardlink count > 1 and no CoW flag set, but I can't tell for sure 1169685380 M * Guy- doener_: that still doesn't help because you can hardlink them later 1169685404 M * Guy- juggo: I don't think there is an easy and clean way to do that, other than reinstall them using amd64 1169685416 M * doener_ that should hopefully break the original hardlink, but I'm not sure if that actually happens 1169685440 M * mugwump hey, there's a security issue there 1169685456 M * mugwump if hashify touches setuid binaries 1169685461 M * juggo guy: yes that's correct 1169685469 M * juggo i386 arch to amd64 arch 1169685507 M * Guy- juggo: I guess you could try to dpkg --get-selections >somefile 1169685508 M * doener_ i.e. to get CoW-linked the file must have a hardlink count of 1 or the CoW flag set. And if you create a hardlink on a CoW file, the original hardlink must be broken. Otherwise you can get broken behaviour 1169685524 M * Guy- juggo: set up the new amd64 vserver with debootstrap 1169685534 M * Guy- juggo: and then dpkg --set-selections 1169724840 M * meebey cool :) 1169724861 M * nox daniel_hozac: 2.6.18.2-vs2.1.1 1169724936 M * daniel_hozac nox: that should do the right thing. 1169724981 M * daniel_hozac i don't have such an old devel kernel running anywhere to verify though. 1169725006 M * nox remounting /vservers is a bit complicated to remount, otherwise i would give that a try 1169725052 M * nox would 2.3 run with same guestconf (because lo and foo?) 1169725067 M * daniel_hozac 2.2 would certainly do it. 1169725113 M * daniel_hozac i haven't gotten around to using 2.3 yet, so i can't speak for that. 1169725124 M * nox ok switch to 2.2 then on the productiv system 1169725136 M * nox and test 2.3 9~9~9~9~9~9~qhome 1169725143 M * nox argh @ 1169725205 J * zombiee ~Matlabi@cm163.gamma141.maxonline.com.sg 1169725327 M * nox if i should wait for 2.6.20? 1169725384 M * daniel_hozac i don't think 2.6.20 brings anything really interesting. 1169725435 M * daniel_hozac AFAIK it's just a partial implementation of the pid namespace. 1169725451 M * daniel_hozac and that might not even make it into the release. 1169725459 M * nox oic 1169726627 Q * ensc Killed (NickServ (GHOST command used by ensc_)) 1169726636 J * ensc ~irc-ensc@p54B4F93E.dip.t-dialin.net 1169727680 M * cehteh 2.6.20 brings kvm :P 1169727766 M * daniel_hozac but that's not really interesting from a vserver point of view. 1169727860 M * daniel_hozac (and i don't have a single box where it'd work, so... :)) 1169728030 M * cehteh yeah ... only my wife's box will work with it .. but i plan to use it there for desktop purposes ... no vserver there 1169728078 M * meebey why the need for KVM? isn't xen not good enough? 1169728115 M * daniel_hozac not quite the same, IIUC. 1169728125 M * daniel_hozac KVM is more like qemu-accelerator. 1169728148 M * meebey "Xen supports both full virtualization and a technique called paravirtualization, which allows better performance for modified guests. kvm does not at present support paravirtualization." 1169728174 M * daniel_hozac plus Xen isn't in mainline. 1169728202 M * daniel_hozac despite their claims of wanting to be. 1169728239 M * meebey IMHO pushing xen into mainline they would get more from that than re-inventing it 1169728255 M * meebey only x86 is supported for KVM, great, thats like xen some years ago 1169728284 M * daniel_hozac but nobody is pushing into mainline. 1169728294 M * daniel_hozac so there's ample room for KVM. 1169728367 M * meebey so it could be xen fault to not bring xen into shape for being included mainline, things like selinux made it though 1169728469 M * meebey http://kvm.qumranet.com/kvmwiki/Debian 1169728482 M * meebey looks like they are pretty far already, being available in distros 1169728498 M * daniel_hozac yep. 1169728523 M * nox any reason to turn VSERVER_REMAP_SADDR off? 1169728567 M * daniel_hozac if you want the old behaviour. 1169728586 M * cehteh meebey: i want a *simple* solution to run other maybe propietary oses on the desktop .. qemu/kvm have the best user interface for that imo 1169728614 M * daniel_hozac i.e. connections to 127.0.0.1 inside a guest appears to come from 127.0.0.1 to the first assigned IP. 1169728624 J * DavidS ~david@vpn.uni-ak.ac.at 1169728625 M * daniel_hozac cehteh++ 1169728665 M * meebey what userinterface? :) 1169728671 M * meebey you mean simple CLI? 1169728672 M * cehteh commandline ;) 1169728673 M * Hollow KVM doesnÄt even need to provide paravirtualization, since it supports full virtualization 1169728675 M * cehteh yes 1169728679 M * meebey :) 1169728685 M * meebey I dont like bloaty stuff either 1169728693 M * cehteh but it is very flexible and qemu has quite cool snapshotting support 1169728697 M * meebey I tried xen some days ago, its not running yet :) 1169728705 M * cehteh just what you want for desktop apps 1169728712 M * meebey it uses some python fluff which has problems 1169728718 M * nox daniel_hozac: thx again 1169728720 M * cehteh for a server i would likely use xen when i have to runb diffrent kernels 1169728738 M * cehteh qemu doesnt use python 1169728743 M * meebey but xen 1169728743 M * daniel_hozac Xen does. 1169728751 M * cehteh i didnt yet looked into xen ... no need 1169728756 M * meebey and it fails without useable messages 1169728759 M * nox i hearded xen to have stability probs (so i.e redhat goes away from it) 1169728796 M * meebey xend doesnt start with just "connection refused" in the log with a pyhton stack trace 1169728804 M * nox and it seems to be far away from beeing included into mainline 1169728804 M * cehteh lol 1169728815 M * meebey far away from being simple :) 1169728834 A * meebey loves and believes in KISS 1169728843 M * daniel_hozac meebey: yeah, i had to spend a couple of days stracing various xen processes to get a guest running... 1169728856 M * meebey daniel_hozac: horrible 1169728861 A * nox kisses vserver ^^ 1169728864 M * cehteh i just have no need for it since i only use linux 1169728868 M * meebey yeah vserver rocks 1169728885 M * cehteh but my wife has some business application which runs only on windows 1169728889 M * meebey I want to use xen for resource control 1169728891 M * cehteh (not even wine) 1169728919 M * cehteh currently we run it in vmware but i want to move away from vmware 1169728933 M * meebey we use also vmware for win32 stuff on servers 1169728939 M * meebey vmware-server is pretty ok 1169728939 M * cehteh maybe i try dbox too ... but first KVM .. looks promising 1169728945 M * meebey but no resource control 1169728950 M * cehteh vmware-workstation here 1169728969 M * meebey yeah I might try KVM too, looks very easy :) 1169728976 M * meebey I mean in 4 command line, its running, great :) 1169728986 M * cehteh yes thats the point 1169729004 M * cehteh for desktop things KVM is really the right aproach imo 1169729007 M * meebey IMHO system-software should be like that, no enterprisy please 1169729025 M * cehteh if it works well servers, that has still to be prooven 1169729027 M * meebey configs can always fine-tune it... 1169729038 M * meebey true 1169729068 M * meebey software that is easy to use, gets many users and with that it becomes stable fast, compare to software nobody uses :) 1169729100 M * cehteh xen is even to play with too much hassle to set up unless you are really interested and have some spare time 1169729138 M * meebey oh also the most annoying thing in xen I found in the first few seconds trying it 1169729139 M * cehteh vserver was once simple too .. but now its little more complicated :P 1169729145 M * meebey the kernel is auto-resetting if there is a problem 1169729152 M * meebey thats very very user unfriendly 1169729195 M * daniel_hozac cehteh: how so? 1169729199 M * meebey cehteh: yeah IMHO it only got more complicated because of a spreaded config layout 1169729212 M * meebey have to read more docs now, before you can start :) 1169729225 M * meebey before you could use the example config, copy it, start vserver 1169729230 M * daniel_hozac what is it that you need to configure, that is not configurable with vserver ... build switches? 1169729265 M * meebey maybe I should use the newvserver scripts or so, currently its pain to create new configs for me, by hand 1169729283 M * daniel_hozac ... why on earth would you be creating the configs by hand? 1169729301 M * cehteh because i dodnt know about newvserver scripts :P 1169729304 M * meebey because thats how system-software does it? 1169729316 M * meebey and yes I didnt need newvserver scripts before, because it was so easy 1169729327 M * daniel_hozac vserver ... build -m skeleton ... will create the config for you. 1169729340 M * cehteh i like the one-config-file thing more ... 1169729353 M * meebey me too :-P 1169729354 M * cehteh but anyways its not too complicated 1169729359 M * daniel_hozac newvserver is a Debianism that probably only a handful of people know how it works, and none of them frequent the channel. 1169729376 M * meebey oh thats not the official way, didnt know that :) 1169729378 M * daniel_hozac so, how would you express e.g. disk limits in the one-config-file? 1169729385 M * meebey so I will take a look into vserver build command 1169729401 M * cehteh i rarely create new vservers .. 1169729405 M * meebey daniel_hozac: using one config file is not that easy, thats correct 1169729417 M * meebey it can become very messy, see apache 1169729434 M * meebey but as another example samba, it works very well 1169729434 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1169729441 M * cehteh well the new debian way configureing apache is ok imo 1169729448 M * cehteh (for apache standards :P) 1169729451 M * daniel_hozac i think apache is rather simple to configure. 1169729453 M * meebey :) 1169729481 M * daniel_hozac but apache also has a sophisticated configuration file parser. 1169729501 M * cehteh when i ever finish my smal config language i'll have to talk with ensc about integrating it in the vserver userland tools :P 1169729521 M * daniel_hozac _i_ have no interest in writing anything more sophisticated than what the current utils use. 1169729556 M * cehteh yeah config syntax has to be simple 1169729563 M * daniel_hozac configuration file parsers are inherently prone to problems. 1169729564 M * cehteh key = value 1169729584 Q * Fire_Egl Quit: ... 1169729587 M * cehteh well i have some novel idea ... which is simple 1169729592 M * meebey ok and now the killer: XML! 1169729602 M * daniel_hozac 0.30.214 should hopefully support different configuration backends. 1169729610 M * meebey I could kill ppl using XML for configs... 1169729620 A * cehteh pukes into meebey's shoes 1169729629 M * cehteh hehe 1169729639 M * daniel_hozac so then it's just up to the people complaining to write new backends :) 1169729644 M * meebey the first time I saw someone crazy enough using XML as config is tomcat 1169729645 M * daniel_hozac ;) 1169729665 M * daniel_hozac well, tomcat is nuts on so many levels. 1169729675 M * meebey and since that I know I never ever want XML configs 1169729686 M * daniel_hozac i mean, Java? come on. 1169729689 M * meebey the syntax is way too flexible to get it right :) 1169729700 M * meebey you needs tons of documentation which is usually always missing 1169729702 M * meebey in FOSS 1169729714 M * meebey and even then its PITA to write it 1169729721 M * meebey as I am not a computer but a human 1169729759 M * meebey so I love the directory/file config approach compared to XML :) 1169729794 M * daniel_hozac the flower page should have every option supported. :) 1169729816 M * meebey I was dissappointed I couldn't edit the page, as its not part of the wiki 1169729818 M * daniel_hozac (i know there are some missing, but that's on the TODO for 0.30.213) 1169729830 M * daniel_hozac well, patches are accepted, as always. 1169729835 M * daniel_hozac the source is in doc/configuration.xml. 1169729849 M * meebey editing wikis is easier, at least for me 1169729874 M * cehteh btw anyone of you read my question on the ML about Oldenburger Linux Informationstage? 1169729878 M * meebey I only take my time to write patches if its very important 1169729911 M * daniel_hozac meebey: well, given that it's a file in the utils, editing the wiki page will have no effect... 1169729932 M * meebey hm the typical source problem 1169729937 M * meebey I had that too already 1169729958 M * daniel_hozac cehteh: if we wanted a booth? 1169729980 M * cehteh yes, at least being present there 1169729987 Q * Borg- Read error: Connection reset by peer 1169729991 M * meebey I had a big document in wiki, and in the end I had to rewrite it using some better format 1169729993 M * meebey which was SGML 1169730012 M * meebey downside of wikis I guess 1169730029 M * cehteh good wikis have XML export :P 1169730031 M * meebey to merge contributions back into the official sources 1169730091 A * cehteh just maintains docs in the wiki and dumps the page with w3m into a textfile which goes intro the distribution 1169730114 M * daniel_hozac well, the flower page is an entirely separate page. 1169730127 M * cehteh yes i know 1169730139 M * cehteh should be maintained in the wiki ... 1169730181 M * yarihm anyone having a good howto for creating a OpenSuSE vserver? 1169730214 M * daniel_hozac well, the person who wrote the XSLT for wiki-output used some constructs my xsltproc doesn't understand. 1169730221 M * daniel_hozac so i can't export things to the wiki anyway. 1169730242 M * cehteh how about just copy and paste the text first? 1169730243 M * daniel_hozac (and we have it in the wiki already, btw. http://linux-vserver.org/util-vserver:Documentation) 1169730250 M * cehteh ah jey 1169730252 M * cehteh yes 1169730261 M * daniel_hozac IIRC that's 0.30.211 though. 1169730273 M * yarihm l[[[ 1169730294 M * daniel_hozac yarihm: none that i know of. 1169730339 M * daniel_hozac besides, if the flower page was moved to the wiki, we couldn't call it the flower page anymore. 1169731118 M * daniel_hozac yarihm: looks like it should be possible to use yum to install it. 1169731238 M * yarihm daniel_hozac: i've not too much of a clue about RPM based distros. I guess i'd have to do something like vserver create opensuse -m yum --path-to-the repository or something? any pointers? 1169731274 M * daniel_hozac you'd have to create a /etc/vservers/.distributions/opensuse10.2 or similar first. 1169731341 M * daniel_hozac i've never used SuSE so i'm not entirely sure what the right thing would be. 1169731407 M * yarihm ok ... so i guess in there there should be some content ... i'll check the flowerpage :) i'd appreciate any hints you could give anyway, even though they might require some tweaking 1169731446 M * daniel_hozac i'm gonna try it out myself, and if it works out, it'll be in 0.30.213. 1169731501 P * zombiee 1169731757 M * yarihm :) that's not the thing i was whishing for since i'd need that opensuse-thing for a customer now. i'll try to get one running 1169731816 M * daniel_hozac well, pulling it out of svn isn't hard... ;) 1169731884 M * yarihm ah, it's in the svn-tree already? 1169731903 M * daniel_hozac no, but it will be once i see that it works. 1169731954 M * yarihm yes :) that's great but i'll need it this evening. no problem though, i think i have an idea how i could get there, even though it might not be such a clean approach 1169731979 M * yarihm ... argh, what a distro, the installer allone needs 512MB RAM ... 1169731986 M * yarihm s/allone/alone 1169732020 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/uv/experimental/opensuse10.2-config.tar.gz is what i'm testing with, seems to get the job done. 1169732064 M * yarihm ok. i'd extract that to /etc/vservers/.distributions/opensuse10.2 and then get a clue on how to call it i guess 1169732067 M * yarihm thanks a lot 1169732098 M * daniel_hozac extract in /etc/vservers/.distributions, it'll create the opensuse10.2 directory. 1169732106 M * daniel_hozac vserver opensuse build -m yum ... -- -d opensuse10.2 1169732118 M * daniel_hozac the initpost script doesn't seem to do the right thing though. 1169732150 M * yarihm you made my day :) i'll have a look at the initpost-script. what's wrong with it? 1169732154 M * daniel_hozac (as expected, since i just copied it from the fc6 tree) 1169732200 M * bonbons daniel_hozac: you're right, I got the wrong console when looking at inittab... the right one is '/etc/init.d/boot' followed by '/etc/init.d/rc $level' 1169732205 Q * Ramjar 1169732342 M * daniel_hozac bonbons: hmm, so sysv should do the right thing, unless rc bails out if boot hasn't done som prep stuff. 1169732480 M * bonbons thats really possible, will restart the guest and check if it outputs anything to console... (/dev/console -> /dev/tty1, tty1 c 4 8) 1169732515 M * daniel_hozac so tty8 in reality? 1169732559 M * bonbons yes 1169732824 M * bonbons hm, and that guest does not even want to terminate properly, it's 'halt -p -d -f' process is stuck in D state and vshelper still there 1169732837 M * bonbons don't know what it's waiting for! 1169732870 M * daniel_hozac hmm, what util-vserver is that? 1169732909 M * bonbons the 0.30.212-r1 (gentoo), on x86_64 1169732947 M * bonbons kernel is 2.6.19.2-vs2.2.0-rc8 (with IPv6) 1169732984 M * daniel_hozac hmm, so vshelper should exit right after a SIGINT to init has been sent. 1169733026 M * bonbons looks like the vshelper is doing something with /tmp/vshelper-stop-sync.$TMP/pipe (cat) 1169733032 M * daniel_hozac OpenSuSE sure has some weird dependencies. the network service requires haldaemon to be on... 1169733039 M * daniel_hozac and syslog-ng requires the network service. 1169733058 M * daniel_hozac right, it's waiting on the synchronization signal from vserver ... stop 1169733138 M * bonbons where should that one be coming from? no vserver stop in sight 1169733192 M * bonbons running it manually it just complains 'vkill: vc_ctx_kill(): no such process' and remaining halt process 1169733213 M * bonbons looks like a kind of inter-process deadlock 1169733313 M * bonbons what helped is echoing something to the pipe 1169733678 M * bonbons not a single line of ouput from SuSE when running with default init style (or explicit sysv) 1169733716 M * bonbons adding some echo to /etc/init.d/rc it stops nearly at the start: test "$PREVLEVEL" = "$RUNLEVEL" && exit 0 1169733808 M * bonbons neither is set 1169733842 M * bonbons that's a SuSE 10.1 1169733910 N * Snow-Man_ Snow-Man 1169734027 M * daniel_hozac ah ha! 1169734138 M * daniel_hozac i guess you could set them in /etc/vservers//apps/init/environment 1169734237 M * bonbons I could but isn't plain a better default style? will work with more guests, even those that are not sysv-based at all 1169734294 M * daniel_hozac it adds an unnecessary process to each guest, and it means you don't get to see init's output. 1169734658 M * daniel_hozac seems SuSE is gonna need some love before it runs cleanly... 1169735903 J * FireEgl Atl-NA@adsl-4-58-61.bhm.bellsouth.net 1169736587 M * Guy- can I have a syslog process on the host listen on a unix domain socket in a vserver, with clients running in the vserver connecting to it? 1169736967 M * Guy- or are unix domain sockets of different contexts isolated from each other as well? 1169737048 M * cehteh Guy-: that works, i am using it 1169737071 M * Guy- cool, thanks 1169737080 M * cehteh unix-stream("/dev/log"); 1169737080 M * cehteh unix-stream("/vservers/galaxy/dev/log"); 1169737080 M * cehteh unix-stream("/vservers/luna/dev/log"); 1169737080 M * cehteh unix-stream("/vservers/wormhole/dev/log"); 1169737085 M * bonbons daniel_hozac: for the init script SuSE certainly needs some love, they do spit out some warnings/errors 1169737085 M * cehteh for syslog-ng 1169737110 M * bonbons not seeing output is not really true, depends on wether on uses a tty for the guest or not 1169737158 M * bonbons with visible output I had trouble in the past, doing keyboard-stealing from X! 1169737273 Q * DavidS Quit: Leaving. 1169737673 Q * michal` Ping timeout: 480 seconds 1169738008 J * michal` ~michal@www.rsbac.org 1169738037 J * fish_ ~fish@60-242-81-84.tpgi.com.au 1169738049 Q * fish_ 1169739693 Q * TrueBrain Quit: Caught signal 15, Terminated 1169739720 J * TrueBrain truelight@openttd.org 1169740042 J * EvilDin ~Snake@BSN-77-83-28.dsl.siol.net 1169740134 M * EvilDin hi, i have one question, is there possible to do anyway that vservers would have limit of network traffic, i have VPS each have its own IP, would be possible to make limit of 100 GB per IP, and if that 100 GB traffic is reached that network for that VPs would stop 1169740216 M * daniel_hozac should be possible with iptables. 1169740233 M * EvilDin has anyone any idea? 1169740269 Q * bonbons Quit: Leaving 1169740377 M * daniel_hozac just have some script that queries your accounting rules and if the limit has been reached, add a DROP rule. 1169740452 M * id23 i use udev and i want to use my soundcard inside a vserver running X (KDE) ... it dont stop complaining that there is no /dev/dsp (which is right as it residents in /dev/.static/dev/dsp) 1169740456 M * EvilDin do you know any that kind of scripts, maybe link? 1169740514 M * daniel_hozac none that i can think of. once you've got the accounting, it really shouldn't be hard though. 1169740535 M * daniel_hozac id23: do you run udev inside the guest? 1169740614 J * shuri ~shuri@hq01.electronicbox.net 1169740615 M * id23 nope - i guess this is not possible - i tried a mound --bind on sys 1169740620 M * id23 mount 1169740636 Q * gab Remote host closed the connection 1169740652 M * daniel_hozac so you're bind mounting the host's /dev? or what? 1169740654 M * id23 the last time i tried this setup there was no udev - and it worked right after i copied the right /dev entry 1169740668 M * daniel_hozac copying the device node should do it, yes. 1169740673 M * id23 this i tried too - no success 1169740687 M * id23 strange 1169740756 M * EvilDin how can i make accounting ? 1169740759 M * id23 do you know why /dev/dsp (and the mixers) are not longer in /dev ? 1169740771 M * daniel_hozac they should be in /dev. 1169740798 M * id23 they now are in /dev/.static/dev 1169740801 M * daniel_hozac /dev/.static is where Debian keeps the static set of devices, i believe they are copied to the real /dev mount on boot. 1169740809 M * id23 i see 1169740814 M * id23 i will do a testrun 1169740846 M * daniel_hozac EvilDin: iptables -I INPUT -d ; iptables -I OUTPUT -s 1169740877 M * EvilDin then i should just use quota, maybe ? 1169740877 M * daniel_hozac then check the stats on those rules. 1169740911 M * EvilDin what about if i want that network will stop when some traffic will be reached 1169740957 M * id23 do a check on the accounting and then place a drop rule when traffic limit is reached 1169741049 M * EvilDin how could i make this 1169741109 M * id23 parse the output of iptables -nvL and then use the *right* entry to do your calculations - maybe in a cronjob or similar 1169741160 M * EvilDin aha so just cronjob which will be checking the iptables 1169741176 M * id23 this is one of many solutions 1169741184 M * EvilDin and read how much traffic there is, and if is reached limit block the IP 1169741192 M * id23 yes 1169741211 M * EvilDin how can i drop, block ip 1169741223 M * id23 man iptables ;) 1169741234 M * id23 it is just a simple drop rule 1169741254 M * EvilDin please :) 1169741292 M * id23 iptables -D INPUT -s xxx.xxx.xxx.xxx -j DROP 1169741298 M * id23 -A 1169741300 M * daniel_hozac S/D/A/ 1169741304 M * id23 ;) 1169741323 M * EvilDin a, what S/D/A/ ? 1169741348 M * id23 replace -D with -A 1169741367 M * EvilDin and S too? 1169741381 M * id23 lol - no 1169741409 M * id23 -s is the source - the IP you want to block 1169741423 M * id23 INPUT is the input chain 1169741430 M * daniel_hozac but for INPUT you actually want -d, the destination. 1169741433 M * id23 -j means jump - but please do a RTFM 1169741439 M * id23 yes 1169741479 M * EvilDin but still dont get what is the diffrence between -D and -A 1169741489 M * id23 -D deletes a rule 1169741492 M * id23 -A adds a rule 1169741495 M * id23 to iptables 1169741507 M * EvilDin aha so in this case i need -A :) 1169741508 M * id23 it is case sensitive ;) 1169741514 M * id23 yes 1169741532 M * EvilDin but when i will be pusting this back on 1169741555 M * EvilDin puting 1169741565 M * EvilDin what should i use 1169741603 M * id23 i dont understand .... release the block ? 1169741612 M * id23 just do a -D on the same rule 1169741627 M * EvilDin aha :) 1169741628 M * EvilDin tnx 1169741691 M * id23 you are welcome 1169741696 M * id23 cya laters 1169741742 N * DreamerC_ DreamerC 1169741885 J * stefani ~stefani@tsipoor.banerian.org 1169743146 Q * yarihm Remote host closed the connection 1169743454 Q * stefani Quit: I Quit! 1169744211 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1169744633 J * stefani ~stefani@flute.radonc.washington.edu 1169745017 Q * eyck_ Quit: leaving 1169745027 J * eyck_ eyck@kuszelas.com 1169745180 J * bonbons ~bonbons@83.222.37.103 1169745485 Q * id23 Ping timeout: 480 seconds 1169745564 Q * shedi Ping timeout: 480 seconds 1169746095 J * shedi ~siggi@ftth-237-144.hive.is 1169746101 J * id23 ~id@p5081295E.dip0.t-ipconnect.de 1169748050 N * Bertl_oO Bertl 1169748054 M * Bertl morning folks! 1169748059 M * daniel_hozac morning Bertl! 1169748064 M * Bertl how's going? 1169748095 M * daniel_hozac fine, thanks. you? 1169748103 M * Bertl yeah, better now :) 1169748115 M * daniel_hozac oh? 1169748163 M * Bertl well, combination of snow/network problems/work/cold ... 1169748184 M * Bertl but I'm fine and I I'm back online now :) 1169748193 M * daniel_hozac hehe, okay, sounds good. 1169748239 M * shuri morning Bertl 1169748305 M * Bertl daniel_hozac: so, what happened when I was 'away'? :) 1169748334 M * Bertl s/when/while/ 1169748381 M * Bertl hey shuri! 1169748408 M * shuri ltns 1169748434 M * Bertl indeed, but I guess you're still with Linux-VServer :) 1169748439 M * shuri yep 1169748469 M * daniel_hozac we found out SuSE is going to need some love before it works cleanly, PowerKe's ui files were most likely symlinks (one of the examples was, at least)... 1169748499 M * Bertl ah, ic. btw, regarding the vhashify 1169748532 M * Bertl (and utimes) wouldn't it make sense to at least provide an option to ignore time differences completely? 1169748567 M * Bertl (as far as I understood mtime/ctime? is compared too) 1169748573 M * daniel_hozac just mtime. 1169748615 M * daniel_hozac but yeah, i guess that would make sense. 1169748690 Q * FireEgl Quit: ... 1169748859 M * Bertl daniel_hozac: what's your status on the 2.6.16.xx backport/fixup? 1169748896 M * daniel_hozac i haven't gotten around to do any more to it. 1169748931 M * Bertl ah, np, will read up on the ML now ... 1169749031 Q * dlezcano Read error: Connection reset by peer 1169749353 M * daniel_hozac oh, and we got a supposed fix for the NFS problem. 1169749372 M * daniel_hozac (you were CCed to, right?) 1169749525 M * daniel_hozac +o 1169749615 M * Bertl ah? from mainline? 1169749655 M * daniel_hozac hallyn. 1169749703 M * daniel_hozac it does seem to fix the problem, but i have to agree with Oleg that i don't see how... 1169749706 M * Bertl ah, :) 1169749755 M * Bertl did somebody talk with serge? 1169749801 M * daniel_hozac about? 1169749914 M * Bertl about his fix :) 1169749941 M * daniel_hozac seems he just replied... 1169749943 M * daniel_hozac or i just got it. 1169750021 M * daniel_hozac heh, so it looks like the patch was wrong. 1169750027 M * Bertl lol 1169750382 J * dna ~naucki@254-197-dsl.kielnet.net 1169751848 M * Hollow Bertl: http://paste.linux-vserver.org/922 1169751863 M * Hollow i just came across that, not usre if vcd is causing the segfault or the kernel 1169752039 M * Bertl well, but is bug, so that is caused because the ekrnel encounters something which must not happen 1169752046 M * Bertl s/but/bug/ 1169752062 M * Hollow yeah.. but the segfault happens in vcd? 1169752066 M * Bertl question is, what kernel version is that? 1169752071 M * Hollow 2.2.0_rc8 1169752081 M * Bertl on something which looks like 2.6.19.2? 1169752089 M * Hollow yep 1169752114 M * Bertl because the kernel doesn't know about that :) 1169752128 M * Hollow genpatches do not include the fourth version id 1169752134 M * Bertl okay 1169752144 M * Bertl give me a minute to check then 1169752145 M * Hollow i don't know the reason, but well .. 1169752206 M * Bertl the kernel does a free_vx_info() with an vx_nsproxy still asigned 1169752233 M * Bertl at least it looks like this here, could you verify that the line 200 is this one: 1169752242 M * Bertl BUG_ON(vxi->vx_nsproxy); 1169752280 M * Hollow yup, the line matches 1169752287 M * Bertl as it happens on the create, I assume it is a kernel bug/problem with partially initialized contexts 1169752313 M * Bertl could you use the addr2line on the [] address for me, please? 1169752447 M * Hollow hm.. the vmlinux is not thre anymore (not one of my boxes), does it work if i recompile with same .config? 1169752468 Q * goblin Quit: . 1169752503 M * Hollow seems not .. 1169752504 M * Hollow ;) 1169752508 M * Bertl if you use the same toolchain yes 1169752518 M * Hollow well, i only get ??:0 1169752531 M * Bertl maybe a broken toolchain, try gdb 1169752542 M * Bertl l *0xffffffff8029360b 1169752555 M * Hollow ok 1169752657 J * _dmax ~semaj@bl4-63-120.dsl.telepac.pt 1169752765 M * Bertl hmm, I guess I already know what happens ... 1169752771 M * Bertl expect a fix shortly 1169752782 M * Bertl (and keep your test case :) 1169752801 M * Hollow ok.. gdb says no symbol table loaded .. 1169752898 Q * michal` Ping timeout: 480 seconds 1169752986 Q * dmax Ping timeout: 480 seconds 1169752992 N * _dmax dmax 1169753076 M * Bertl Hollow: can you trigger this one reliably? 1169753611 J * michal` ~michal@www.rsbac.org 1169753865 J * Aiken ~james@tooax8-224.dialup.optusnet.com.au 1169754142 M * Bertl daniel_hozac, Hollow: http://vserver.13thfloor.at/Experimental/delta-nsproxy-fix01.diff 1169754151 M * Bertl morning Aiken! wb michal`! 1169754217 M * Bertl daniel_hozac: I updated the bug analysis with the data from jarek: http://vserver.13thfloor.at/Stuff/BUGHUNT/jarek-0001/analysis.txt 1169754240 M * Bertl check out the funny part @ LC5 :) 1169754315 M * Bertl so I guess that can be considered fixed too :) 1169754372 M * daniel_hozac hmm, how did that happen?! 1169754383 M * Bertl missing colon 1169754401 M * daniel_hozac oh damn. 1169754438 M * Bertl s/colon/comma/ 1169754515 J * mcp ~hightower@wolk-project.de 1169754525 M * Bertl wb mcp! LTNS! 1169754609 M * mcp re 1169754939 M * Hollow Bertl: yep, it always happens during ctx_create -> helper fails -> BUG 1169754945 M * Hollow will try the patch shortly 1169755132 M * Bertl okay, tx 1169755459 M * Bertl btw, the path suggests, that you try to allocate one and the same context twice, so you still might to check vcd afterwards 1169755588 M * Bertl ah, yes, helper fail results in disposal too 1169755696 M * matti Morning Bertl. 1169755703 M * matti Hi mcp! 1169756076 M * Bertl hey matti! 1169756085 Q * Johnnie Remote host closed the connection 1169756260 M * daniel_hozac Bertl: could you explain the delta-nsproxy-fix01? i don't get how it fixes the problem. 1169756282 M * daniel_hozac (or what the problem is) 1169756420 M * daniel_hozac seems mostly like cleanup and avoiding the shutdown helper if create fails. 1169756562 J * yarihm_ ~yarihm@84-75-123-221.dclient.hispeed.ch 1169756568 Q * yarihm Read error: Connection reset by peer 1169756683 M * Bertl daniel_hozac: let's assume we create a new context 1169756729 M * Bertl we do, __create_vx_info() 1169756767 M * Bertl which executes __alloc_vx_info() 1169756866 M * daniel_hozac right... 1169756925 M * Bertl sec, checking something 1169756982 J * Piet hiddenserv@tor.noreply.org 1169757067 M * Bertl okay, Hollow is now doing some weird things in the helper, right? 1169757079 M * Bertl (Hollow: no offence meant :) 1169757098 M * Bertl which ends up assigning an ns_proxy to the context 1169757110 M * Bertl but at some point, the helper fails 1169757124 M * Bertl if (vs_state_change(new_vxi, VSC_STARTUP)) 1169757124 M * Bertl goto out_unhash; 1169757142 M * daniel_hozac ah, right! Hollow does the startup from the helper. 1169757152 M * Bertl so we unhash the context from within the vc_ctx_create() 1169757173 M * Bertl and of course, the vx_info isn't shut down properly at this point 1169757187 M * Bertl remember what I said last time we fixed something there? 1169757209 M * daniel_hozac hmm, not exactly? 1169757213 M * Bertl I said, we should change that so that the context is auto disposed to avoid such issues :) 1169757264 M * Bertl nevertheless, I won't change this now, just before a perfect release :) 1169757276 M * daniel_hozac hehe. 1169757299 N * yarihm_ yarihm 1169757311 M * matti The perfect release. 1169757312 M * Bertl I guess we should now have resolved all known issue with 2.2.0 (if Hollow and Jarek can confirm the fixes) 1169757312 M * matti :> 1169757355 M * daniel_hozac pending the mainline NFS issues, i'd have to agree. 1169757384 M * Bertl yeah, of course, but I assume, now that it was confirmed :) it will be fixed too ... 1169757494 M * daniel_hozac but i still don't see how delta-nsproxy-fix01 changes anything. 1169757507 Q * yarihm Quit: Leaving 1169757508 M * daniel_hozac and shouldn't we __unhash first? 1169757519 M * Bertl okay, we now ccontinue at: out_unhash, right? 1169757544 M * Bertl the new part is that we now call 1169757552 M * Bertl __shutdown_vx_info() 1169757578 M * Bertl which will get rid of the vx_nsproxy and vx_fs 1169757605 M * Bertl thus, the following __unhash_vx_info() and put_vx_info() 1169757631 M * Bertl which will end up in calling the free_vx_info() 1169757632 M * daniel_hozac oh, yeah, of course. 1169757644 M * Bertl will get rid of the context, without bailing out with: 1169757648 M * Bertl BUG_ON(vxi->vx_nsproxy); 1169757650 M * daniel_hozac i didn't realize the shutdown wasn't there before. 1169757669 M * Bertl I just had to rearrange the existing one a little bit 1169757682 M * Bertl so that the shutdown helper is not called 1169757720 M * daniel_hozac right. 1169757745 M * matti Folks. 1169757749 M * matti Good night :) 1169757753 M * daniel_hozac sorry, i kept reading it as a -shutdown_vx_info +__shutdown_vx_info hunk. 1169757758 M * daniel_hozac good night matti 1169757790 M * Bertl matti: have a good one! 1169757792 M * matti Bertl: Let me just make a report, that soon-to-be-stable version of VServer is working stable with 2.6.19.2. 1169757802 M * matti Bertl: Thanks very much. 1169757808 M * Bertl excellent, tx! 1169757821 M * matti :) 1169757930 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1169757985 J * bronson ~bronson@adsl-75-36-145-166.dsl.pltn13.sbcglobal.net 1169757987 M * bronson #chandler 1169757994 M * Bertl hmm :) 1169757996 M * matti LOL 1169757998 M * bronson doh, bootup issues. 1169758005 M * bronson howdy folks. :) 1169758014 M * matti Hi and bye :) 1169758635 M * Bertl bronson: so how is chandler? 1169758964 Q * shuri Quit: Quitte 1169759051 M * Hollow Bertl: awesome, works 1169759058 M * Bertl excellent! 1169759619 M * Hollow Bertl: seems like i found another one ;) 1169759635 M * Hollow http://paste.linux-vserver.org/923 1169759661 M * Hollow processes for xid=4 are still around, but /proc/virtual does not list xid=4 1169759698 M * Hollow it somehow happened during start of another guest... the first one worked quite fine 1169760216 M * Bertl could you upload the entire status of that process? 1169760313 M * Hollow Bertl: http://paste.linux-vserver.org/924 1169760446 M * FaUl halt 1169760456 M * FaUl oops 1169760464 M * FaUl kvm <-> monitor desync 1169760570 M * Bertl Hollow: okay, guess we need a debug run for that one 1169760597 M * Bertl i.e. with the switch info and claim/release turned on 1169760633 M * Hollow ok, guess i'll need to rebuild the kernel with debug options .. 1169760892 Q * bonbons Quit: Leaving 1169760920 J * CHTEKK ~chtekk@62.48.110.172 1169760929 M * CHTEKK hi all ;) 1169760935 M * Bertl welcome CHTEKK! :) 1169760954 M * Hollow Bertl: all these bugs were found on CHTEKKs box :P 1169760961 M * Bertl excellent :) 1169760997 M * Bertl Hollow: the following bits are interesting: 1169761007 M * Hollow Bertl: i'm also experiencing some shutdown/kill problems, but i'll have to investigate that first, may be a vcd problem 1169761084 M * CHTEKK hi Bertl, hi Hollow :) jup, my boxes have magical attraction to weird bugs and segfaults, Hollow can attest to that :P 1169761094 M * Hollow indeed 1169761096 M * Bertl Hollow: xid: 2,3,4,5,6 switch: 0,1,4 misc: 4,5 1169761112 M * Bertl CHTEKK: it's always good to have such boxes :) 1169761164 M * Hollow is there some neat syntax in bash to do (1 << n)? 1169761198 M * Bertl echo $[ 2**3 ] 1169761201 M * CHTEKK Bertl, I agree they're good to find bugs, it just sucks when in 14 hours I have to give a presentation about some linux-vserver stuff based on that box... :P It looks like I'll just have to... skid around some issues, like never show the people attending the stop button :) 1169761203 M * Hollow ah :) 1169761239 M * Bertl CHTEKK: nah, 14 hours should be more than enough to fix all of them 1169761269 M * Bertl CHTEKK: at least the ones related to the Kernel should be fixed by then ... 1169761277 M * CHTEKK probably, but otoh I don't want to keep you and Hollow up all night or something like that, so if needed I can still give the presentaiton even with stop and so on not really working 1169761310 M * Bertl can't tell for Hollow, but I'll be up for a while now ... 1169761407 M * CHTEKK k :) 1169761484 Q * mire Ping timeout: 480 seconds 1169761541 M * Hollow yeah, plenty of time here too 1169761655 J * Piet_ hiddenserv@tor.noreply.org 1169761769 J * Johnnie ~jdlewis@jdlewis.org 1169761781 M * Bertl wb Johnnie! Piet_! 1169761841 M * Johnnie Thanks. :) 1169761850 M * Hollow uhm.. the log with debug switches is 4.3M 1169761864 M * Bertl bzip2? 1169761907 M * Hollow CHTEKK: can you upload it to d.g.o? in /var/log/kern.log 1169761915 M * Hollow don't have my keys on your box 1169761950 M * CHTEKK neither do I, but I can make that box accessible via HTTP, just put the thing into /var/www/localhost/htdocs/ 1169761955 M * Hollow k 1169761967 Q * mugwump Remote host closed the connection 1169761974 J * mugwump ~samv@watts.utsl.gen.nz 1169762019 M * CHTEKK Bertl, ok try http://longitekk.homelinux.net:88/ 1169762070 Q * Piet Ping timeout: 480 seconds 1169762102 M * Bertl CHTEKK: yup, seems to work 1169762131 M * Bertl but access to the file is forbidden :) 1169762158 J * mire ~mire@170-167-222-85.adsl.verat.net 1169762159 M * CHTEKK Hollow, fix perms? 1169762213 M * Hollow done 1169762287 M * Bertl hmm, I smell an excessive newline in one of the debug entries :) 1169762337 Q * Hollow Remote host closed the connection 1169762343 J * Hollow ~hollow@styx.xnull.de 1169762472 M * Bertl Hollow: okay, and this is all from that single command? 1169762632 M * Hollow yep, this happens on startup... the context is up, init is started, including some daemons, but at the same time the context somehow disappears, processes still exist 1169762638 M * mugwump WARNING: This machine has real i386 class processor. 1169762643 M * mugwump Debian etch and later does not support such old hardware any longer. 1169762649 M * mugwump longdrop:~# uname -m 1169762649 M * mugwump i386 1169762667 M * Bertl not that unusual 1169762682 M * mugwump :) 1169762686 M * mugwump just a surprise to me 1169762697 M * Bertl Hollow: okay, but according to the locks, the context is still there, and has 4 claims, and 13 references 1169762709 M * Bertl s/locks/logs/ 1169762728 M * Hollow uhm.. you're right .. 1169762735 M * Hollow after the reboot the context bootet fine 1169762736 M * Hollow o.o 1169762748 Q * dna Quit: Verlassend 1169762772 M * CHTEKK yup Hollow I noticed that too, after a full reboot of the host it sometimes starts up fine when you start it up right away, is that what you just saw? 1169762777 M * CHTEKK happened 1-2 times to me 1169762791 M * Hollow seems so 1169762800 M * Bertl okay, please try to 'recreate' the issue with the logging enabled then 1169762808 M * CHTEKK but most of the times it starts,a nd then suicidies, while remaining active, and all goes down the hill from there :) so I assume that's an issue anyway 1169762827 M * Hollow ok, rebooting .. 1169762962 M * Bertl CHTEKK: suicidal contexts are always suspicious :) 1169763005 M * CHTEKK jup especially when they're still around after telling everyone they just killed themselves 1169763008 M * Hollow still works .. 1169763031 M * CHTEKK strange... Hollow did you try to start vs2 first and then amd64ball? 1169763039 M * Hollow yep 1169763190 M * Hollow maybe it was caused by the segfault in vcd.. i did not reboot after fixing that .. 1169763207 M * Bertl could be, same context id? 1169763238 M * Hollow yeah .. 1169763241 M * Hollow still works .. 1169763267 M * Bertl okay, then let's move to the next issue :) 1169763289 M * Hollow ok.. ;) 1169763304 M * Hollow netstat: no support for `AF INET (tcp)' on this system. 1169763312 M * Hollow netstat -nl --inet 1169763318 M * Hollow inside 1169763325 M * Hollow outside works 1169763365 M * Hollow maybe a proc issue? 1169763377 M * Bertl could be, strace -fF? 1169763400 M * daniel_hozac 2.2.0-rc8 still? 1169763413 M * Hollow ah yeah .. /proc/net/tcp = ENOENT 1169763422 M * Hollow will have to check the vprocunhide script 1169763422 M * daniel_hozac vprocunhide? 1169763460 M * Bertl I vaguely remember some report that vprocunhide was not executed on gentoo at some point? 1169763478 M * Hollow nah, this is all with vcd & friends.. 1169763507 M * Bertl okay, then it's YOUR fault :) 1169763522 M * daniel_hozac well, would've been his fault if it was a Gentoo problem too, no? :) 1169763536 M * Bertl *shht* 1169763613 M * sid3windr :> 1169763702 M * Hollow ok, it's a vprocunhide issue .. 1169763738 Q * stefani Quit: I Quit! 1169764043 M * CHTEKK Hollow, uhhmmm according to my interface currently vs2 and amd64ball are running both on the same I? 1169764046 M * CHTEKK *IP 1169764056 M * CHTEKK that somehow doesn't seem right ;) 1169764096 M * Hollow doesn't matter.. just for testing 1169764141 M * Hollow CHTEKK: i figured the ssh problem... chroot("/var/empty") = EPERM 1169764398 M * Hollow seems like too many bcaps get stripped 1169764497 M * Bertl ssh as root or user? 1169764511 M * Hollow root 1169764519 M * daniel_hozac no CAP_SYS_CHROOT? 1169764527 M * Hollow yeah, i added it, but still doesn't work 1169764564 M * Bertl check the guest filesystem and 'normal' permissions as well as the barrier flags 1169764581 M * Bertl (all way up to guest /) 1169764603 M * Hollow ah.. the result is the same, but the cause has changed now ;) 1169764608 M * Hollow the chroot worked 1169764639 M * CHTEKK Hollow, so basically sshd with chroot USE was part of the problem? 1169764671 M * Hollow CHTEKK: no, vcd has disabled too many bcaps on startup... 1169764683 M * Hollow i added SYS_CHROOT and SETGID and everything works now 1169764700 M * CHTEKK well yeah, that was why chroot call died, but sshd wouldn't probably have done that with -chroot USE 1169764708 M * daniel_hozac might want to use the util-vserver defaults? 1169764724 M * CHTEKK so yeah it was a bug in vcd emphasized by how I setup sshd, if I understand it all correctly 1169764732 M * Hollow daniel_hozac: i actually copied them from util-vserver... it's some other weird bug i guess 1169764787 M * Hollow same for vprocunhide, but the issue here is that the ix command does not work recusively... will have to update vprocunhide to use setattr 1169764801 M * Hollow many little bugs here and there ;) 1169764830 M * daniel_hozac hehe. 1169764850 M * CHTEKK :) did this actually also reliably fix the startup of amd64ball and hutdown maybe? or just the network problem? 1169764873 M * Hollow well, the startup seems to work fine now 1169764886 M * Hollow i suspect the segfault here that still was around .. 1169764899 M * Hollow the one that trigered the nsproxy BUG 1169764919 M * daniel_hozac hmm, that sounds strange. 1169764932 M * daniel_hozac or is vcd also the helper? 1169764966 M * Hollow kind of .. kernel calls helper, helper calls vcd, so the kernel recognized vcd segfaulting .. 1169764971 M * CHTEKK ok so startup seems so be ok on both baselayouts now, good... kernel bug was fixed... network seems to work too now, was a vprocunhide + bcaps issue... 1169764981 M * CHTEKK so only shtudown/reboot remain to be debugged/tested 1169764994 M * Bertl okay, let's test then :) 1169765008 M * daniel_hozac i think x86_64 is more verbose about segfaults, i believe it outputs something every time. 1169765038 M * Hollow Bertl: it looks like VXF_REBOOT_KILL does not kill on reboot/halt, but i'm not sure yet what's going on exactly 1169765072 M * Bertl okay, I'll prepare a number of debug bits for that, yes? 1169765086 M * Hollow yeah, that would be fine 1169765101 M * daniel_hozac REBOOT_KILL only strikes if the helper succeeds, does it? 1169765115 M * Bertl yes, I think so 1169765183 M * Bertl xid: 3,5 switch: 0,1,4 misc: 4,5 1169765250 M * Bertl daniel_hozac: so as far as I understood the replies on the ML, we have test teams for xfs dlimits and 2.6.16.xx kernels, right? 1169765287 M * daniel_hozac Bertl: AFAICT, yeah. 1169765305 M * CHTEKK just curious: what's so important about a backport to 2.6.16 to have people who'd actually spend time on that? 1169765315 M * Bertl daniel_hozac: okay, I take it that you might spend more time on the 2.6.16 kernel, yes? 1169765347 M * daniel_hozac sure, i'll try roll it forward to 2.0.3-rc1 and look at the 2.2 changes as well. 1169765361 M * Bertl CHTEKK: well, it seems that there are older kernels around (as distro kernels?) which work quite nicely with Xen (which is always behind) 1169765363 M * daniel_hozac (and update the 2.0 changelog while i'm at it) 1169765382 M * Bertl daniel_hozac: okay, excellent, so I'll focus on the xfs part then 1169765418 M * harry heya all! 1169765425 M * CHTEKK Bertl, ah k I see :) don't use Xen myself and our vserver-sources in gentoo never lack behind that much :) but I can see why people might want that 1169765452 M * daniel_hozac Xen actually is pretty updated. 1169765458 M * daniel_hozac just not the stable tree, IIUC. 1169765516 M * Bertl that's what I meant 1169765773 M * Hollow hmm... the helper isn't even called on shutdown .. 1169765784 M * Hollow but SC_HELPER is enabled 1169765818 M * Bertl sure the context is not persistant? 1169765847 M * Hollow no, persistent is off 1169765877 M * Bertl okay, let's get the debug trace then 1169765979 M * Bertl ah, SYS_REBOOT is there? 1169765992 M * Hollow d'oh. 1169766029 M * Bertl CAP_SYS_BOOT I mean 1169766031 M * daniel_hozac what bcaps _do_ you have? :) 1169766057 M * Bertl CAP_SETPCAP :) 1169766077 M * daniel_hozac isn't that impossible to get? :) 1169766204 M * Bertl that can't stop Hollow, can it? 1169766213 M * daniel_hozac haha 1169766240 M * Hollow indeed 1169766241 M * Hollow :) 1169766410 Q * yarihm Quit: Leaving 1169766749 M * Hollow yay! i have the debug output for lost context now 1169766765 M * daniel_hozac yay! 1169766767 M * Bertl hmm, sounds like a movie :) 1169766784 M * CHTEKK yay! 1169766786 M * Bertl 'debug output from the lost context, part I' 1169766791 M * Hollow hehehe 1169766797 M * daniel_hozac lol 1169766806 M * CHTEKK only "Lost Context" could be the name of some sci-fi series episode :P 1169766838 M * Hollow Bertl: ok, same location as before 1169766950 M * Bertl okay, what are we looking at here, and what was the problem again? 1169767012 M * Hollow startup seems to work, init starts, services too (syslog, sshd, etc), but context then disappears, though processes still exist 1169767030 M * Bertl ah, so the 'original' issue 1169767033 M * Hollow yep 1169767040 M * Bertl with the original debug flags? 1169767043 M * Bertl probably not 1169767047 M * Hollow 255 actually 1169767056 M * Hollow i was too lazy to calculate them again :) 1169767119 M * Bertl well, makes it somewhat unreadable :) 1169767170 M * Bertl but the context is still here 1169767183 M * Hollow at least not in /proc/virtual/ 1169767214 M * Bertl yeah, it seems it was unhashed at some point 1169767345 M * Bertl okay, can you reproduce that now? 1169767353 M * Hollow will try 1169767421 M * Hollow should i change the debug bits? 1169767488 M * Bertl not yet, just try to reliably trigger that 1169767519 M * Bertl it looks very suspicious that the context hits __release with a very high ref/claim count 1169767521 M * Hollow ok, triggered again .. 1169767528 Q * Hunger cation.oftc.net unununium.oftc.net 1169767536 M * Hollow with a completely new guest/xid 1169767618 J * Hunger Hunger.hu@213.163.11.138 1169767632 M * Bertl also, is your logger working fine? 1169767648 M * Hollow yep.. printks are logged 1169767652 M * Bertl Jan 26 00:12:01 MiddleEarth [ 3674.761343] vxD: /usr/sbin/vshelper: (shutdown 4) returned sync with 0 1169767655 M * Bertl Jan 26 00:12:01 MiddleEarth [ 3674.761345] vxD: __unhash_vx_info: ffff8101338b5000[#4] 1169767662 M * Bertl Jan 26 00:12:01 MiddleEarth [ 3674.761343] vxD: /usr/sbin/vshelper: (shutdown 4) returned sync with 0 1169767665 M * Bertl Jan 26 00:12:01 MiddleEarth [ 3674.761345] vxD: __unhash_vx_info: ffff8101338b5000[#4] 1169767675 M * Bertl doesn't that look somewhat strange to you? 1169767699 M * Bertl i.e. it seems to repeat certain sequences over and over 1169767715 M * Bertl it's not a real issue, as I can unify them 1169767828 M * Hollow yeah, looks strange 1169768115 M * Hollow Bertl: i have a clean log with just the bits enabled you told me.. same location .. 1169768121 M * Bertl okay, tx 1169768188 Q * Hunger cation.oftc.net unununium.oftc.net 1169768199 M * Hollow ATM every 2-4 seconds the vx_child_reaper line appears .. 1169768216 M * Bertl yeah, I guess we should remove that bit for now 1169768261 M * Hollow bit number? 1169768284 M * Bertl needs a kernel mod, so let's ignore it for now 1169768285 J * Hunger Hunger.hu@213.163.11.138 1169768288 M * Hollow ok 1169768303 N * Piet_ Piet 1169768312 M * Bertl no idea why I did put it on the bit it currently uses 1169768646 Q * Hunger cation.oftc.net unununium.oftc.net 1169768742 J * Hunger Hunger.hu@213.163.11.138 1169768838 M * Hollow Bertl: quite tried already .. anything useful you still need? 1169768994 M * Bertl I think we are hitting the same issue as before 1169769005 M * Bertl just in a slightly more complicated setup 1169769035 M * Bertl I guess we have to change the create in such a way that it can do a proper cleanup 1169769065 M * Bertl I'll do a few changes to the debug logging we have now, so that we can confirm this 1169769088 M * Hollow ok, will go to bed now.. you could have access to that box if it helps 1169769186 M * Bertl hmm, okay, what about CHTEKK? 1169769238 M * Hollow *shrug* probably left to bed already 1169769251 M * Bertl okay, np, so we will continue tomorrow then 1169769272 M * CHTEKK still here 1169769276 M * Hollow ah :) 1169769283 M * CHTEKK and you can have access to the box, that's not a problem 1169769289 M * Bertl CHTEKK: can you continue to do some testing for me? 1169769332 M * CHTEKK uhmmm I actually tought to go soon to bed and my competence in debugging and those things are faaar less than Hollows... maybe it would be more productive to just give you access too? 1169769363 M * Bertl well, np here, as I said, we delay this till tomorrow 1169769367 M * Hollow well, we can also do it tomorrow.. 1169769371 M * Hollow heh :) 1169769378 M * Hollow CHTEKK: the things you need should work, no? 1169769383 M * CHTEKK ok 1169769385 M * Hollow except stop 1169769393 M * Hollow but vx -kill does the job 1169769397 M * CHTEKK Hollow, yeah create/start is enough 1169769410 M * Hollow ok, fine, hope it will all work well, good luck :) 1169769413 M * CHTEKK yup, did you alraedy fix vprocunhide and friends to actually make network work? 1169769421 M * Hollow ah, good point .. 1169769427 M * Hollow will add a quick fix for it 1169769437 M * CHTEKK well nah np, I'll just show vcc login 1169769444 M * CHTEKK and show that sshd is listening with netstat 1169769472 M * CHTEKK do what you have to do correctly tomorrow when you're fully rested, there's no hurry now, thanks a lot to both you and Bertl for the help so far! 1169769487 M * Hollow CHTEKK: find /proc/net -exec ix -attr-set {}=~HIDE \; 1169769490 M * Hollow should do it 1169769523 M * Hollow as a workaround ;) 1169769531 M * Hollow will fix it tomorrow then 1169769543 M * CHTEKK k I'll remember that, thanks :) cya all tomorrow then! and thanks again, gn8! 1169769548 M * Hollow night 1169769559 M * Bertl have a good one folks!