1102464381 M * Doener kinda expected something like that
1102464517 M * Doener Bertl: when did you drop rcu stuff? didn't notice that yet...
1102464577 M * Bertl well, actually the rcu stuff was one attempt to fix a refcount issue
1102464747 M * Bertl after that I moved back to 'normal' refcounting, but left the rcu stuff in ... you'll never know
1102465274 Q * ensc Ping timeout: 480 seconds
1102465443 M * Bertl okay, vshelper for context start/stop works ...
1102465508 M * albeiro :]
1102465592 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102465940 M * rs it wasn't work ?
1102466052 M * Bertl hey rs! if I understand your question right, no, because it wasn't implemented yet ;)
1102466076 Q * ensc Ping timeout: 480 seconds
1102466839 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102466845 M * rs hmm so I don't understand this new feature :)
1102466879 M * rs oh yes I remember now, you send an event when the context is created/deleted
1102466895 M * Bertl precisely!
1102466901 M * rs thus we can bind some start/stop script with correct syncronization ?
1102466923 M * Bertl yes, and it runs on the host and it is synchronous
1102467210 M * Bertl rs: do you want to test something new?
1102467217 M * rs why not
1102467230 M * Bertl I sneaked in some feature (into 1.9.3.10)
1102467242 M * rs which ones ?
1102467256 M * Bertl kind of capability mask ...
1102467296 M * rs means ?
1102467301 M * Bertl allows contexts to have a capability, but disallows certain 'unwanted' effects of that capability
1102467330 M * Bertl so that actually _might_ solve the bind9 issues ...
1102467339 M * rs intersting!
1102467370 M * Bertl so we would need a setup with a failing bind ...
1102467380 M * Bertl and of course the greatest and latest kernel ;)
1102467434 M * rs 2.6.10.. ?
1102467496 M * Bertl 2.6.10-rc3
1102467572 Q * flock Ping timeout: 480 seconds
1102468242 A * albeiro is watching this liek a good sci-fi movie ;]
1102468386 M * albeiro ok, going to (more or less) sleep now
1102468393 M * albeiro cu tommorow !
1102468394 M * Bertl have a good one!
1102468435 M * albeiro thx.
1102468440 A * albeiro hibernates
1102469742 M * rs Bertl: btw, I'm building the kernel
1102469935 M * Bertl okay, keep the source somewhere, so we can cahnge some things easily
1102469944 M * rs yeah
1102469977 M * Bertl sorry, you know that by now ...
1102470353 M * rs :)
1102470460 M * Bertl ah, btw, the kernel oops you reported, did you try with 2.6.10-rc2 as Xu suggested?
1102470475 M * rs on production ?
1102470477 M * rs no :)
1102470486 M * rs I don't want to test an rc kernel on production
1102470496 M * Bertl okay, so we do not know if that is really fixed then ...
1102470522 M * rs yeah and it's not really easy to know, we got the issue only two times in 3 weeks
1102470567 M * Bertl ah, okay ...
1102470702 M * Bertl Doener: any cleanups of the ngnet stuff from your side yet? or still busy testing the code ...
1102470738 M * Doener sorry, got distracted by a visitor...
1102470746 M * Bertl np
1102470894 M * rs Bertl: got a node booted with the rc3-vs1.9.10
1102471183 M * Bertl excellent ...
1102471206 M * Bertl now let's check with the failing bind
1102471215 M * Bertl (i.e. verify that it fails now)
1102471325 M * Bertl IIRC it requires CAP_SYS_RESOURCE ...
1102471333 M * rs yeah
1102471475 M * Bertl okay, let me know when we have a 'failing' bind ...
1102471648 M * Bertl btw, that might be interesting for lycos (and other folks)
1102471650 M * Bertl Subject: Re: Time sliced CFQ io scheduler
1102471650 M * Bertl From: Andrea Arcangeli <andrea@suse.de>
1102471687 M * rs =)
1102471701 M * Bertl he basically says: IMHO the default io scheduler should be changed to cfq.
1102471785 M * rs redhat is really broken...
1102471798 M * Bertl hmm, which one ;)
1102471807 M * rs I tell it to install bind and it depend on half of the distribution
1102471864 M * Bertl okay, vnet dev cleanup almost done
1102472406 M * Bertl rs:  you could check something else in the meantime ... we need a simple test for CAP_SYS_RESOURCE (for example changing some limits)
1102472428 M * rs seems to be really difficult to have a failing bind running...
1102472450 M * Bertl hmm?
1102472807 Q * ensc Ping timeout: 480 seconds
1102473138 M * rs actually, current debian source repository seems unsynced
1102473150 M * rs so bind9 isn't installable... :(
1102473181 M * Bertl hmm ... well, I know that might sounds strange, but what about simply compiling it from source?
1102473211 M * rs yeah why not
1102473257 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102473849 M * rs Bertl: is it possible to avoid nfs mounts (maybe at compile time)
1102473858 M * rs inside vservers that is
1102473879 M * Bertl hmm, you mean forbid?
1102473891 M * rs yes
1102473904 M * Bertl should be possible ...
1102473945 M * rs because a customer tried to mount a remote nfs server and its mount comment is now uninterruptible
1102473963 M * rs then it's vserver can't be stopped
1102474001 Q * tchan Remote host closed the connection
1102474015 M * Bertl hmm, okay, I'll investigate this 'feature' after I finished the cleanup
1102474026 M * rs thx :)
1102474493 J * matti matti@linux.gentoo.pl
1102474676 M * Bertl welcome matti!
1102474691 M * Bertl rs: well I guess that goes for the other network based filesystems too, right?
1102474709 M * rs hmm not really necessary for us but why not
1102474721 M * rs we don't include support for other network based fs
1102474729 M * Bertl i.c.
1102474753 M * Bertl well, that might change in the future I guess ...
1102474874 M * matti Bertl: Hello! :]
1102474885 M * matti Bertl: What's up? :]
1102474897 M * Bertl new ngnet stuff of course ...
1102474903 M * matti O! WOW! :]
1102474906 M * matti :]
1102475237 M * Bertl Doener: what is your opinion on network based (kernel side) mounts from within contexts? should we forbid them in general? should we make it a flag?
1102475271 M * Bertl of course, everybody else feel free to state your opinion too ;)
1102475354 M * Bertl hmm .. s/your/his/her/
1102475358 M * rs wow got a failing bind...
1102475367 M * Bertl great! ;)
1102475384 M * rs Starting named: named: capset failed: Operation not permitted
1102475392 M * rs still failing with the new kernel
1102475399 M * Bertl yeah, expected
1102475417 M * Bertl okay, now try with ulimit to raise the hard limit ...
1102475440 M * Bertl (or something like that, it's supposed to fail too, or be silently ignored)
1102475484 M * rs ignored
1102475508 M * Bertl checked with ulimit -Ha
1102475523 M * rs oups
1102475536 M * rs I can raise limits
1102475549 M * Bertl yeah, actually that is a feature ;)
1102475558 M * rs it's wanted ?
1102475564 M * Bertl but an old one, as matter of fact ...
1102475586 M * Bertl sec .. looking for the cap
1102475590 M * rs user shouldn't be able raise hard limits we set in the vserver config
1102475630 M * Bertl 2 linux/vserver/context.h 52 #define VXC_SET_RLIMIT 0x00000002
1102475657 M * Bertl just remove that ccap, and he/she will not be ...
1102475723 M * Bertl but actually the rlimits are no real issue IMHO
1102475744 M * rs it's not like rlimit we setup in the configure is it ?
1102475759 M * Bertl nope, they can not be surpassed
1102475764 M * rs ok
1102475772 M * rs so yes, it's not an issue
1102475784 M * Bertl so actually the following limits can be raised without any control:
1102475817 M * Bertl core file size, data seg size, file size, pipe size, stack size, cpu time
1102475849 M * Bertl where the file sizes get limits from the disk limit of course
1102475872 M * rs so it's not an issue at all I guess
1102475886 M * Bertl okay, so lets remove that CCAP for now
1102475904 M * Bertl so that we can test with the ulimit (against CAP_SYS_RESOURCE)
1102475914 M * rs ulimit -Hn 5000
1102475915 M * rs -bash: ulimit: open files: cannot modify limit: Operation not permitted
1102475922 M * Bertl excellent ...
1102475951 M * Bertl okay, now we check if bind is happy with CAP_SYS_RESOURCE
1102475961 M * Bertl (i.e. please add it to the list of caps)
1102476018 M * rs hmm like this: vattribute --bcap CAP_SYS_RESOURCE --xid 115 ?
1102476031 M * Bertl will require a restart ...
1102476043 M * rs why ?
1102476043 M * Bertl (the bcaps are inherited)
1102476056 M * rs ok
1102476077 M * Bertl well, actually it would be sufficient to raise the bcaps and transfer the required cap to each process
1102476087 M * Bertl but that is a pita ...
1102476176 M * rs named now start correctly
1102476211 M * Bertl excellent, okay, check with the ulimit that you can raise the limits now ...
1102476220 M * Bertl (make sure the ccap is removed)
1102476230 M * rs I can
1102476251 M * Bertl okay, now we have to change a line in the kernel source and recompile the kernel
1102476262 M * rs ok
1102476269 M * Bertl include/linux/vserver/context.h ~49
1102476274 M * Bertl #define VXC_CAP_MASK            0x00000000
1102476297 M * Bertl CAP_SYS_RESOURCE is cap #24 .. so we have to set bit 24 here
1102476315 M * Bertl #define VXC_CAP_MASK            0x01000000
1102476348 M * rs how does this mask work ?
1102476361 M * Bertl well, it's a little tricky ...
1102476371 M * Bertl basically there are checks like this:
1102476376 M * Bertl capable(blabla)
1102476379 M * rs it just make the maching caps ignored
1102476381 M * rs ?
1102476382 M * Bertl all over the kernel
1102476388 M * rs yeah
1102476405 M * Bertl and this check is modified by the recent code to do something like this:
1102476457 M * Bertl if (old_capable(foo) && mask(foo) && ^ccap(foo << 16)) return not_capable;
1102476479 J * tchan ~tchan@c-24-13-81-164.client.comcast.net
1102476495 M * Bertl so you get a new ccap for that flag, which decides if the capability can be 'utilized'
1102476518 M * Bertl welcome tchan!
1102476549 M * Bertl in addition to that, there is a check which allows to make ccap to depend on the real caps
1102476562 M * Bertl (that wasn't english at all)
1102476570 M * rs haha :)
1102476592 M * Bertl in addition to that, there is a new check, which allows to make a ccap depend on the real cap
1102476610 M * rs you change need a recompilation of all files of the kernel :/
1102476639 M * Bertl (yeah, I know ;) so for example, the VXC_SET_RLIMIT could be made to depend on the CAP_SYS_RESOURCE
1102476672 M * Bertl which in turn would allow to give a 'limited' CAP_SYS_RESOURCE, which can be controlled from within the vserver
1102476728 M * Bertl (think about the possibilities while the kernel compiles ;)
1102476789 M * rs so we have to find the right value for this mask right?
1102476820 M * rs or you will change this mask at compile time, depending on some configuration?
1102476834 M * Bertl once everything has been updated to this mechanism, the mask will basically be the entire mask of context available flags
1102476839 M * Bertl s/flags/ccaps/
1102476894 M * rs so mask will become unecessary ?
1102476919 M * Bertl well, it will become a 'fixed' subset of all caps ...
1102476928 M * rs ok
1102477167 Q * virtuoso Remote host closed the connection
1102477182 J * virtuoso ~s0t0na@spb.sot.com
1102477189 M * Bertl wb virtuoso!
1102477221 M * rs ok got new kernel
1102477245 M * rs how to test now ?
1102477291 M * Bertl basically the same but the other way round ... first test with the CAP_SYS_RESOURCE given
1102477338 M * Bertl we 'expect' the bind to succeed now, but the ulimit to fail (without VXC_SET_RLIMIT)
1102477374 M * albeiro you should really be all sleeping now ;]
1102477405 M * rs albeiro: agreed :)
1102477420 M * Bertl hey albeiro, is that you? 02:14  * albeiro hibernates
1102477424 M * rs Bertl: named fail now
1102477449 M * Bertl hmm, with the same message or a new one?
1102477456 M * albeiro sure, didn't you knew i can irc even where sleeping ?
1102477473 M * Bertl hibernated, please!
1102477475 M * rs the same
1102477492 M * Bertl check if you have CAP_SYS_RESOURCE inside the context
1102477497 M * albeiro i have special usb MindInterfaceDevice ;p
1102477523 M * Bertl ah, that explains it ...
1102477551 M * rs I don't really know how to check that :)
1102477565 M * Bertl grep Cap /proc/self/status ?
1102477567 M * rs BCaps:  ffffffffd44c04ff
1102477663 M * rs is it enabled ?
1102477687 M * Bertl don't know, please execute the grep inside ;)
1102477706 M * Bertl but the bcaps says no
1102477711 M * rs CapInh: 0000000000000000
1102477711 M * rs CapPrm: 00000000d44c04ff
1102477712 M * rs CapEff: 00000000d44c04ff
1102477724 M * Bertl nope, no CAP_SYS_RESOURCE ...
1102477741 M * Bertl hmm, since when do we have 64bit caps?
1102477747 M * albeiro i wonder how you can interpret them in mind
1102477768 M * Bertl it's actually easy ...
1102477799 M * rs ok now it's activated and works
1102477822 M * Bertl a byte = 2 nybbles = 8 bits
1102477834 M * Bertl so 00 = byte and 8 bits
1102477852 M * Bertl bit number 8 therefor has hex 0x0100
1102477869 M * Bertl bit number 24 (the one here) has 0x01 00 00 00
1102477891 M * Bertl d4 = d0 | 04 which is bit 26 ;)
1102477922 M * Bertl it will now have a d5 there ;)
1102477925 M * rs you aren't made like us Bertl :) (like me at least :)
1102477944 M * Bertl okay, so bind works, right?
1102477951 M * rs yeah :)
1102477964 M * Bertl okay, did you remove the VXC_SET_RLIMIT?
1102477971 M * rs no not yet
1102477977 M * Bertl okay, try without that
1102477978 M * albeiro ok, i will re-think it another time ;]
1102477995 M * Bertl albeiro: just start counting sheeps in binary ...
1102478003 M * Bertl 1, 10, 11, 100, 101 ...
1102478012 A * albeiro uses CAP_SYS_SLEEP_WITHOUT_IRC_CONNECTION
1102478027 M * albeiro Bertl: good idea, will try ;p
1102478031 M * Bertl ;)
1102478049 M * rs Bertl: hmm now I can't kill bind :)
1102478056 M * rs # killall named
1102478058 M * rs named(1948): Operation not permitted
1102478059 M * rs ...
1102478081 M * Bertl hmm, that is at least 'unexpected' ;)
1102478095 M * rs hehe funny :)
1102478108 M * rs with or without the ccap
1102478115 M * rs I can't kill root processes :)
1102478117 M * Bertl you're sure you didn't remove any other cap accidentially?
1102478131 M * rs hmm
1102478139 M * Bertl like the CAP_KILL for example ;)
1102478155 M * rs CapInh: 0000000000000000
1102478155 M * rs CapPrm: 0000000000000000
1102478156 M * rs CapEff: 0000000000000000
1102478158 M * rs fun :)
1102478161 M * Bertl hehe ;)
1102478176 M * rs but I did this with just removing rlimit ccap??
1102478257 M * Bertl could be, I've lost the perspective regarding the userspace tool/system calls
1102478284 M * Bertl so it might be that some util-vserver invocation removed the bcaps too
1102478303 M * Bertl after the next fork/enter, that mask will hit you like that
1102478310 M * rs yeah since the mask change, removing ccap remove all bcaps too
1102478323 M * rs wasn't the case before
1102478354 M * Bertl hmm, sounds weird ... but okay, can we restore the bcaps for now?
1102478372 M * rs how ?
1102478409 M * rs we will continue tomorrow, I'm too tired for now :)
1102478425 M * Bertl okay, you basically know what to test ...
1102478435 M * rs yeah :)
1102478438 M * Bertl thanks for your time!
1102478442 M * rs see you tomorrow :)
1102478444 M * Bertl cya
1102478446 M * rs thx for yours :)
1102478453 M * Bertl you're welcome!
1102478458 Q * rs Quit: zZzZ
1102478946 J * sam_ ~sam@ppp141-160.lns1.adl2.internode.on.net
1102479001 M * Bertl welcome sam_!
1102479111 M * sam_ hi
1102479137 M * sam_ just one quick question atm ... where do i set the vserver root directory for util-vserver?
1102479161 M * Bertl which version of util-vserver?
1102479187 M * sam_ the debian backports 0.29-4
1102479218 M * Bertl well, I really don't know those ...
1102479235 M * Bertl but I'd say, it is probably based on the stable util-vserver branch
1102479259 M * Bertl and IIRC, those tools fixed the path at compiletime
1102479274 M * sam_ i tried changing VROOTDIR in /usr/lib/util-vserver/util-vserver-vars but that didnt do anything
1102479275 M * sam_ oh ok
1102479303 M * Bertl give me a minute to verify that ...
1102479307 M * sam_ k
1102479398 M * Bertl do you have a vserver-info tool?
1102479436 M * sam_ no
1102479458 M * Bertl okay, then it really looks like it's fixed ...
1102479473 M * Bertl for debian probably somewhere in /var ...
1102479490 M * Bertl (i.e. it's specified at compile time)
1102479498 M * sam_ yea  ... /var/lib/vservers/
1102479508 M * sam_ ok well i have a couple options then
1102479510 M * sam_ either symlink
1102479521 M * sam_ or compile
1102479523 M * Bertl or --bind mounts ...
1102479546 M * mugwump sam_: dpkg-reconfigure vserver
1102479571 M * Bertl that works?
1102479573 M * mugwump maybe dpkg-reconfigure util-vserver
1102479591 M * sam_ nup dpkg-reconfigure doesnt do anything
1102479592 M * mugwump sure.  all that the configure time option did was munge up the shell scripts.
1102479629 M * sam_ i cant compile on this machine tho because its only running off of a small compact flash
1102479642 M * Bertl hey sounds cool!
1102479653 M * mugwump I'd use a symlink
1102479683 M * Bertl sam_: what arch is that?
1102479693 M * mugwump or perform surgery on the .deb using `ar'
1102479723 M * sam_ i386
1102479756 M * Bertl ah, PC104?
1102479778 M * sam_ PC104?!? :s
1102479813 M * Bertl hmm, okay so just an i386 with a flash I guess ...
1102479828 M * sam_ yea thats pretty much it
1102479871 M * Bertl and what is it doing, if I may ask?
1102479895 M * Bertl (just curious)
1102479945 M * sam_ it basically mounts a raid array which holds each of the vservers
1102479978 M * Bertl okay, so the 'flash' boot replaces a CD or floppy ...
1102479986 M * sam_ my superiors believe it will add extra security doing it that way because the compact flash is (kind of) write protected
1102479998 M * sam_ yea the flash is running pebble
1102480007 M * sam_ http://www.nycwireless.net/pebble/
1102480014 M * Bertl i.c., thanks for the info!
1102480029 M * sam_ np
1102480121 M * sam_ ok well creating the symlink works fine
1102480175 M * sam_ second question ... has anyone used whitebox linux as a vserver?
1102480224 M * sam_ or does anyone have any opinions on whitebox linux - good or bad?
1102480261 M * Bertl seems there is somebody offering such vservers
1102480281 M * Bertl [Sandino.NET], México
1102480282 M * Bertl Offering GR Security protected vservers with Gentoo, Fedora, Red Hat or White Box.
1102480301 M * Bertl so it seems to work (at least after some modifications)
1102480452 M * Bertl aside from that, I have no opinion to whitebox linux ;)
1102480463 M * sam_ ok thanks though
1102480479 M * Bertl you're welcome!
1102480897 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1102480979 M * Bertl welcome flock!
1102481352 J * _no_x ~vps@c150229.adsl.hansenet.de
1102481362 M * Bertl welcome _no_x!
1102481450 Q * no_x Ping timeout: 480 seconds
1102481451 N * _no_x no_x
1102483122 Q * sam_ Quit: Leaving
1102483809 M * Loki|muh moin
1102483831 M * Bertl moin! and a good night/day I guess 
1102483894 M * Loki|muh hehe, just came back from night duty and in a hour i'm going to uni ;)
1102483924 M * Bertl sounds good ...
1102483951 M * Bertl but for me it's time to go to bed ... 
1102483964 M * Loki|muh sleep well ;)
1102483968 M * Bertl thanks!
1102483971 M * Bertl have a good whatever everyone!
1102483977 N * Bertl Bertl_zZ
1102485268 J * doug- douglas@68-170-50-227.ontrca.adelphia.net
1102485283 M * matti Bertl_zZ: Good night :]
1102485290 M * doug- hey everyone, just curious on using vserver with mrtg
1102485299 M * doug- anyone know of a howto to set that up?
1102488014 Q * ensc Ping timeout: 480 seconds
1102488976 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102494503 J * jsambrook ~jsambrook@aelfric.plus.com
1102494794 P * jsambrook 
1102497457 Q * ensc Ping timeout: 480 seconds
1102498397 J * rs rs@ice.aspic.com
1102498400 M * rs hi
1102499527 Q * pusling Ping timeout: 480 seconds
1102499708 J * pusling ~pusling@cpe.atm4-0-7285.0x50c44806.boanxx19.customer.tele.dk
1102500039 Q * mcp Ping timeout: 480 seconds
1102501409 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102505495 Q * grecea Remote host closed the connection
1102505557 Q * ensc Ping timeout: 480 seconds
1102505755 J * grecea ~grecea@h-195-22-237-74.mdl.net
1102506214 Q * virtuoso Ping timeout: 480 seconds
1102509390 M * Eyck doug-: what exactly are you trying to do?
1102509400 M * Eyck doug-: mrtg works out-of-the-box inside vserver..
1102510045 Q * doug- Quit: Lost terminal
1102511359 J * BWare ~bware@212.26.196.41
1102514713 Q * sannes Read error: Connection reset by peer
1102516216 J * jsambrook ~jsambrook@aelfric.plus.com
1102516247 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102516868 J * virtuoso ~s0t0na@172ppp10.telegraph.spb.ru
1102517043 Q * ensc Ping timeout: 480 seconds
1102517110 J * Shuri Shuri@dsl.speedline209.226.electronicbox.net
1102521680 J * sannes ~ace@home.skarby.no
1102522356 N * Bertl_zZ Bertl
1102522360 M * Bertl morning folks!
1102522393 M * albeiro morning (? more or less... ;)
1102522431 M * albeiro are you sure Austria is still part of Europe ?
1102522432 M * Bertl well, I 'just' got up ... and the daystar can't be seen anymore ... so it has to be morning, right? ;)
1102522443 M * albeiro ;p
1102522445 M * albeiro 06:32:31      Bertl : but for me it's time to go to bed ...
1102522462 M * albeiro everybody knows that coding is better at night
1102522497 M * albeiro look at MS windows - it was coded in the very morning thx to strong caffe ;p
1102522780 M * Bertl yeah, right! ;)
1102523097 Q * virtuoso Read error: Connection reset by peer
1102523262 Q * Shuri Ping timeout: 480 seconds
1102523362 Q * tchan Remote host closed the connection
1102523564 Q * Johan Remote host closed the connection
1102524085 M * rs "morning" Bertl 
1102524087 M * rs :)
1102524095 M * Bertl hey rs! how are you?
1102524106 M * rs fine thx 
1102524106 J * Shuri Shuri@dsl.speedline209.226.electronicbox.net
1102524124 M * Bertl welcome Shuri!
1102524153 J * mcp ~hightower@81.17.110.148
1102524197 M * albeiro hello mcp :)
1102524257 M * Shuri re
1102524259 M * rs Bertl: you were talking about using CFQ IO scheduler for vds, was only for the filer or you think it could be interesting for nodes too ?
1102524404 M * Bertl both, and I guess the node can benefit a lot from that
1102524429 M * rs not the filer ?
1102524442 M * rs could solve the sync export issue
1102524446 M * Bertl of couse, I assume the filer will benefit ...
1102524458 M * rs worth a try
1102524771 M * Bertl definitely
1102525201 M * Bertl rs: did you make any further tests with the cap mask or just got up too?
1102525236 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102525268 M * rs not yet but I'm ready to continue testing
1102525268 Q * ensc Read error: Connection reset by peer
1102525402 M * Loki|muh does every vserver handle his own librarys? how are they handled?
1102525431 M * Bertl depends, if you use unified libraries, then they are 'shared' ...
1102525487 M * daniel_hozac how about in memory?
1102525519 M * matti Hmm...
1102525531 M * Bertl if the libraries have separate inodes, they get mapped anew
1102525580 M * Loki|muh thx
1102525878 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de
1102526849 M * Bertl hmm, seems I constantly fail to do an ifconfig <dev> down from inside the kernel ...
1102526938 M * Eyck and it's a bad thing?
1102526960 M * Bertl well, it hangs the kernel if you take down a context :(
1102526972 M * Bertl unregister_netdevice: waiting for lo to become free. Usage count = 1
1102526973 M * Bertl unregister_netdevice: waiting for lo to become free. Usage count = 1
1102526995 M * rs Bertl: about our tests, what could I do now ?
1102527004 M * Bertl Eyck: rie ne va plus!
1102527020 M * rs :)
1102527035 M * Bertl rs: the first step is a) to figure where the bcaps where lost
1102527056 M * Bertl and b) to verify that bind starts, but ulimit fails
1102527075 M * Bertl (assumed that the VXC_SET_LIMIT is not set)
1102527082 M * rs for bcaps do you have some clue about how to track it down ?
1102527132 M * Bertl I would assume it's some kind of bug ... either in userspace or kernel space
1102527145 M * Bertl a good idea would be to try the vflag/vcaps tools ...
1102527175 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/vflags-0.01.tar.bz2
1102527200 M * Bertl if they show the same 'odd' behaviour, then it has to be a kernel issue, and I'll look into that ...
1102527878 Q * sannes Read error: Connection reset by peer
1102527958 M * rs cfq io scheduler doesn't help much for our sync export issue
1102528143 M * rs Bertl: could you remind me how to remove rlimit ccap with you tool ?
1102528274 M * Bertl sec, I have to remind myself first ...
1102528298 M * rs I guess it's vccaps -C something
1102528307 M * rs I guess it's vccaps -x xid -C something
1102528311 M * rs I need this something :)
1102528399 M * Bertl it's the flag number ...
1102528451 M * Bertl #define VXC_SET_RLIMIT 0x00000002
1102528457 M * Bertl so it's bit 1
1102528470 M * Bertl vccaps -x xid -C 1
1102528699 M * Bertl Doener: you around?
1102528784 M * rs ok so if I clear this ccap
1102528797 M * rs I still can raise rlimits
1102528831 M * Bertl hmm ...
1102528835 M * Bertl sec
1102528916 M * Bertl what does cat /proc/virtual/<xid>/status report?
1102528937 M * rs UseCnt: 35
1102528937 M * rs RefCnt: 33
1102528937 M * rs Flags:  00100000030b0310
1102528937 M * rs BCaps:  ffffffffd54c04ff
1102528937 M * rs CCaps:  0000000000010101
1102528940 M * rs Ticks:  0
1102529148 M * Bertl hmm and 'grep Cap /proc/self/status' from inside?
1102529159 M * rs CapInh: 0000000000000000
1102529160 M * rs CapPrm: 00000000d54c04ff
1102529160 M * rs CapEff: 00000000d54c04ff
1102529170 Q * anonymous-coward uranium.oftc.net xenon.oftc.net
1102529217 J * Johan ~johan@ip5451c51a.direct-adsl.nl
1102529218 M * Johan Hi all
1102529229 M * Bertl hey Johan!
1102529260 M * Bertl rs: hmm and your rlimit was higher than the one set before?
1102529266 M * Johan heya
1102529275 J * anonymous-coward ~nwalsh@shaggy.internode.com.au
1102529304 M * rs yeah
1102529318 M * rs vserver145:~# ulimit -Hn
1102529318 M * rs 5000
1102529318 M * rs vserver145:~# ulimit -Hn 6000
1102529318 M * rs vserver145:~# ulimit -Hn
1102529318 M * rs 6000
1102529332 M * Bertl strange, guess we have to put in some debug output ...
1102529360 M * Bertl let's add a single debug statement first (which doesn't do much recompile)
1102529377 M * Bertl kernel/sys.c ~1507
1102529392 M * Bertl right after old_rlim = current->signal->rlim + resource;
1102529486 M * Bertl printk("--- %d,%ld\n", capable(CAP_SYS_RESOURCE), vx_ccaps(VXC_SET_RLIMIT));
1102529539 M * Bertl hmm, sec ... gcc will complain
1102529570 M * Bertl let's make that:
1102529584 M * Bertl printk("--- %d,%lld\n", capable(CAP_SYS_RESOURCE), vx_ccaps(VXC_SET_RLIMIT));
1102529719 M * rs lets try
1102530020 J * tchan ~tchan@c-24-13-81-164.client.comcast.net
1102530070 M * Bertl wb tchan!
1102530364 M * rs ok so
1102530391 M * rs got some --- 0,2
1102530421 M * Bertl hmm, so VXC_SET_RLIMIT is still on ...
1102530424 M * rs then --- 0,0
1102530455 M * Bertl okay, but with 0,0 you can not raise the ulimts, can you?
1102530461 M * rs  ulimit -Hn 1000
1102530461 M * rs -bash: ulimit: open files: cannot modify limit: Invalid argument
1102530485 J * DuckKing ~Duck@dyn-83-154-126-121.ppp.tiscali.fr
1102530490 M * Bertl good, so where did we get the 0,2 first?
1102530503 M * rs dunno exactly
1102530503 M * Bertl welcome DuckKing!
1102530518 M * Bertl rs: okay doesn't really matter, try to start the bind now
1102530544 M * rs named: capset failed: Operation not permitted
1102530544 M * rs named: capset failed: Operation not permitted
1102530579 M * Bertl grep Cap /proc/self/status ?
1102530591 M * rs CapInh: 0000000000000000
1102530591 M * rs CapPrm: 00000000d44c04ff
1102530591 M * rs CapEff: 00000000d44c04ff
1102530594 M * rs hum
1102530599 M * rs should be d5
1102530603 M * Bertl ah, okay, we are missing the cap
1102530621 M * Bertl let's add that one (but to the vserver config)
1102530631 M * Bertl and let's restart the vserver ...
1102530659 M * rs ok so the vserver is started with right cap
1102530661 M * rs got --- 1,2
1102530671 M * rs then I remove the rlimit
1102530682 M * Bertl the VXC flag ...
1102530706 M * rs ok so now
1102530710 M * rs ulimit doesn't work
1102530713 M * rs but bind start
1102530717 M * Bertl yes?
1102530720 M * rs yes
1102530722 M * Bertl great!
1102530747 M * rs can't really understand what I did different than before
1102530763 M * Bertl don't worry ... there are so many parameters ...
1102530772 M * rs two... :)
1102530774 M * Bertl what does the debug message log now?
1102530785 M * rs --- 1,2
1102530785 M * rs --- 1,2
1102530785 M * rs --- 1,0
1102530785 M * rs --- 1,0
1102530785 M * rs --- 1,0
1102530787 M * rs --- 1,0
1102530797 M * Bertl rs:  it looks like two, but it's much more complicated here ...
1102530822 M * Bertl and the output doesn't seem right ... sec
1102530823 M * rs yeah ok, but it's not that many to deal with on my side, I guess I did something wrong
1102530859 M * Bertl do you have CONFIG_SECURITY=y in your setup?
1102530864 M * Bertl (kernel config that is)
1102530879 M * rs # CONFIG_SECURITY is not set
1102530885 M * Bertl okay good ..
1102530912 Q * DuckMaster Ping timeout: 480 seconds
1102530932 M * Bertl let's add another debug line, but that one will cause a larger recompile
1102530948 M * Bertl (I'll schedule dinner for me ;)
1102530960 M * rs for me too :)
1102530971 M * Bertl include/linux/sched.h ~892
1102530974 M * rs but lets do it before
1102530986 M * Bertl right before:
1102530987 M * Bertl         if ((cap & VXC_CAP_MASK) && !vx_mcaps(cap))
1102531019 M * Bertl oops .. sec
1102531040 M * Bertl I guess I found the bug ...
1102531046 M * rs haha ;)
1102531047 M * Bertl andyway, let's modify that to:
1102531098 M * Bertl printk("+++ %d,%d\n", cap, vx_mcaps(cap));
1102531112 M * rs in the if clause ?
1102531119 M * Bertl if (((1 << cap) & VXC_CAP_MASK) && !vx_mcaps(cap))
1102531135 M * Bertl so the printk() before the modified if
1102531141 M * rs k
1102531210 M * rs include/linux/sched.h: In function `capable':
1102531211 M * rs include/linux/sched.h:892: warning: int format, different type arg (arg 3)
1102531211 M * rs include/linux/sched.h:892: warning: int format, different type arg (arg 3)
1102531218 M * Bertl hmm, yes
1102531221 M * Bertl should be:
1102531230 M * Bertl printk("+++ %d,%lld\n", cap, vx_mcaps(cap));
1102531237 M * Bertl I always forget that ...
1102531253 M * rs ok compiling
1102531264 M * Bertl okay, enjoy your dinner ;)
1102531275 M * rs thx, same for you :)
1102531278 M * Bertl back later ...
1102531288 N * Bertl Bertl_oO
1102531310 Q * rs Quit: home
1102534850 J * sannes ~ace@home.skarby.no
1102535081 Q * jsambrook Quit: Download Gaim: http://gaim.sourceforge.net/
1102540915 Q * Shuri Quit: 
1102541709 Q * sannes Read error: Connection reset by peer
1102541777 Q * tchan Remote host closed the connection
1102543047 J * tchan ~tchan@c-24-13-81-164.client.comcast.net
1102546219 Q * brc Ping timeout: 480 seconds
1102546514 Q * Johan Remote host closed the connection
1102546807 M * Eyck so.. this would be the perfect time for 'good morning Bertl' ?
1102547567 Q * no_maam Ping timeout: 480 seconds
1102547884 M * Loki|muh I guess so *g*
1102548380 M * albeiro Eyck: not yet, he will be back in some time ;]
1102548675 J * sannes ~ace@home.skarby.no