1303085464 J * ce_lagi_telanjang_pgn_cs ~BigEars@mail.sanmeidd.com
1303085464 Q * ce_lagi_telanjang_pgn_cs autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:04)
1303085465 J * c0_dws_cr_c3 ~VegePat29@ool-4572c7ef.dyn.optonline.net
1303085465 Q * c0_dws_cr_c3 autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:05)
1303085467 J * RUD1 ~Co20_4_Pr@112.204.149.141
1303085467 Q * RUD1 autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:07)
1303085469 J * pretty_Nice ~CO_BuNCiT@110.139.56.64
1303085469 Q * pretty_Nice autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:09)
1303085469 J * mandira ~KORCH-awa@110.137.185.9
1303085470 Q * mandira autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:09)
1303085475 J * ripcord ~Oki_jie@182.23.8.42
1303085475 Q * ripcord autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:11:15)
1303085932 N * Bertl_zZ Bertl
1303085942 M * Bertl back now ...
1303086348 J * ktwilight_ ~keliew@91.176.161.63
1303086424 J * cow_ol_dikantor ~cE-cHuBby@118.96.30.22
1303086424 Q * cow_ol_dikantor autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:27:04)
1303086431 J * Tav ~ceti_reni@173-27-51-159.client.mchsi.com
1303086431 J * bigbootylver ~doel@c-71-231-201-110.hsd1.wa.comcast.net
1303086431 Q * Tav autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:27:11)
1303086431 Q * bigbootylver autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:27:11)
1303086645 Q * ktwilight__ Ping timeout: 480 seconds
1303087544 J * CO_HOTZ_BGT ~pretty_Ni@220.189.227.2
1303087544 Q * CO_HOTZ_BGT autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:45:44)
1303087549 J * Male-Seek-SugarBabe ~ce_kece@c-98-203-110-99.hsd1.fl.comcast.net
1303087549 J * f-cantik ~asian_fac@h243.30.49.24.cable.unassigned.jetbroadband.com
1303087549 Q * Male-Seek-SugarBabe autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:45:49)
1303087549 Q * f-cantik autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:45:49)
1303087554 J * Noe ~fida_jele@83.246.217.53
1303087554 Q * Noe autokilled: Spammer - Contact support@oftc.net for help. (2011-04-18 00:45:54)
1303089621 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com
1303090483 Q * FireEgl Ping timeout: 480 seconds
1303102382 J * FireEgl FireEgl@2001:470:e056:1:7c62:29a7:b3bf:7ecf
1303104136 Q * FireEgl Remote host closed the connection
1303104663 M * Bertl off to bed now ... have a good one everyone!
1303104667 N * Bertl Bertl_zZ
1303106407 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1303107314 J * derjohn_mob ~aj@d003099.adsl.hansenet.de
1303107884 J * ncopa_ ~ncopa@3.203.202.84.customer.cdi.no
1303108342 Q * ncopa Ping timeout: 480 seconds
1303108941 Q * derjohn_mob Ping timeout: 480 seconds
1303109338 J * ghislain ~AQUEOS@adsl2.aqueos.com
1303110488 Q * ncopa_ Ping timeout: 480 seconds
1303110499 J * ncopa_ ~ncopa@ti0143a340-0488.bb.online.no
1303112249 J * derjohn_mob ~aj@213.238.45.2
1303112416 J * petzsch ~markus@dslb-088-075-170-205.pools.arcor-ip.net
1303114384 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com
1303115024 Q * petzsch Quit: Leaving.
1303121431 Q * SwenTjuln Ping timeout: 480 seconds
1303121549 J * SwenTjuln ~SwenTjuln@77.111.2.36
1303122485 Q * SwenTjuln Ping timeout: 480 seconds
1303123379 J * SwenTjuln ~SwenTjuln@77.111.2.36
1303123593 Q * quasisane Read error: Operation timed out
1303124149 J * s0undt3ch s0undt3ch@80.69.34.153
1303124816 N * ncopa_ ncopa
1303133665 N * Bertl_zZ Bertl
1303133671 M * Bertl morning folks!
1303137297 J * dowdle ~dowdle@scott.coe.montana.edu
1303139695 Q * FireEgl Ping timeout: 480 seconds
1303139880 Q * s0undt3ch Remote host closed the connection
1303140022 J * s0undt3ch s0undt3ch@80.69.34.153
1303142004 Q * derjohn_mob Ping timeout: 480 seconds
1303144696 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1303144789 J * petzsch ~markus@dslb-088-075-170-205.pools.arcor-ip.net
1303144798 Q * BenG 
1303146092 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com
1303146342 J * bonbons ~bonbons@2001:960:7ab:0:90c9:d9bf:d5b9:24b8
1303147342 Q * s0undt3ch Remote host closed the connection
1303151487 Q * FireEgl Read error: Connection reset by peer
1303152027 J * manana ~mayday090@84.17.25.149
1303152420 J * FireEgl FireEgl@2001:470:e056:1:e1b0:af31:59c5:c484
1303153298 J * derjohn_mob ~aj@d003099.adsl.hansenet.de
1303155922 J * derjohn_foo ~aj@d025137.adsl.hansenet.de
1303156361 Q * derjohn_mob Ping timeout: 480 seconds
1303158564 J * frank\ 4fd5b053@ircip1.mibbit.com
1303158574 M * frank\ hellos....
1303158621 M * frank\ just noticed that the 'testme.sh' script now suddenly gives an error in recent 2.6.38.x kernels
1303158657 M * frank\ ( did work fine with Linux 2.6.37-vs2.3.0.37-rc2 )
1303158661 M * daniel_hozac what's the error?
1303158690 M * frank\ subtest 011
1303158696 M * frank\ mom - need to reboot again =)
1303158729 M * frank\ it somehow fails doing this 'chcontext --secure $SID $UXID mknod $tmpdir/node c 0 0'
1303158961 M * frank\ hm hm hm
1303158989 M * frank\ guess I'll paste complete debug output of testme.sh into pastebin
1303159020 M * daniel_hozac paste .config while you're at it.
1303159126 M * frank\ http://paste.linux-vserver.org/19245
1303159140 M * frank\ 011 is fine - 001 is failing
1303159145 M * frank\ my mistake
1303159184 M * frank\ util-vserver is '0.30.216-pre2955'
1303159378 M * frank\ .config didn't change that much between my builds (merely a make oldconfig + some debug enabled where I can control it via sysctl + new drivers)
1303159500 Q * manana Remote host closed the connection
1303159706 Q * bonbons Quit: Leaving
1303159988 Q * derjohn_foo Ping timeout: 480 seconds
1303160045 M * frank\ hehe - can't post .config using pastebin because pastebin says 'Your post could not be processed. It looks like spam.' ;)
1303160077 M * cehteh haha
1303160113 M * cehteh you have a webserver where you can put it?
1303160150 M * frank\ sure - yeah
1303160153 M * frank\ good idea
1303160422 M * frank\ wtf - the error is gone...?!
1303160526 M * frank\ I just was like - hey wait a second - because the webserver is the very same kernel .config (only difference is that it's for 32bit) and just noticed that the failure doesn't appear on 32bit
1303160582 M * frank\ so I went back to the 64bit host - rebooted this specific kernel... and the failure is gone...
1303160614 M * frank\ .oO someone stole my error :/
1303160907 M * frank\ or wait - the failure is back
1303160916 M * Bertl hmm?
1303160939 M * frank\ I'll reboot again
1303160973 M * frank\ I suspect that the failure comes when I run the testme.sh a second time (if this even makes sense - sounds silly)
1303161000 M * Bertl which testme.sh version? latest?
1303161026 M * frank\ 'Linux-VServer Test [V0.17] Copyright (C) 2003-2006 H.Poetzl' - guess this is latest , isn't it?
1303161048 M * Bertl looks good, run it with -vvv and upload the output
1303161269 M * frank\ http://paste.linux-vserver.org/19246
1303161307 M * frank\ this was after a clean reboot
1303161452 M * frank\ it does fail now in 001 in subsequent runs
1303162220 M * frank\ I can at least confirm that this issue doesn't hit me on 32bit
1303162557 M * frank\ kernel .configs are available:
1303162588 M * frank\ http://213.211.192.143/32bit--config-2.6.38.2-vs2.3.0.37-rc10   /    http://213.211.192.143/64bit--config-2.6.38.2-vs2.3.0.37-rc10
1303162920 M * Bertl that looks like a race condition (maybe in util-vserver?) could you try with a more recent util-vserver and maybe the up-to-date patch for 2.6.38.3?
1303162958 M * frank\ but 0.30.216-pre2955 should be latest - or?
1303162979 M * frank\ both hosts run 0.30.216-pre2955
1303163000 M * Bertl hmm, yeah, seems to be latest ... daniel_hozac?
1303163083 M * frank\ I'm rebooting the 64bit host into 2.6.38.3 + it's vserver patch
1303163099 Q * petzsch Quit: Leaving.
1303163392 M * frank\ 2.6.38.3-vs2.3.0.37-rc14 +  0.30.216-pre2955 gives the same... first run with failure in 011 / second and subsequent runs with failure in 001
1303163451 M * Bertl can you do both runs with -vvv and upload them again?
1303163687 M * frank\ sure - just a minute
1303163889 M * frank\ erm - ffs - again...
1303163903 M * frank\ not yet pasted - but completely different result
1303163914 M * frank\ unfortun. without -vvv :/
1303163930 M * frank\ first run ok - second and subsequent runs with failure in 001
1303163934 M * frank\ I reboot again
1303164331 M * frank\ ok - here we go -> http://paste.linux-vserver.org/19247
1303164342 M * frank\ 4 runs with -vvv after a clean reboot
1303164745 M * Bertl could you also upload `vserver-info - SYSINFO' please?
1303164767 M * frank\ another reboot -> http://paste.linux-vserver.org/19248   (first run - no failure / all other runs with failure in 001)
1303164837 Q * ghislain Quit: Leaving.
1303164858 M * frank\ http://paste.linux-vserver.org/19249 -> vserver-info SYSINFO
1303164879 M * Bertl the thing is, I cannot really recreate the issue here .. I just tried on a 2.6.38.2-vs2.3.0.37-rc10, which is what you had before, with no success so far
1303164900 M * frank\ 32bit or 64bit?
1303164925 M * Bertl 64bit
1303164926 M * frank\ as stated above - I can't even reproduce this on 32bit - only on 64bit
1303164930 M * frank\ ah ok
1303164974 M * frank\ puzzles me as well - because I don't see any significant differences between my 32/64 bit kernel config
1303165010 M * Bertl it definitely looks like a race condition
1303165051 M * Bertl i.e. something makes the context disappear or dissolve just before the command gets executed
1303165074 M * Bertl any unusual config options or system/security settings?
1303165081 M * frank\ not that I know off
1303165105 M * frank\ just my plain/usual .config I use since ages
1303165131 M * frank\ I just recheck manually with make menuconfig each option after major release jumps
1303165147 M * frank\ so like when it went from 2.6.37.x to 2.6.38.x
1303165177 M * Bertl do we have an uploaded version of that .config now somewhere?
1303165177 M * frank\ no problems doing so since ages
1303165215 M * frank\ yes - above in the chatlog here - I've uploaded them to a host of mine
1303165229 M * Bertl ah, okay
1303165266 M * frank\ besides that - I could grant you access to a host where it happens
1303165333 M * frank\ this is just a plain debian squeeze with just this kernel
1303165429 M * Bertl no need (yet)
1303165466 M * Bertl what if you execute the following command in a shell
1303165478 M * Bertl chcontext --secure --xid 45678 mknod /tmp/node c 0 0
1303165545 M * frank\ New security context is 45678 mknod: `/tmp/node': Operation not permitted
1303165573 M * Bertl okay, that's the expected response, what if you execute that in a loop?
1303165614 M * frank\ btw. /tmp is not in it's own partition with weird mount options that could prevent creating nodes inside
1303165667 M * Bertl as I said, the EPERM is perfectly fine there, i.e. it is intentional
1303165679 M * frank\ ah
1303165698 M * Bertl your uploaded run OTOH, gives ESRCH, and vspace: vc_enter_namespace(): No such process
1303165717 M * Bertl what version is the bash, btw?
1303165764 M * frank\ debian lenny default -> GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu)
1303165814 M * Bertl so rather new ... maybe it tries to be smart or debian folks just enabled some 'strange' stuff
1303165836 M * Bertl let's see what the following bash command does:
1303165884 M * frank\ but on the other hand - running a pre 2.6.38 kernel doesn't give this failure
1303165917 M * Bertl bash -c 'chcontext --xid 45678 egrep "context|VxID" /proc/self/status; chcontext --secure --xid 45678 true'
1303165950 M * frank\ New security context is 45678 VxID: 45678 vspace: vc_enter_namespace(): No such process
1303165977 M * Bertl bingo
1303165989 M * Bertl now let's change that to
1303165995 M * frank\ this 'vspace: vc_enter_namespace(): No such process' comes up as well when I run my loop without a little sleep
1303166004 M * Bertl bash -c 'chcontext --xid 45678 egrep "context|VxID" /proc/self/status; wait; chcontext --secure --xid 45678 true'
1303166014 M * frank\ when running the loop with sleep 1 it won't appear
1303166066 M * frank\ New security context is 45678 VxID: 45678 vspace: vc_enter_namespace(): No such process
1303166111 M * Bertl so it isn't a separate process started by the bash, but the context stays around long enough to cause that collision
1303166116 M * frank\ I did 'while true; do chcontext --secure --xid 45678 mknod /tmp/node c 0 0; sleep 1; done' ==> NO 'vspace: vc_enter_namespace(): No such process' error
1303166127 M * Bertl let's strace -fF the first bash -c and upload the output
1303166140 M * frank\ but without sleep at all it gives 'vspace: vc_enter_namespace(): No such process'
1303166166 M * Bertl okay, then let's try the following much simpler bash c
1303166196 M * Bertl bash -c 'chcontext --xid 45678 true; chcontext --xid 45678 true'
1303166215 M * Bertl I presume that will cause the same error message
1303166232 M * frank\ yup
1303166232 M * frank\ New security context is 45678 vspace: vc_enter_namespace(): No such process
1303166253 M * Bertl okay, good, let's strace -fF -o bash.trace bash -c ...
1303166279 M * Bertl (where ... is the '' part just tested)
1303166403 M * frank\ this gives a couple of bash.trace.xxx files
1303166419 M * Bertl okay, please upload them
1303166469 M * frank\ can grab their output from stdout as well - or do you need the plain files?
1303166497 M * Bertl doesn't really matter
1303166543 M * frank\ here we go: http://213.211.192.143/bash.traces.tar.gz
1303166564 M * frank\ 6 files directly inside
1303166567 M * frank\ no subdir
1303167075 M * Bertl guess we need to have some look at Linux-VServer debug output to narrow this down
1303167113 M * Bertl does this affect guest startup on your system?
1303167214 M * frank\ not even sure if it even affects guests - because no guests are running
1303167242 M * Bertl okay, I don't think it is a critical issue, but of course, we want to track this down
1303167250 M * frank\ it's a backup host where I would failover manually some guests in case of a failure
1303167266 M * Bertl I still cannot recreate the issue here, the sequences work fine on my host
1303167279 M * Bertl so, what I'd suggest we do is the following:
1303167304 M * Bertl you build a kernel with Linux-VServer debug stuff enabled (and debug info, frame pointers, etc)
1303167336 M * Bertl and we do some tests tomorrow (or when you find the time) with various debug settings (and compare them with my system)
1303167350 M * frank\ okay
1303167353 M * Bertl (I'll see that I match your kernel config as closely as possible till then)
1303167409 M * Bertl I'm a little tired today and I'm off to bed shortly, so I think that's the best approach
1303167418 M * frank\ so - you'll give me a kernel .config with the specific options required?
1303167431 M * Bertl we can do that as well, yes, no problem there
1303167434 M * frank\ or should i activate them by myself?
1303167437 M * frank\ ah ok
1303167462 M * Bertl what you are observing is a context which clashes with itself
1303167479 M * frank\ I'd then prefer that you edit my (posted above) 64bit kernel config with all debug options you need
1303167481 M * Bertl or to be precise, with the previous incarnation of the same context
1303167523 M * Bertl as this is a rather unlikely case in normal use, I don't think it will affect your guests
1303167534 Q * dowdle Remote host closed the connection
1303167559 M * frank\ well - I was as well like 'whoups, what's that' when I saw testme.sh failing there
1303167565 M * Bertl okay, I'll prepare configs for tomorrow afternoon, and you let me know when you have some time to test
1303167571 M * frank\ didn't run it for quite a time ;)
1303167609 M * frank\ I'll login to irc tomorrow/later when I'm back at work - or you just mail me them gzipped
1303167621 M * frank\ frank@undermydesk.org
1303167626 M * Bertl okay
1303167648 M * frank\ fine
1303167658 M * Bertl so thanks for reporting ... I'm off to bed then 
1303167663 M * frank\ aye
1303167665 M * frank\ same here
1303167673 M * Bertl night everyone ...
1303167678 N * Bertl Bertl_zZ
1303167678 M * frank\ good night to you and thanks for debugging this issue ;)
1303168069 J * Piet_ ~Piet__@1RDAAAIXF.tor-irc.dnsbl.oftc.net
1303168096 Q * frank\ Quit: http://www.mibbit.com ajax IRC Client
1303168471 Q * tomreyn__ Ping timeout: 480 seconds
1303170635 J * imcsk8 ~ichavero@189.155.154.236