1101255767 Q * flock Ping timeout: 480 seconds
1101256033 Q * UnionPivo Ping timeout: 480 seconds
1101256134 J * _maharaja maharaja@ipax.at
1101256134 Q * maharaja Read error: Connection reset by peer
1101257829 Q * ndim Ping timeout: 480 seconds
1101258094 J * ndim U2FsdGVkX1@helena.bawue.de
1101259932 J * mac mac010@ip68-7-42-69.sd.sd.cox.net
1101259960 P * mac 
1101271337 J * flock restless@l192-117-111-12.broadband.actcom.net.il
1101271717 J * _no_x vps@c207199.adsl.hansenet.de
1101271812 Q * no_x Ping timeout: 480 seconds
1101271816 N * _no_x no_x
1101274080 Q * dsanta Ping timeout: 480 seconds
1101274263 J * dsanta santa@c68.190.156.105.roc.mn.charter.com
1101286584 M * _maharaja morgen
1101287666 N * Doener|gone Doener
1101287767 M * Doener morning
1101287885 J * rs rs@ice.aspic.com
1101287909 M * rs hey dudes
1101287916 M * Doener hi rs!
1101288496 M * _maharaja doener: that brk thing happens with a vanilla kernel too
1101288504 M * _maharaja the strange thing is:
1101288531 M * _maharaja /dev/md0 is my root device, dpkg -l dakes 22secs because each brk(0) takes 0.x seconds instead of 0.00x
1101288543 M * _maharaja when i chroot /mnt/hda2 (rescue system), everything works as expected
1101288571 M * _maharaja when i boot into the rescue system, so /dev/hda2 becomes my root device, it again takes 22 secs
1101288583 M * _maharaja chroot into /mnt/md0 -> everything works as expected
1101288604 M * _maharaja this happens with vmlinuz-2.6.9-p4, vmlinuz-2.6.9-rc4-vs1.9.3-rc3-p4, vmlinuz-2.6.9-vs1.9.3-p4
1101288611 M * _maharaja this does not happen with vmlinuz-2.4.23-1-386
1101290980 M * Doener _maharaja: strace available?
1101291173 M * _maharaja yes
1101291178 M * _maharaja ill  put it online
1101291272 M * _maharaja http://dev.ipax.tk/~raoul/dpkg/
1101291400 M * _maharaja doener: tell me what you think
1101291438 M * Doener atm i think "wow, everything is a lot slower when you're not chrooted"
1101291442 M * Doener ;)
1101291484 M * Doener even write takes 6-7 times longer
1101291557 M * _maharaja it happens with all 2.6.9 kernels
1101291561 M * _maharaja no matter if vanilla or vserver
1101291566 M * _maharaja 2.4.23 runs fine
1101291577 M * _maharaja (debian)
1101291640 M * Doener funny idea: try: chroot / dpkg -l
1101291677 M * _maharaja k
1101291714 M * _maharaja slow
1101291715 J * BWare bware@212.26.216.34
1101291752 M * Doener ok, now: mount --rbind / /mnt/something ; chroot /mnt/something dpkg -l
1101291937 M * _maharaja no improvment
1101291977 M * Doener ok, remove the mount we just did ( umount -l /mnt/something ) and do:
1101291992 M * Doener mount / /mnt/something ; chroot /mnt/something dpkg -l
1101292059 M * _maharaja mount / /mnt/root/
1101292059 M * _maharaja mount: / is not a block device
1101292082 M * _maharaja ill do a mount /dev/md0 /mnt/root
1101292086 M * _maharaja still slow
1101292113 M * Doener ah, i forgot "--bind", anyways /dev/md0 is fine...
1101292130 M * _maharaja k
1101292164 M * _maharaja mount --bind / /mnt/root/
1101292166 M * _maharaja chroot /mnt/root/
1101292169 M * _maharaja still no improvmenet :)
1101292171 M * Doener but with /dev/hda2 it is ok, right?
1101292177 M * _maharaja yes
1101292179 M * _maharaja ill retest
1101292194 M * _maharaja real    0m0.977s
1101292203 M * _maharaja kernel 2.6.9-p4
1101292211 M * Doener can you upload your kernel config as well?
1101292214 M * _maharaja sure
1101292227 A * Doener is kind of clueless ...
1101292238 M * _maharaja done
1101292251 M * _maharaja me too
1101292258 M * _maharaja meanwhile, i build a 2.6.8 with the same config
1101292289 M * _maharaja i do not know what chroot does in depth
1101292371 N * _maharaja maharaja
1101292400 M * Doener not much... 
1101292416 M * maharaja is there a kernel hacker irc chan here?
1101292423 M * maharaja or where should i report
1101292429 M * maharaja i dont think that is a dpkg problem
1101292430 M * Doener maybe in #kernelnewbies
1101292441 M * maharaja is there a better network than this one?
1101292443 M * maharaja ircnet/..
1101292465 M * Doener you said 'here', so oftc ;)
1101292476 M * maharaja i know :)
1101292480 M * maharaja but im on other networks too
1101292488 M * maharaja ircnet/efnet/linknet/quakenet/private ones
1101292493 M * maharaja call me irc junkie ;)
1101292500 M * Doener hehe
1101292523 M * Doener i guess #kernelnewbies on oftc is fine... viro, wli and others also hang around sometimes
1101292531 M * maharaja k
1101292600 M * maharaja maybe bertl knows more as he has been into the kernel for a longer time
1101295600 J * KimHansen kim@palrel1.hp.com
1101295877 Q * KimHansen Quit: 
1101296386 Q * eyck Read error: Connection reset by peer
1101296390 J * eyck eyck@81.219.64.71
1101296879 M * infowolfe sladen: ping?
1101296977 M * infowolfe sladen: if you could point me in the right direction, i was looking for your per-ip traffic accounting howto... should be at least a year old at this point...
1101297540 N * Bertl_zZ Bertl
1101297552 M * Bertl morning folks!
1101297575 M * infowolfe good morning Bertl 
1101297580 M * infowolfe Bertl: do you normally work from home?
1101297601 M * Bertl well, depends, but often yes, why?
1101297604 M * infowolfe (because you just beat morning CET by one minute :-p)
1101297621 M * infowolfe you don't keep normal "office" hours... that's all
1101297627 M * Bertl exactly!
1101297694 M * infowolfe Bertl: do you remember paul sladen's howto on ip-accounting?
1101297722 M * infowolfe nevermind :-p i just found it
1101297739 M * Bertl excellent, make a link on the wiki then ;)
1101297746 M * infowolfe will do
1101297892 M * Bertl okay, off for dinner, back in an hour ...
1101297902 N * Bertl Bertl_oO
1101297927 M * maharaja damn
1101297928 M * maharaja missed him
1101298244 M * infowolfe maharaja: anything i can help with?
1101298480 M * maharaja no, i wanted to ask bertl what he thinks about my performance problem with 2.6.9
1101298485 M * maharaja i discussed it with doener bevore
1101298491 M * maharaja if you followed
1101298904 Q * sannes Read error: Connection reset by peer
1101298919 J * sannes ace@home.skarby.no
1101298996 M * infowolfe maharaja: what kind of performance problem are you having?
1101299285 M * infowolfe maharaja: i don't think i did
1101299469 Q * infowolfe Read error: Connection reset by peer
1101299473 J * infowolfe infowolfe@infowolfe.vps.xhcl.net
1101299499 M * infowolfe argh
1101299501 M * infowolfe i hate oftc
1101299511 M * infowolfe this whole rebooting thing really pisses me off
1101299519 M * infowolfe or rather, reconnecting due to ping timeout
1101299535 M * infowolfe maharaja: do you like my reverse-dns?
1101299580 M * infowolfe :infowolfe (~infowolfe@infowolfe.vps.xhcl.net) []
1101299585 A * infowolfe grins
1101299592 M * infowolfe i *really* love djbdns
1101299606 M * infowolfe and qmail ain't so bad either
1101299611 M * TheSeer hehe
1101299625 M * TheSeer .oO( lazyinstaller.net )
1101299628 M * infowolfe TheSeer: i've got like 8 djbdns processes on my new box... and they're SUPER fast
1101299638 M * infowolfe dnscache <3
1101299645 M * TheSeer is use bind for dns.. but qmail for mail
1101299666 M * infowolfe TheSeer: why do you use bind?
1101299677 M * TheSeer basically because of rndc ;>
1101299680 N * Bertl_oO Bertl
1101299689 M * TheSeer and because out of lazyness..
1101299696 M * infowolfe TheSeer: you don't have to use rndc with djbdns... issue a make.
1101299703 M * infowolfe see http://www.djbdnsrocks.org for more info
1101299720 M * TheSeer infowolfe: the important part in rndc is the "r" ;)
1101299724 M * infowolfe i have web-based admin that's secure that does my configuratin fo rme...
1101299734 M * infowolfe TheSeer: i have rsync and make.
1101299735 M * Bertl hrm ... who said that? 'djbdnsrocks' ;)
1101299752 A * infowolfe beams... and is madly in love with djbdns
1101299775 M * infowolfe my dns changes take effect in less than 5 minutes... as per my cronjob... lol
1101299786 M * infowolfe on my primary and secondary nameservers.
1101299794 M * infowolfe and i don't have to edit serial #'s :-p
1101299803 M * TheSeer hehe
1101299812 M * TheSeer i have ascript for that.. so i don't either
1101299845 M * Bertl hmm, secondary ns loads the stuff from the primary (transfer)
1101299862 M * Bertl and incrementing the primary serial is not really hard?!
1101299867 M * infowolfe TheSeer: here's a page for you: http://cr.yp.to/djbdns/run-server-bind.html
1101299883 M * infowolfe i'm migrating a user from bind to djbdns...
1101299889 M * infowolfe and vegadns for web-based admin...
1101299900 M * Bertl yeah, but why? because of the djb incompatibilities?
1101299918 M * infowolfe Bertl: what djb incompatibilities?
1101299938 M * Bertl well, you know that djb's universe clashes with reality ...
1101299944 M * TheSeer hehe
1101299990 M * infowolfe lol, yes, i do know that, i've read probably a good 70% of his bitching...
1101300021 M * infowolfe BUT... there isn't much out there that is as secure AND fast as djbdns
1101300026 M * TheSeer as a matter of fact i tend to disagree to quite a few things ;>
1101300028 M * infowolfe not to mention simple
1101300030 M * TheSeer but still qmail rocks *g*
1101300053 M * TheSeer installing djb software is a pita
1101300068 M * Bertl well, the freedom of choice, as long as you know _what_ you choose ... go ahead!
1101300069 M * TheSeer don't tell me installing djbdns is simple
1101300072 M * infowolfe who doesn't disagree with djb... the guy really seems like he's got the maturity of a 4 year old that doesn't want to play nice with the rest of the 'net world
1101300092 M * TheSeer *g*
1101300118 M * infowolfe TheSeer: emerge djbdns && tinydns-conf tinydns dnslog /etc/dns/primary 213.131.245.100 && ln -s /etc/dns/primary /service/primary
1101300122 M * infowolfe done.
1101300139 M * infowolfe lol...
1101300175 M * infowolfe TheSeer: i've found things MUCH more complicated than installing djbdns
1101300190 M * TheSeer Bertl: erm..
1101300194 M * TheSeer * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build
1101300194 M * TheSeer   method knows how to deal with this, but on existing installations,
1101300194 M * TheSeer   appending 'true' to this file will he
1101300195 M * maharaja bertl: you know any reason why syscalls in a non chrooted environment can take 20x longer than in a chrooted env?
1101300195 M * TheSeer wtf..?
1101300197 M * infowolfe TheSeer: have you ever installed jabberd and some transports?
1101300226 M * maharaja kernel: 2.6.9
1101300236 M * maharaja with the stock debian 2.4.23, everything works fine
1101300257 M * Bertl maharaja: no idea ... let's hear the dirty details
1101300277 M * maharaja i made some straces which you can find on http://dev.ipax.tk/~raoul/dpkg/
1101300286 M * maharaja i first noticed a major slowdown while using dpkg
1101300289 M * maharaja to sum it up:
1101300303 M * TheSeer /usr/sbin/vserver: line 131:  6249 Segmentation fault  
1101300308 M * TheSeer Bertl: ..???
1101300324 M * maharaja bertl: rootdev=/dev/md0, dpkg -l takes 22secs, chroot /mnt/hda2 dpkg -l takes <1sec.
1101300338 M * Bertl TheSeer: don't point at me, it's userspace, isn't it?
1101300341 M * maharaja bertl: rootdev=/dev/hda2, dpkg -l takes 22secs, chroot /mnt/md0 dpkg -l takes < 1secs.
1101300347 M * TheSeer Bertl: grmpf ;)
1101300360 M * maharaja bertl: the setup is more or less the same (used dump/restore to copy hda2 to md0)
1101300378 M * Bertl maybe md0 is faster?
1101300392 M * maharaja read carefully, chroot is faster :)
1101300409 M * maharaja but only while using a different partition
1101300440 M * maharaja i tried to find the cause with doener and chrooted /, mounted the rootdev somewhere else and chrooted, tried to symlink / and chroot.
1101300456 M * maharaja or maybe the correct phrase should be the system hd is slower
1101300462 Q * flock Ping timeout: 480 seconds
1101300467 M * maharaja no matter which one you use
1101300471 M * maharaja as said, 2.4.23 works fine
1101300500 M * Bertl I have no idea what dpkg really does, so let's take something known, like tar
1101300544 M * Bertl do a ' sync; time bash -c "tar xf linux-2.6.9.tar; sync"'
1101300559 M * Bertl once outside and once inside a chroot
1101300581 M * Bertl make sure to do it at least twice, and rm -rf the dir before that
1101300610 M * maharaja take a look at http://dev.ipax.tk/~raoul/dpkg/
1101300614 M * maharaja i tried a ps aux
1101300625 M * maharaja the syscalls are way too slow
1101300712 M * maharaja ok, disabled a lot of stuff. still the same behavior: you want me to trie that tar stuff though?
1101300719 M * maharaja cause i think the bahavoir will be the same
1101300726 M * Bertl would be interesting ...
1101300746 M * Bertl what machine and what kernel config?
1101300771 M * maharaja but i will choose a smaller volume... using the big one takes too long ;)
1101300876 M * maharaja http://dev.ipax.tk/~raoul/kernel/
1101300879 M * maharaja i put everything there
1101300884 M * maharaja (renamed the dpkg dir)
1101301327 M * maharaja ok, running without chroot
1101301894 N * Val_away Val
1101301903 M * Val hi
1101301939 M * Bertl greetings Val!
1101301946 M * Val hi Bertl :)
1101301979 M * Val last patch you made for 2.4.27-vs1.29 debian (with q0.14) works fine
1101301989 M * Bertl excellent!
1101301992 M * Val ...i just have to test quotas stuff
1101302000 M * Bertl ah ;)
1101302024 M * Val in fact, i just tested all basic vserver's functions
1101302030 M * Val for stable branch
1101302043 M * Val i'm now reading docs about quota stuff
1101302056 M * Val before breaking all :)
1101302244 J * xmms xmms@211.162.76.241
1101302260 M * Bertl xmms: next title
1101302406 M * xmms Bertl?
1101302410 M * maharaja bertl: in the chroot, i get a lot of "Cannot mkdir: No such file or directory
1101302418 M * maharaja ah, ok,
1101302420 M * maharaja out of diskspce
1101302433 M * Bertl hey my music player speaks!
1101302437 M * Bertl welcome xmms!
1101302463 M * Bertl maharaja: how could that happen on the same device?
1101302499 M * maharaja its another device
1101302506 M * Bertl please use the same device
1101302517 M * maharaja on the same device, things are slow
1101302531 M * Bertl that's fine, but they are comareable
1101302536 M * Bertl compareable even
1101302542 M * maharaja well, they give the same result
1101302542 Q * albeiro Read error: Connection reset by peer
1101302543 J * albeiro albeiro@linux.gentoo.pl
1101302546 J * flock restless@l192-117-111-12.broadband.actcom.net.il
1101302548 M * maharaja slow ass crawling syscalls
1101302561 M * maharaja i don't know what you want from this test
1101302564 M * Bertl maharaja: so what you are testing is that you have two devices, one is slow and one fast?!
1101302579 M * maharaja noe
1101302580 M * Bertl that is a great test, but how is it related to chroot?
1101302596 M * maharaja i rephrased myself some time ago
1101302601 M * maharaja the root volume is slow
1101302610 M * maharaja does not matter if i use root=/dev/md0 or root=/dev/hda2
1101302628 M * maharaja with root=/dev/md0 and chroot /mnt/hda2, everything works fine in the chroot
1101302634 M * maharaja and vice versa
1101302640 M * xmms Bertl :)
1101302652 M * maharaja i tested with doener and others different settings
1101302664 M * Bertl so what do you want to tell me then?
1101302667 M * maharaja mount --bind / /mnt/root/; chroot /mnt/root dpkg -l
1101302673 M * maharaja mount --rbind / /mnt/something ; chroot /mnt/something dpkg -l
1101302684 M * maharaja chroot / dpkg -l
1101302699 M * maharaja ln -s / ./testroot; chroot /tmp/testroot
1101302728 M * maharaja i would like to know your opinion why syscalls on the rootdev do take that long
1101302735 M * maharaja no matter which rootdev i use
1101302744 M * maharaja and on the second device i chroot to, everything works as expected
1101302770 M * maharaja btw, tar works fine in both szenarios
1101302779 M * Bertl well, either I still do not understand your question/issue
1101302789 M * Bertl or you are asking why one of your devices is slow?!
1101302831 M * maharaja im asking why the rootdevice is slow
1101302840 M * xmms it is my first time here. Is there an howto to introduce me to the vserver?
1101302859 M * Bertl hope I didn't frigthen you?
1101302874 M * maharaja bertl: ill explain slowley
1101302877 M * maharaja 1. test
1101302880 M * Doener maharaja: stop saying that the rootdevice is slow ;)
1101302889 M * maharaja doener: well, tell him in a better way :)
1101302890 M * Bertl xmms: http://linux-vserver.org/
1101302900 M * Bertl http://linux-vserver.org/Linux-VServer-Paper
1101302910 M * Bertl http://linux-vserver.org/Documentation
1101302930 M * maharaja doener: tar is working as expected in both setups
1101302935 M * maharaja with and without chroot
1101302939 M * Bertl xmms: feel free to ask ...
1101302959 M * xmms Bertl, thx , I am reading the page. 
1101302978 M * Doener maharaja: got a strace?
1101302984 M * maharaja yes, one sec
1101303008 M * maharaja preparing the second one from within the chroot
1101303029 M * maharaja though i used another layer there, so things are a little slower
1101303035 M * Bertl please also upload the kernel config if possible
1101303046 M * maharaja like xfs -> lvm -> md -> disc
1101303049 Q * flock Ping timeout: 480 seconds
1101303056 M * maharaja so disc access is slower
1101303094 M * Doener Bertl: thing is, when maharaja does not chroot, all syscalls take much longer to complete. It is not device dependent, being chrooted just makes the syscalls faster somehow, i.e. they operate at normal speed.
1101303145 M * Bertl well, I have at least three explanations for that:
1101303149 M * maharaja doener: the tar strace is 10mb in size ;)
1101303159 M * Bertl - maja is testing on various devices of different speed
1101303179 M * Bertl - maja uses some obscure security stuff which is disabled inside a chroot
1101303199 M * Bertl - the fs cache in the chroot is not warmed up
1101303216 M * Doener Bertl: sys_uname uses the device?
1101303230 M * maharaja doener: ill give you a couple of thousand lines
1101303235 M * Bertl no, but async overlapping I/O will do
1101303317 M * maharaja bertl: kernel 2.4.23 is working without any flaw
1101303337 M * maharaja (debian default kernel)
1101303352 M * Bertl excellent! use it! ;)
1101303362 M * maharaja thats the way to solve problems :)
1101303388 M * Bertl well, it's a s good as testing 10 things at a time ...
1101303431 M * maharaja who is doing that?
1101303463 M * Bertl well, theory is: "chroot makes syscalls perform faster"
1101303474 M * Bertl right?
1101303498 M * Doener more like 'without chroot syscalls are slow' ;)
1101303505 M * Bertl okay
1101303518 M * Bertl so let's do a simple syscall, like the vserver version syscall
1101303537 M * Bertl get my vsched tool, and use the -V option
1101303561 M * maharaja i dont know the anatomy of the kernel well enough
1101303566 M * Bertl http://vserver.13thfloor.at/Experimental/vsched-0.01.tar.bz2
1101303596 M * Bertl you could even make the syscall a loop of 1000 syscalls
1101303622 M * maharaja it can be like this: 2.6.9/2.6.10rc2 do some weird stuff that syscalls in the normal environment is slow. chrooting to another device (no matter which!) does magic
1101303625 M * Bertl or 10k maybe .. then check that, compiled statically, inside and outside the chroot
1101303636 M * maharaja ok, ill boot into vserver
1101303647 M * maharaja did the current testing with a vanilla 2.6.10
1101303655 M * Bertl well, just modify the syscall to be some other syscall
1101303656 M * Bertl sec
1101303657 M * maharaja k
1101303671 M * maharaja doener: the first 5k lines of the tar output are on dev.ipax.tk/~raoul/kernel
1101303693 M * Doener saw it, same slow down as with dpkg and ps...
1101303711 M * maharaja mhm, il check too :)
1101303715 M * rs re
1101303720 M * Bertl wb rs!
1101303737 M * maharaja doener: ah, indeed
1101303742 M * Bertl Doener, Maja: let's use getnodename
1101303764 M * Bertl next possible option: glibc bloat
1101303779 M * Bertl (so make sure to use the syscall wrapper and not the glibc syscall)
1101303789 M * maharaja is glibc bloat related to the kernel family?
1101303796 M * Bertl NOO!
1101303798 M * Bertl ;)
1101303809 M * maharaja just keep in mind that exactly the same (!) setup runs fine with 2.4.23
1101303823 M * Bertl doesn't mean anything ...
1101303849 M * maharaja i just thought that may remove any lib depending stuff
1101303857 M * maharaja ok, lets use getnodename
1101303862 M * maharaja do i get a c file from you?
1101303864 M * Doener and that both root and chroot contain the same stuff...
1101303865 M * Bertl sys_uname
1101303886 M * Bertl or what about sys_getpgid?
1101303912 Q * TheSeer Read error: Connection reset by peer
1101303916 M * maharaja bertl, doener: and we can switch the both linux installs and get the same result, so its device independen (like speed, ...)
1101303925 J * TheSeer theseer@border.office.salesemotion.net
1101303943 M * Bertl okay, you get a test tool
1101303967 M * maharaja and ill compile another kernel with even less stuff enabled
1101303972 M * maharaja (if that may help)
1101304121 M * Val Quota tools packages for stable branch are cq-tools-0.06.tar.bz2 and vr-tools-0.14.tar.bz2, aren't they ?
1101304504 M * maharaja bertl: basically you can use everything
1101304509 M * maharaja bertl: see http://dev.ipax.tk/~raoul/kernel/ps_aux.strace
1101304521 M * maharaja slow: 1508       0.000452 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
1101304529 M * maharaja normal: 1512       0.000081 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
1101304773 Q * meebey Read error: Connection reset by peer
1101304824 J * flock restless@l192-117-111-12.broadband.actcom.net.il
1101304908 M * Bertl maharaja: http://vserver.13thfloor.at/Experimental/vsyscall-0.01.tar.bz2
1101304955 M * Bertl # ./vsyscall -n 100000
1101304955 M * Bertl    40574 us     0
1101305149 M * maharaja *testing*
1101305184 M * maharaja mhm
1101305246 M * maharaja nonchroot:
1101305250 M * maharaja master:/home/raoul# ./vsyscall -n 100000
1101305250 M * maharaja    46245 us          0
1101305254 M * maharaja chroot:
1101305260 M * maharaja master:/tmp# ./vsyscall -n 100000
1101305260 M * maharaja    46662 us          0
1101305270 M * Bertl within limits ...
1101305272 M * maharaja but: when i strace them
1101305303 M * maharaja nonchroot:
1101305303 M * maharaja 1938       0.000256 getpgid(0x1)        = 0
1101305312 M * maharaja chroot:
1101305312 M * maharaja 1944       0.000050 getpgid(0x1)        = 0
1101305326 M * maharaja any idea?
1101305348 M * Bertl well, obviously is the strace doing something different ...
1101305363 M * maharaja i guess that strace uses other calls, which slow things down?
1101305384 M * Bertl first, check with md5sum all the involved binaries
1101305400 M * Bertl (strace, libs) then check if /proc is present or not
1101305442 M * maharaja oric was not present, redoing the chrooted test
1101305463 M * maharaja still within the limits without strace
1101305561 M * maharaja strace, libc.so.6 and ld-linux.so.2 are the same
1101305561 Q * UFOczek Read error: Connection reset by peer
1101305561 Q * Loki|muh Read error: Connection reset by peer
1101305565 J * UFOczek ufoczek@hood.openbug.net
1101305569 J * Loki|muh loki@satanix.de
1101305577 M * maharaja another thing:
1101305581 M * maharaja time ps aux
1101305585 M * maharaja real    0m0.120s
1101305598 M * maharaja vs real    0m0.008s
1101305602 M * maharaja in the chroot
1101305699 Q * Zoiah Read error: Connection reset by peer
1101305706 M * Bertl but we agree that the syscalls are not slower/faster ;)
1101305716 M * maharaja not all
1101305718 J * Zoiah Zoiah@matryoshka.zoiah.net
1101305730 M * Bertl ah, so my test tool is broken?
1101305743 M * maharaja i dont know :)
1101305753 M * maharaja i can only tell that stuff runs slower without the chroot
1101305758 M * maharaja like the ps aux
1101305771 M * maharaja so any other possibilities?
1101305811 M * maharaja i could look if there is any debian premade 2.6 kernel
1101305812 M * Bertl preload cracker library on your host which sends your passwords over network?
1101305847 M * Bertl syscall intercaption security wossname?
1101305848 M * maharaja what do you mean by that?
1101305931 M * maharaja please explain 
1101305931 M * Bertl maybe your host has a preload library which 'does' something whenever a syscall is made
1101305931 M * maharaja i can switch the two setups
1101305931 M * maharaja i got two identical partitions
1101305933 M * maharaja /dev/hda2 and /dev/md0
1101305949 M * maharaja so it should do the same within the chroot, or am i wrong
1101305964 M * maharaja the behaviour is the same, no matter which system i boot
1101305979 M * Bertl and is it? or not?
1101306032 M * maharaja well, as i do not know the indepth working of chroot and linux, i say it should behave the same on the host as on the other install
1101306038 M * maharaja but obviously, it does not
1101306070 M * Bertl well, obviosuly that isn't possible for various reasons
1101306079 M * maharaja the current test where done with root=/dev/md0
1101306084 M * maharaja now i boot into root=/dev/hda2
1101306094 M * maharaja and test again
1101306100 M * Bertl okay
1101306114 M * maharaja i did that test in the morning with 2.6.9
1101306116 M * maharaja (vanilla)
1101306130 M * maharaja so somehow i do not think that 2.6.10 will make any difference
1101306344 J * DuckMaster Duck@dyn-83-155-5-218.ppp.tiscali.fr
1101306411 M * maharaja ok, rootdev = hda2
1101306412 M * maharaja real    0m0.144s
1101306415 M * maharaja (ps aux)
1101306417 M * maharaja on the host
1101306427 M * maharaja real    0m0.008s
1101306429 M * maharaja on the client
1101306442 M * maharaja the first time after mounting proc, i got the same result as on the host
1101306449 M * maharaja maybe some caching/indexing/whatever issue?
1101306577 M * maharaja what does the ro option do?
1101306595 M * maharaja /vmlinuz-2.6.10-rc2-p4 root=/dev/hda2 ro
1101306651 M * Bertl readonly mount of the rootfs
1101306775 Q * DuckKing Ping timeout: 480 seconds
1101306798 M * maharaja could that be anything
1101306934 M * Val 2.4.X stable cq-tools debian package available at http://vallar.linuxfr.org/debian/cq-tools-0.06-1/
1101306939 M * Val and...
1101306941 M * Val it works :)
1101306949 M * Bertl fascinating ...
1101307036 M * Bertl thanks a lot! links are on the wiki page?
1101307047 M * Val they were
1101307093 M * Val but they don't now :-/
1101307118 M * Val someone did remove the page that refer to my debian package repository
1101307129 M * Val grmble
1101307130 M * Val ...
1101307139 M * Val let's make a new link
1101307145 M * Bertl check if it wasn't moved somewhere else first
1101307151 M * Val yes
1101307163 M * Val and then re-link it on the homepage
1101307183 M * Val bu before i make vr-tools debian package too :)
1101307425 M * Bertl mugwump: sam, you are here?
1101308331 M * Val 2.4.X stable vr-tools debian package available at http://vallar.linuxfr.org/debian/vr-tools-0.14-1/
1101308356 M * Val now doing a koffe pause and then updating linux-vserver wiki
1101308358 M * Bertl Val: please no direct link on the first page ...
1101308363 M * Val ok
1101308364 M * Val np
1101308371 M * Bertl otherwise other distros will move there too
1101308376 M * Val yes
1101308383 M * Bertl and then we drown in links
1101308383 M * Val i do like the other
1101308392 M * Bertl tx
1101308395 M * Val in specific distro stuff
1101308412 M * Val but first koffe pause :)
1101308425 M * Val koffe break
1101308594 J * Shuri Dew@dsl.speedline209.226.electronicbox.net
1101308610 Q * Shuri Quit: 
1101308714 J * sebd konversat@lns-th2-4f-81-56-247-131.adsl.proxad.net
1101308734 M * Bertl welcome sebd!
1101308757 M * sebd hi
1101308879 M * Val http://linux-vserver.org/Tools+and+patches updated
1101308912 M * Bertl excellent!
1101309375 M * Hollow hm, can't compile mysql... gen_lex_hash segfaults... and core dumping does not work cause ulimit can not set: operation not permitted..
1101309401 M * Bertl hmm, inside a vserver?
1101309408 M * Hollow yep
1101309424 M * Bertl what about specifying the -c ulimit at startup?
1101309428 M * Hollow it's 2.6.9-vs1.9.3 with gentoo-uclibc-hardened
1101309444 M * Hollow i'll try...
1101309513 M * Hollow in apps/init/cmd.prepare, no?
1101309526 M * Bertl no, in rlimits
1101309542 M * Bertl or maybe it's called ulimits
1101309591 M * Hollow hm... min soft and hard... what should be min for core dumping?
1101309618 M * Bertl sec you are in the wrong palce
1101309628 M * Hollow alpha utils!
1101309680 M * Bertl /etc/vservers/vserver-name/ulimits
1101309681 M * Bertl A directory with ulimits. Possible resources are cpu, data, fsize, locks, memlock, nofile, nproc, rss and/or stack. This configuration will be honored for kernel 2.4 only. 
1101309687 M * Bertl hum, why 2.4 only?!
1101309689 M * Hollow <- 2.6
1101309695 M * Hollow 2.6 has rlimits
1101309704 M * Bertl yeah, but they are orthogonal
1101309731 M * Bertl okay, try just to specify it before context startup
1101309746 M * Hollow sec..
1101309750 M * Bertl a pity that enrico isn't showing up lately ...
1101309848 M * Hollow core dumped.. perfect :)
1101309895 M * Hollow wtf...
1101309908 M * Hollow it is the same like it was last time i did a core dump for you
1101309916 M * Hollow Core was generated by `./gen_lex_hash'.
1101309916 M * Hollow Program terminated with signal 11, Segmentation fault.
1101309916 M * Hollow #0  0xb7ffce8b in ?? ()
1101309919 M * Hollow that's it.
1101309990 M * Bertl and what did we find out last time?
1101309995 M * Hollow nothing :)
1101310003 M * Bertl any entries in the dmesg logs?
1101310007 M * Hollow or at least you didn't tell me
1101310019 M * Hollow nope.. nothing in dmesg
1101310048 M * Bertl where does your kernel start?
1101310072 M * Hollow er? where?
1101310110 M * Hollow what do you mean by where?
1101310118 M * Bertl try 'objdump -d vmlinux | head -6 | tail -1'
1101310176 M * Hollow zeus linux # objdump -d vmlinux | head -n6 | tail -n1
1101310177 M * Hollow c0100000 <startup_32>:
1101310186 M * Bertl okay, so the segfault happens in userspace
1101310206 M * Hollow cause the hex in gdb is after this one?
1101310211 M * Hollow (just to learn sth) :)
1101310217 M * Bertl before, but yes
1101310224 M * Hollow ok...
1101310249 M * Bertl what is the gen_lex_hash ?
1101310250 M * Hollow let's see if 4.0.20 compiles
1101310258 M * Bertl sounds like lex/flex to me
1101310260 M * Hollow dunno yet, i just try to find out
1101310274 M * Bertl maybe you ahve an outdated/broken flex
1101310379 M * Hollow outdated: no, broken: maybe
1101314304 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3
1101314304 T * Bertl -
1101314505 M * davaga Hi every one mabie some one can help me with a problem.
1101314507 M * davaga I have a Vserver set up and in one of the vserver accounts I am tring to compile
1101314508 M * davaga PHP (any version 4 - 5) win I compile it as a cgi It works fine but when I add the 
1101314510 M * davaga apach module it fails. It only happens when I do it on the vserver 
1101314511 M * davaga Any ideas?
1101314547 M * Bertl hmm .. maybe some misconfiguration inside that vserver?
1101314547 Q * sannes Read error: Connection reset by peer
1101314776 M * Bertl davaga: it's relatively unlikely that the vserver itself affects the apache/php stuff ... at least php as apache module runs fine here ...
1101315383 Q * Plug Read error: Connection reset by peer
1101315399 J * Plug plug@datadot.net
1101315550 M * Val back home
1101315551 M * Val cya
1101315560 N * Val Val_away
1101315612 M * Bertl http://www.heise.de/newsticker/meldung/53613 (german)
1101315637 M * Bertl thanks to Jan-Marc for forwarding that ...
1101316000 M * Hollow i'm just looking over the lycos products... sounds quite nice
1101316001 M * davaga sorry 
1101316002 M * davaga Thats what I thought but I just don't know what else it might be 
1101316045 J * sannes ace@home.skarby.no
1101316050 M * Hollow anyone knows what heise means by "lycos uses a self developed version of vserver"? what did they do?
1101316061 M * Bertl davaga: well, how did you verify that it works outside, but fails inside?
1101316078 M * Bertl Hollow: that's marketing gibberish ...
1101316088 M * Hollow i thought so...
1101316091 A * sannes was at a PlanetLab presentation today :)
1101316106 M * Bertl hey sannes! and?
1101316111 M * davaga I can install it on the root server just fine
1101316115 M * sannes pretty cool stuff! :)
1101316120 M * sannes (they use vservers and all)
1101316144 M * sannes anyways, I think I have it on stream if you havn't been to it?
1101316149 M * Bertl jeah, I just wish mef would listen a little closer to what I tell him ...
1101316280 M * sannes Timothy Roscoe spoke there .. (Intel guy and one of the designers of planetlab)
1101316292 M * sannes I always knew vservers was a cool technology :>
1101316297 M * Bertl ;)
1101316899 M * Bertl okay, back later .. please help davaga!
1101316920 N * Bertl Bertl_oO
1101316997 M * davaga here is the error I get 
1101316999 M * davaga libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.0.2/libs'
1101317000 M * davaga chmod 755 /usr/local/apache2/modules/libphp5.so
1101317002 M * davaga make: *** [install-sapi] Error 139
1101317048 M * davaga it seems to fail after the istalation of the apache module
1101317100 M * sannes hm, ..
1101317142 M * davaga it is as if the instalation is tring to over right something and it cant  mabie some wierd attribute set or something
1101317158 M * davaga err overwrite
1101317223 M * davaga I am using shared or linked files for the skel would that have something to do with it?
1101317224 Q * sannes Read error: Connection reset by peer
1101317257 Q * BWare Ping timeout: 480 seconds
1101317390 M * davaga here is the debug chain of the make install
1101317392 M * davaga Installing PHP SAPI module:       apache2handler
1101317393 M * davaga Got a SIGCHLD; 1 unreaped children.
1101317394 M * davaga Reaping winning child 0x080c0da8 PID 30086
1101317396 M * davaga Live child 0x080c0da8 (install-sapi) PID 30087
1101317397 M * davaga Got a SIGCHLD; 1 unreaped children.
1101317399 M * davaga Reaping winning child 0x080c0da8 PID 30087
1101317400 M * davaga Live child 0x080c0da8 (install-sapi) PID 30104
1101317402 M * davaga Got a SIGCHLD; 1 unreaped children.
1101317403 M * davaga Reaping winning child 0x080c0da8 PID 30104
1101317405 M * davaga Live child 0x080c0da8 (install-sapi) PID 30105
1101317406 M * davaga /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules
1101317408 M * davaga /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/
1101317409 M * davaga cp .libs/libphp5.so /usr/local/apache2/modules/libphp5.so
1101317411 M * davaga cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la
1101317412 M * davaga libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.0.2/libs'
1101317414 M * davaga chmod 755 /usr/local/apache2/modules/libphp5.so
1101317415 M * davaga Got a SIGCHLD; 1 unreaped children.
1101317417 M * davaga Reaping losing child 0x080c0da8 PID 30105
1101317418 M * davaga make: *** [install-sapi] Error 139
1101317420 M * davaga Removing child 0x080c0da8 PID 30105  from chain.
1101318283 J * id_ test@relax-media.softwarezentrum.de
1101318290 M * id_ hi #vserver
1101318457 J * sannes ace@home.skarby.no
1101318675 Q * anonymous-coward Read error: Connection reset by peer
1101319210 Q * lilo_ Read error: Connection reset by peer
1101319223 J * lilo lilo@lilo.usercloak.oftc.net
1101319435 Q * sannes Read error: Connection reset by peer
1101319632 M * infowolfe Bertl_oO: did you know that lycos is using your software?
1101319666 M * infowolfe http://webcenter.lycos.de/
1101319673 M * infowolfe it's using linux-vserver
1101320011 M * infowolfe btw, is linux-vserver GPL?
1101320148 M * sladen infowolfe: of course
1101320197 M * infowolfe sladen: thought so... did you know about the lycos thing?
1101320206 M * sladen infowolfe: yes
1101320217 M * infowolfe hrm, i didn't
1101320222 M * sladen infowolfe: mugwump was involved with it
1101320242 M * infowolfe lol, oooh, about my earlier ping, i found your ip-accounting page and added your FAQ (although a little outdated) to the wiki
1101320288 M * sladen infowolfe: groovy.  Hope it was useful!
1101320334 M * infowolfe it was... although i can't find docs outlining how to do per-ip accounting via ipac-ng
1101320348 M * infowolfe all of is per-interface :(
1101320517 M * eyck ipfm does nice per-ip accounting
1101320583 M * eyck hmm, I'm offtopic again, huh?
1101320585 M * eyck sorry
1101320648 M * sladen eyck: one of the match critiea is 'IP' (along with interface, port etc)
1101320661 M * sladen two rules per server, one for 'IN' matching the IP of the vserver
1101320668 M * sladen one for 'OUT' matching the IP of the vserver
1101320758 M * infowolfe sladen: could you paste a sample IN line for me?
1101320774 M * infowolfe it's WHERE to put the ip that is getting me
1101320808 M * infowolfe Incoming Total System|ipac~o|eth0|all||||
1101320818 M * infowolfe that's one of the stock rules...
1101321463 M * Doener infowolfe: rs is the lycos guy ;)
1101321528 M * infowolfe ok
1101322077 Q * sladen Read error: Connection reset by peer
1101322081 J * sladen paul@starsky.19inch.net
1101323089 Q * rs Quit: leaving
1101324160 Q * Hollow Read error: Connection reset by peer
1101324170 J * Hollow bene@home.xnull.de
1101324295 Q * Snow-Man Write error: connection closed
1101324312 J * Snow-Man sfrost@snowman.net
1101324904 J * UnionPivo union@clj8-137.dial-up.arnes.si
1101326434 J * sannes ace@home.skarby.no
1101326688 J * logger rs@vds.pas-mal.com
1101327037 M * Hollow Bertl_oO: this segfault thing seems to be a uclibc issue, compiles fine inside a glibc vserver...
1101330243 Q * id_ Quit: master of disaster
1101330420 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3
1101331092 M * infowolfe argh@oftc
1101331993 N * Bertl_oO Bertl
1101332126 M * Bertl Hollow: hmm, uclibc?
1101332131 M * Bertl evening folks!
1101332172 M * Bertl infowolfe: yes I know ...
1101338180 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3
1101338180 T * Bertl -
1101338536 M * Bertl okay folks you can talk again ... pinky was hot-fixed ...
1101339664 Q * flock Ping timeout: 480 seconds
1101340685 Q * davaga Quit: ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040903]