1191200667 Q * hparker Ping timeout: 480 seconds 1191202577 J * coderanger ~coderange@kantrn.stu.rpi.edu 1191211926 Q * FireEgl Quit: Bye... 1191213387 Q * edible 1191214190 M * MooingLemur are there base tarballs of vserver guests? The documented install process for non-gentoo vservers raises my blood pressure :) 1191214208 M * MooingLemur I don't want to rely on a package manager on the host OS, which is Gentoo. 1191214467 M * daniel_hozac so you'd rather install using some random tarball from someone you don't know? :) 1191214519 M * MooingLemur maybe the debootstrap process is easier than the yum one 1191214523 M * MooingLemur I'm trying that now 1191214524 M * daniel_hozac besides, it's just during build. 1191214570 M * MooingLemur I actually resorted to installing Fedora on another box so I could build a vserver and tar it up to upload it to my gentoo box :P 1191214649 M * daniel_hozac why? 1191214686 T * daniel_hozac http://linux-vserver.org/ | latest stable 2.2.0.3, 2.0.3-rc3, devel 2.3.0.25, stable+grsec 2.0.2.1, 2.2.0.3 | util-vserver-0.30.214 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;) 1191214715 M * MooingLemur I don't remember why, but the process kept bailing out 1191214720 M * MooingLemur before it finished 1191215261 M * MooingLemur Linux phoenix-west 2.6.22-vs2.3.0.17-gentoo #1 SMP Tue Sep 4 02:52:36 MST 2007 x86_64 AMD Processor model unknown AuthenticAMD GNU/Linux 1191215271 M * MooingLemur debootstrap is probably choking on that 1191215272 M * MooingLemur heh 1191215278 M * MooingLemur E: Invalid Release file, no entry for main/binary-AuthenticAMD/Packages 1191215308 M * daniel_hozac -- --arch amd64 1191215313 M * MooingLemur excellent 1191215314 M * MooingLemur thanks 1191215476 M * MooingLemur that's what I get for buying an X2 6000+ shortly after release, and haven't gotten around to creating a memdisk image with the updated bios on it. 1191215839 J * balbir ~balbir@122.167.79.239 1191217084 J * dna ~dna@p54BCDB76.dip.t-dialin.net 1191218576 J * ktwilight ~ktwilight@49.192-66-87.adsl-static.isp.belgacom.be 1191218713 Q * nebuchadnezzar Remote host closed the connection 1191219408 Q * MooingLemur Ping timeout: 480 seconds 1191219507 Q * cehteh Ping timeout: 480 seconds 1191219564 J * jmcaricand ~user@d83-179-210-152.cust.tele2.fr 1191219587 J * cehteh ~ct@pipapo.org 1191223743 Q * cehteh Ping timeout: 480 seconds 1191223762 J * arekm arekm@carme.pld-linux.org 1191223795 M * arekm Bertl_zZ, daniel_hozac: I have great luck or no idea what 1191223799 J * cehteh ~ct@pipapo.org 1191223809 M * daniel_hozac what? 1191223820 M * arekm Bertl_zZ, daniel_hozac: http://pastebin.com/m7995735a it is a PC with AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 1191223855 J * meandtheshell ~markus@85.127.119.109 1191223883 M * daniel_hozac same as me then... 1191223887 M * daniel_hozac and i can't trigger it. 1191223987 M * daniel_hozac have you tried init=/bin/bash, chcontext...? 1191224043 M * arekm daniel_hozac: no, I can try (+ remember that I can't trigger without ntpd) 1191224067 M * arekm daniel_hozac: you are using rhel5 right? 1191224073 M * daniel_hozac CentOS. 1191224079 M * daniel_hozac and Fedora. 1191224092 M * arekm centos, does it have public buildlogs for packages? 1191224153 M * daniel_hozac no idea... 1191224278 M * arekm can you run ntp package rebuild and see what configure will tell about clock_settime? 1191224464 M * daniel_hozac no. 1191224926 J * JonB ~NoSuchUse@130.227.63.19 1191225376 Q * JonB Quit: Leaving 1191225484 M * daniel_hozac you had yes on that, right? 1191225572 J * JonB ~NoSuchUse@130.227.63.19 1191225598 N * Bertl_zZ Bertl 1191225602 M * Bertl morning folks! 1191225604 M * JonB i 1191225607 M * JonB hi 1191225617 M * Bertl arekm: could you try to disable hrtimers? 1191225657 M * arekm daniel_hozac: yes, I had yes. guy on #centos checks that for me 1191225720 Q * JonB Read error: Connection reset by peer 1191225837 M * daniel_hozac do you know how your ntpd calls clock_settime? 1191225878 J * JonB ~NoSuchUse@130.227.63.19 1191225894 M * arekm checking if we'll use clock_settime or settimeofday or stime... settimeofday() 1191225895 M * arekm configure: WARNING: *** But clock_settime() would be better (if we had it) *** 1191225910 M * arekm that's from centos. -lrt is missing in configure test to properly detect this 1191225963 M * arekm daniel_hozac: don't know. building ntp without clock_settime() to test if it still triggers 1191226115 M * arekm Bertl: yes, need to find which CONFIG_ is that 1191226616 J * ktwilight_ ~ktwilight@203.95-66-87.adsl-dyn.isp.belgacom.be 1191226997 Q * ktwilight Ping timeout: 480 seconds 1191227182 J * DavidS ~david@85.125.165.34 1191227216 N * DavidS DavidS|Wien 1191227216 M * JonB my vserver guest shows UID and not username for some processes in ps aux ? 1191227286 M * daniel_hozac and the same system on a physical machine shows the username? 1191227367 J * ktwilight ~ktwilight@215.217-66-87.adsl-static.isp.belgacom.be 1191227390 M * JonB it's a system i installed on the guest 1191227399 M * JonB but a process from a physical server 1191227405 M * JonB where i only kopied the data over 1191227440 M * JonB but the process does show username in the old server, but not the guest. However it is only this process. apache shows www-data just fine 1191227444 M * JonB the rest are root 1191227476 M * JonB just these few processes should say smokeping, but they say 101 (which is the smokeping user in passwd) 1191227492 M * daniel_hozac so passwd has the username? 1191227517 M * JonB yes 1191227544 M * daniel_hozac do you use the same version of procps? 1191227575 M * daniel_hozac because i know some versions won't show usernames that are longer than 8 characters 1191227581 M * JonB nope, one is debian sarge, the other is etch 1191227589 M * JonB okay, thanks will look at that problem 1191227611 M * arekm Bertl: when you were testin my ntpd - did it synchronized at all? 1191227626 M * Bertl arekm: yes, had a buch of messages from it 1191227631 M * JonB daniel_hozac: bingo, thanks you know EVERYTHING :-) 1191227752 Q * ktwilight_ Ping timeout: 480 seconds 1191228293 J * nebuchadnezzar ~nebu@zion.asgardr.info 1191229637 Q * ex Ping timeout: 480 seconds 1191229673 Q * cehteh Ping timeout: 480 seconds 1191230205 M * Bertl arekm: I'm working on a new test/debug patch :) 1191230325 M * arekm I'm working on other people to reproduce the problem on their machines 1191230340 M * arekm so I won't be alone 1191230346 M * Bertl good :) 1191230356 M * JonB arekm: what was the problem? 1191230379 M * arekm JonB: vserver oopses when ntpd runs on host 1191230406 M * arekm JonB: not every ntpd, has to be "the one" 1191230435 M * arekm JonB: so far only x86_64 smp/n core (where n >= 2) was tested (4 different machines) 1191230451 M * arekm JonB: and the problem is that I'm the only one able to reproduce :) 1191230486 M * JonB arekm: sorry, i do not have such a machine 1191230566 M * arekm zbyniu is going to test this too 1191230647 M * JonB ok 1191231172 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net 1191232869 M * arekm geeez 1191232928 M * arekm I even reproduced the problem on ... 1 x some old sempron, i686 machine 1191232979 M * Bertl that is good news, as it isn't x86_64 specific then 1191232998 M * arekm Bertl: and UP is enough 1191233015 M * Bertl even better, what about preemption? 1191233049 M * arekm let me see what was config there 1191233090 M * Bertl btw, the kernel I compiled for you shows the same issues, yes? 1191233157 M * arekm Bertl: I didn't get second bzImage from you afaik so didn't test 1191233169 M * Bertl ah, uploaded it yesterday, same location 1191233185 M * arekm [root@pepe ~]# zgrep PREE /proc/config.gz 1191233185 M * arekm # CONFIG_PREEMPT_NONE is not set 1191233185 M * arekm CONFIG_PREEMPT_VOLUNTARY=y 1191233185 M * arekm # CONFIG_PREEMPT is not set 1191233185 M * arekm CONFIG_PREEMPT_BKL=y 1191233191 M * Bertl http://vserver.13thfloor.at/Stuff/AREKM/bzImage 1191233208 M * Bertl try if you can trigger it on the UP with PREEMP disabled 1191233230 M * arekm but voluntary is not typical "bad" preempt 1191233238 M * Bertl yes, I know 1191233341 M * arekm and of course my special ntpd was needed to crash the thing 8-) 1191233466 M * Bertl hehe :) 1191233517 M * Bertl maybe we could adapt that ntpd code to 'just' do the trigger event in an endless loop? 1191233539 M * Bertl that should increase the probability for the oops 1191233648 M * arekm the problem is that I have no idea what ntpd does so important that vserver crashes. did small program that was issuing clock_gettime and clock_settime in loop but that didn't trigger 1191233719 M * Bertl maybe you have to correct the time before setting it 1191233724 M * arekm btw. that latest sempron test was with kernel == SMP running on UP machine 1191233841 M * arekm Bertl: your vserver.*princeton kernel also crashed. http://pastebin.com/m6ee60915 1191233867 M * arekm Bertl: 10 times make -j6+ctrl c when ntpd was stopped == no crash. 3 x make -j6 when ntpd was running and it crashed 1191233884 M * Bertl okay, almost assumed that 1191233899 M * Bertl didn't look like a toolchain issue to me 1191233903 Q * bzed Ping timeout: 480 seconds 1191233969 M * arekm Bertl: toolchain was already tested.I was using debian etch toolchain once. And gcc 4.2.2rc2, too. And 4.2.1 1191233975 J * bzed ~bzed@devel.recluse.de 1191233987 M * arekm and even 4.2.0 20070603 1191234050 M * arekm Bertl: did you mount /proc in chroot when testing my ntpd? + fixed resolv.conf? 1191234526 M * Bertl I took your environment as is, without proc 1191234601 M * arekm ntpd uses timer_create() and timer_settime() 1191234625 M * Pazzo Hi @ll, hi Bertl! 1191234696 M * Bertl hey Pazzo! 1191234724 M * Pazzo Bertl: could you provide us a 2.2.x patch for 2.6.20.20? 1191234760 M * Pazzo (-> CVE-2007-4573) 1191234788 M * Bertl latest is 2.6.20.15, right? 1191234804 M * Pazzo nope, 2.6.20.20 1191234816 M * Bertl no, I mean, the latest available patch is for 2.6.20.156 1191234818 M * Bertl *15 1191234821 M * Pazzo yep 1191234831 M * Bertl and that one doesn't apply to 2.6.20.20, yes? 1191234860 M * Pazzo it applies, but there are more than a few hunks applying from 1 to 9 lines "away" from their original destination 1191234877 M * Bertl okay, I'll give it a look 1191234905 M * Pazzo should be ok, but there remains a strange feeling - as I'm not experienced enough to REALLY be sure if it would be ok :-) 1191235448 M * JonB those kernel.org patches named patch-2.6.22.7.bz2 are they a patch between 2.6.22.6 and 2.6.22.7 ? 1191235469 M * Bertl no, between 2.6.22 and 2.6.22.7 1191235541 M * JonB hmm, so how do i update my 2,6,22,6 with vserver to the latest and greatest and get the security updates 1191235608 M * Bertl simple, you get the 2.6.22.9 patch and the appropriate vserver patch ontop of that 1191235630 M * JonB yeah, but then i have to download 2.6.22 as well, right? 1191235643 M * Bertl what did you download before? 1191235653 M * JonB 2.6.22.6 1191235659 M * Bertl as full version? 1191235663 M * JonB yes 1191235669 M * arekm Bertl: when running ntpd on host I get 1191235670 M * arekm Oct 1 12:47:18 phobos kernel: [ 1276.072143] vxD: task_get_vx_info(ffff8100792be040) @kernel/posix-timers.c:304 1191235673 M * arekm Oct 1 12:47:18 phobos kernel: [ 1276.072148] vxD: enter_vx_info(0000000000000000[#0],ffffffff807a9e00) ffffffff806e8440[#0,0000000000000000] @kernel/posix-timers.c:304 1191235674 M * JonB i suppose i should not do that again 1191235676 M * arekm Oct 1 12:47:18 phobos kernel: [ 1276.072153] vxD: leave_vx_info(ffffffff807a9e00[#0,0000000000000000]) ffffffff806e8440[#0,0000000000000000] @kernel/posix-timers.c:332 1191235682 M * Bertl JonB: then get the 2.6.22.6 patch too, revert that and apply the 2.6.22.9 ontop 1191235682 M * arekm Bertl: this is normal even for non guest processes? 1191235702 M * JonB Bertl: brilliant 1191235721 M * Bertl arekm: can be optimized, but should be fine IMHO 1191235722 M * JonB Bertl: does patch-2.6.22.6-vs2.2.0.3.diff apply cleany to .9 ? 1191235748 M * Bertl JonB: probably, but latest and greatest is 2.3.0.25 :) 1191235784 M * JonB Bertl: how stable is that for production servers? 1191235798 M * Bertl it is development, not stable :) 1191235808 M * JonB good, then i go for stable 1191235832 M * Bertl but 2.2.0.3 should apply, if not let me know, the update is still on my todo list 1191235848 M * arekm Bertl: ok. I see this repeatly when ntpd runs 1191235872 M * Bertl arekm: and I suspect it _is_ related somehow 1191235950 M * Bertl I should have my test patch ready in a few minutes 1191235987 M * Bertl maybe move to a platform where it can be easily triggered but we want to look at the non-oops case here 1191236020 M * Bertl i.e. it would be nice to get a few ctrl-c abortions of a compile run without the oops 1191236299 M * Bertl arekm: http://vserver.13thfloor.at/Experimental/delta-refcheck-debug01.diff 1191236316 M * Bertl arekm: please remove (or avoid) the doubleref debug patch 1191236327 M * Bertl (if not already done so) 1191236561 M * arekm normal boot or with some sysctl setting? 1191236563 M * Bertl arekm: ah, I forgot to mention, please use only xid values below 255 1191236586 M * Bertl and do a 'cat /proc/virtual/vxrc' before and after each test 1191236605 M * Bertl normal boot should be fine 1191236651 M * Bertl hmm, sec, maybe something is missing in the patch, it compiled fine for you? 1191236708 M * arekm no 1191236709 M * arekm include/linux/kernel.h: At top level: 1191236710 M * arekm include/linux/kernel.h:158: error: conflicting types for 'printk' 1191236710 M * arekm include/linux/kernel.h:158: note: a parameter list with an ellipsis can't match an empty parameter name list declaration 1191236713 M * arekm include/linux/vserver/debug.h:164: error: previous implicit declaration of 'printk' was here 1191236716 M * Bertl yeah, thought so, sec 1191236766 M * JonB cd .. 1191236767 M * JonB ls 1191236782 M * Bertl JonB: my_first_file.txt 1191236885 M * JonB haha 1191236894 M * Bertl arekm: yeah, please move the #include in inet.c below the vs_inet6.h include 1191236902 M * JonB :-D 1191236917 M * JonB when i grow up i wanna be like Bertl 1191237155 M * arekm Bertl: tell me what to look in /proc/virtual/vxrc 1191237166 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191237166 M * arekm [0] 20 -1479 50 0 0 1191237166 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191237166 M * arekm [0] 21 -1481 50 0 0 1191237177 M * Bertl that is perfectly fine, the 0 is a catch all 1191237189 M * arekm first 0? 1191237191 M * Bertl what we are looking for is something like: 1191237197 M * Bertl [110] 0 4 0 0 0 1191237208 M * Bertl [110] 0 4 0 0 0 1191237212 M * Bertl or even better 1191237219 M * Bertl [110] 0 -2 -3 0 0 1191237232 M * Bertl 110 is the context number you are using 1191237240 M * arekm http://pastebin.com/m1556d7af 1191237242 M * Bertl but more important, we have kernel log messages 1191237258 M * Bertl there should be about 4 put_vxi ... ZERO messages for each test 1191237289 M * Bertl and if we can reach the 'bug' state, we should also get put_vxi ... val=-N logs 1191237324 M * Bertl the ZERO messages are fine, the val= messages not 1191237374 M * JonB Bertl: 2 patch rejects. One simple in Makefile, the other in fs/locks.c #hunk 10. but it seems trivial to change. Trying to compile now 1191237391 M * Bertl JonB: okay, as expected ... tx for the info 1191237392 M * arekm http://pastebin.com/m3abc02c5 1191237407 M * arekm Bertl: and didn't start test yet. 1191237410 M * arekm tried to do: LC_ALL=C chcontext --xid 666 -- cat /proc/virtual/vxrc 1191237410 M * arekm cat: /proc/virtual/vxrc: No such file or directory 1191237426 M * daniel_hozac you can't access that from a context. 1191237428 M * Bertl that is expected 1191237450 M * Bertl arekm: but please avoid 666 for now, take 42 :) 1191237459 M * arekm ok, so I'm supposed to do cat from host, right? 1191237466 M * Bertl yep, correct 1191237476 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191237476 M * arekm [0] 27 -1647 64 0 258 1191237476 M * arekm [154] 2 -18 0 0 0 1191237479 M * arekm and starting make -j6 now 1191237499 M * Bertl how do we get negative on fork? 1191237511 M * Bertl (maybe I missed one entry, checking) 1191237572 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191237573 M * arekm [0] 27 -1674 64 4 348 1191237573 M * arekm [154] 31 -770 0 -4 0 1191237575 M * Bertl yep, missing one 1191237578 M * arekm crashed 1191237861 M * arekm so where to add and what missing one? 1191237877 M * Bertl sec, patch is available shortly 1191237952 M * bzed JonB: although I'm wondering why the fs/lock.c rejects. but maybe I'm jsut blind, realyl easy to fix, though 1191238013 M * Bertl arekm: http://vserver.13thfloor.at/Experimental/delta-refcheck-debug02.diff 1191238025 M * Bertl (the second hunk is the change you already did manually) 1191238058 J * Piet ~piet@tor.noreply.org 1191238100 M * Bertl wb Piet! 1191238111 M * JonB bzed: it rejects because the line is similar but not identical ? 1191238326 M * Bertl arekm: the -4 is quite interesting 1191238378 M * bzed JonB: yeah, I just didn;t find the difference on the first look 1191238391 M * JonB bzed: ok 1191238397 M * Bertl bzed: diff/patch has better eyes :) 1191238411 M * bzed :P 1191238420 M * JonB Bertl: are you saying bzed looks bad? ;-) 1191238450 M * bzed JonB: I look good, that doesn't say that I'm able to see :P 1191238468 M * bzed err me looks well is probably the better english O_o 1191238468 M * JonB bzed: oh, i see ;-) 1191238506 M * Bertl see, he does *G* :) 1191238598 M * Bertl daniel_hozac: I think I found it! 1191238605 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191238605 M * arekm [0] 23 55 51 0 0 1191238605 M * arekm [154] 2 3 0 0 0 1191238625 M * arekm ntpd stopped, did few make -j6 + ctrl -c - last 2 columns were always 0 1191238627 M * Bertl the context is still running, yes? 1191238636 M * arekm yes 1191238639 M * Bertl if you leave it, it should return to 0 1191238648 M * Bertl i.e. the 154 line will disappear 1191238671 M * DavidS|Wien btw: I found a place, where the XID can be found from within a context: grep XID /proc/$$/vinfo 1191238674 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191238674 M * arekm [0] 22 54 51 0 0 1191238674 M * arekm [154] 0 1 0 0 0 1191238686 M * DavidS|Wien since i know that this question came up repeatedly, where in the wiki could this be added? 1191238689 Q * Borg- Ping timeout: 480 seconds 1191238692 M * Bertl DavidS|Wien: congrats, but that is a) intentional, and b) optional :) 1191238698 M * arekm baldy: didn't disappear 1191238708 M * arekm Bertl: didn't disappear 1191238732 M * Bertl hmm, the 1 is interesting .. that means a single task is still active 1191238736 M * arekm Bertl: vps aux shows only MAIN and ALL_PROC processes 1191238756 M * Bertl what does /proc/virtual/status show? 1191238768 M * arekm [root@phobos carme-pld]# chcontext --xid 666 -- ps aux 1191238768 M * arekm New security context is 666 1191238768 M * arekm USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1191238768 M * arekm root 3122 0.0 0.0 87164 756 pts/1 R+ 13:39 0:00 ps aux 1191238769 M * arekm [root@phobos carme-pld]# 1191238777 M * arekm running chcontext --xid 666 -- ps aux 6 times and 1191238783 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191238783 M * arekm [0] 22 60 51 0 0 1191238783 M * arekm [154] 0 7 0 0 0 1191238798 M * Bertl okay, that sounds more like another missing put, sec 1191238802 M * arekm [root@phobos ~]# cat /proc/virtual/status 1191238802 M * arekm #CTotal: 0 1191238802 M * arekm #CActive: 0 1191238802 M * arekm #NSProxy: 0 22 0 0 0 1191238815 M * Bertl that is fine ... 1191239040 M * arekm starting ntpd and last 0 rises to 1 1191239041 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191239041 M * arekm [0] 26 65 64 0 1 1191239041 M * arekm [154] 2 10 0 0 0 1191239056 M * arekm stopping 1191239057 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191239057 M * arekm [0] 25 64 52 0 25 1191239057 M * arekm [154] 2 10 0 0 0 1191239082 M * Bertl okay, one after the other, give me a few minutes :) 1191239089 M * arekm running make -j6 + ctrl c and 1191239091 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191239091 M * arekm [0] 26 65 64 2 43 1191239091 M * arekm [154] 2 10 0 -2 0 1191239101 M * Bertl ah, here it is again, the 2/-2 1191239110 M * Bertl that is what we are actually looking for IMHO 1191239170 M * arekm and logs 1191239172 M * arekm Oct 1 13:44:20 193.239.45.150 ntpd: ntpd startup succeeded 1191239172 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.943006] vxD: put_xid(#666) val=-1 @kernel/posix-timers.c:335 1191239175 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.980185] vxD: put_xid(#666) ZERO @net/core/sock.c:920 1191239178 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.980340] vxD: put_xid(#666) ZERO @net/core/sock.c:920 1191239181 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.983566] vxD: put_xid(#666) ZERO @net/core/sock.c:920 1191239184 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.983655] vxD: put_xid(#666) ZERO @net/core/sock.c:920 1191239187 M * arekm Oct 1 13:44:36 193.239.45.150 kernel: [ 663.984968] vxD: put_xid(#666) ZERO @net/core/sock.c:920 1191239190 M * arekm Oct 1 13:44:37 193.239.45.150 kernel: [ 664.940824] vxD: put_xid(#666) val=-2 @kernel/posix-timers.c:335 1191239195 M * arekm (didn't crash yet :) 1191239203 M * Bertl yep, but that was just luck 1191239503 M * JonB * arekm (193.239.45.150) has quit (ping timeout) 1191239558 M * arekm I'm a ghost now. 1191239596 M * JonB arekm: BOOO 1191239750 A * JonB calls the GhostBusters, and Bertl answers 1191240082 M * Bertl arekm: okay, I think I found and fixed the task account error 1191240292 M * arekm waiting for a patch then 1191240316 M * Bertl yeah, but that won't help the issue, I'm trying to get some more debug info for the timer case 1191240369 M * Bertl let's have a short lunch break ... I need something to eat :) 1191240372 M * daniel_hozac ah 1191240378 M * daniel_hozac i see it, i think. 1191240388 M * daniel_hozac vxis.vxi is not the context we increment the use count for. 1191240388 M * Bertl the leader part is definitely problematic :) 1191240422 M * daniel_hozac we need to store the task_get_vx_info context, and decrement that use count. 1191240429 M * Bertl yep 1191240446 M * daniel_hozac (or did i already miss the patch that does this? :)) 1191240447 M * Bertl and we should be prepared to do that anew for the leader 1191240468 M * Bertl no, feel free to make one while I get something to eat :) 1191240625 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-timers-fix01.diff 1191240798 A * arekm applying that manually 1191240910 M * JonB arekm: bit by bit 1191240918 M * arekm http://pastebin.com/m5dbe5cee 1191240928 M * arekm leaving bertl debuging stuff there 1191240951 J * StOaN_ ~julius@p57B26E17.dip.t-dialin.net 1191240957 M * StOaN_ hiho 1191240961 M * JonB hi StOaN_ 1191241016 M * StOaN_ i read something about networking between guests by giving them private ip addresses 1191241044 M * daniel_hozac http://linux-vserver.org/Networking_vserver_guests 1191241058 M * StOaN_ merci beaucoup 1191241104 M * StOaN_ dummy interface. ok 1191241657 M * StOaN_ where can i define commands to run before my vserver starts? 1191241678 M * daniel_hozac see /etc/vservers//scripts on http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1191241906 M * brc Bertl there ? 1191241908 M * arekm [root@phobos ~]# cat /proc/virtual/vxrc 1191241908 M * arekm [0] 26 58 64 3 19 1191241908 M * arekm [154] 2 3 0 -3 0 1191241932 M * daniel_hozac can you get it to crash now? 1191241955 M * arekm no :) 1191241958 M * arekm still trying 1191242022 M * arekm tried about 20 times and doesn't crash, good 1191242149 M * arekm looks like it works :) 1191242298 M * daniel_hozac great! 1191242344 M * arekm thanks! :) now I can use something newer than 2.6.17 hehe 1191242353 M * arekm still wondering why only I was seeing this 1191242385 M * bzed arekm: probably because you're the first one with too much cpu power :P 1191242412 M * arekm bzed: 1 x sempron 1500 is too much power? ;) (reproduced here, too ;) 1191242438 M * Bertl brc: yep, back now 1191242463 M * bzed brc: he's @ lunch 1191242468 M * Bertl arekm: I think it was a combination of all kind of different things 1191242473 M * brc Good morning Bertl! 2 weeks ago i had a problem that ps would not work inside VPS 1191242489 M * brc Sent some info to someone on the channel, dontremember who it was 1191242493 M * Bertl arekm: the ntpd + drifting time retriggers the posix timers 1191242508 M * brc and was tol to wait for you but as i need it fixed (clients complaning) i did a reboot and everything was ok after the reboot 1191242512 M * brc now it is happening again 1191242517 M * Bertl brc: okay, what kernel/tools and was it fixed yet? 1191242529 M * brc 2.6.20.4-vs2.2.0-rc21 1191242530 M * bzed hmm, I may be wroing, but why does one want to run ntpd in a guest!? 1191242540 M * brc util-vserver-0.30.213 1191242554 M * brc ps output (insid vserver) shows nothing 1191242558 M * Bertl brc: please get a release version, not a release candidate 1191242577 M * StOaN_ nmy openvpn complains about a missing device node (/dev/net/tun0) but i created a tun device on the host and added it to the guest devices 1191242593 M * StOaN_ -devices +interfaces 1191242617 M * Bertl brc: I assume that is/was related to initpid disappearing, let me check where it was fixed 1191242630 M * JonB brc: patch-2.6.22.6-vs2.2.0.3.diff applies almost cleanly to vanilla 2.6.22.9 1191242636 M * Bertl StOaN_: there are no 'guest devices' 1191242652 M * Bertl StOaN_: did you make the tun0 persistant? 1191242659 M * JonB brc: 2 errors, which you can fix yourself by hand 1191242683 M * StOaN_ well 1191242684 M * Bertl note @all: there will be a new release for most branches shortly 1191242701 M * StOaN_ i used openvpn --mktun --dev tun0 1191242721 M * Bertl okay, that sounds reasonable, on the host, I presume? 1191242721 M * StOaN_ and copied the ifconfig and route configuration from the startup log 1191242721 M * daniel_hozac StOaN_: you still need /dev/net/tun inside the guest to allow OpenVPN to connect to the tun interface. 1191242736 M * brc Did not know it was alredy fix. what i find weird is that i have 2 other servers with some kernel and this issue never happened. going to do kernel upgrade 1191242747 M * StOaN_ so i have to copy it into the guest? 1191242752 M * JonB StOaN_: does the kernel know what to do with the tun interface? 1191242754 M * daniel_hozac StOaN_: yes. 1191242761 M * Bertl brc: give it a few hours, you should be able to upgrad to a new version then 1191242769 M * brc ok i am going to wait 1191242800 M * brc Is there anyway to get ps to work again without reboot ? 1191242801 M * Bertl daniel_hozac: we also want to consider that the leader is in a different context, no? 1191242819 M * daniel_hozac Bertl: hmm? 1191242823 M * Bertl brc: check if /proc still contains numeric entries 1191242842 M * brc it does 1191242843 M * Bertl brc: if that is so, try to enter/list /proc/1 on the host/guest 1191242871 M * brc auxv cwd exe maps mounts ninfo oom_score seccomp stat status vinfo 1191242871 M * brc cmdline environ fd mem mountstats oom_adj root smaps statm task wchan 1191242873 M * Bertl if it is what I assume it is, then this has a good chance to fix it :) 1191242912 M * daniel_hozac IIRC, brc's bug is strange in that cat /proc/*/status works fine. 1191242926 M * Bertl daniel_hozac: we start with the vx_info from timr->it_process is used 1191242937 M * daniel_hozac Bertl: ah, i see what you mean now, i missed that branch entirely. 1191242982 M * Bertl so I think we want to move the enter/leave down, and have a separate for the send_sigqueue 1191242989 J * Chr0nicles ~Primus_@a82-93-138-63.adsl.xs4all.nl 1191242996 M * Bertl welcome Chr0nicles! 1191243020 M * Chr0nicles Hi 1191243021 M * daniel_hozac well, in a way, i think it makes sense that only the process owning the timer's context is used. 1191243022 M * brc brc: What you mean by enter/list is just to: cd /proc/1 ; ls ; ? 1191243030 M * brc Bertl: What you mean by enter/list is just to: cd /proc/1 ; ls ; ? 1191243031 M * arekm thanks for patch, going to add that patch to all our kernels now 1191243037 J * hparker ~hparker@linux.homershut.net 1191243052 M * Bertl arekm: give it an hour or two, we'll have new releases then 1191243065 M * Bertl arekm: also testing with this patch on the 8way would be good 1191243080 M * Bertl (as I assume it has the best chances to trigger any issues) 1191243101 M * arekm will update it there, too 1191243106 M * Bertl arekm: and please leave us some info for your Hall'o'Fame entry 1191243147 M * Chr0nicles Question: Is there a known issue with vserver-utils trying to build a vserver? "segmentation fault?" 2.6.22.6 / 2.3.0.24 1191243158 M * arekm Arkadiusz Miskiewicz 1191243174 M * arekm see you on the next bug case :) 1191243179 P * arekm 1191243180 M * Chr0nicles i'm not sure what causes this behavior :/ 1191243233 M * JonB Chr0nicles: version? 1191243236 M * Bertl Chr0nicles: nope, no known issue, what util-vserver version do you use? 1191243267 M * Chr0nicles 0.30.214 1191243298 M * Bertl could you upload the output of 'vserver-info - SYSINFO' to paste.linux-vserver.org please? 1191243300 J * ema ~ema@rtfm.galliera.it 1191243310 M * Chr0nicles i wish it segaults too ;) 1191243352 M * Bertl that is interesting :) 1191243362 M * Bertl how did you get the tools? 1191243362 M * Chr0nicles i probably did something wrong updating kernel 1191243368 M * Chr0nicles because 2.6.22.1 worked fine 1191243375 M * Chr0nicles errm from source 1191243388 M * Bertl so you did build them yourself, now they segfault 1191243406 M * Chr0nicles Yes, but using same procedure 1191243408 M * Bertl do you use 64bit and maybe the tools are 32bit? 1191243416 M * Chr0nicles hmm gimme sec ;) 1191243418 M * Bertl (or the other way round) 1191243601 M * Chr0nicles nope both 32bits 1191243617 M * Chr0nicles i'll try distr pkg now 1191243620 M * Bertl what does 'ldd vserver-info' say? 1191243622 J * pmenier ~pmenier@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1191243708 M * Chr0nicles that i f* up 1191243721 M * Chr0nicles not a dynamic executable 1191243725 M * Chr0nicles hmm 1191243728 M * Bertl that is fine, actually 1191243770 M * daniel_hozac that means you got it right ;) 1191243777 M * Bertl maybe you did compile it with 686 asm codes, and now your kernel only supports 386 or so? 1191243871 M * Chr0nicles well i didn't add any extra build options just a plain ./configure make etc.. i'll look into that 1191243906 M * Chr0nicles trying if the dist pkg works. if it still fails i'll redo it from scratch and try to reproduce 1191243934 M * daniel_hozac what distribution? 1191243943 M * Chr0nicles ubuntu 1191243960 M * Bertl could be some hardened stuff then? 1191243977 M * Bertl i.e. stack protector issue 1191243993 M * daniel_hozac yeah. 1191244000 M * daniel_hozac Ubuntu's dietlibc is known broken. 1191244003 M * Chr0nicles ah 1191244024 M * Chr0nicles i'll try that from source too then (dietlibc) 1191244055 M * daniel_hozac make sure you get the latest version, i think that's supposed to be fixed wrt. the stack protector stuff. 1191244066 M * StOaN_ i think i just screwed up my server -.- 1191244074 M * daniel_hozac why's that? 1191244077 M * Bertl StOaN_: how so? 1191244078 M * Chr0nicles Cool thx for the advice ;) 1191244182 M * StOaN_ i guess device nodes created in the /dev/ directory of a guest survive a reboot of the host 1191244185 A * pmenier is AWAY at 15:13:10 : client au tel 1191244247 M * Bertl StOaN_: yes, they do 1191244483 Q * Piet Ping timeout: 480 seconds 1191244518 M * Bertl daniel_hozac: what patches do we have on hold for 2.2.x and for 2.0.x? (missing fixes and/or improvements)? 1191244762 M * daniel_hozac i've been meaning to go over that, i don't remember off hand. 1191244767 Q * StOaN_ Remote host closed the connection 1191244776 M * daniel_hozac has the loop device thing been fixed in 2.2 yet? 1191244787 M * Chr0nicles lsattr: Inappropriate ioctl for device While reading flags on X <-- now we are getting somewhere \o/ 1191244813 M * daniel_hozac uh, why are you using lsattr? 1191244816 M * Bertl daniel_hozac: this one? http://vserver.13thfloor.at/Experimental/delta-loop-fix01.diff 1191244819 M * daniel_hozac right 1191244847 M * Bertl nope, doesn't seem so 1191244851 M * Chr0nicles daniel: No idea but that's an error returning when using the distr pkg 1191244859 M * daniel_hozac really old version? 1191244890 M * daniel_hozac Bertl: the uid/gid copying on COW should probably be applied to 2.2 as well. 1191244892 A * pmenier is back after 0 d 0 h 11 m 47 s 1191244894 M * Chr0nicles now moving on to your dietlibc tip 1191244931 M * daniel_hozac other than that, i can't think of anything and the changelog doesn't have anything. 1191244946 M * JonB daniel_hozac: 'vserver ... suexec' is supported for running vservers only; aborting... - i get that alot when i try to install 4 guests in parallel. i also get 1 vcontext: vc_ctx_migrate(): Bad address 1191244986 M * daniel_hozac JonB: i guess that's expected, it's rather racy. it's better to build once, and clone that. 1191245001 M * daniel_hozac the Bad address looks weird though. 1191245026 M * daniel_hozac can you reproduce it? what host OS? 1191245036 Q * Aiken Quit: Leaving 1191245050 M * JonB host os is debian 1191245055 M * JonB guest os is also debian 1191245075 M * JonB i suppose i could try to built all 4 again in parallel? is that okay? 1191245082 M * JonB or just built that one ? 1191245094 M * Bertl JonB: do you specify an xid for each of them? 1191245110 M * daniel_hozac whatever you did to produce it is probably good for a first test. 1191245155 M * JonB Bertl: i dont think so vserver dksvn build -m debootstrap --hostname dksvn.laerdal.global --interface eth0:192.168.123.237/24 -- -d etch -m ftp://ftp.dk.debian.org/debian/ -- --resolve-deps --arch i386 1191245178 M * Bertl try with adding different --context entries for each 1191245181 M * daniel_hozac so you're using util-vserver 0.30.213+? 1191245211 M * JonB i do have a context.next file, but it appears to be incremented 1191245217 M * JonB 0.30.214-3 1191245233 M * JonB source built from sid to get 214 on etch 1191245245 M * Bertl just give it a try with explicit context numbers, could be a race issue 1191245259 M * daniel_hozac indeed, that's definitely racy. 1191245266 M * JonB Bertl: after i try reproducing it 1191245364 M * Bertl daniel_hozac: so we probably also want to move to splice for 2.6.22.9-vs2.2.x, no? 1191245383 M * daniel_hozac i was thinking about that, are we sure it works satisfactory yet? 1191245406 M * Bertl good question, haven't had any issues after the splice fix 1191245415 M * daniel_hozac me neither, i think we're good. 1191245430 M * daniel_hozac but i think it's still a bit too immature for stable. 1191245435 M * Bertl okay 1191245455 M * Bertl we definitely have to move for 2.6.23 once it is out 1191245462 J * Piet ~piet@tor.noreply.org 1191245479 M * daniel_hozac sure. 1191245566 M * matti Hi d_h ;) 1191245573 M * daniel_hozac hello matti 1191245824 M * Chr0nicles Thx for the advice :) dietlibc from source fixed it 1191245855 M * Bertl excellent! 1191245913 M * Chr0nicles updating wiki when i find an appropriate spot ;P 1191245925 M * Bertl yes, please do so 1191245957 M * daniel_hozac http://linux-vserver.org/Installation_on_Ubuntu 1191245994 M * Chr0nicles thx 1191246430 M * Bertl daniel_hozac: I'll apply the free-fix01 to vs2.2 kernels too as I consider it safe, but I will leave the mm changes in devel for now, does that sound fine? 1191246492 M * daniel_hozac yeah. 1191246518 M * JonB daniel_hozac: one of the builds was reproduced, the others are still running 1191246551 M * daniel_hozac Bertl: is http://people.linux-vserver.org/~dhozac/p/k/delta-cow-fix12.diff applied? 1191246582 M * daniel_hozac JonB: i'm not sure what that means. 1191246602 M * Bertl nope 1191246609 M * JonB daniel_hozac: a racy as you said. I will once this is done try to build one at a time 1191246648 M * daniel_hozac so you got the vcontext error again? 1191246663 J * Julius ~julius@p57B26E17.dip.t-dialin.net 1191246680 M * JonB not in the build that finished. The others are started a little later and was still running last time i checked 1191246710 M * JonB number 2 stopped as well 1191246762 M * JonB number 3 is stopped and it got vcontext: vc_ctx_migrate(): Bad address 1191246772 M * JonB but number3 did not get that error last time 1191246793 M * JonB building again, one at a time 1191247190 M * Darkglow Hi guys, I have noticed something odd when I install packages in Etch using apt-get... I get lines like these : "tar: ./md5sums: time stamp 2007-10-01 13:58:20.117304 is 0.000002 s in the future" I don't think it's a real problem, but maybe you already know how to fix it ;-) ? 1191247204 M * Darkglow (when I install in a vserver, of course ;-) 1191247206 M * Bertl your guest is on NFS? 1191247212 M * Darkglow nope 1191247232 M * Bertl interesting ... 1191247245 M * Darkglow I install on a mounted LVM volume tho... 1191247261 M * Bertl that shouldn't cause any time deviations 1191247268 Q * Julius Ping timeout: 480 seconds 1191247284 M * Bertl but 0.000002 sounds more like a rounding bug to me than a real issue 1191247284 M * Darkglow that's what I thought... but the derivation is *very* small... 1191247302 M * Bertl do you have ntpd or something like that active? 1191247305 M * Darkglow yeah, and I did not notice any other problem on other softwares... 1191247311 M * Darkglow hum.... :-) 1191247314 M * Darkglow let me check... 1191247338 M * Darkglow not on the guests... 1191247346 M * Bertl nah, on the host I mean ... 1191247364 M * Darkglow yes, openntpd 1191247379 M * Bertl okay, could you try if the issue remains if you disable it? 1191247402 M * Darkglow I will try. 1191247417 J * {KATRINA} ~MAGIX@modemcable013.216-200-24.mc.videotron.ca 1191247421 Q * {KATRINA} autokilled: This host violated network policy. Mail support@oftc.net if you have any questions. (2007-10-01 14:03:40) 1191247431 M * Bertl hehe :) 1191247462 M * JonB daniel_hozac: when running 1 vserver build alone i still get 'vserver ... suexec' is supported for running vservers only; aborting... 1191247495 M * brc What is the easiest way to "migrate" the config from an old kernel to a new one ? 1191247503 Q * Piet Ping timeout: 480 seconds 1191247512 M * JonB brc: copying .config? 1191247516 M * Bertl brc: copy it to the new one, and make oldconfig 1191247539 M * Bertl brc: but be careful, certain kernel config options change drastically across versions 1191247663 M * brc ok. i usually just copy .config from the old kernel to the new kernel directory but i noticed that lof ot options do not work. So i though i was doing something wrong 1191247703 M * brc Bertl, any news on quota on shared aprtitions? :) 1191247723 M * Bertl still not interesting enough for the broad public as it seems 1191247810 M * brc Don't know if i told you i succeed running CPanel inside vserver 1191247836 M * brc But i need one vserver per partition. not good :) 1191247902 M * Bertl well, if you feel like sponsoring the development, I should have some time at the end of the month :) 1191247995 M * brc hehe 1191248005 M * brc how much $$ ? :) 1191248011 J * Julius ~julius@p57B26E17.dip.t-dialin.net 1191248056 M * Bertl Pazzo: patch-2.6.20.20-vs2.2.0.4.diff was just uploaded 1191248072 M * Pazzo Thanks Bertl, you're great! 1191248126 M * Pazzo ?? 1191248128 M * Pazzo ähm 1191248150 M * Pazzo ooops... -> (is it "ehm" in englisch??) 1191248153 M * Pazzo :-) 1191248160 M * Pazzo can't find the file! 1191248174 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.20.20-vs2.2.0.4.diff 1191248196 M * Bertl the patches will get moved to the usual places when they are all there 1191248206 M * Pazzo thnx! 1191248308 M * Pazzo Patch successfully applied :-) 1191248638 Q * nebuchadnezzar Read error: Connection reset by peer 1191248641 J * nebuchad` ~nebu@zion.asgardr.info 1191248651 Q * matled Read error: Connection reset by peer 1191248710 J * matled ~matled@85.131.246.184 1191248828 J * igraltista ~jens@p4FD25FB1.dip.t-dialin.net 1191248844 M * Bertl wb matled! igraltista! nebuchad`! 1191249612 M * JonB Bertl: my hand editing of lock 1191249614 J * Punkie ~Punkie@87.236.192.11 1191249627 M * JonB fs/locks.c seemed to work, alt least it is running again 1191249683 M * pmenier Bertl: i'm testing patch-2.6.22.9-vs2.3.0.25 on amd64 : works fine. Do you want i make some tests ? 1191249713 M * Bertl yeah, with the 2.3.0.26 release (which should be out shortly) 1191249761 M * Bertl JonB: okay, you know there will be updated patches shortly? 1191249761 N * nebuchad` nebuchadnezzar 1191249792 J * dowdle ~dowdle@scott.coe.montana.edu 1191249800 M * Bertl wb dowdle! 1191249847 M * dowdle I don't like to be here unless I'm really here. 1191249865 M * Bertl np, but feel free to hang around :) 1191250002 Q * Punkie Quit: Odcházím 1191250010 Q * igraltista Read error: Connection reset by peer 1191250046 J * Punkie ~Punkie@87.236.192.11 1191250173 Q * JonB Ping timeout: 480 seconds 1191250185 Q * Punkie 1191250843 J * Punkie ~Punkie@87.236.192.11 1191250859 Q * arachnist Ping timeout: 480 seconds 1191251673 Q * ktwilight Ping timeout: 480 seconds 1191252576 M * Bertl okay, the vs2.2.0.4 kernels should be all up now, preparing the vs2.3.0.26 now 1191252786 J * arachnist arachnist@088156184167.who.vectranet.pl 1191253172 T * Bertl http://linux-vserver.org/ | latest stable 2.2.0.4, 2.0.3-rc3, devel 2.3.0.26, stable+grsec 2.0.2.1, 2.2.0.3 | util-vserver-0.30.214 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;) 1191253188 M * Bertl *2.2.0.4 and 2.3.0.26 1191253549 N * ensc Guest488 1191253559 J * ensc ~irc-ensc@p54B4E8D0.dip.t-dialin.net 1191253668 Q * Guest488 Ping timeout: 480 seconds 1191253995 J * ex ex@valis.net.pl 1191254003 Q * ex 1191254047 Q * Darkglow Ping timeout: 480 seconds 1191254108 Q * meandtheshell Quit: Leaving. 1191254307 J * JonB ~NoSuchUse@192.38.8.25 1191254533 M * igraltist hi 1191254555 M * igraltist i had try to start the X in the vguest but i get no device 1191254586 M * Bertl 'get no device' means? 1191254604 M * igraltist the graficcard are not there 1191254665 M * Bertl http://oldwiki.linux-vserver.org/Vservers+and+X 1191254674 M * igraltist i do also cp the lib/module/kernel_name to the the vguest but it say not find the nvidia driver 1191254717 M * Bertl you should not load kernel modules inside a guest 1191254733 M * Bertl (by default, you are not permitted to do so anyways) 1191254783 M * Bertl why do you want to run X11 inside a guest, btw? 1191254812 M * igraltist i like it :) 1191254815 M * igraltist no 1191254822 M * igraltist i have a gentoo hardend 1191254833 J * CWC ~CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg 1191254847 M * igraltist and now i am prepaer a normal gentoo without so many restriction 1191254874 M * Bertl well, you need to give certain capabilities to the guest (which will make it insecure) and you need to load kernel modules in advance 1191254927 M * igraltist this is on my desktop and only for more comfortable for me 1191254988 M * igraltist me cpu not support the vt technic and xen is me to much for this 1191255027 M * Bertl that's fine, check out the url above and do what is listed there, should work except for the kernel module load (which has to be done in advance) 1191255058 Q * yang Remote host closed the connection 1191255088 M * igraltist ok i have the url thx 1191255122 M * igraltist in the moment i must wait otherwise last time when i start X it shutdown my dektop 1191255140 M * Bertl interesting ... 1191255158 Q * eSa| Ping timeout: 480 seconds 1191255209 M * igraltist i mix up mayby something 1191255217 Q * CWC Quit: Client exiting 1191255317 M * igraltist he is building the firefox in the moment and this take a while 1191255409 M * igraltist i use the newer patch and with this the iface lo is automatic there, this is very nice 1191255426 M * igraltist so postfix do no feel disturbt anymore 1191255446 M * Bertl yeah, that's the idea of the lback remapping 1191255456 M * Bertl glad that it work fine for you 1191255748 M * bzed igraltist: you can clue postfix pretty easy to a non-loopback interface 1191255775 M * igraltist yes with the interface option 1191255801 M * igraltist but i like it only for the internal messages 1191255840 M * igraltist lo to have it simply pratical 1191255866 M * igraltist eg to bind mysql to it etc 1191255996 M * pmenier Bertl: ok for 2.6.22.9-vs2.3.0.26 : works fine, too. Just a question : i can't use ping within a guest. 1191256013 M * Bertl sure 1191256068 M * Bertl (means: yes you _can_ use ping within a guest :) 1191256095 M * pmenier doesn't work for me. Perhaps a mistake during configuration ? 1191256109 M * igraltist i can ping too 1191256110 M * Bertl what does it tell you, and what does 'ip addr ls' 1191256115 M * Bertl show inside the guest? 1191256143 M * pmenier it tells me : icmp open socket: Operation not permitted 1191256178 M * Bertl http://linux-vserver.org/Capabilities_and_Flags 1191256191 M * Bertl check that RAW_ICMP is configured for your guest 1191256206 M * Bertl (it should be on by default on recent util-vserver) 1191256310 J * morten ~hahnomat@a89-182-93-17.net-htp.de 1191256317 M * morten hello all ;-) 1191256327 M * Bertl wb morten! 1191256365 M * morten hi bertl.. how is it goin'? 1191256389 M * Bertl fine, thanks! and for you? 1191256422 M * morten all good... 1191256457 M * morten i'll migrate my current host into a vserver now, to get rid of my loopback problems ;-) 1191256490 M * morten so there's only one management port open on the host itself... 1191256553 M * Bertl sounds good 1191256595 M * morten this grsecurity thinggy... does it block "productive" calls/functions/... on the default install? never used it before... 1191256613 M * morten or does it just warn/alarm/log? 1191256638 M * Bertl don't know either, never really used it, but I guess harry will know (and he has some work to do anyway :) 1191256732 Q * Julius Ping timeout: 480 seconds 1191256795 M * morten never used before sounds like ... never needed it before :-) all my vservers/guests are maintained by trustworthy users... this thing looks like something you need when you want to offer vservers to people you don't personally know... like mass vserver providers 1191256859 M * Bertl well, definitely not, at least I never heard of any issues where grsec saved/helped a mass vserver provider ... 1191256877 M * Bertl if set up correctly, a Linux-VServer guest is considered secure 1191256905 M * Bertl if we get a report of some possible attack scenario, then we consider it a bug in the code and will fix it ASAP 1191256928 J * ktwilight ~ktwilight@19.92-66-87.adsl-dyn.isp.belgacom.be 1191256975 M * pmenier Bertl: sorry but can't find what bcaps or ccaps to add... 1191256987 M * Bertl pmenier: how so? 1191257024 M * pmenier i add RAW_ICMP in ccapabilities : can't ping 1191257047 M * morten i just saw that 2.6.22.9 is released ... anybody already tested if it works with the vs2.3.0.24 patch ? 1191257063 M * Bertl pmenier: and ping still complains that it cannot open an icmp socket? 1191257088 M * Bertl pmenier: did you restart the guest and did you check that it has this ccap? 1191257111 M * Bertl morten: I would suggest to use the 2.3.0.26 patch which is for this kernel :) 1191257119 M * pmenier yes of course. i stop the guest, add the ccaps and start it 1191257142 J * _jmcaricand_zzz ~jmcarican@d77-218-112-87.cust.tele2.fr 1191257147 M * Bertl daniel_hozac: what do you think of this one: http://vserver.13thfloor.at/Experimental/delta-cow-fix14.diff 1191257176 M * morten morten: where is it? in the svn? it's not in http://ftp.linux-vserver.org/pub/kernel/vs2.3/testing/ 1191257185 M * morten -morten +bertl :-) 1191257197 M * Bertl the usual place (i.e. where it gets uploaded first) http://vserver.13thfloor.at/Experimental/patch-2.6.22.9-vs2.3.0.26.diff 1191257226 M * morten ahh, i see.. thx 1191257240 M * Bertl you're welcome! 1191257254 J * Julius ~julius@p57B26E17.dip.t-dialin.net 1191257354 M * Bertl wb Julius! _jmcaricand_zzz! 1191257375 M * pmenier i put bcaps and ccaps in use : http://paste.linux-vserver.org/6817 1191257397 Q * hparker Ping timeout: 480 seconds 1191257455 M * Bertl pmenier: could you upload the output of 'cat /proc/virtual//status' too? 1191257466 M * pmenier ok 1191257551 M * pmenier http://paste.linux-vserver.org/6818 1191257601 M * Bertl that looks fine, your ping should work (unless it is somewhat broken) 1191257626 M * Bertl note that if you have several ips assigned to your guest, you might want to specify the one you are ping-ing as -I 1191257682 Q * JonB Ping timeout: 480 seconds 1191257696 M * pmenier just one ip on the guest... 1191257717 M * Bertl of course, if you ping uses raw sockets instead of icmp sockets, then it will not work (for security reasons) 1191257739 M * Bertl we had such pings but IIRC, they have been retired some time ago 1191257768 J * hparker ~hparker@linux.homershut.net 1191257846 M * pmenier Thks. I'll take a look tomorrow. I go home now. 1191257901 Q * pmenier Quit: pmenier 1191258071 M * daniel_hozac Bertl: right! good. 1191258089 M * daniel_hozac Bertl: (re: delta-cow-fix14) 1191258155 M * Bertl okay, so I will add that to the next round then :) 1191258257 M * morten is it possible to assign the host ip to a vhost? (yes, i now that's a little bit ugly... but i have my reason :-) ) 1191258285 M * Bertl yes, works perfectly fine, although you might want to consider S/DNAT for security reasons 1191258307 M * morten k, cool... 1191258328 M * derjohn morten, you need to set "nodev" in the interface config (or a vserver foo down will take down the host ....) 1191258336 M * morten S/DNAT .. yapp, i have to rework my fwscripts anyway 1191258354 M * morten foo down? 1191258403 M * Bertl what derjohn tries to warn of is that if you assign the host ip with a device to the guest, the tools will add/remove it on guest startup/shutdown 1191258420 M * morten ahhh 1191258420 M * morten i see 1191258422 M * morten :-) 1191258424 M * Bertl (which might be not what you want :) 1191258432 M * derjohn morten, sry, I meant "vserver stop". 1191258438 M * morten k, i'll set it to nodev 1191258447 M * morten k, thx 1191258700 J * esa ~esa@ip-87-238-2-45.adsl.cheapnet.it 1191258703 N * esa eSa| 1191258750 M * daniel_hozac Bertl: VXC_RAW_ICMP -> NXC_RAW_ICMP, no? 1191258923 M * Bertl for recent kernels, yes, indeed 1191258963 M * Bertl I guess the tools do take care of that too, no? 1191258986 Q * ema Quit: leaving 1191259343 M * daniel_hozac recent ones, at least. 1191259347 M * daniel_hozac i.e. 0.30.214. 1191259366 M * Bertl okay, so with a recent kernel and older tools there might be a problem, I guess 1191259425 M * daniel_hozac right. 1191259789 J * cehteh ~ct@pipapo.org 1191259848 M * bXi that nodev is just an empty file in the interface/?/ folder right? 1191259897 M * daniel_hozac yes. 1191260080 J * dna_ ~dna@p54BCDB76.dip.t-dialin.net 1191260329 Q * dna Ping timeout: 480 seconds 1191260357 J * Piet ~piet@tor.noreply.org 1191261070 M * bXi hah 1191261075 M * bXi vserver helped me find a bug in mc 1191261083 M * daniel_hozac mc? 1191261118 M * bXi midnight commander 1191261135 M * daniel_hozac how so? 1191261145 M * bXi i had a file with lo in it 1191261157 M * bXi it replaced the first l with some weird ascii sign 1191261178 M * bXi but only if i edit the file with mcedit starting inside mc 1191261432 Q * Punkie Quit: Odcházím 1191261486 Q * Pazzo Quit: ... 1191261782 J * dna ~dna@p54BCC58E.dip.t-dialin.net 1191262020 M * morten i've just installed my kernel for my new dedicated server in a co-location 400km away... looks like i missed some modules (normally i would guess something like sata-controller or fs).. but i'm pretty sure i got the right ones. i have a panic=20 appended .. so it automaticly reboots to the old kernel when the new one failed.... 1191262071 M * morten i'm missing a way to look on the console... you guys have any idea if theres a way to see into the last kernel boot output when the kernel doesnt even get disk access...? :-) 1191262089 M * daniel_hozac use net or serial console. 1191262134 Q * dna_ Ping timeout: 480 seconds 1191262163 M * morten i have nothing attached to the serial console... what do you mean by net when the bootup process dont even gets to the init process? :-D 1191262174 M * daniel_hozac netconsole. 1191262192 M * morten ahhh 1191262202 M * morten i see... i'll have a look into it :-) thx 1191262365 M * morten i'll try.. i'm not sure if it's the same vlan.. i guess not.. :-( 1191262428 J * JonB ~NoSuchUse@kg1-20.kollegiegaarden.dk 1191262451 M * morten ahh, i see it's also possible when it's not on the same lan by giving netconsole the mac of the router... clever clever :D 1191262473 M * daniel_hozac yep. 1191263541 J * ema ~ema@rtfm.galliera.it 1191263799 J * virtuoso_ ~s0t0na@ppp91-122-160-196.pppoe.avangard-dsl.ru 1191263870 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33 1191263899 M * Ashsong_ Bertl: ping 1191263904 N * Ashsong_ Ashsong 1191263909 N * Ashsong m_stone 1191263923 M * Bertl m_stone: pong! 1191263934 M * m_stone I have a few questions about your patch. 1191263942 M * m_stone vsOLPC-0.4.5 1191263947 M * Bertl let's hear 1191263974 M * m_stone 1) it changes the sendpage mechanism over to splice 1191263980 M * m_stone JFFS2 does not appear to implement splice 1191264017 M * Bertl hmm, should I have overlooked that? 1191264025 M * m_stone Inspection of fs/splice.c indicates that attempting to splice when a FS's file_operations struct gives no info, will fail with -EINVAL 1191264060 M * m_stone this is do_splice_to in fs/splice.c 1191264075 M * m_stone Question 2) 1191264109 M * m_stone The changes in cow_break_link (other than the specific permissions fix we requested) appear to consist of detecting errors earlier and cleaning up intermediate results. 1191264126 M * m_stone is this correct? 1191264136 M * Bertl yes 1191264136 M * m_stone If so, do any of these error cases occur in practice? 1191264142 M * daniel_hozac yes. 1191264174 M * daniel_hozac i've managed to hit a number of them, and then it's easier to just fix them all... 1191264208 Q * virtuoso Ping timeout: 480 seconds 1191264213 Q * jmcaricand Remote host closed the connection 1191264222 M * Bertl m_stone: there will be a follow up patch shortly, which will include the generic_splice hooks for jffs2 1191264228 P * _jmcaricand_zzz Time makes no sense 1191264239 J * |jmcaricand|_ ~jmcarican@d77-218-112-87.cust.tele2.fr 1191264240 M * m_stone Bertl: okay. In the mean time, we're trying to get Trial-3 out the door very soon. 1191264249 M * Bertl m_stone: I somehow assumed that all fs maintainers have updated to splice by now 1191264264 M * Bertl (after all, it's there since 2.6.19) 1191264279 M * m_stone Bertl: is it okay if we backport the permissions fix to our trial-3 branch and finish your new features after that release is made? 1191264300 M * Bertl sure you can do whatever you like :) 1191264317 M * Bertl note that the patches for olpc all fix known issues 1191264343 M * Bertl and you probably want to add the following too: 1191264394 M * Bertl http://people.linux-vserver.org/~dhozac/p/k/delta-timers-fix01.diff 1191264401 M * m_stone Bertl: (I was asking this way because dilinger is rather overwhelmed by power-management investigations) 1191264435 M * Bertl well, most of the patches should be in the kernel since a month now :) 1191264469 M * Bertl but I'm fine with going through them with you once again if you like 1191264547 M * m_stone Bertl: what does delta-timers-fix01.diff fix? 1191264560 M * Bertl a problem with the refcounting 1191264574 M * Bertl (which can lead to a kernel panic :) 1191264650 M * Bertl we were searching for that one for a few days now, finally nailed it today 1191264817 M * Bertl m_stone: http://vserver.13thfloor.at/Experimental/delta-jffs2splice-fix01.diff (please let me know if that works for you) 1191265019 M * m_stone Bertl: what does changing the return code in splice do? 1191265034 M * m_stone i.e. changing the test from < 0 to <= 0? 1191265070 M * daniel_hozac fixes an infinite loop problem in the splice code. 1191265076 M * Bertl that is a mainline fix done my jens axboe 1191265080 M * daniel_hozac IIRC, that's already fixed in 2.6.22.9. 1191265108 M * m_stone thanks. 1191265207 M * m_stone in i/l/vs/base.h, in nx_info_ncaps, the n is not fully parenthesized. 1191265245 M * m_stone same in nx_info_flags and nx_info_state 1191265311 M * Bertl what do you mean? 1191265386 M * m_stone compare the parenthesization of #define __nx_flags(n) ((n) ? (n)->nx_flags : 0) to 1191265411 M * m_stone vs_check_flags(__nx_flags(n), m, f) 1191265458 M * Bertl m_stone: that is how preprocessing works 1191265499 M * Bertl #define macro(a,b) other_macro(a) + other_macro(b) is fine 1191265503 M * Bertl but 1191265514 M * Bertl #define macro(a,b) a + b is not 1191265524 M * Bertl you need to make that: 1191265535 M * Bertl #define macro(a,b) (a) + (b) 1191265698 M * m_stone thanks for the explanation. 1191265713 M * Bertl np 1191265729 M * daniel_hozac shouldn't it be (m), (f) though? 1191265736 M * Bertl no 1191265754 M * Bertl if an argument is passed as argument, it will be passed atomic 1191265758 M * Bertl *atomicly 1191265943 M * m_stone can you explain the ipv4 changes? 1191265959 M * m_stone what's the purpose in making ip an array with two elements? 1191266001 M * Bertl that is necessary to handle ranges properly in regard of the network (mask) 1191266024 M * Bertl we first assumed that it would be enough to have two ips (ip and mask) for a range 1191266038 M * m_stone so formerly that upper extent of the range was stored in the mask field? 1191266049 M * Bertl but that is not true when it comes to network checks, which require the mask too 1191266053 M * Bertl yes 1191266063 M * m_stone okay, that makes sense. thanks. 1191266064 M * Bertl note that ranges are not really used yet 1191266070 M * m_stone Yeah, I'd noticed. 1191266079 M * Bertl (so you can postpone this change if you like) 1191266193 M * m_stone what are the nx_map_sock_lback() calls in the ipv4 stack? 1191266220 M * daniel_hozac disguising the lback address as 127.0.0.1. 1191266264 M * Bertl basically this allows a guest to have a 'private' 127.0.0.1 1191266284 M * Bertl (which actually is a 127.x.y.1 :) 1191266308 M * m_stone nifty. 1191266315 M * michal_ smart :> 1191266335 M * michal_ so the actual limit on vserver guest is 255*255? 1191266354 M * daniel_hozac 65535 has always been the limit. 1191266355 M * m_stone are the aio changes also backports from recent upstream trees? 1191266366 M * michal_ daniel_hozac: sounds like enough :) 1191266390 M * daniel_hozac m_stone: if you're talking about the hunks i think you're talking about, those are reverts to upstream. 1191266396 M * michal_ 65535 guests if good for everyone ;) 1191266417 M * daniel_hozac (since we no longer need the sendfile-to-files modification) 1191266422 M * m_stone daniel_hozac: I'm looking at the ones in mm/filemap.c 1191266428 M * daniel_hozac right. 1191266508 M * m_stone okay, thanks. 1191266524 M * m_stone So we need to continue carrying those until we move CoW over to use splice(). 1191266574 M * Bertl m_stone: the patch above should add the splice for jffs2 1191266580 M * m_stone I saw 1191266590 M * m_stone Bertl: I'm just making sure I understand the hunk dependencies. 1191266597 M * Bertl okay, np 1191266603 M * m_stone Also, I was recently bitten by filesystem tagging again. 1191266621 M * m_stone Our filesystems are still being mounted "defaults, noatime", so, as I understand it, tagging is supposed to be off. 1191266636 M * daniel_hozac you can use notagcheck with recent kernels. 1191266636 M * Bertl yep, with the fix we did for jff2 1191266653 M * Bertl *jffs2 1191266655 M * daniel_hozac (which disables the tag checking) 1191266666 J * Darkglow ~pdesnoyer@208.71.184.41 1191266667 M * Bertl daniel_hozac: not in olpc kernels IIRC 1191266673 M * daniel_hozac ah, okay. 1191266694 M * Bertl m_stone: and, what unexpected behaviour did you see? 1191266720 M * Darkglow Hi guys... any reasons why a program would run slower in a vserver ? in this case, spamassassin runs in 5 seconds in vserver and 1.9 outside (on the host)... 1191266746 M * Bertl Darkglow: maybe you have CPU limits set for the guest? 1191266761 M * Bertl Darkglow: maybe the data it operates on is completely different? 1191266766 J * kir_home ~kir@81.5.110.169 1191266786 M * Bertl wb kir_home! 1191266804 M * Darkglow I know it's quite vague... Im still searching... I have no cpu limits... only dlimits. Would data on a unified volume be slower to access ? 1191266831 M * Bertl Darkglow: nope 1191266833 M * daniel_hozac it should be faster. 1191266843 M * Bertl if it was already cached, yes 1191266869 M * m_stone Bertl: the fix you suggested was bundled into commit http://dev.laptop.org/git?p=users/mstone/olpc-2.6;a=commit;h=ac05d6da05fb5e4c9fd2754477de0ccb6a533f78 1191266873 M * m_stone ? 1191266888 M * m_stone ack, wrong link. 1191266893 M * Darkglow Ok, I will continue my investigation... :( thanks 1191266905 M * m_stone http://dev.laptop.org/git?p=users/mstone/olpc-2.6;a=commit;h=25d0ef5920781156470a1948e28166b2d2ddc24b 1191266957 M * Bertl no, that one is for the remount 1191266995 M * Bertl http://vserver.13thfloor.at/Experimental/delta-jffs2tag-fix01.diff 1191267004 M * Bertl this is the one which fixes the tagging 1191267029 M * m_stone ah, thanks. 1191267094 M * Bertl (which is also in vsOLPC-0.4.5, if I'm not completely wrong :) 1191267147 M * Bertl or maybe not? 1191267161 M * m_stone I don't see it there. 1191267163 M * Bertl it was definitely in the branch we did 1191267180 M * m_stone Bertl: I remember seeing the patch, but I don't see it in the branch. 1191267183 M * m_stone Checking the actual code. 1191267265 M * m_stone http://dev.laptop.org/git?p=users/mstone/olpc-2.6;a=blob;f=fs/jffs2/fs.c;h=ccfd46801cda045302c7856f27f6d15f06dfeadf;hb=2de2a3c51c61d04b257beaa8dde02a30521374d5#l145 1191267276 M * m_stone It apparently did not get merged while you were here, even into my personal tree. 1191267282 M * m_stone Though I definitely saw the patch. 1191267315 M * Bertl well, we tested it on an X0, you remember :) 1191267317 M * m_stone indeed, the patch is still sitting in /opt/GIT/ 1191267322 M * m_stone Bertl: so I recall. 1191267339 M * morten hmm, netconsole worked for me... my provider also installed a remote-vga-console... 1191267342 M * morten warning: unable to open an initial console ... hmm 1191267349 M * Bertl m_stone: but yeah, my fault, I assumed that to be history already 1191267390 M * Bertl morten: some devices are likely missing (maybe in the initramfs) or some console drivers 1191267414 M * morten i got no initramfs, i have all i need in the kernel (modules,...) 1191267420 M * Bertl m_stone: will prepare an OLPC-0.4.6 tonight 1191267427 M * morten i've created /etc/console etc... 1191267439 M * Bertl morten: /dev/* :) 1191267456 M * m_stone Bertl: thanks. 1191267461 M * Bertl morten: usually those are created by udev nowadays ... 1191267463 M * morten rsynced /dev/ from a rescue system 1191267499 M * Bertl m_stone: I'm relocating now (moving to the other place) but should be back in an hour and a half ... 1191267515 M * morten hm, devfs is not a option anymore? hmmm 1191267553 M * Bertl m_stone: patch should be done an hour after that ... is there an up-to-date GIT branch now or should I just assume the old one is current? 1191267563 M * JonB http://xkcd.com/138/ 1191267579 M * Darkglow I get the same "slow" behavior with dpkg -l... but I don't have this on another server with vservers without unification... can I disable unification easily ? 1191267631 M * Bertl Darkglow: yes, should be simple, IIRC, there is even a tool/script for that, but a brute force copy of the guest data (or touch) should do the trick 1191267640 M * Bertl off now ... back later ... 1191267646 N * Bertl Bertl_oO 1191267647 M * m_stone Bertl: take care. 1191267836 M * m_stone daniel_hozac: am I correct that link-breaking only applies to file-like inodes and does not apply to directories? 1191267843 M * daniel_hozac yes. 1191267847 M * m_stone good. 1191267968 M * m_stone daniel_hozac: then what semantics are given to directories that have the U and I flags set? 1191267977 M * daniel_hozac none. 1191267984 M * m_stone e.g. by running setattr -R --iunlink 1191267985 M * daniel_hozac i.e. unspecified. 1191267993 M * m_stone hmm. 1191267996 Q * JonB Quit: This computer has gone to sleep 1191268011 M * daniel_hozac i honestly don't know what happens, i'd expect the directories to become immutable. 1191268018 M * m_stone hmm. 1191268038 M * m_stone okay, so we should avoid setattr -R and only call setattr on the exact files we want to be CoW? 1191268101 M * daniel_hozac right. 1191268107 M * m_stone hmm. 1191268113 M * daniel_hozac regular files are the only ones for which COW works. 1191268140 M * m_stone daniel_hozac: I know that; the question was whether having the I and U flags set on directories was going to do anything bad 1191268140 M * daniel_hozac so find -type f -print0 | xargs -0 setattr --iunlink is probably best. 1191268147 M * m_stone The answer appears to be "we don't know." 1191268152 M * m_stone right. 1191268158 M * daniel_hozac well, the directory is going to be immutable. 1191268164 M * m_stone daniel_hozac: it appears not to be. 1191268181 M * daniel_hozac meaning you can create new files? 1191268197 M * m_stone yes. 1191268222 M * m_stone And chmoding the directory succeeds. 1191268228 M * m_stone (It also removes the I and U attribtues). 1191268259 M * daniel_hozac hmm... that is... odd... 1191268341 M * m_stone true immutable directories, e.g. with I but with ~U appear to be correctly immutable. 1191268417 J * arekm arekm@carme.pld-linux.org 1191268421 A * arekm is back again 1191268461 M * arekm http://pastebin.com/m7bdcd02f 1191268492 M * arekm isn't 127.0.0.1 supposed to be internally replaced with first ip assigned to guest? 1191268528 M * daniel_hozac no, it's replaced with the lback address. 1191268585 M * arekm what do you mean by "loopback address" ? 1191268639 M * daniel_hozac in 2.3, each guest has it's own lback address to which connections/binds to 127.0.0.1 are rewritten, and that address is in turn rewritten back to 127.0.0.1 when userspace asks. 1191268665 M * daniel_hozac note: that is with CONFIG_VSERVER_AUTO_LBACK. without it, you'll have to set the address yourself. 1191268689 M * arekm not set here, thanks 1191269049 M * arekm zbyniu tells me that it can be turned on via flag without need to use CONFIG_VSERVER_AUTO_LBACK=y, correct? 1191269069 M * daniel_hozac what? 1191269381 M * arekm daniel_hozac: can auto_lback be set via flags on per vserver basis? 1191269415 M * daniel_hozac CONFIG_VSERVER_AUTO_LBACK is a convenience option, it handles it automatically. 1191269443 M * daniel_hozac you can set remap_lback and hide_lback in nflags, and set the lback address with /etc/vservers//interfaces/lback 1191269488 M * arekm can I turn on auto_lback for single vserver if kernel has # CONFIG_VSERVER_AUTO_LBACK is not set? 1191269515 M * daniel_hozac if you do what i said above, you'll achieve the same effect. 1191269532 M * arekm I know. Asking if there is special flag for that 1191269546 M * arekm without need to manually play with address etc 1191269569 M * daniel_hozac well, if you say no to the automatic one, you of course have to do it manually.. 1191269625 Q * DavidS|Wien Quit: Leaving. 1191269644 M * arekm that wasn't so obvious :-) there always could be special flag to turn such thing on (on per guest basis) 1191269655 M * arekm thanks, rebuilding kernel :) 1191269758 Q * hparker Quit: Quit 1191269797 P * arekm 1191270305 J * hparker ~hparker@linux.homershut.net 1191271019 J * Punkie ~Punkie@home.pekelny.net 1191271121 J * Aiken ~james@ppp121-45-249-108.lns2.bne4.internode.on.net 1191272307 Q * Julius Remote host closed the connection 1191272729 M * morten bye guys.. see you soon :-) 1191272758 Q * morten 1191272871 Q * Darkglow Remote host closed the connection 1191274504 Q * dna Quit: Verlassend 1191274815 Q * bonbons Quit: Leaving 1191275799 Q * ema Quit: leaving 1191275989 Q * Piet Remote host closed the connection 1191276142 J * Piet ~piet@tor.noreply.org 1191276301 N * eSa| fede 1191276613 Q * kir_home Ping timeout: 480 seconds 1191277238 N * Bertl_oO Bertl 1191277245 M * Bertl back now ... 1191277683 M * bzed wb Bertl ;) 1191279722 Q * Piet Quit: Piet 1191282622 Q * Johnnie Ping timeout: 480 seconds 1191282903 Q * dowdle Remote host closed the connection 1191283164 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa