1380243872 Q * Ghislain1 Quit: Leaving.
1380243929 J * Ghislain ~aqueos@adsl1.aqueos.com
1380246287 Q * Ghislain Quit: Leaving.
1380252220 M * Bertl_oO off to bed now ... have a good one everyone!
1380252224 N * Bertl_oO Bertl_zZ
1380262681 N * l0kit Guest446
1380262689 J * l0kit ~1oxT@0001b54e.user.oftc.net
1380263046 Q * Guest446 Ping timeout: 480 seconds
1380265178 J * Ghislain ~aqueos@adsl1.aqueos.com
1380269545 J * beng_ ~BenG@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com
1380271988 Q * beng_ Quit: I Leave
1380272109 J * beng_ ~BenG@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com
1380272112 Q * beng_ 
1380273525 N * Bertl_zZ Bertl
1380273529 M * Bertl morning folks!
1380279021 M * AlexanderS Bertl: is there any official fix for the /proc/net issue with network namespaces? i only found this patch: http://www.paul.sladen.org/vserver/archives/201305/0003.html
1380279484 M * Bertl no, I don't think we addressed that yet, at some point it was discussed but the folks testing it vanished and I got the feeling that it was already resolved from userspace
1380279495 J * beng_ ~BenG@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com
1380279538 M * Bertl if that isn't true and somebody is interested in fixing it properly, I'm open to suggestions (the patch is really a hack) but I need to understand the problem first
1380279552 Q * ircuser-1 Ping timeout: 480 seconds
1380279605 M * AlexanderS currently i am facing that problem... when combining vserver with network ns /proc/net/ is empty and netstat does not work
1380279625 M * AlexanderS if you could give me some pointers, i will try to debug it
1380279702 M * Bertl IIRC, I did some checks back then, and everything looked fine, of course, the entries might be hidden at first
1380279715 M * Bertl so the first step would be to enter the network namespace only
1380279722 M * Bertl and see if the proc entries are there
1380279730 M * Bertl (I'd say, they should be)
1380279751 M * Bertl then after that, try to get the attributes for those entries
1380279771 M * Bertl if they are hidden (I presume so), just change them to become visible
1380279933 M * AlexanderS ah showattr shows  "Awh", that seems to stand for context 0
1380280085 M * AlexanderS oh /proc/net/tcp is AwH--uic-
1380280099 M * Bertl check the entries and more importantly the directories, but make sure to do it from the correct network namespace
1380280143 M * Bertl and try to adjust them from inside the network namespace (which should work just fine)
1380280157 M * Bertl btw, what kernel/patch version do you use?
1380280241 M * AlexanderS I see "setattr --~hide /proc/net/tcp" just works and /proc/net/tcp is afterwards visible from inside the vserver
1380280261 M * AlexanderS I'm currently on 3.10.11-vs2.3.6.6-beng
1380280347 M * Bertl okay, so shouldn't be a problem to change that with the network namespace creation, yes?
1380280406 M * AlexanderS ah okay, basicly I've to executing vprocunhide from inside the network namespace again?
1380280433 M * Bertl yep
1380280484 M * AlexanderS okay, than problem solved
1380280532 M * Bertl maybe you could document it on the wiki?
1380280616 M * AlexanderS thats maybe a good idea
1380282106 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1380289434 J * thierryp ~thierry@sop069r.vpn.inria.fr
1380292377 Q * thierryp Read error: Connection reset by peer
1380294193 Q * beng_ Quit: I Leave
1380294532 Q * imcsk8 Ping timeout: 480 seconds
1380297049 Q * geb Quit: ZNC - http://znc.sourceforge.net
1380297076 J * geb ~geb@mars.gebura.eu.org
1380297662 Q * hparker Ping timeout: 480 seconds
1380298057 J * hparker ~hparker@0000fb24.user.oftc.net
1380301504 J * thierryp ~thierry@LNeuilly-152-21-8-169.w193-253.abo.wanadoo.fr
1380301580 J * thierryp_ ~thierry@LNeuilly-152-21-8-169.w193-253.abo.wanadoo.fr
1380301580 Q * thierryp Read error: Connection reset by peer
1380301662 Q * thierryp_ Remote host closed the connection
1380301733 J * thierryp ~thierry@LNeuilly-152-21-8-169.w193-253.abo.wanadoo.fr
1380304155 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1380304247 Q * thierryp Remote host closed the connection
1380305716 M * Guy- hi
1380305731 M * Guy- if I run bitlbee from a 'vserver foo enter' shell, it works
1380305739 M * Guy- if I have the plain init in the vserver start it, it fails
1380305747 M * Guy- open("/dev/tty", O_RDWR|O_NONBLOCK)     = -1 ENXIO (No such device or address)
1380305755 M * Guy- why would this be the case?
1380305763 M * Guy- if run interactively, this call succeeds:
1380305772 M * Guy- open("/dev/tty", O_RDWR|O_NONBLOCK)     = 3
1380305790 M * Guy- kernel 3.7.6-vs2.3.5.5
1380305959 M * Bertl I'd say your init somehow reduces the capabilities?
1380305979 M * Guy- I have the same init on a different box, with 3.7.2-vs2.3.5.5, and the same bitlbee works there
1380306015 M * Bertl maybe with a different configuration or filesystem attributes
1380306042 M * Guy- I don't think so
1380306083 M * Bertl I presume you already wrapped bitlbee somehow to get the strace, yes?
1380306102 M * Guy- in the non-working case, I straced its parent process (runsv)
1380306111 M * Guy- in the working case, I started it with strace directly
1380306138 M * Bertl okay, well, maybe start a wrapper/script instead and ls -la /dev/tty for a start?
1380306171 M * Guy-  crw-rw-rw- 1 root root 5, 0 Jun  8  2007 /dev/tty
1380306177 M * Guy- this is when invoked by runsv
1380306186 M * Guy- (where bitlbee subsequently fails)
1380306230 M * Bertl and how do you test it interactively?
1380306253 M * Guy- I enter the vserver and do ./run (which is the script that starts bitlbee)
1380306270 M * Bertl enter it how?
1380306281 M * Guy- vserver foo enter
1380306307 M * Guy- (the script is a two-liner, fwiw)
1380306320 M * Bertl try to ssh into the guest, 5.0 is the current tty and you will bring the one from the host with you
1380306360 M * Guy- oh, then I have a suspicion - is it possible that the tty I did the vserver start on no longer exists?
1380306418 M * Guy- fwiw, ssh root@foo, then ./run works too
1380306443 M * Bertl okay, so maybe try to restart the guest, and see if that works just fine
1380306475 M * Guy- that's something I'd like to avoid as there are a number of IRC sessions active in it (including mine :)
1380306496 M * Guy- but does what I'm saying make sense?
1380306510 M * Bertl i.c. well, maybe wrap bitlbee in something allocating a new tty?
1380306517 M * Guy- can that tty have disappeared, so that init (and its direct children) no longer have a tty?
1380306530 M * Bertl possible, yes
1380306534 M * Guy- I suppose I could wrap it in screen...
1380306539 M * Guy- OK, thanks for now
1380306562 M * Guy- oh, there's another thing
1380306591 M * Guy- sometimes the tty I start a number of vservers from will periodically receive 'permission denied' from some vserver guest process
1380306595 M * Guy- but I have no idea which one
1380306601 M * Guy- is there a good way to find out? :)
1380306640 M * Guy- (I suppose I could start each vserver from a separate tty and then I'd at least know which vserver it is)
1380306652 M * Bertl probably the only way :)
1380306653 M * Guy- but how to tell what process?
1380306672 M * Guy- strace them all? :)
1380306695 M * Bertl for example
1380308478 J * thierryp ~thierry@LNeuilly-152-21-8-169.w193-253.abo.wanadoo.fr
1380308961 Q * thierryp Ping timeout: 480 seconds
1380312035 Q * hijacker_ Quit: Leaving
1380312628 J * bonbons ~bonbons@2001:a18:20f:4601:e05a:755f:6c45:bd6f
1380317678 Q * Guy- Quit: client restart
1380317713 J * Guy- ~korn@elan.rulez.org
1380318374 Q * Ghislain Quit: Leaving.
1380318838 J * bzed_ ~bzed@bzed.netrep.oftc.net
1380318992 Q * bzed Remote host closed the connection
1380318997 N * bzed_ bzed
1380322465 Q * bonbons Quit: Leaving
1380325918 J * thierryp ~thierry@LNeuilly-152-21-8-169.w193-253.abo.wanadoo.fr