1119053090 M * Doener evening Bertl! 1119053110 M * Bertl hey Doener! how are you? 1119053123 M * Doener quite good! 1119053170 M * Doener actually i wonder why I'm not sleeping on the keyboard, had only three and a half hours of sleep last night, but well... ;) 1119053195 M * Bertl maybe you _are_ sleeping right now, and all this is just a dream :) 1119053227 M * Doener regarding the VXF_STATE_SETUP flag thingy, you said that lookups for contexts in setup state should fail, but doesn't that make the setup state useless? 1119053244 M * Doener how would you get it out of setup mode, if you can't use it? 1119053248 M * Bertl no, the 'original' idea is/was the following: 1119053268 M * Bertl - you create a context in setup state 1119053300 M * Bertl - your process doesn't enter the context right now, but instead is 'recorded' as the creator 1119053305 M * Doener hmm, who ate my "what about you?"?... 1119053321 M * Doener anyways... how are you doing? 1119053326 M * Bertl (so you can see the creator as 'half' entered) 1119053333 M * Bertl I'm fine, thanks for asking! 1119053356 M * Bertl - the process can then 'configure' the context to its likings 1119053384 M * Bertl - after all that is done, the setup is ended (by removing the flag) and becomes visible to the public 1119053396 M * Doener so lookups (should) fail for everybody but the creator? 1119053404 M * Bertl precisely 1119053496 M * Doener ok, any idea if the tools would start to bail out if we actually use those semantics? 1119053529 M * Bertl it's actually pretty easy, as the context is moved in, but keeps its rights as long as the context setup is not finished 1119053564 M * Bertl so 'just' hiding the context from lookups (IIRC a special return was planned for that) should not mess up the tools too much 1119053592 M * Bertl If I'm not entirely delirious, we even had a release which did get this right ... 1119053662 M * Doener ok 1119053813 M * Bertl probably we killed this 'feature' by changing the way the contexts are hashed 1119053833 M * Bertl IIRC, they where not put on the hash before initialized 1119053945 M * Bertl ah, here we are: 1119053952 M * Bertl kernel/vserver/context.c 1119053961 M * Bertl __create_vx_info() 1119053971 M * Doener ah, i remember the patch... 1119053971 M * Bertl vxdprintk(VXD_CBIT(xid, 0), 1119053971 M * Bertl "create_vx_info(%d) = %p (already there)", id, vxi); 1119053971 M * Bertl if (vx_info_flags(vxi, VXF_STATE_SETUP, 0)) 1119053971 M * Bertl vxi = ERR_PTR(-EBUSY); 1119053971 M * Bertl else 1119053974 M * Bertl vxi = ERR_PTR(-EEXIST); 1119054003 M * Doener it was the one that caused the ngnet patch the have a hunk apply cleanly at the wrong location :) 1119054003 M * Bertl but we do not check this for the 'other' commands yet 1119054049 M * Doener (the patch that changed the hash behaviour) 1119054055 M * Bertl yup 1119054070 M * Bertl so probably syscall commands use locate_vx_info() 1119054084 M * Bertl which just needs to verify that the context is not in setup state 1119054095 M * Doener yep, that was in the oops trace 1119054121 M * Bertl yep, pretty much all commands use that 1119054150 M * Bertl ah, I love it when the design is just right :) 1119054183 M * Doener now that i got the navigate my kernel source trees again... is there a way to change bash tab-completion to behave like vim's? 1119054220 M * Bertl hmm, actually never used vim's tab completion (yet) 1119054227 M * Bertl what does it do? 1119054296 M * Doener if you have files "abc1" and "abc2" and type "vim ab", bash does nothing, second gets you a list of possible completions (yeah, you can get that on the first tab as well) 1119054322 M * Bertl ah, you want to cycle, right? 1119054325 M * Doener if in vim you type :e ab it starts iterating through all possible completions 1119054337 M * Doener yep 1119054452 M * Bertl menu-complete 1119054452 M * Bertl Similar to complete, but replaces the word to be completed with a single match from the list 1119054455 M * Bertl of possible completions. Repeated execution of menu-complete steps through the list of possi­ 1119054458 M * Bertl ble completions, inserting each match in turn. At the end of the list of completions, the 1119054461 M * Bertl bell is rung (subject to the setting of 0and the original text is restored. An argument of n 1119054464 M * Bertl moves n positions forward in the list of matches; a negative argument may be used to move 1119054468 M * Bertl backward through the list. This command is intended to be bound to TAB, but is unbound by 1119054471 M * Bertl default. 1119054472 M * Bertl it's not bound, but binding tab will do that 1119054475 M * Bertl (man bash) 1119054554 M * Doener damn, i've been reading all the stuff on 'Completion', but did not search for 'Completing'... (and of course i used case-sensitive search... d'oh) 1119054558 M * Doener thanks! 1119054567 M * Bertl you're welcome! 1119054628 M * Bertl so this means we should probably change the locate_vx_info() to return an error value (and check for that, no?) 1119054672 M * Doener yep, I'll prepare a patch... or would you like to? 1119054691 M * Bertl no, go ahead if you like to, I'll continue with my debug patch ... 1119054755 M * Doener what's that going to be? 1119054767 M * Doener hm, well, a debug patch... but what does it add? ;) 1119054778 M * Bertl you remember the perl script I was teasing eyck with ... 1119054804 M * Doener hmm... about the VC_CMD(21,432,2312) stuff? 1119054820 M * Bertl yeah, something like that (actually the debug messages) 1119054844 M * Bertl give me a few minutes, it's almost done ... 1119054846 M * Doener yeah, but i don't remember their format ;) 1119055304 M * Bertl http://vserver.13thfloor.at/Experimental/delta-debuginfo-feat02.diff 1119055320 M * Bertl http://vserver.13thfloor.at/Experimental/vxdebug 1119055360 M * Bertl still have to decide if we should make this part of a release or just keep for updating the information ... 1119055549 M * Bertl (the script can autogenerate the debug.txt help in Documentation/vserver) 1119056476 Q * knoppix_ Remote host closed the connection 1119056482 M * Bertl okay, have to reboot, back in a minute ... 1119056891 M * Bertl hmm, seems I need a new kernel ... 1119056904 M * Doener why? 1119056933 M * Bertl somehow my 'old' one decided to put my resources on irq 11 ... all of them ... 1119056944 M * Doener nice :) 1119056959 M * Bertl which leads to the funny result that the audio device is _always_ busy :) 1119058053 M * Doener http://www.13thfloor.at/~doener/vserver/patches/delta-state_setup.diff -- suggestion... naming probably sucks, but i didn't find any better name... 1119058099 M * Bertl what's in a name, would that, what we call rose, by any other name, not smell as sweet? :) 1119058138 M * Bertl ah, I love my highlight filter ... 1119058180 M * Doener yeah, but i used a __ prefix, and the function is not really that internal... 1119058236 M * Bertl IIRC, we had a mixture of lookup/locate some time ago ... 1119058248 M * Bertl maybe we should reintroduce that with strict semantics? 1119058380 M * Doener hm, don't remember that one... 1119058383 M * Bertl also, maybe we can avoid the get/put sequence in certain cases? 1119058559 M * Bertl __lookup_vx_info() 1119058608 M * Bertl maybe your __locate_vx_info() should become a lookup_vx_info() isntead? 1119058784 M * Doener sounds good... 1119058789 M * Bertl the (id < 0) probably only makes sense in the locate_vx_info() called from the commands 1119058810 M * Doener yep 1119058819 M * Bertl while an optimization of the form: 1119058850 M * Bertl id == current->vx_info->id or just current->xid might make sense ... 1119058915 M * Bertl but let's make that two different patches ... 1119059497 M * Doener uhm... which one should be lookup_vx_info? the one that recognizes negative ids? 1119059641 M * Bertl let's define it this way: 1119059654 M * Bertl lookup does a simple hash lookup, with get() no magic 1119059677 M * Bertl (it might have an optimization if requested to 'lookup' the current xid) 1119059705 M * Bertl this one is used in the various places where we lookup an existing (used) xid 1119059741 M * Bertl then we have locate, which does not just lookup, but also check for other stuff like id < 0 and the setup case 1119059770 M * Bertl both of them, idependantly use the lowlevel __lookup which does just that (the hash lookup) 1119059791 M * Bertl does that seem sound? 1119059984 M * Doener eek, yeah, right... i mixed up the two... quite logical that i got confused ;) 1119061001 M * Doener hm, time to update patches... 1119061004 M * Doener 2.6.12 is out 1119061048 M * Doener will need some adjusted as far as i can tell, from my experiments with cogito... (but maybe i just used cogito the wrong way *g*) 1119061113 M * Bertl vstest 1119061124 M * Bertl *sorry* 1119061174 M * Bertl hmm ... well, I was hoping for a 2.0 release before 2.6.12, but probably it's better this way ... 1119061195 M * Bertl i.e. we can get rid of all those memory allocations 1119061198 Q * ruuth Quit: Nettalk6 der Freeware IRC-Client 1119061226 M * Doener http://www.13thfloor.at/~doener/vserver/patches/delta-state_setup2.diff 1119061264 M * Doener memory allocations? 1119061357 M * Bertl my memory accounting comments? 1119061380 M * Bertl they should be obsoleted by 2.6.12, no? 1119061394 M * Bertl (I know we removed them for 2.6.11.x too) 1119061440 M * Bertl patch looks good, except for a view details in locate_vx_info() 1119061460 M * Bertl a) what is the vxi = ERR_PTR(-ESRCH); supposed to do? 1119061499 M * Bertl b) why do we have curly braces where there is only one statement? 1119061513 M * Bertl s/one/a single/ 1119061531 J * mef ~mef@pcp09895218pcs.ewndsr01.nj.comcast.net 1119061544 Q * mef Quit: 1119061558 M * Bertl hmm, mef is trying to reach us? 1119061751 M * Doener a) context not found (was: vxi = NULL; plus some logic in the functions calling this one) 1119061794 M * Bertl ahem, it's late, but how is the assignment supposed to last over the vxi = __lookup_vx_info(id); ? 1119061796 M * Doener b) the if (id < 0) had those with only one command, so I thought that you prefer it that way 1119061846 M * Bertl the (id < 0) is actually a mistake on my side ... 1119061852 M * Doener *lol* right... i need to set it in the id > 1 branch too... 1119061868 M * Doener the initialization is needed nevertheless, for id = 0 1119061885 M * Bertl okay ... 1119061906 M * Bertl but we might make that a final else, no? 1119061940 M * Bertl and actually make the checks be ordered the proper way ... 1119061969 M * Bertl i.e. if (id>1) {} else if (id<0) {} else {} 1119061975 M * Doener just did that :) 1119062005 M * Bertl and add a comment that the else covers id=0 and 1 1119062016 M * Bertl (although it should be obvious ) 1119062086 M * Doener ok, before it comes to style question again, where to place it? like this: else/* blabla */ 1119062104 M * Bertl else 1119062130 M * Bertl /* context id 0 and 1 cannot be located */ 1119062143 M * Bertl vxi = ERR_PTR(-ESRCH); 1119062157 M * Bertl where the comment and assignment is at the same level of indentation 1119062828 M * Doener http://www.13thfloor.at/~doener/vserver/patches/delta-state_setup3.diff 1119062976 M * Bertl okay, two nitpicks (:) 1119063007 M * Bertl I'd move the 'else if' into the next line (after the '}') 1119063045 M * Bertl and the vxi = ERR_PTR(-EBUSY); seems to be intended twice ... 1119063073 M * Bertl rest looks fine, I assume it is compile tested? 1119063231 M * Doener http://www.13thfloor.at/~doener/vserver/patches/delta-state_setup4.diff 1119063235 M * Doener sure it is 1119063376 M * Bertl the get() optimization looks good, do you remember if we have a refcount when the vxi is on the hash? 1119063448 M * Bertl yes, it is referenced when hashed ... 1119063458 M * Bertl so the hash lock is sufficient to guarantee that 1119063484 M * Bertl and for the current, we know that we have it too ... 1119063485 Q * pusling Ping timeout: 480 seconds 1119063540 M * Bertl yes, looks fine to me ... 1119063640 M * Doener good :) 1119063641 M * Bertl good work! 1119063664 M * Doener thanks! 1119064025 M * Bertl okay, time for another reboot .. back in 5 1119065059 M * Bertl hmm ... 1119065104 M * Doener does not sound too well 1119065113 M * Bertl no sound at all :) 1119065135 M * Doener heh, that sounds familiar... 1119065241 M * Doener i didn't my sisters box (with some cheap on-board sound) to play sounds with any but the debian kernel config (regarding sound)... 1119065253 M * Doener s/didn't/didn't get/ 1119065276 M * Bertl well, I'm a little confused actually, because it just 'worked' a week ago ... 1119065298 M * Bertl now 'something' has changed, and I cosntantly get audio: Device or resource busy 1119065320 M * Bertl (without any application having the audio device open) 1119065635 M * Doener i'm off to bed now, trying to sleep... not really tired, but up for too long anyways... have a good one and good luck! 1119065649 M * Bertl thanks, sweet dreams! 1119065652 N * Doener Doener_zZz 1119066099 J * Doener` ~doener@p54876134.dip.t-dialin.net 1119066536 Q * Doener_zZz Ping timeout: 480 seconds 1119070089 M * DaPhreak morning Bertl ;) 1119070096 M * Bertl morning DaPhreak! 1119070126 M * DaPhreak its 2.6.12 finally :) 1119070239 M * Bertl yup 1119072035 M * Bertl okay, I'm off to bed now ... have a good one everyone! 1119072043 N * Bertl Bertl_zZ 1119072493 Q * Hunger iridium.oftc.net uranium.oftc.net 1119072493 Q * Doener` iridium.oftc.net uranium.oftc.net 1119072493 Q * Vudumen iridium.oftc.net uranium.oftc.net 1119072493 Q * TheSeer iridium.oftc.net uranium.oftc.net 1119072493 Q * flock iridium.oftc.net uranium.oftc.net 1119072493 Q * Zoiah iridium.oftc.net uranium.oftc.net 1119072493 Q * mugwump iridium.oftc.net uranium.oftc.net 1119072493 Q * daniel_hozac iridium.oftc.net uranium.oftc.net 1119072493 Q * pattieja iridium.oftc.net uranium.oftc.net 1119072493 Q * gregster iridium.oftc.net uranium.oftc.net 1119072493 Q * id iridium.oftc.net uranium.oftc.net 1119072493 Q * case iridium.oftc.net uranium.oftc.net 1119072495 Q * kevinp|gone iridium.oftc.net uranium.oftc.net 1119072495 Q * sladen iridium.oftc.net uranium.oftc.net 1119072495 Q * SiD3WiNDR iridium.oftc.net uranium.oftc.net 1119072495 Q * atsab iridium.oftc.net uranium.oftc.net 1119072495 Q * Beirdo iridium.oftc.net uranium.oftc.net 1119072495 Q * Bertl_zZ iridium.oftc.net uranium.oftc.net 1119072495 Q * DaPhreak iridium.oftc.net uranium.oftc.net 1119072495 Q * greedy iridium.oftc.net uranium.oftc.net 1119072495 Q * zimbo iridium.oftc.net uranium.oftc.net 1119072495 Q * nox iridium.oftc.net uranium.oftc.net 1119072495 Q * berni iridium.oftc.net uranium.oftc.net 1119072495 Q * aba iridium.oftc.net uranium.oftc.net 1119072495 Q * brc iridium.oftc.net uranium.oftc.net 1119072495 Q * micah iridium.oftc.net uranium.oftc.net 1119072495 Q * mcp iridium.oftc.net uranium.oftc.net 1119072495 Q * stephen-^ iridium.oftc.net uranium.oftc.net 1119072495 Q * Loki|muh iridium.oftc.net uranium.oftc.net 1119072495 Q * ArnY[AwaY] iridium.oftc.net uranium.oftc.net 1119072495 Q * Pazzo iridium.oftc.net uranium.oftc.net 1119072495 Q * ola iridium.oftc.net uranium.oftc.net 1119072495 Q * SNy iridium.oftc.net uranium.oftc.net 1119072495 Q * virtuoso iridium.oftc.net uranium.oftc.net 1119072495 Q * albeiro iridium.oftc.net uranium.oftc.net 1119072495 Q * FaUl iridium.oftc.net uranium.oftc.net 1119072495 Q * janra iridium.oftc.net uranium.oftc.net 1119072495 Q * meebey iridium.oftc.net uranium.oftc.net 1119072495 Q * lilo iridium.oftc.net uranium.oftc.net 1119072551 J * Doener` ~doener@p54876134.dip.t-dialin.net 1119072551 J * DaPhreak ~phreak@styx.xnull.de 1119072551 J * brc bruce@200141099215.user.veloxzone.com.br 1119072551 J * greedy ~jesper@0x503e3545.arcnxx21.adsl-dhcp.tele.dk 1119072551 J * Vudumen vudumen@perverz.hu 1119072551 J * TheSeer ~theseer@border.office.salesemotion.net 1119072551 J * Hunger Hunger.hu@LevNor.Hu 1119072551 J * micah micah@micha.hampshire.edu 1119072551 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1119072551 J * zimbo ~zimbo@callisto.dom.bonis.de 1119072551 J * Zoiah Zoiah@matryoshka.zoiah.net 1119072551 J * mcp ~hightower@wolk-project.de 1119072551 J * stephen-^ ~stephen@user-2774.l6.c5.dsl.pol.co.uk 1119072551 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1119072551 J * daniel_hozac ~daniel@h56n2fls32o829.telia.com 1119072551 J * pattieja ~pattieja@adsl-69-153-174-41.dsl.stlsmo.swbell.net 1119072551 J * Loki|muh loki@satanix.de 1119072551 J * gregster ~gregor@greart.de 1119072551 J * id ~id@relax-media.softwarezentrum.de 1119072551 J * ArnY[AwaY] ~arny@copernic.lina.sciences.univ-nantes.fr 1119072551 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it 1119072551 J * case ~case@donpanic.faveve.uni-stuttgart.de 1119072551 J * berni ~berni@svr01.mucip.net 1119072551 J * ola ~ola@c-adt-5.ataco.se 1119072551 J * SNy ~mfr@bmx-chemnitz.de 1119072551 J * virtuoso ~s0t0na@80.253.205.251 1119072551 J * kevinp|gone ~kevinp@ny.webpipe.net 1119072551 J * albeiro ~albeiro@albeiro.usercloak.oftc.net 1119072551 J * sladen paul@starsky.19inch.net 1119072551 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1119072551 J * Beirdo ~gjhurlbu@beirdo.usercloak.oftc.net 1119072551 J * atsab ~as@lotes.vtu.lt 1119072551 J * Bertl_zZ ~herbert@212.16.62.52 1119072551 J * nox ~nox@noxlux.de 1119072551 J * aba ~aba@eos.turmzimmer.net 1119072551 J * lilo ~lilo@lilo.usercloak.oftc.net 1119072551 J * meebey meebey@booster.qnetp.net 1119072552 J * janra janra@paradox.homeip.net 1119072552 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1119072590 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, 2.0-rc4, ng9.5 -- 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 ;) 1119073372 J * mef ~mef@pcp09895218pcs.ewndsr01.nj.comcast.net 1119073381 Q * mef Remote host closed the connection 1119075836 J * erwan_ho ~erwan@konilope.dyndns.org 1119078130 Q * serving Quit: 1119080470 J * Aiken ~james@tooax6-064.dialup.optusnet.com.au 1119081409 J * pusling ~pusling@195.215.29.124 1119081715 Q * erwan_ho Remote host closed the connection 1119083548 M * pusling what capability is needed to mount something ? (and what else can you do with that capability ?) 1119084425 M * eyck I think ADMIN is needed 1119084439 M * eyck but you can accomplish that with fstab in new utils 1119084464 M * eyck because in general you wouldn't like to give such powerfull CAP to your vservers 1119085206 J * rs ~rs@imhotep.rhapsodyk.net 1119086247 M * pusling i was thinking of restricting mount by only giving access to devicenodes that that vserverowner should use 1119086324 Q * atsab Remote host closed the connection 1119086329 J * atsab ~as@lotes.vtu.lt 1119086400 M * pusling but if 'mount-cap' gives access to create new devicenodes, then it wont work ;) 1119086516 M * daniel_hozac why don't you just mount them from the host? 1119086619 M * pusling because if vserverowner want to change mountpoint, partitioning on the disk or something like that, it means work to me ;) (it is giving access to /dev/hdd*) 1119087331 M * Hollow util-vserver is so evil 1119088565 Q * duckx Read error: Connection reset by peer 1119088580 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1119088674 Q * stephen-^ Ping timeout: 480 seconds 1119089172 J * eXplasm explasm@p549F5783.dip.t-dialin.net 1119089536 J * Greek0 ~greek0@81.189.246.175 1119089538 M * Greek0 hi 1119089819 M * Greek0 the help for CONFIG_VSERVER_DEBUG talks about adding a small overhead, then details "(~??%)" 1119089828 M * Greek0 should probably be changed before 2.0 ;) 1119089842 M * Greek0 (using version 2.0rc4) 1119089887 M * id the debug switch is for developers and bug hunters - you dont need to enable it in production 1119090033 M * Greek0 yes, nevertheless an overhead of ??% doesn't look very good in the documentation. 1119090079 M * id right - but i guess there are no performance tests for the debug switch ;) - imho the details should be removed completly 1119091077 M * Greek0 probably the right way to go 1119093496 M * Greek0 are the userspace tools from debian sid any good? or should I build the tools on my own? 1119093502 M * Greek0 from the upstream sources? 1119093733 M * id i suggest to build your own, (i use debian pure-64). My 32-Bit test-box currently run the sid vserver-utils 1119093742 M * id no problems 1119093761 A * SiD3WiNDR uses debian ones everywhere 1119093765 M * SiD3WiNDR no real problems :) 1119093978 M * Greek0 ok, I'll try the debian ones. 1119094201 M * Greek0 strange feeling to reboot my server.. 1119094209 M * Greek0 well, brb 1119094212 Q * Greek0 Quit: leaving 1119094631 J * Greek0 ~greek0@81.189.246.175 1119094633 M * Greek0 re 1119095533 N * Doener` Doener 1119095541 M * Doener morning folks! 1119095577 M * DaPhreak morning Doener :) 1119095611 M * DaPhreak Doener: might you have a look at http://phreak.xnull.de/kernel/patches/vserver/patch-2.6.12-vs2.0-rc4.diff ? 1119095614 M * Doener hey DaPhreak, good job with the 2.6.12 port 1119095621 M * Doener heh, check your inbox ;) 1119095665 M * DaPhreak heh, well was actually on you latest port ;) 1119095678 M * DaPhreak fresh fetched from 13thfloor ;) 1119095969 M * DaPhreak thanks for the patch Doener ;) 1119095993 M * Doener my pleasure 1119096150 M * DaPhreak it wasn't that hard ;) only fixed a few rejects .. not more :) 1119096179 M * DaPhreak bit harder is the grsec-stuff ;( every second hunk is rejected ... so its more a pain in the ass 1119096250 M * Doener reminds me of the 2.6.12-rc2 port... ;) 1119096275 M * DaPhreak heh ;) 1119096312 M * DaPhreak is there a "smart" way to extract that patch from your mail ? since kmail doesn't show the tabs .. 1119096353 M * DaPhreak s/tabs/tabstops/ 1119096369 M * Doener hm, save the mail and get it with vim or sth. like that... 1119096410 Q * rs Quit: rs 1119096466 M * DaPhreak nah ... shitty mailer ;) i'll simply use your patch ;) 1119096544 M * DaPhreak but since i'm too unsmart to use mutt, i'll keep kmail ;p 1119096568 A * Doener switched to mutt some months ago, will never go back :) 1119096587 M * DaPhreak yeah .. i already tried it 3 times or so :) 1119096818 M * DaPhreak *grrr* that deprecated stuff hasn't yet been fixed ;) 1119096854 M * Doener hm? 1119096944 M * DaPhreak yeah .. "kernel/power/pm.c:259: warning: `pm_register' is deprecated (declared at kernel/power/pm.c:62)" 1119096947 M * DaPhreak mainline :) 1119097020 M * Doener ah that... 1119097038 M * DaPhreak since i'm running the tests on my laptop ;) 1119097340 M * Greek0 is the setattr --barrier stuff still needed on 2.6? I've read something about it in README.Debian.. 1119097361 M * Greek0 it said it was needed if I changed the default vserver root. 1119097461 M * Doener if you use namespaces, it is AFAIK not needed, but i'd set it anyway 1119097468 M * Greek0 or was this obsoleted by the namespace stuff you use in 2.6 instead of chroot? 1119097469 M * Greek0 ic 1119097499 M * Doener chroot'ing is still used, namespaces are additional 1119097561 M * Doener brb 1119097562 Q * Doener Quit: Leaving 1119097725 Q * matti Ping timeout: 480 seconds 1119097753 J * matti matti@linux.gentoo.pl 1119098265 J * Doener ~doener@p54876134.dip.t-dialin.net 1119098393 Q * albeiro Read error: Connection reset by peer 1119098466 Q * Greek0 Ping timeout: 480 seconds 1119099119 J * frzzz ubkeyos@jaim.at 1119099123 M * frzzz . 1119099212 P * frzzz 1119100166 Q * Aiken Ping timeout: 480 seconds 1119100268 J * mef ~mef@pcp09895218pcs.ewndsr01.nj.comcast.net 1119100273 Q * mef Quit: 1119101486 J * rs ~rs@ATuileries-152-1-43-102.w82-123.abo.wanadoo.fr 1119101738 J * Greek0 ~greek0@81.189.246.175 1119102097 M * id brb 1119102441 J * Greek0_ ~greek0@81.189.246.175 1119102489 Q * Greek0_ Quit: 1119102508 J * Greek0_ ~greek0@81.189.246.175 1119102660 Q * Greek0 Ping timeout: 480 seconds 1119102720 Q * alex|ikse Ping timeout: 480 seconds 1119102818 N * Greek0_ Greek0 1119103323 J * alex|ikse ~alexx@84.4.146.161 1119103519 J * alexx|dotnode ~alexx@84.4.2.167 1119103950 Q * alex|ikse Ping timeout: 480 seconds 1119104250 Q * alexx|dotnode Ping timeout: 480 seconds 1119104717 J * sannes ~ace@cm-84.118.217.070.chello.no 1119105292 Q * Hunger iridium.oftc.net jupiter.oftc.net 1119105292 Q * sannes iridium.oftc.net jupiter.oftc.net 1119105292 Q * Doener iridium.oftc.net jupiter.oftc.net 1119105292 Q * pusling iridium.oftc.net jupiter.oftc.net 1119105292 Q * SiD3WiNDR iridium.oftc.net jupiter.oftc.net 1119105292 Q * kevinp|gone iridium.oftc.net jupiter.oftc.net 1119105292 Q * case iridium.oftc.net jupiter.oftc.net 1119105292 Q * id iridium.oftc.net jupiter.oftc.net 1119105292 Q * gregster iridium.oftc.net jupiter.oftc.net 1119105292 Q * pattieja iridium.oftc.net jupiter.oftc.net 1119105292 Q * daniel_hozac iridium.oftc.net jupiter.oftc.net 1119105292 Q * mugwump iridium.oftc.net jupiter.oftc.net 1119105294 Q * Zoiah iridium.oftc.net jupiter.oftc.net 1119105294 Q * TheSeer iridium.oftc.net jupiter.oftc.net 1119105294 Q * Vudumen iridium.oftc.net jupiter.oftc.net 1119105294 Q * flock iridium.oftc.net jupiter.oftc.net 1119105294 Q * Bertl_zZ iridium.oftc.net jupiter.oftc.net 1119105294 Q * sladen iridium.oftc.net jupiter.oftc.net 1119105294 Q * Beirdo iridium.oftc.net jupiter.oftc.net 1119105294 Q * Greek0 iridium.oftc.net jupiter.oftc.net 1119105294 Q * eXplasm iridium.oftc.net jupiter.oftc.net 1119105294 Q * greedy iridium.oftc.net jupiter.oftc.net 1119105294 Q * DaPhreak iridium.oftc.net jupiter.oftc.net 1119105294 Q * zimbo iridium.oftc.net jupiter.oftc.net 1119105294 Q * nox iridium.oftc.net jupiter.oftc.net 1119105295 Q * berni iridium.oftc.net jupiter.oftc.net 1119105295 Q * aba iridium.oftc.net jupiter.oftc.net 1119105295 Q * matti iridium.oftc.net jupiter.oftc.net 1119105295 Q * atsab iridium.oftc.net jupiter.oftc.net 1119105295 Q * FaUl iridium.oftc.net jupiter.oftc.net 1119105295 Q * janra iridium.oftc.net jupiter.oftc.net 1119105295 Q * meebey iridium.oftc.net jupiter.oftc.net 1119105295 Q * virtuoso iridium.oftc.net jupiter.oftc.net 1119105295 Q * SNy iridium.oftc.net jupiter.oftc.net 1119105295 Q * ola iridium.oftc.net jupiter.oftc.net 1119105295 Q * Pazzo iridium.oftc.net jupiter.oftc.net 1119105295 Q * ArnY[AwaY] iridium.oftc.net jupiter.oftc.net 1119105295 Q * Loki|muh iridium.oftc.net jupiter.oftc.net 1119105295 Q * micah iridium.oftc.net jupiter.oftc.net 1119105295 Q * brc iridium.oftc.net jupiter.oftc.net 1119105295 Q * lilo iridium.oftc.net jupiter.oftc.net 1119105295 Q * mcp iridium.oftc.net jupiter.oftc.net 1119105328 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1119105328 J * janra janra@paradox.homeip.net 1119105328 J * meebey meebey@booster.qnetp.net 1119105328 J * lilo ~lilo@lilo.usercloak.oftc.net 1119105328 J * aba ~aba@eos.turmzimmer.net 1119105328 J * nox ~nox@noxlux.de 1119105328 J * Bertl_zZ ~herbert@212.16.62.52 1119105328 J * Beirdo ~gjhurlbu@beirdo.usercloak.oftc.net 1119105328 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1119105328 J * sladen paul@starsky.19inch.net 1119105328 J * kevinp|gone ~kevinp@ny.webpipe.net 1119105328 J * virtuoso ~s0t0na@80.253.205.251 1119105328 J * SNy ~mfr@bmx-chemnitz.de 1119105328 J * ola ~ola@c-adt-5.ataco.se 1119105328 J * berni ~berni@svr01.mucip.net 1119105328 J * case ~case@donpanic.faveve.uni-stuttgart.de 1119105328 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it 1119105328 J * ArnY[AwaY] ~arny@copernic.lina.sciences.univ-nantes.fr 1119105328 J * id ~id@relax-media.softwarezentrum.de 1119105328 J * gregster ~gregor@greart.de 1119105328 J * Loki|muh loki@satanix.de 1119105328 J * pattieja ~pattieja@adsl-69-153-174-41.dsl.stlsmo.swbell.net 1119105328 J * daniel_hozac ~daniel@h56n2fls32o829.telia.com 1119105328 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1119105328 J * mcp ~hightower@wolk-project.de 1119105328 J * Zoiah Zoiah@matryoshka.zoiah.net 1119105328 J * zimbo ~zimbo@callisto.dom.bonis.de 1119105328 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1119105328 J * micah micah@micha.hampshire.edu 1119105328 J * Hunger Hunger.hu@LevNor.Hu 1119105328 J * TheSeer ~theseer@border.office.salesemotion.net 1119105328 J * Vudumen vudumen@perverz.hu 1119105328 J * greedy ~jesper@0x503e3545.arcnxx21.adsl-dhcp.tele.dk 1119105328 J * brc bruce@200141099215.user.veloxzone.com.br 1119105328 J * DaPhreak ~phreak@styx.xnull.de 1119105328 J * pusling ~pusling@195.215.29.124 1119105328 J * atsab ~as@lotes.vtu.lt 1119105328 J * eXplasm explasm@p549F5783.dip.t-dialin.net 1119105328 J * matti matti@linux.gentoo.pl 1119105328 J * Doener ~doener@p54876134.dip.t-dialin.net 1119105328 J * Greek0 ~greek0@81.189.246.175 1119105328 J * sannes ~ace@cm-84.118.217.070.chello.no 1119105337 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, 2.0-rc4, ng9.5 -- 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 ;) 1119106299 J * alexx ~alexx@82.225.136.176 1119107988 J * monrad ~monrad@213083190130.sonofon.dk 1119108452 J * hillct ~hillct@client200-5.dsl.intrex.net 1119108471 M * hillct hi all 1119108589 M * hillct I'm seeing this stupid problem that isn's strictly a vserver problem but with an FC2 vserver, I'm trying to get logwatch working and no matter what I do it reports none of the logs need rotating. I'm almost inclined to think there's a missing dependency here of perhaps a library that handles stat operations or somesuch thing 1119108666 J * shuri shuri@64.235.209.226 1119108885 M * hillct of course I'm removing logrotate.status for testing 1119108899 M * hillct and yet it still reports the logs don't need rotating 1119109959 J * albeiro ~albeiro@albeiro.usercloak.oftc.net 1119111678 M * hillct ping... 1119112779 M * micah hillct: try the freenode irc server for redhat maybe? 1119112792 M * micah also, I think you are meaning logrotate, not logwatch 1119112870 M * hillct yah, guess i mistyped 1119112884 M * hillct looked in the redhat channel 1119112891 M * hillct looked in the fedora channel 1119112900 M * hillct but this is a vserver specific issue 1119112912 M * hillct in the sense that it works fine on the host machine 1119113276 M * hillct it has some seriously strange build dependencies too 1119113280 M * hillct selinux.h 1119113595 Q * flock Ping timeout: 480 seconds 1119115996 P * hillct 1119116555 Q * rs Ping timeout: 480 seconds 1119116757 J * knoppix_ ~knoppix@dsl-213-023-136-140.arcor-ip.net 1119119840 Q * knoppix_ Read error: Connection reset by peer 1119120652 J * rs ~rs@imhotep.rhapsodyk.net 1119120722 Q * rs Quit: 1119121589 J * hillct ~hillct@65.76.245.91 1119122292 M * hillct Doener ping 1119122998 M * Greek0 what is legacy mode? 1119123016 M * hillct legacy API and configuration method 1119123024 M * hillct for a new install, you don't need it 1119123060 M * Greek0 how would I enable it? (ie. what not to do to prevent accidently enabling it) 1119123109 M * hillct depends where you're talking about but generally, you'd first have to enable it in the kernel configuration 1119123118 M * hillct at compile time 1119123130 A * Greek0 double-checks 1119123186 M * Greek0 ah, disabled :) 1119123212 M * hillct after you apply the kernel patches, you should see it when you run make oldconfig or make menuconfig 1119123214 M * hillct yah 1119123247 M * Greek0 I deselected it in make menuconfig, I just didn't remember it.. 1119123281 M * hillct yah 1119123288 M * Greek0 what is CONFIG_VSERVER_HARDCPU actually? the toket-bucken stuff? 1119123300 J * rs ~rs@imhotep.rhapsodyk.net 1119123307 M * Greek0 what a typo 1119123321 M * hillct you'd have to ask Bertl_zZ or Doener 1119123351 M * hillct Bertl_zZ is da'man when it comes to Kernel patches 1119123372 M * Greek0 yeah, I've seen him life on monday :) 1119123423 M * hillct I still need to work out why the hell I can't get logrotate to work properly on a vserver 1119123424 M * DaPhreak Greek0: 1119123426 M * DaPhreak CONFIG_VSERVER_HARDCPU 1119123427 M * DaPhreak Enables hard cpu limits. Linux-VServer supports a token bucket scheduler to adjust cpu usage of the vservers. If you don't enable this option, the scheduler will only adjust priorities for the vservers, with this option enabled, you can also choose to use the hard scheduler which will put the context on hold if it has use up its cpu tokens. For details, please take a look at documentation specific to this feature. 1119123448 M * Greek0 DaPhreak: where did you get that helptext from? 1119123458 M * DaPhreak hehe 1119123459 M * DaPhreak http://linux-vserver.org/Step-by-Step+Guide+2.6 1119123459 M * hillct menuconfig 1119123466 M * hillct and there 1119123483 M * DaPhreak menuconfig should be a bit more verbose ;) 1119123545 M * hillct havn't checked but I don't believe it is 1119123573 M * Greek0 should I take the 5 minutes, stuff that explaination into a patch, and submit it? 1119123611 M * DaPhreak heh, yeah .. i would take that 5 minutes effort to help Bertl_zZ & Doener ;) 1119123663 M * Greek0 k, will do then 1119123956 M * hillct this makes absolutely no sense 1119124283 M * DaPhreak what doesn't makes sense hillct ? 1119124337 M * hillct logrotate operates properly on every redhat/fedora box I've ever installed including the vserver host box 1119124347 M * hillct but not in any of the vservers themselves 1119124358 M * hillct it never recognizes that a log is in need of rotation 1119124365 M * DaPhreak hmm works fine here at least on a dozen vservers 1119124380 M * hillct for testing I'm of course deleting logrotate.status 1119124408 M * hillct I think there's some dependency that isn't handled by the RPM spec file 1119124419 M * hillct something low level that's just assumed to be there 1119124430 M * hillct but isn't because of my minimalist install 1119124443 M * hillct it doesn't exit abnormally 1119124463 M * hillct It just reports that none of the logs are in need of rotation 1119124479 M * hillct I've also observed this on vservers configured by my colligue 1119124507 M * DaPhreak well maybe are there no logs, that need to be rotated ;) 1119124548 A * DaPhreak 's going to bed ;) 1119124683 M * hillct nope 1119124699 M * hillct I'm making sure there are, for testing 1119124712 M * hillct deleting the status file should ensure that files are rotated 1119124723 M * hillct since there are no size specifications 1119124850 M * sannes " legacy API and configuration method 1119124863 M * hillct ? 1119124868 M * sannes " and " for a new install, you don't need it" 1119124903 M * sannes is this correct? 1119124958 M * hillct as far as I know 1119124976 M * hillct I disabled all the legacy code in my installs 1119124994 M * sannes thought the utils wasn't there yet? 1119125014 M * hillct and they works like a champ except for this fucked up logrotate problem which iimagine isn't related 1119125021 M * hillct most of the utils are there 1119125046 M * hillct a few of the bserver-build methods aren't ready for non-legacy 1119125065 M * hillct but I tend to use skeleton which is fine 1119125304 J * knoppix_ ~knoppix@dsl-082-082-083-063.arcor-ip.net 1119125397 N * Bertl_zZ Bertl 1119125409 M * Bertl evening folks! 1119125424 M * sannes when did it start working without legacy support? 1119125443 M * sannes hi Bertl! :) 1119125449 M * Bertl hey sannes! 1119125581 M * hillct Bertl! 1119125584 M * hillct my hero! 1119125589 M * Bertl hmm? 1119125595 M * hillct help!?! 1119125614 M * Bertl with what? 1119125625 M * hillct I'm seeing this strange behavior where logrotate always thinks none of the logs need to be rotated 1119125630 M * hillct on every vserver 1119125635 M * hillct but on the host it's fine 1119125644 M * Bertl sounds like a logrotate issue? 1119125652 M * hillct I'm thinking logrotate has some low level undocumented dependency 1119125655 M * hillct yes and no 1119125680 M * hillct wondering if it's trying to stat the files in some strange way that the vserver doesn't allow 1119125694 A * hillct is using xfs for the vserver partition 1119125717 M * hillct same behavior on the vservers run by a friend of mine also on xfs 1119125725 M * hillct others have reported no problems 1119125737 M * Bertl and your host system uses xfs too? 1119125742 M * hillct yes 1119125745 M * hillct and it's fine there 1119125754 M * hillct other possibility is 1119125783 M * hillct my minimalist install on the vservers lacks a logrotate dependency not tested for by the RPM spec file 1119125805 M * hillct which would be a logrotate problem, but still, something good to be able to diagnose 1119125809 M * hillct any ideas? 1119125851 M * Bertl well, first I would check what happens if you start logrotate by hand 1119125856 M * hillct the host and each of the vservers are using the last RPM updates for FC2 1119125861 M * sannes Bertl : I was under the impression that legacy was still needed, has this changed? what version? 1119125865 M * Bertl (after you made sure that the times are updated 1119125882 M * Bertl legacy is still required for some tools 1119125894 M * hillct my test ptocedure is to delete the logrotate.status file and run by hand with -d for debug 1119125921 M * Bertl and then wait a week? 1119125932 M * hillct it reports that no logs are in need of rotation (even with no status file) 1119125957 M * hillct made everything daily for testing, but it shouldn't matter if there's no status file 1119125994 M * Bertl aha, and that makes the logrotate on the host rotate? 1119126025 M * hillct logrotate on the host rotates normally, as espected and in the default configuration 1119126033 M * hillct the problems appear only on the vservers 1119126048 M * Bertl yes, but your 'test procedure' works on the host? 1119126088 M * sannes Bertl : any particulary (that I might use?) :) 1119126104 M * Bertl chbind, vserver-stat, vps ... 1119126140 M * hillct rotation behaves normally on the host without incident AND the test procedure causes the rotation to occur each and every time 1119126177 M * Bertl hillct: okay, so you 'remove' the state file on the host and invoke logrotate -d, right? 1119126189 M * Bertl and it 'rotates' the logs, yes? 1119126204 M * hillct yes 1119126214 M * sannes meaning most things .. 1119126221 M * Bertl and if you do the same on the guest, it doesn't do that? 1119126227 M * hillct right 1119126239 M * Bertl okay, and of course the logrotate version is the same, no? 1119126253 M * hillct no matter what is done on the guest, it always reports that lone of the logs require rotation 1119126260 M * hillct same version same RPM 1119126275 M * hillct same installation and configuration 1119126289 M * Bertl okay, then let's do an strace -fF -o rotate.log logrotate 1119126297 M * Bertl on both, the host and the guest ... 1119126310 M * hillct K 1119126313 M * Bertl then please upload that somewhere (e.g. pastebin.com) 1119126322 M * hillct yh 1119126326 M * hillct hang on 1119126764 M * hillct hmm 1119126817 M * hillct looks like my test procedure is slightly broken 1119126820 M * hillct although 1119126867 M * Greek0 should I send the Kconfig doc patch to vserver@lists.linux-vserver.org, or is there a special devel list? or should it go diretly to Bertl 1119126885 M * hillct it does seem to rotate on the host (as evidenced by the existence of rotated logs from the past) 1119126894 A * hillct takes a closer look 1119126903 M * Bertl Greek0: Kconfig doc patch sounds interesting, any url? 1119126919 M * Bertl Greek0: and sending it to the ML is always a good idea 1119126940 Q * sannes Ping timeout: 480 seconds 1119127012 M * Greek0 http://greek0.net/~greek0/patches/patch-vserver-Kconfig-doc.diff 1119127089 M * Bertl hmm, did you verify the first one? :) 1119127171 M * SiD3WiNDR if it has use up -> if it has used up 1119127182 M * SiD3WiNDR (hard cpu limits thing) 1119127182 M * Bertl Greek0: the vproc entry is wrong ... it sets the 'default' the hiding is always enabled ... 1119127207 A * hillct revises test stretegy 1119127227 M * SiD3WiNDR Bertl: it says: if you enable that option, they're hidden by default - is that wrong? 1119127232 M * SiD3WiNDR (i don't know what option :p) 1119127253 M * Bertl Greek0: the difference is, that on 2.4/1.x the proc visibility is on by default, while on 2.6/1.9/2.0 the entries are hidden by default 1119127265 M * Greek0 Bertl: well, I was told here that the legacy stuff is only there for compatibility 1119127276 M * SiD3WiNDR oh 1119127291 M * Bertl yeah, unfortunately the alpha util-vserver contain some 'legacy' tools ... 1119127317 M * hillct there were one or two last I checked. Nothing significant though 1119127350 M * Bertl well, we need to clean up the tools anyway .. so maybe it is true when we release :) 1119127352 M * hillct or maybe I'm just not doing complex enough things to need any of the tools that havn't been converted from legacy 1119127373 M * Greek0 Bertl: hmm. so do I still need the flags in /proc then? 1119127387 J * ntrs ~ntrs@62.162.242.220 1119127392 M * Bertl evening ntrs! 1119127396 M * Bertl Greek0: hmm? 1119127430 M * ntrs Hi Bertl 1119127432 J * Hollow|mobile ~bene@p5497910C.dip0.t-ipconnect.de 1119127436 M * Hollow|mobile heya 1119127453 M * Greek0 I have some problems understanding what that config option does.. does it enable parsing of the AWH flags in procfs? 1119127465 M * Bertl no 1119127469 M * Greek0 or does it hide entries on it's own, without the flags 1119127480 M * Bertl again, no 1119127484 M * Greek0 .. 1119127488 M * Bertl it's like this: 1119127495 M * Bertl proc entries have 3 flags ... 1119127507 M * Greek0 yes 1119127512 M * Bertl they have it on 2.4/1.x and on 2.6/1.9.x/2.x 1119127524 M * Bertl it's an integral part of the security 1119127549 M * Hollow|mobile Bertl: i tried to make some basic vserver app, but still some problems... how can i use the xid_t type e.g.? 1119127561 M * Bertl Greek0: for compatibility reasons, on 2.4 all entries are visible by default, and have to be hidden if required 1119127593 M * Bertl Greek0: on 2.6 the default is the oposite: all entries are hidden, and you ahve to make them visible 1119127604 M * Bertl unless you change that kernel option :) 1119127622 M * Greek0 ah, so H is set by default? 1119127634 M * Greek0 and that option lets you change that? 1119127673 M * Bertl yep 1119127685 M * Greek0 ah 1119127836 M * hillct logrotate must use some additional criteria besides the logrotate.status file to determine eligability to be rotated 1119127838 M * hillct hmm 1119127842 M * Greek0 should I rework the VSERVER_LEGACY description, or should I just keep it as is and we'll wait until the tools hold what the Kconfig docs promise? 1119127947 Q * ntrs Quit: Leaving 1119127966 M * Bertl Greek0: I'd say post it to the ML, maybe folks will add/comment on it 1119127990 M * Bertl I'll integrate the changes into the next rc then ... 1119128097 M * Bertl Greek0: and thanks for the contribution! 1119128112 M * Bertl Hollow|mobile: hmm, where do you want to use it? 1119128166 M * Hollow|mobile in a small test programm which runs ctx_create i want the function to return an xid_t type 1119128176 M * Hollow|mobile instead of int e.g. 1119128179 Q * FaUl Ping timeout: 480 seconds 1119128237 M * Greek0 Bertl: np 1119128307 M * Bertl Hollow|mobile: hmm, the xid_t is a kernel internal type, you should not use it in userspace, or you have to (re)define it yourself 1119128316 M * Hollow|mobile ah ok.. 1119128328 M * Hollow|mobile so i should use int? 1119128338 M * Bertl the interfaces use fixed size integers, defined in stdint.h 1119128365 M * Bertl except for the syscall return value, which is traditionally a long 1119128384 M * Hollow|mobile ok.. and second question: what is the third argument og the vserver function? 1119128398 M * Bertl a data structure ... 1119128407 M * Hollow|mobile containing what? 1119128427 M * Bertl depends on the syscall command, they are defined in the ABI 1119128459 M * Hollow|mobile the *_v0 structs? 1119128469 M * Bertl http://vserver.13thfloor.at/Stuff/API-2.0/vserver_include_2.0.tar.bz2 1119128494 M * Bertl they are labeled vcmd_* 1119128505 M * Bertl and they might include a version at the end 1119128528 M * Hollow|mobile e.g. vcmd_ctx_flags_v0? 1119128533 M * Bertl yep 1119128535 M * Hollow|mobile k 1119128551 M * Bertl have a look at the various hack tools how to use them 1119128582 M * Hollow|mobile yeah, i looked at them.. just trying to do some basic things.. already created a context + namespace running bash inside ;) 1119128591 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/vflags-0.02.tar.bz2 1119128612 M * Bertl excellent! 1119128634 M * hillct d'oh 1119128638 M * Hollow|mobile so the vserver function is a wrapper for the syscalls? 1119128646 M * hillct I'm using debug instead of vorbose 1119128654 A * hillct is a moron 1119128683 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1119128692 M * Bertl evening FaUl! 1119128696 M * FaUl oops 1119128706 M * FaUl hey bertl 1119128724 M * FaUl Bertl: anything new on ngnet? 1119128741 M * Bertl not yet ... was fighting with my PC today ... 1119128754 M * FaUl use your hp instead :-) 1119128807 M * Hollow|mobile Bertl: but the tar doesn't include vserver.h .. do i need it? 1119128830 M * Bertl http://vserver.13thfloor.at/Stuff/API-2.0/vserver_syscall_2.0.tar.bz2 1119128905 M * Hollow|mobile ah ok.. thx.. this is your syscall wrapper..? 1119128928 M * Bertl yup 1119129006 M * Hollow|mobile good.. i start getting ghe idea bhind it ;) 1119129029 M * Hollow|mobile i hate notebook keyboards 1119129083 M * FaUl Hollow|mobile: depends. that thinkpad-keyboards are acceptable IMHO 1119129235 M * Hollow|mobile heh 1119129258 M * Hollow|mobile just a matter how much you're sitting in front of your notebook keyboard imo 1119129277 M * Hollow|mobile you can get used to many keyboards :P 1119129350 M * FaUl Hollow|mobile: well, i prefer my m-series, too. but that is not that kind of keyboard you want to carry arround :-) 1119129371 M * FaUl s/m-series/model-m/ 1119129390 M * Hollow|mobile ;) 1119129559 M * Doener evening folks 1119129579 M * Bertl evening Doener! 1119129626 J * ghpolo ~polo@201.15.214.133 1119129711 M * Bertl welcome ghpolo! 1119130010 M * Doener Bertl: there are some sys_(old)?uname syscalls that use system_utsname instead of vx_new_utsname(). Is that intentional or should i prepare a patch? 1119130119 M * Bertl hmm, probably I just missed them ... where? 1119130156 M * ghpolo hi Bertl 1119130171 M * hillct yah 1119130176 M * hillct er wrong window 1119130201 M * Doener IIRC m32r, sh, sh64, ppc, ia64, x86_64 1119130205 Q * albeiro Ping timeout: 480 seconds 1119130252 J * albeiro ~albeiro@graffias.estrefa.pl 1119130260 M * hillct there seems to be some underlying problem with logrotate 1119130262 M * Bertl Doener: yeah, looks like a mistake ... 1119130266 M * hillct no suprise I guess 1119130280 M * Bertl btw, we have something similar with alpha for the pid ... but that's a little trickier ... 1119130308 M * hillct have fun 1119130311 P * hillct 1119130343 M * Bertl hmm, guess that means it's not a vserver issue after all :) 1119130920 M * Greek0 hmm, is there some simple way to leave a note that the content I contributed to the wiki is GPL/FDL dual? 1119131055 M * Bertl doesn't matter, as the wiki is GDL ... 1119131090 M * Bertl (see bottom line) 1119131095 M * Doener http://www.13thfloor.at/~doener/vserver/patches/delta-vs2.0-rc4-uname-fix.diff 1119131122 M * Doener not sure about the includes, but as you said "include .h in .c only" it seems quite right... 1119131182 M * Bertl arch/mips/kernel/linux32.c why the include there? 1119131206 M * Greek0 well, I'm not really a big fan of the FDL on itself. 1119131263 M * Greek0 with gpl/fdl dual people could use at least my stuff under the gpl 1119131290 M * Doener because sys32_newuname() there is using vx_new_utsname() 1119131345 M * Bertl hmm .. so that should have thrown an error at compiletime, no? 1119131375 M * Bertl Greek0: well, of course you can add a footnote or something if you feel like doing so ... 1119131421 M * Doener i'd think so... unless there's some .h in .h inclusion going on... 1119131455 M * Bertl k, will check that ... 1119131726 J * _are_ ~are@dsl-084-056-173-051.arcor-ip.net 1119131730 M * _are_ hi 1119131749 M * Bertl welcome _are_! 1119131762 M * Greek0 hmm, does vserver .. build -m debootstrap use locally cached packages to bootstrap? 1119131770 M * _are_ ha sbeen a while since I've been here, had a busy time and still have :-) 1119131832 M * _are_ has anyone ever run a vserver inside a uml? 1119131879 M * Bertl yep, several times actually ... 1119131896 M * Bertl Greek0: it uses whatever the debootstrap config uses 1119132064 M * _are_ well, it compiled and I am 'pretty' sure I have the necessary switches, but the uml claims when I do 'vserver-stat: vc_new_s_context(): Function not implemented 1119132074 M * _are_ to me it sounds like vserver is not in the kernel 1119132075 M * Greek0 Bertl: nice. seemed to get many packages directly from my apt cache.. 1119132124 M * Bertl _are_: which kernel patch version, what config options? 1119132244 M * Doener Bertl: hm, what about the osf_*, irix_* stuff? should those also be changed regarding the utsname stuff? (what are those actually anyways? 1119132254 M * _are_ Bertl: patch-2.6.11.11-vs2.0-rc4.diff.bz2 on a 2.6.11.12 with skas patch 1119132282 M * _are_ forget the skas patch, the uml clients have no skas 1119132285 M * Bertl testme.sh reports? 1119132308 M * Bertl (and on what harware arch was the uml compiled? 1119132313 Q * Hollow|mobile Quit: Leaving 1119132344 M * _are_ uml-host: i386 (athlon XP, 2GB RAM) 1119132362 Q * ghpolo Quit: BitchX Official IRC Channel -- #BitchX on EFNet 1119132388 M * _are_ uml-client: smae kernel, but no skas patch and instead the vserver patch and ARCH=um 1119132452 M * Bertl okay, testme.sh? 1119132498 M * _are_ where can i find testme.sh (first time something goes really wrong with vserver here) 1119132527 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh 1119132586 M * _are_ Linux-VServer Test [V0.12] (C) 2003-2005 H.Poetzl 1119132586 M * _are_ chcontext: vc_new_s_context(): Function not implemented 1119132586 M * _are_ chcontext failed! 1119132586 M * _are_ chbind: vc_set_ipv4root(): Function not implemented 1119132587 M * _are_ chbind failed! 1119132587 M * _are_ Linux 2.6.11.12 i686/0.30.204/0.30.204 [Ea] 1119132589 M * _are_ VCI: 0002:0001 273 03000016 1119132589 M * _are_ --- 1119132661 M * _are_ /proc/config.gz is enabled and the VSERVER-options in ther elook fine to me 1119132703 M * Bertl it looks like it is syscall related 1119132717 M * _are_ CONFIG_VSERVER=y 1119132717 M * _are_ CONFIG_VSERVER_SECURITY=y 1119132717 M * _are_ CONFIG_VSERVER_LEGACYNET=y 1119132717 M * _are_ CONFIG_VSERVER_LEGACY=y 1119132717 M * _are_ CONFIG_VSERVER_PROC_SECURE=y 1119132719 M * _are_ CONFIG_INOXID_UGID24=y 1119132730 M * Bertl let's try something, you can compile inside the UM? 1119132755 M * _are_ yes, might have toi install a compiler, but perfectly possible 1119132794 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/vdlimit-0.03.tar.bz2 1119132815 M * Bertl try to compile that one, and if it works, let's try vdlimit -V 1119132871 M * Greek0 how do I get rid of vservers? just rm'ing them in /vserver, /etc/vservers ? 1119132910 M * Bertl basically, yes, there might also be some stuff in /var/run/vservers 1119133014 M * _are_ # ./vdlimit -V 1119133014 M * _are_ vc_get_version: Function not implemented 1119133055 M * Greek0 thanks Bertl 1119133074 M * Greek0 debootstrap failed, due to a dbootstrap bug. fixed already, though 1119133081 M * Bertl _are_: okay, then it's a bug in the vserver code ... will investigate 1119133086 M * _are_ :-) 1119133203 M * _are_ hmm, if it does some difference: I think I have strip-ed the linux kernel binary as suggested by UML 1119133220 M * Bertl ah, seems like an issue I keep fixing over and over again :) 1119133232 M * Bertl arch/um/kernel/sys_call_table.c 1119133241 M * Bertl change the line: 1119133246 M * Bertl [ __NR_vserver ] = (syscall_handler_t *) sys_ni_syscall, 1119133249 M * Bertl to 1119133262 M * Bertl [ __NR_vserver ] = (syscall_handler_t *) sys_vserver, 1119133359 M * _are_ ok, compiling now, will take some time 1119133482 M * _are_ arch/um/kernel/sys_call_table.c:258: error: `sys_vserver' undeclared here (not in a function) 1119133681 M * Greek0 how can it happen that this is ni? I mean, that's set to sys_vserver in the patch, or? 1119133683 M * Bertl sec 1119133703 M * _are_ hmm, did I miss a reject? 1119133713 M * _are_ nope, no .rej 1119133737 M * Bertl it's fine, just add the following to the beginning: 1119133749 M * Bertl extern syscall_handler_t sys_vserver; 1119133764 M * Bertl and yes, I think we had that in the patch 1119133787 M * _are_ hmm, as said, no .rej file here 1119133813 M * Bertl I just verified, it's not in 2.0-* 1119133844 M * Bertl got lost somehow ... 1119133852 M * Bertl 1.9.3 does contain it ... 1119133917 M * Greek0 it's not in the -rc series? 1119133945 M * Bertl obviously not ... 1119134003 M * Greek0 ah, in arch/um.. 1119134010 A * Greek0 should pay more attention 1119134745 M * Greek0 http://greek0.net/~greek0/div/vserver 1119134757 M * Greek0 is it normal that it talks about /dev/hdv1? 1119134773 M * Greek0 I have no hdv1.. at least not physically. 1119134797 M * Bertl no 1119134812 M * Bertl the thing is .. your guest is executing shutdown scripts 1119134832 M * Bertl i.e. it tries to do some stuff like taking interfaces down or unmounting the roots 1119134836 M * Bertl *rootfs 1119134838 M * Greek0 yes 1119134852 M * Bertl which is not possible inside a guest, so it leads to some error messages 1119134862 M * Greek0 yeah, those don't scare me 1119134871 M * Greek0 the mound problems and hdv1 scare me 1119134872 M * Bertl basically a guest should not do anything of that stuff 1119134881 M * Greek0 s/mound/mount/ 1119134883 M * Bertl why? 1119134897 M * Bertl hdv1 is a placeholder (a dummy) for the already mounted rootfs 1119134906 M * Greek0 so that _is_ normal? 1119134915 M * Bertl if the guest is not cleaned up, yes 1119134922 M * Greek0 ok. 1119134968 M * Greek0 so I should just gut the guest's /etc/rc?.d, and that reboot daemon? 1119134979 M * Bertl reboot daemon? 1119135046 M * Greek0 The vshelper userspace reboot helper? 1119135061 M * Greek0 I haven't really read the docs about it, just noted it exists 1119135061 M * Bertl ah, that is invoked from the kernel ... 1119135079 M * Bertl very similar to the hotplug helpers ... 1119135185 M * _are_ # ./vdlimit -V 1119135185 M * _are_ version: 0002:0001 1119135185 M * _are_ Bertl: tis seems to have helped :-) 1119136003 N * _are_ are|afk 1119136110 M * Greek0 hmm. I've got a couple of reboot processes hanging in the sid chroot.. and I can't kill them 1119136181 M * Bertl Greek0: that's a bug with the tools ... which version do you use? 1119136203 M * Bertl btw, you can get rid of them by killing the helper bash on the host 1119136294 M * Greek0 it worked, thanks 1119136325 M * Greek0 0.30.207 from debian 1119136331 M * Greek0 (despite your warnings ;) 1119136355 M * Bertl well, I doubt it is working in 0.30.207 non-debian ... 1119136401 M * Greek0 how does the shutdown process work actually? is the context shut-off once no processes run in it any more? 1119136435 M * Greek0 or do you somehow handle some kind of halt/reboot syscall from the guest contexts? 1119136511 M * Bertl both 1119136526 M * Bertl the kernel interfaces do the following: 1119136550 M * Bertl - a context will exist until the last process exits 1119136579 M * Bertl - when a context exits, it's possible to get a helper callback, right before the context is destroyed ... 1119136608 M * Bertl - when a process inside a context calls sys_reboot() which is used for reboot and halt, the helper is called too 1119136651 M * Greek0 but the processes inside don't have halt/reboot capability, or do they? 1119136669 M * Bertl usually they have, but it doesn't halt/reboot the host 1119136684 M * Greek0 ic 1119136706 M * Bertl the proper reboot actions from userspace would look like this: 1119136737 M * Bertl - when the reboot helper is called, fork a 'waiter' (which waits for context termination, aother syscall command) 1119136755 M * Bertl - then kill out all remaining processes including the init 1119136768 M * Bertl - then exit 1119136788 M * Bertl after that, the context will be removed, the waiter unlocked 1119136803 M * Bertl and the context can be started anew from the process 1119136852 M * Greek0 and where does this go wrong with the current tools? 1119136859 M * Greek0 killing the remaining ones? 1119136877 M * Bertl the tools do some 'custom' synchronization and 'try' to restart the context from the helper 1119136894 M * Bertl which fails, because the helper itself is keeping the context alive 1119136920 M * Bertl (this was somewhat improved by going back to async helper calls) 1119136940 M * Bertl but the proper solution is something similar to the sequence I described 1119136945 M * Greek0 and is there a real solution (i.e. an implementation doing what you outlined) in sight? 1119136986 M * Bertl unfortunately Enrico can not be reached atm (no idea why, he just doesn't respond) 1119137126 M * Greek0 how difficult would it be to do this for someone not fimilar with the code? 1119137190 M * Bertl I did a quick hack, not a proper solution in a few minutes, and I'm not really familiar with the code 1119137305 M * Greek0 well, but you at least know the other side of the interface well ;) 1119137314 M * Bertl http://vserver.13thfloor.at/Experimental/vshelper-hack-01.diff 1119137321 M * Bertl yep, I do ... 1119137352 M * Bertl but I can be reached quite fine, so you can always ask me ... 1119137400 M * Greek0 ok, when does this happen exactly? when processes inside won't terminate on themselves? or always? 1119137404 M * Bertl btw, if you plan to dig into the tools, you should two things: 1119137411 M * Bertl s/two/do two/ 1119137419 A * Greek0 listens 1119137438 M * Bertl a) you should subscribe to the openfoundry thingy 1119137457 M * Bertl b) you should get the cvs version from there, and check some of the commited stuff 1119137482 M * Bertl among others, ola has an account there and contributed some debian specific stuff 1119137506 M * Bertl and some stub commands (e.g. for removing a guest ;) have been added by myself ... 1119137539 M * Bertl http://www.paul.sladen.org/vserver/archives/200505/0028.html 1119137617 M * Bertl any work there would be really appreciated ... 1119137672 M * Greek0 ok, so the svn stuff there is the stuff to work on? 1119137694 M * Bertl it definitely has some stuff which is not in 0.30.207 1119137712 M * Bertl but I don't know the actual status of it ... 1119137733 M * Bertl Sam (mugwump) has updated it recently to contain fixes from the cvs @ savannah 1119137774 M * Greek0 ok, I'll look at it tomorrow, if there's something I can do for it. 1119137784 M * Bertl great! 1119137793 M * Greek0 when does that problem I ran into happen exactly? 1119137829 M * Bertl reboot is called inside the guest (command) 1119137829 M * Greek0 if you've started your vserver without cleaning the init scripts first, I noticed that ;) 1119137850 M * Bertl this sens a message to init (via initctl) 1119137853 M * Bertl *sends 1119137864 M * Greek0 ok. so just adding back that symlink should make it break again. fine. 1119137871 M * Bertl init is now supposed to kill everything except itself 1119137887 M * Bertl it then calls the sys_reboot() into the kernel 1119137899 M * Bertl which in turn spawns the helper on the host 1119137931 M * Bertl that's it ;) 1119137996 M * Greek0 and where does the reboot have to be triggered? in the reboot helper, after the context has been fully destroyed (ie in that forked waiter you mentioned)? 1119138200 M * Greek0 ok, saw that in the patch you mentioned above 1119138222 M * Bertl yep, from within the waiter 1119138247 M * Bertl maybe the following issues should get extra attention: 1119138268 M * Bertl - the vserver stop should be split in two parts 1119138287 M * Bertl a) the kill all processes and wait for context exit part 1119138310 M * Bertl b) the actually remove meta information/do unmount/etc stuff 1119138340 M * Bertl because vserver stop-a should not happen inside the waiter 1119138357 M * Bertl but the stop-b part is required for a 'clean' shutdown 1119138388 M * Greek0 hu? 1119138390 M * Bertl so the stop-a/b is basically moved into two separate processes (which sync via the wait) 1119138409 M * Bertl when you do 'vserver stop' 1119138419 M * Greek0 that part is clear 1119138419 M * Bertl then this does two things ... 1119138435 M * Greek0 ah 1119138441 M * Bertl it executes the various stop scripts and such stuff (including the final kill) 1119138460 M * Bertl and it removes entries on the host in /var/run/vservers etc 1119138466 M * Greek0 stop-a is done inside the main process, and while stop does stop-b later, restart just restarts the server later.. 1119138482 M * Bertl yep 1119138503 M * Bertl so it would probably be wise to have a restart which is != stop/start 1119138512 M * Greek0 so bring stop and restart more in sync, so they just differ in the part that happens after wait returns. 1119138539 M * Bertl sec, let me put that into an ascii art :) 1119138545 M * Greek0 :) 1119138587 M * Greek0 btw, I really like the way you structure information over irc. it's really clearly laid out.. 1119138625 M * Greek0 much better then the good old multiple-layers-of-parentheses method ;) 1119138640 M * Bertl running running 1119138640 M * Bertl ________ ______________ 1119138640 M * Bertl \ / 1119138640 M * Bertl \ restart / 1119138640 M * Bertl \_______/ 1119138642 M * Bertl \ 1119138645 M * Bertl \ 1119138647 M * Bertl \___ stop 1119138652 M * Greek0 yes. 1119138661 M * Greek0 you can save the whole stop-b part you mean.. 1119138677 M * Bertl yes, either this way, or you do it like this: 1119138753 M * Bertl running running 1119138753 M * Bertl ________ ______________ 1119138753 M * Bertl \ / 1119138753 M * Bertl reboot \ / 1119138756 M * Bertl _________\ / 1119138758 M * Bertl \ / 1119138761 M * Bertl \ / 1119138763 M * Bertl \_ stop _/ 1119138771 M * Bertl it's basically up to userspace to decide which one 1119138780 M * Bertl is better, maybe both make sense ... 1119138796 M * Greek0 what is the second one? 1119138822 M * Bertl the first part of the 'stop' is done by the guest itself 1119138833 M * Bertl (because init is doing it) 1119138835 M * Greek0 ah.. 1119138853 M * Bertl the rest of the stop (i.e. everything after the processes where killed) 1119138875 M * Bertl happens in the reboot helper, while the waiter does the new startup 1119138883 M * Greek0 well I think you need some kill-everything-left-over anyway on the host, or? 1119138902 M * Bertl yes, this can happen in the helper ... 1119138903 M * Greek0 iirc there can be an init running inside the guests.. 1119138921 M * Greek0 so what happens if you go for (2), but init doesn't kill everything? 1119138945 M * Bertl you usually do a double vkill to get rid of a) processes and b) init 1119138957 M * Bertl (this can be done anyway) 1119138962 M * Greek0 ah, that is the 2 kills I saw in your script 1119138984 M * Bertl yep 1119139024 M * Greek0 can you detail (2) a little more? guest init kills processes, reboot, kernel -> helper, makes sure guest is dead, waits for ctx to terminate, umounts, remounts, starts guest?! 1119139124 M * Greek0 I'm pretty sure I don't understand (2) fully, but (1) sounds better for me, since you save remounting, and that what you save in 2 (the killing) you probably have to do anyway, if you don't want to rely on the guest to do it in any case.