1239927342 Q * dowdle Remote host closed the connection
1239928564 Q * bourgeau Quit: bourgeau
1239929422 J * ghislainocfs21 ~Ghislain@adsl2.aqueos.com
1239929740 Q * ghislainocfs2 Ping timeout: 480 seconds
1239932959 J * imcsk8 ~ichavero@189.155.103.193
1239933369 Q * imcsk8 Quit: This computer has gone to sleep
1239935658 Q * hparker Quit: Quit
1239937438 J * fb fback@red.fback.net
1239941042 Q * pmenier Ping timeout: 480 seconds
1239941061 J * pmenier ~pmenier@ACaen-152-1-18-207.w83-115.abo.wanadoo.fr
1239942775 J * balbir_ ~balbir@59.145.136.1
1239943046 J * sharkjaw ~gab@149-240-82.oke2-bras6.adsl.tele2.no
1239943476 Q * Medivh Quit: changing servers
1239943513 Q * balbir_ Ping timeout: 480 seconds
1239943533 J * Medivh ck@dolphin.serverbox.de
1239943872 J * balbir_ ~balbir@59.145.136.1
1239948968 J * thierryp ~thierry@home.parmentelat.net
1239948978 Q * balbir_ Ping timeout: 480 seconds
1239949681 J * Punkie ~Punkie@2a01:5f0:1:80:216:d4ff:fe05:5987
1239949803 J * balbir_ ~balbir@59.145.136.1
1239949865 J * davidkarban ~david@193.85.217.71
1239950333 J * Pazzo ~ugelt@sadsl-246059.rol.raiffeisen.net
1239953566 Q * sharkjaw Ping timeout: 480 seconds
1239953773 J * cga ~weechat@62.196.2.6
1239953919 J * esa bip@62.123.8.129
1239954208 J * sharkjaw ~gab@149-240-82.oke2-bras6.adsl.tele2.no
1239954229 J * harobed ~harobed@pda57-1-82-231-115-1.fbx.proxad.net
1239954739 J * esa` bip@62.123.8.70
1239954747 Q * harobed Quit: Ex-Chat
1239954752 J * harobed ~harobed@pda57-1-82-231-115-1.fbx.proxad.net
1239954762 Q * esa Ping timeout: 480 seconds
1239954921 Q * balbir_ Ping timeout: 480 seconds
1239955215 J * balbir_ ~balbir@59.145.136.1
1239955223 Q * Pazzo Quit: Ex-Chat
1239956183 J * jze ~jesper@gw.comsys.informatik.uni-kiel.de
1239956449 J * kir ~kir@swsoft-msk-nat.sw.ru
1239956871 J * chi6IT41 ~chigital@noc.mivitec.net
1239956972 Q * chi6IT41 
1239957246 M * ghislainocfs21 ping Bertl
1239957247 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net
1239958819 Q * balbir_ Ping timeout: 480 seconds
1239958851 M * ghislainocfs21 dam bertl is unreachable i think we will have to reboot it
1239958855 M * ghislainocfs21 ;p
1239959202 J * balbir_ ~balbir@59.145.136.1
1239959694 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net
1239960497 Q * sharkjaw Ping timeout: 480 seconds
1239960794 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk
1239962501 J * sharkjaw ~gab@149-240-82.oke2-bras6.adsl.tele2.no
1239964275 Q * padde Remote host closed the connection
1239964367 J * padde ~padde@patrick-nagel.net
1239964392 J * geb ~geb@AOrleans-253-1-52-38.w92-140.abo.wanadoo.fr
1239964859 J * nas ~chatzilla@bb121-7-190-216.singnet.com.sg
1239964912 M * nas when going into the vserver and issue the top command, is it the usage of the vserver that is displayed?
1239964937 M * nas if not how to determine how loaded a vserver is?
1239964947 M * nas vserver guest*
1239965188 Q * BenG Quit: I Leave
1239965447 M * geb it depend of the flags
1239965466 A * ard graphs the info from /proc/virtual/
1239965475 M * geb VIRT_MEM , VIRT_UPTIME etc
1239965477 M * ard which is pretty accurate
1239965559 M * ard geb : yet another part of vserver I only now seem to notice :-)
1239965594 M * geb by default it should be the system load, as ard says you can get the load in /proc/virtual/$ctx/cvirt , but if you active VIRT_UPTIME you should get the load of vserver
1239965655 M * geb there is always another part to notice , that's a part of the fun with vserver :)
1239965812 M * ard :-)
1239966000 M * nas thanks guys
1239966003 M * nas :)
1239966031 N * Bertl_zZ Bertl
1239966035 M * Bertl morning folks!
1239966044 M * nas morning!
1239966174 M * Bertl geb: note: VIRT_LOAD, VIRT_UPTIME is for the uptime :)
1239966240 M * Bertl ghislainocfs21: so what did you need to reboot?
1239966243 M * geb oups sry :)
1239966249 M * geb morning !
1239966367 M * Bertl ghislainocfs21: regarding your cgroup tests, did you enable the cgroup stuff for the guest?
1239966369 M * Guy- does anyone run a desktop system in a vserver, with hal, dbus & co?
1239966384 M * Guy- (other than myself :)
1239966395 M * Bertl yep, the Moreubuntu folks do/did
1239966434 M * Guy- I was wondering how/where to best run hal and dbus
1239966446 M * Guy- on the host, or in the vserver (and give the vserver lots of extra privileges)
1239966455 M * Bertl hal should go on the host, it is hardware bound/related
1239966490 M * Bertl dbus can go inside the guest, but might need to be tied to hal if you actively want to receive hardware changes
1239966501 M * Guy- and how will the guest use the hal running on the host?
1239966514 M * Bertl if you have just a single system running, I'd put the dbus on the host too
1239966520 M * Guy- bind mount /var/run/hald?
1239966541 M * Guy- I'd like to have at least two desktop vservers
1239966550 M * Bertl that really depends on the individual setup ..
1239966569 M * Guy- I'm a little hazy on what hal actually does
1239966583 M * Guy- assuming I plug in a USB drive, and hal gets notified by udev
1239966596 M * Bertl in that case, read the manual and visit the hal(d) folks :)
1239966596 M * Guy- is there any chance of getting the drive mounted in a guest?
1239966623 M * Guy- I tried, but what documentation I could find was either incomplete, outdated or incomprehensible :)
1239966629 M * Guy- (or a combination thereof)
1239966631 M * Bertl yes, you can do the mount in the guest namespace, or make it shared so that the guest ends up with the mount too
1239966644 M * Guy- some solaris person even resorted to reverse engineering it, because the docs were so inadequate :)
1239966690 M * Guy- OK, this will be a subproject for a later time, thanks for the advice
1239966890 M * Bertl yeah, probably the source is a good source for details :)
1239967122 Q * scientes Ping timeout: 480 seconds
1239967506 M * ghislainocfs21 bertl: yes i use the cgroup for the guest and the memory limit is set for the guest
1239967548 Q * balbir_ Ping timeout: 480 seconds
1239967573 M * Bertl ghislainocfs21: how does your config look like (for the cgroup, in /etc/vservers/...)?
1239967634 M * ghislainocfs21 ==> /etc/vservers/aq0001/cgroup/memory.limit_in_bytes <==
1239967634 M * ghislainocfs21 2147483648
1239967737 M * ghislainocfs21 bertl: and i see it fine in /dev/cgroup/aq0001....
1239967759 M * Bertl but the memory is accounted to the host cgroup?
1239967787 M * Bertl or did I read your email wrong?
1239967801 J * saulus_ ~saulus@d046240.adsl.hansenet.de
1239967807 M * ghislainocfs21 to both, the host cgroup is the top cgroup so the system mem is the host cgroup memory.usage_in_bytes
1239967828 M * ghislainocfs21 and i guess the cgroups under the top one are part of it as i understand
1239967844 M * Bertl ah, okay, so it is accounted correctly then?
1239967851 M * ghislainocfs21 i have 5 other guest running i should say apart the 4 for the test
1239967859 M * ghislainocfs21 but they are mostly idle
1239967863 M * ghislainocfs21 it seems
1239967893 M * Bertl okay, so what was the problem with your tests? (btw, can you convert the spreadsheets to a pdf and upload somewhere?)
1239967909 M * ghislainocfs21 but i have a difference. for memory.usage_in_bytes i have for exemple   	 	 		 			12288 		 	   as a diff between 1 guest and 4 guest for guest 1 usage
1239967910 Q * SauLus Ping timeout: 480 seconds
1239967910 N * saulus_ SauLus
1239967932 M * Bertl so guest 1 uses more memory then the others?
1239967956 M * ghislainocfs21 and for vserver i have 15 which is 15x4096=61440kb no ?
1239968043 M * Bertl well, that doesn't look like a big difference to me, could be stuff we account but which isn't accounted by the cgroup (or vice versa)
1239968115 M * Bertl and no, as the page size is 4k, it is 61440 byte or 60k
1239968122 J * balbir_ ~balbir@59.145.136.1
1239968140 M * ghislainocfs21 oh ok
1239968179 M * ghislainocfs21 so there is 40k of differences between the guest starts, could be just processes life then
1239968195 M * ghislainocfs21 do you know a program that has some very big shared libs ;)
1239968213 M * ghislainocfs21 i used mysql, apache2 with all module enabled and proftpd
1239968217 M * Bertl could be, or could be the actual mapped pages we account, (for executables) which might not be accounted by the cgroup
1239968240 M * ghislainocfs21 ok
1239968265 M * ghislainocfs21 ok so if i am right the memory limit is counting all the memory for a guest that is private space and shared library (via hashify)  also
1239968299 M * Bertl one interesting part/test would be to see if they change accordingly if you create more processes, and if they differ once those processes have finished
1239968320 M * Bertl e.g. ssh into the guest, do some mysql queries on the database
1239968330 M * ghislainocfs21 i can test this by stopping and starting apache for exemple
1239968332 M * Bertl then stop the mysql service and leave the guest
1239968344 M * ghislainocfs21 vserver xx enter would not do it ?
1239968349 M * Bertl repeat that several times and record the highest and lowest value
1239968360 M * Bertl avoid the enter, as it might mess up the results
1239968368 M * ghislainocfs21 ok i shall install ssh then
1239968543 M * ghislainocfs21 so i stop it, i record ram usage,  i start it,wait 20s, i record, then ssh stop apache/mysql, 20s record ?
1239968761 M * ghislainocfs21 whith one guest running or several ?
1239968832 M * Bertl for one guest, but make sure that you do something with the mysql when it is running, best run a query or so which can be repeated (so that some memory gets used)
1239968879 M * ghislainocfs21 debian do a repair by default when mysql start is it enough ?
1239968954 M * ghislainocfs21 http://paste.linux-vserver.org/12841
1239969470 M * ghislainocfs21 oh i must leave, you can join me by mail if you have ideas of test, see you soon ! :)
1239969556 J * bourgeau ~bourgeau@euclide.rsr.lip6.fr
1239970459 Q * nas Quit: ChatZilla 0.9.83 [Firefox 3.0.8/2009032609]
1239971241 Q * balbir_ Ping timeout: 480 seconds
1239971331 J * mrfree ~mrfree@host-84-220-17-86.cust-adsl.tiscali.it
1239971527 J * Guest811 ~dreamind@et-1-10.gw-nat.bs.ka.oneandone.net
1239971554 M * Guest811 hi :)
1239971610 M * Bertl wb dreamind :)
1239971620 M * Guest811 hi bertl :)
1239971636 M * Guest811 I have a strange problem with the latest (pre5) patch for 2.6.29
1239971662 M * Guest811 when I start a single vserver - no problem, but all further vservers I start will receive the network connections instead of the first one
1239971699 M * Bertl hmm, tanjix reported similar, but I cannot reproduce, I have the pre5 running on a test machine which behaves normally
1239971717 M * Bertl could you upload your kernel config for comparison?
1239971719 M * Guest811 for example, I noticed with ssh, which will have big problems... I start an etch-build vserver with an sshd, no problem, but then I start a sarge-build vserver and ssh connections to the etch-build vserver ip will be send to the sarge-build vserver
1239971731 M * Guest811 ok just sec :)
1239971802 M * Guest811 http://www.dreamind.de/files/config-2.6.29.1-vs2.3.0.36.9-pre5-blackbox
1239971831 M * Guest811 all my vservers are in the same subnet, which is only local, but bound to eth0.
1239972087 M * Bertl could you try with CONFIG_NET_NS and CONFIG_NET_KEY_MIGRATE disabled?
1239972127 M * Guest811 ok I'll try :)
1239972158 M * Bertl ah, and disable CONFIG_NET_CLS_CGROUP too
1239972337 M * Guest811 CONFIG_NET_KEY_MIGRATE was already disavbled
1239972349 M * Guest811 I'm now disabling CONFIG_NET_NS and CONFIG_NET_CLS_CGROUP
1239972362 M * Guest811 ok its building :)
1239973765 J * hparker ~hparker@2001:470:1f0f:32c:290:96ff:fe50:40fa
1239974189 M * Guest811 <- reboot :)
1239974193 Q * Guest811 Quit: So long and thanks for all the IRC - telepathy-idle IRC Connection Manager for Telepathy - http://telepathy.freedesktop.org
1239974371 J * ViRUS ~mp@p579B4631.dip.t-dialin.net
1239974625 J * dreamind ~dreamind_@et-1-10.gw-nat.bs.ka.oneandone.net
1239974637 M * dreamind re
1239974643 Q * blathijs Quit: Let's try that again! (brb, reboot)
1239974649 M * dreamind huh, hm, seems empathy has a problem with this channel :(
1239974656 P * dreamind 
1239974693 J * dreamind ~dreamind@et-1-10.gw-nat.bs.ka.oneandone.net
1239974697 M * dreamind hm
1239974743 M * dreamind Bertl: your changes didn't help, still same problem.
1239974856 M * Bertl very strange .. what util-vserver version?
1239974966 M * dreamind  0.30.216~r2772-6
1239974998 M * dreamind (from debian unstable)
1239975125 M * Bertl hmm, drop that and test with the lates version please
1239975146 M * Bertl also, you are on 32bit, which might make a difference too
1239975157 M * Bertl tanjix: what arch do you use? 32bit or 64 bit?
1239975178 M * dreamind I'm on 32bit
1239975203 M * dreamind hm, ok but I don't want to have binaries of util-vserver somewhere in the system :(
1239975216 M * dreamind but I can build a .deb of the latest util-vserver version...
1239975268 M * Bertl please do so, I think the 2772 release is broken for the latest kernel ...
1239975910 M * Bertl ah, I think I found it ...
1239977065 M * dreamind so? :)
1239977126 M * Bertl patience, my young padawan! :)
1239977190 Q * davidkarban Quit: Ex-Chat
1239977211 M * Bertl try this one: http://vserver.13thfloor.at/Experimental/delta-nethash-fix01.diff
1239977546 M * tanjix Bertl: 64bit on my "problem server"
1239977566 M * Bertl tanjix: could you try with the fix I just pasted too?
1239977587 M * tanjix sec, reading the last lines, was not here oin IRC yet for today
1239977663 M * dreamind Bertl: ok I'll try :)
1239977717 M * tanjix Bertl: can i apply the patch to the still patched kernel? and i do nat have pre5 as dreamind, i have pre3
1239977906 Q * PowerKe Quit: Power cycle
1239977939 M * tanjix ok i have done the patching and compiling. am rebooting the server now and testing again what happens
1239978121 M * Bertl yep, should be fine
1239978136 Q * mrfree Quit: Leaving
1239978156 J * PowerKe ~tom@d5153A4C4.access.telenet.be
1239978215 M * tanjix ok, the new kernel is up and running... testing now
1239978347 M * tanjix great, till now i always cam by ssh into the correct server
1239978357 M * tanjix came
1239978372 M * Bertl good!
1239978387 M * tanjix what was the problem?
1239978436 M * Bertl a missing check in the hash code
1239978960 J * balbir_ ~balbir@122.172.147.242
1239979476 M * Bertl okay, uploaded pre6 (with all the fixes)
1239980018 M * dreamind Bertl: are there any chances linux-vserver will sometime switch to using git or maybe something like quilt built on top of git (guilt)?
1239980047 M * dreamind because all of the time its annoying to download patches, with git it would be much more transparent what was fixed and so on. especially in experimental releases.
1239980051 M * Bertl we tried some time ago, didn't work out with git
1239980078 M * Bertl but there is a git repository (private) tracking Linux-VServer development
1239980147 M * dreamind hm, can you define what especially didn't work out well? I don' t get whats so special about the vserver workflow that it will not work with git :(
1239980208 M * Bertl I am concurrently maintaining a bunch of trees, and I'm building test kernels in all of them (and test them mostly with kvm nowadays)
1239980256 M * Bertl there are about 1000 kernel trees, hardlinked together to safe disk space and cache memory
1239980278 M * dreamind ok, for *this* case I guess git will not work
1239980289 M * Bertl git requires me to either check them out, which kills the cache and eliminate build objects
1239980295 M * dreamind but you still could use git to track the development
1239980304 M * Bertl and the advantage would be?
1239980321 M * Bertl I uploaded a patch called delta-nethash-fix01.diff
1239980322 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1239980331 M * dreamind that its easier for people not so involved in the linux-vserver development to track it
1239980339 M * Bertl in git, that would be a commit with e.g. 'nethash fix' as comment
1239980343 M * dreamind and your patch, does it contain any explanation wether it might be important?
1239980359 M * Bertl no, would the git commit know that?
1239980362 M * dreamind well, not really. a comment should at least somehow be explanatory.
1239980384 M * Bertl see, there is the point, I think the code (in the patch) is self explanatory
1239980386 M * dreamind well not the git comment would know, but you should when committing.
1239980400 M * Bertl I could put a comment in the patch too
1239980401 Q * sharkjaw Remote host closed the connection
1239980405 M * dreamind you think so, but not everybody who uses linux-vserver will agree.
1239980412 M * dreamind yes that would be possible too
1239980420 M * Bertl then they should maintain the git repository :)
1239980421 M * dreamind but still it then would not be so easy to fetch
1239980435 M * ktwilight someone should just maintain a git repo ;)
1239980448 M * dreamind not someone!
1239980452 M * dreamind its not centralized.
1239980454 M * Bertl I'm not willing to spend a lot of time to maintain something I do not consider useful
1239980468 M * Bertl unless somebody is going to fund that time, of course
1239980489 M * ktwilight why can't that someone centralize it?
1239980568 M * Bertl we have a git repository, and anybody willing to maintain it is welcome to do so
1239980937 M * dreamind the problem is, it will not help if $somebody would be found to "maintain" that repository. the probiem is, not only somebody would have to use it, but also developers should - in order to maintain their patches. if they don't then it will not work and some day there will be a repository completely outdated and unuseable.
1239980963 M * dreamind even broken out patches (like quilt) would be better than the situation now IMHO.
1239980998 M * Bertl then go ahead, improve it .. start developing Linux-VServer :)
1239981020 M * ktwilight who knows, maybe it'll drive Bertl to use git :P
1239981047 M * Bertl to be honest, I'm kind of tired of hearing how much better git/svn/hq would be for 'my' kernel development ...
1239981078 M * fb Bertl: you've forgot about launchpad + bazaar :P 
1239981088 M * ktwilight haha
1239981089 M * Bertl heh, yeah :)
1239981117 M * dreamind who outside of cannonial is using bazaar? :D
1239981133 M * Bertl we could also adopt the ubuntu policy for packages
1239981150 M * Bertl util-vserver doesn't compile, no problem, just remove it :)
1239981365 M * fb Bertl: btw, i'm full of awe ow you explain your development way with patience, on and on :)
1239981448 M * dreamind well I would say something else but I think I'm not heared, so I'd better leave. bye
1239981450 P * dreamind 
1239981592 Q * Punkie Quit: Leaving
1239981921 M * Bertl daniel_hozac: did you get my message yesterday?
1239983785 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1239984453 Q * jze 
1239985064 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1239985442 Q * kir Quit: Leaving.
1239985943 N * DoberMann[ZZZzzz] DoberMann[PullA]
1239986393 Q * gnuk Quit: NoFeature
1239986671 Q * esa` Quit: Coyote finally caught me
1239988277 Q * bourgeau Ping timeout: 480 seconds
1239988469 Q * thierryp Quit: ciao folks
1239988790 J * Piet ~piet@asteria.debian.or.at
1239989621 J * cga ~weechat@194.244.1.164
1239989832 Q * harobed Ping timeout: 480 seconds
1239990412 Q * Pazzo Quit: Ex-Chat
1239990561 Q * Piet Quit: Piet
1239990709 J * doener ~doener@i59F5B5CD.versanet.de
1239990815 Q * doener_ Ping timeout: 480 seconds
1239992942 J * neofutur ~neofutur@xena.ww7.be
1239993652 M * _Shiva_ # "vserver <XID> start" ---> '/proc/uptime can not be accessed. Usually, this is caused by....' 
1239993671 M * _Shiva_ huh? vprocunhide has been run...
1239993752 M * Bertl any hints regarding kernel/patch/util-vserver version? :)
1239993800 M * _Shiva_ sorry:-)
1239993826 M * _Shiva_ .6.28.9-vs2.3.0.36.10-x86_64-SMP
1239993847 M * _Shiva_ 0.30.215
1239993860 M * _Shiva_ Gentoo..
1239993890 M * _Shiva_ (still waiting for the updated util-vserver.ebuild from hollow ;-))
1239993938 M * _Shiva_ actually it had been fine on the very same machine and setup with 2.6.28.8-vs2.3.0.36.9
1239993974 M * Bertl and you are sure that the vprocunhide has been run?
1239994009 M * Bertl (check with 'chcontext --xid 42 cat /proc/uptime')
1239994028 M * _Shiva_ hmm .. I ran hollow's standard init-script - three times now... alway with $?==0
1239994062 M * Bertl what does 'showattr /proc/uptime' give you?
1239994072 M * _Shiva_ and I ran /usr/lib64/util-vserver/vprocunhide by hand.. also with exit 0
1239994083 M * _Shiva_ AwH-ui- /proc/uptime
1239994090 M * Bertl so that is hidden
1239994099 M * Bertl (which definitely isn't the default)
1239994175 M * _Shiva_ and it definitly is listed in /usr/lib64/util-vserver/defaults/vprocunhide-files
1239994215 M * _Shiva_ maybe a misconfigured kernel-opt?
1239994236 M * Bertl very unlikely, but you never know ... compare the .config files
1239994252 M * _Shiva_ CONFIG_VSERVER_PROC_SECURE=y
1239994292 M * Bertl is that a difference? it should be on by default
1239994327 M * _Shiva_ no - i've simpy grepped for VSERVER in /proc/config.gz :-)
1239994369 M * Bertl I'm sure it isn't a VSERVER option which causes that, unless your vprocunhide doesn't work at all, and the old kernel had proc security disabled :)
1239994420 M * _Shiva_ but exit 0 is an exit 0, right? or might there be some parsing error involved?
1239994452 M * Bertl no idea, maybe daniel_hozac knows ...
1239994492 M * _Shiva_ . o 0 ( it does not hav a verbose option, though .. )
1239994590 M * _Shiva_ i'll re-emerge util-vserver for a first test..
1239994630 M * _Shiva_ does vprocunhide utilize caps?
1239994650 M * Bertl hmm?
1239994674 M * _Shiva_ capabilitiy kernel mod maybe
1239994689 M * Bertl that will get compiled in, on Linux-VServer IIRC
1239994749 M * _Shiva_ is that CONFIG_SECURITY_FILE_CAPABILITIES ?
1239994766 M * Bertl nah, that is the filesystem version ... unrelated
1239994835 M * Bertl CONFIG_SECURITY_CAPABILITIES is the one
1239994871 M * _Shiva_ grep is empty...
1239994881 M * _Shiva_ grep on .config that is
1239994930 M * _Shiva_ so it's not in - not even as a disabled option... 
1239994978 M * Bertl that's fine ... 
1239995183 J * imcsk8 ~ichavero@189.155.206.28
1239995191 M * _Shiva_ damn.. i've cleaned out /boot/ ... so no old config around...
1239995334 M * _Shiva_ re-emergin util-vserver has the same effect...
1239995403 M * _Shiva_ what would be the precise setattr command for unhiding /proc/uptime by hand? just to see if it's not a kernel issue
1239995466 M * Bertl setattr --~hide /proc/uptime
1239995524 M * _Shiva_ nope - setattr does nothing.. - w/o any message but exit 0
1239995544 M * Bertl well, then something _is_ broken
1239995688 M * Bertl http://paste.linux-vserver.org/12842
1239995722 M * _Shiva_ oh wait - it DOES.. small "h" means - not hidden right?
1239995730 M * Bertl yep
1239995748 M * _Shiva_ ok - it IS working :-)
1239995767 M * Bertl good, so your script or the unhide config must be wrong
1239995777 M * _Shiva_ so it mus be somewhere w/i the script
1239995860 M * _Shiva_ got it - 
1239995892 M * _Shiva_ it was my entry /etc/vservers/.defaults/apps/vprocunhide
1239995913 M * Bertl and it worked before, right? :)
1239996037 M * _Shiva_ ahem - it had been booted and running w/o that entry (so default vprocunhide-files) ... then i wanted to show some proc entry of a module to a guest... added that file and restarted the _guerst_
1239996081 M * _Shiva_ the guest was showing the proc entry - so i thought it worked
1239996086 M * Bertl well, glad you found it ...
1239996220 M * _Shiva_ so for the record: creating a file "/etc/vservers/.defaults/apps/vprocunhide/files" with the according entries?
1239996284 M * Bertl will do what one expects, i.e. unhide those entries :)
1239996318 M * _Shiva_ ok - so what is actually wrong with my setup? :-)
1239996337 M * _Shiva_ i have that file with one entry: /dev/dahdi/
1239996352 M * Bertl which doesn't make any sense, does it?
1239996368 M * Bertl /dev/dahdi is not even in proc
1239996377 M * _Shiva_ sorry - /proc/dahdi
1239996398 M * Bertl so, if that is the only entry, only that one will be unhidden
1239996447 M * _Shiva_ and hopefuly all from $__PKGLIBDEFAULTDIR"/vprocunhide-files
1239996466 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html (scroll down to vprocunhide)
1239996506 M * Bertl IIRC, latest util-vserver supports a '+' or so to include the defaults too
1239996532 M * _Shiva_ quote: "..overrides.." *aaargh*
1239996618 M * _Shiva_ i read that like "if that entry already exists in defaults it overrides that _entry_ .."
1239996649 M * Bertl wouldn't make much sense, unhide is unhide
1239996662 M * _Shiva_ okok... reading is a matter of luck ...
1239996705 M * _Shiva_ true - but looking at the defaults there are entries prefixed with "-" ..
1239996762 M * _Shiva_ so actually this reads like "unhide /proc/net/ but then hide /proc/net/ip_conntrack"
1239996763 M * Bertl then the docu is a little outdated ... daniel_hozac?
1239996916 M * _Shiva_         (-*)    params=( --admin         --hide ); filename=${filename#-};;
1239996924 M * _Shiva_         (+*)    params=(                --!hide ); filename=${filename#+};;
1239997227 M * _Shiva_ so maybe a workaround would be a single call for setattr in /etc/vservers/vserver-name/scripts/[pre]pre-start and setting $DONT_SKIP_DEFAULTS ?
1239997249 M * _Shiva_ or are those executed w/i the guest's context?
1239997268 M * Bertl as I said, IIRC, recent util-vserver supports a single plus to include the defaults
1239997536 M * er Bertl, if you have a second - i'm using this hack to solve a problem and would like to know the right way of doing so.
1239997540 M * er http://svn.planet-lab.org/browser/linux-2.6/branches/trellis/linux-2.6-710-netns-unshare-kludge.patch
1239997623 M * er the problem is that we're trying to unshare NET_NS at guest-creation time, but unshare_namespaces -> unshare_netns -> setup_net fails at this point
1239997669 M * er the regular util-vserver path of creating vservers works, but the PL path of doing this via the node manager fails, probably because it's doing stuff in the wrong order
1239997685 M * Bertl I see the words, but how does _this_ check affect the namespace?
1239997739 M * er when you clone a namespace, it calls the init functions of a number of socket handlers
1239997751 M * er to initialize these handlers within the namespace
1239997797 M * er that calls (e.g. in tcp_sk_init) create_ctl_socket -> create_kern_socket -> __sock_create
1239997842 M * Bertl and that fails how?
1239997887 M * Bertl let me explain what the check there does, and then, you explain to me how commenting it out makes it work for you, yes?
1239997922 M * er I see what the check does, I think.
1239997946 M * er it doesn't let you create an ipv6 socket if you don't have an ipv6 ip address, for instance... ?
1239997955 M * Bertl the check, compares the socket type with the Linux-VServer network context config, to prevent ipv4/6 when not configured for the guest
1239997991 M * Bertl yep, and that hurts network namespace unsharing?
1239998081 J * scientes ~scientes@75-165-65-163.tukw.qwest.net
1239998140 M * er hm. when you unshare the network namespace, it calls 'setup_net' to setup the newly created namespace
1239998211 M * Bertl probably the proper handling would be to check for (network) context setup, and skip the check in that case
1239998212 M * er which calls a whole bunch of init functions, for instance, tcp_sk_init. some of these functions appear to create a control socket 
1239998259 M * Bertl but shouldn't you disable the network context when you create a network namespace?
1239998262 M * er right, that's what I thought at first... but for some reason, I don't see this problem when I use util-vserver directly, bypassing the PlanetLab node manager
1239998274 M * Bertl (in which case, the admin check shouldn't trigger)
1239998322 M * Bertl which would suggest that util-vserver gets it right :)
1239998324 M * er ah. I see. 
1239998383 M * er yeah, I was trying to figure out in what way it gets it right... but this seems right. it probably doesn't enable the network context before it unshares.
1239998618 Q * uva Quit: Leaving
1239999586 Q * scientes Ping timeout: 480 seconds
1239999825 Q * bonbons Quit: Leaving
1240000000 Q * FireEgl Quit: Leaving...
1240000151 Q * ViRUS Quit: If there is Artificial Intelligence, then there's bound to be some artificial stupidity. (Thomas Edison)
1240004132 Q * cga Quit: got a DELL??? update you BIOS with http://github.com/cga/dellbiosupdate.sh/tree/master ;)
1240004465 Q * jrdnyquist Quit: connection reset by beer
1240004789 J * vernita ~livingst@203.147.45.60
1240004789 P * vernita 
1240005915 J * uva bno@118-160-163-66.dynamic.hinet.net
1240006065 M * Bertl off to bed now ... have a good one everyone!
1240006078 N * Bertl Bertl_zZ
1240006855 N * DoberMann[PullA] DoberMann[ZZZzzz]
1240009709 Q * imcsk8 Quit: This computer has gone to sleep
1240010869 J * imcsk8 ~ichavero@189.155.84.22
1240011067 Q * geb Ping timeout: 480 seconds
1240011610 J * geb ~geb@AOrleans-253-1-4-41.w90-24.abo.wanadoo.fr