[00:01] Edgan (edgan@proton.cygnusx-1.org) joined #vserver. [00:01] hi Edgan! [00:01] Bertl: Hello [00:10] what brings you here? [00:25] nathan_: any news? [00:30] Bertl, still running crashing stuff [00:30] so it is stable with the modifications, right? [00:31] only started a few minutes go, seems to be [00:31] the // IMHO stuff [00:37] Bertl, did you say you sorted the -1 issue out? [00:37] hmm, well, I said, I (guess I) know what it is, but we have to do some testing ... [00:37] ok [00:38] well i just loaded up all the tests with the console coming to my house [00:38] so they will leave my other box alone [00:38] worst case i lose this testing box [00:38] 16:39:52 up 2:24, 6 users, load average: 530.56, 387.93, 133.04 [00:38] SCHED_RR shells are the best [00:38] box seems to be doing fine [00:39] dam [00:39] load! [00:39] nathan, what the heck are you doing? [00:39] browsing the web, what? whats wrong? [00:39] lol [00:39] Bertl: how can I help you with memory limit? so it will be available for vs1.22 and 1.3.x. [00:39] nathan, want my cpuslam.sh? [00:39] it's guaranteed for 1000 load avg [00:40] infowolfe, does it test vserver or just the main context? [00:40] nathan, it'll slam the cpu of... well, anything that has ssh-keygen :-D [00:40] how you "stop" it is killall -9 ssh-keygen :-D [00:40] infowolfe, ah, i want more context switches than that :) [00:40] thanks though [00:41] well, get into the context, and run 500 ssh-keygens :-D [00:41] noel: hmm, if you volunteer to do some testing, I can do a patch very quick ... [00:41] with -b 8192 -t rsa -f /dev/null [00:41] infowolfe, i need processes dying quickly and respawning [00:41] not cpu bound processes [00:41] Bertl: sure. i'm testing. later also on sparc [00:41] infowolfe: nathan is using kilelr ... [00:41] killer I mean ... [00:42] i'll have to take a look at it [00:42] hmm, you 'should' wait for vs1.3.3 ;) [00:42] otherwise your vserver box will be down in a minute (at most) [00:42] Bertl, id say this box is solid with the stuff we are testing [00:42] okay [00:43] ah, custom made vserver stress-testing [00:43] Bertl, btw what about the ip code? you confident in that or do we want to do some strss testing as well? [00:43] just let me update the patch a 1.3.2.5 ... [00:43] i use cpuslam to burn in processors :-D [00:43] nathan_: and you can think about a ip stress testing variant [00:43] ok [00:44] i have to go get some bananas, ill leave this running and ill be back in about 20m [00:44] oki, cu later, and thanks for testing ;) [00:44] noel: you have some time for mem limits? [00:46] Bertl: yes. its the reason why I'm asking. Its a feature which I would like to have and I want help testing. [00:46] okay, I just meant right now? right? [00:47] Bertl: yes. If you have the time. we are in the same timezone afaik and I have time until 1 or 2 o'clock.:) [00:47] great ... [00:47] so lets start ... [00:47] Bertl: :) [00:49] Bertl: have a runing 2.4.23-vs1.22 testbox (sadly all my testmachines (one i386, one sparc and one sparc64) are not available from the internet, but if I get a feature working I will reproduce it on sparc) [00:52] sounds good to me ... [00:54] http://vserver.13thfloor.at/Experimental/delta-2.4.23-vs1.3.2-vs1.3.2.5.diff [00:55] this is a patch ontop of vs1.3.2 ... we will use this as a basis for the mem limits ... [00:56] ah. ok. I will have to build 1.3.2 with this delta... [00:56] yes, and an additional memory limit patch, I'm currently working on ... [00:57] but in the meantime you could test this version (1.3.2.5) on sparc, if possible ... [00:57] Bertl, if you can give me a pointer on what software i should use to get a kernel up quick for testing, let me know and i'll test in parallel [00:57] hmm, you need a compiler (gcc 2.95/2.96 preferred) [00:58] gnumake, ncurses, a .config file for your machine ... [00:58] Bertl... that's not what i'm talking about [00:58] lol [00:58] what should be used as the virtual machine... [00:58] ahh .. I'm using QEMU and currently trying to fix bochs, because of the SMP emulation ... [00:59] bochs has smp emulation? [00:59] well, sort of .... [00:59] Bertl: sorry. the 2 sparc are only at work and I have no access to them via the net. I will take the sparc32 with me on monday so I can test more often. [00:59] ah okay, np ... TIA ... [01:00] Bertl, i'm lost, give me a little time, i'm trying to get a gentleman that i'm working doing some vserver automation for to send me a dual p3 [01:00] and i can get a sparc from work also [01:00] (both running gentoo to make sure that we're not having problems with using the latest glibc/gcc) [01:01] and i'll probably dual-boot the sparc with gentoo/aurora (since they're the most stable 2 i've seen on sparc... ps i don't like debian) [01:01] hmm, what we will need soon are special test cases, or automated scripts which do some regression/stability tests ... [01:01] bertl, when i get the hardware, i'll give you net access [01:02] and you can directly do whatever you want... [01:02] hmm, thanks, but that wasn't what I meant ... [01:02] ok [01:02] what did you mean then? [01:03] that we will need to do some automated testing scripts/tools/etc ... [01:03] oh, well, if it can be written in bash, i can do it :-D [01:03] hmm, sounds good, you know my testme.sh bash virus? [01:04] nope [01:04] http://vserver.13thfloor.at/Stuff/testme.sh [01:04] reading it now [01:05] it's a basic function test for vserver .. can be extended easily ... [01:05] why'd you call it a virus? [01:06] definitely cute... [01:06] because the first person I asked to run it, believed that it would do something bad ... [01:06] LMFAO [01:06] they obviously didn't read it [01:07] altogether, very pretty... it's what i've come to expect from you Bertl... [01:07] very... efficient [01:07] hmm, thanks ... [01:08] the fact that it includes help... VERY nice... i usually don't allow help features, you have to read it to use it (or be me :-p) [01:08] Action: infowolfe thinks it keeps his boss from doing stupid things with his scripts [01:22] ozan (~ozan@dsl81-215-18120.adsl.ttnet.net.tr) joined #vserver. [01:22] hi ozan! [01:23] hello ... [01:23] what up ? [01:23] well, we are stress testing vserver ... [01:24] umm cool [01:24] and it seems, we fixed some race issues on SMP ... [01:26] super... i was tring to install rh9.0 :) [01:26] may be you can help.. [01:26] with RH 9.0 installation? [01:26] i am using the install-rh9.0 name minimum .. on a debian woody .. [01:28] but rpm gives dep errors.. i added --nodeps but this time gived "need xmb space" for a lot of packages... [01:33] hmm, which tools? what version? [01:33] util-vserver-0.26 [01:34] script is install-rh9.0 [01:34] my kernel is 2.4.23-vs1.1.6 [01:35] hmm, enrico usually favours the apt-get-rpm solution for installation ... [01:35] apt-get-rpm ? [01:35] but I haven't tried the install-rh9.0 script yet ... [01:36] you mean apt-get rpm ? i got rpm installed v4.0.3 [01:36] nope, there is an apt based rpm installation tool somewhere ... [01:36] umm time to google .. [01:37] it basically does the same apt-get does but with rpms ... [01:38] umm you mean , apt-rpm , like debootstrap ... first install apt-rpm then do thinks with it .. umm sounds nine [01:38] ahh, savannah is up again ... [01:38] http://savannah.nongnu.org/projects/util-vserver [01:38] IIRC he has some docu there ... [01:40] noel: we are getting somewhere, you can start preparing some memory test scenarios ... [01:41] compile problem with 1.3.2.5: [01:41] gcc -D__KERNEL__ -I/usr/src/linux-2.4.23-vs1.3.2/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6 -nostdinc -iwithprefix include -DKBUILD_BASENAME=array -c -o array.o array.c [01:41] array.c: In function `proc_pid_stat': [01:41] array.c:398: request for member `vx_initpid' in something not a structure or union [01:41] make[3]: *** [array.o] Error 1 [01:41] make[3]: Leaving directory `/usr/src/linux-2.4.23-vs1.3.2/fs/proc' [01:41] make[2]: *** [first_rule] Error 2 [01:41] make[2]: Leaving directory `/usr/src/linux-2.4.23-vs1.3.2/fs/proc' [01:41] make[1]: *** [_subdir_proc] Error 2 [01:41] hmm ... let me verify ... [01:43] hmm okay, please replace the . in current->vx_info.vx_initpid by a -> [01:43] tanjix (ViRu_@pD904A06C.dip.t-dialin.net) left irc: [01:44] Edgan (edgan@proton.cygnusx-1.org) left #vserver (Client exiting). [01:45] ok.... [01:46] now I have this line: current->vx_info->vx_initpid == ppid) [01:46] yup ... [01:47] that should work ... [01:50] compile... [02:12] maybe I need a fast machine if I test more often;) ok. ready 2.4.23-vs1.3.2 [02:12] you do not need to recompile everything if you patch the 'next' patch (memory limits) ... just a make dep; and then make bzImage ... [02:14] :) jepp. but its still a slow k6. [02:14] vendor_id: AuthenticAMD [02:14] model name: AMD-K6(tm) 3D processor [02:15] cpu MHz: 400.917 [02:15] model name : AMD-K6(tm) 3D+ Processor [02:15] stepping : 1 [02:15] cpu MHz : 400.917 [02:16] see the "+";) [02:16] umm apt worked nice :) [02:16] hey great ... [02:16] thanks for the light Bertl [02:17] maybe you could add that somewhere on linux-vserver.org? [02:18] yes of course .. i will re check the deps .. there is some rpms hadto install first ..may be i can write a little script for it... [02:18] ive never cut so many bananas in my life [02:18] ok bert what do you have for me [02:18] 18:19:42 up 4:04, 6 users, load average: 860.92, 388.31, 328.50 [02:18] box is solid [02:18] cool ... [02:19] try do adapt the killer for ipv4 root testing ;) [02:19] ok [02:19] where did you think it was risky? [02:20] well, basically adding ip_root to the process, adds that info to /proc ... so same issue there ... [02:20] ñok [02:20] so its really the proc access you are worried about? [02:21] jup ... [02:21] k [02:21] ill hack something up and then go make some beef jerky [02:28] make it so, #1 ... [02:28] noel, I'm almost done ... a few minutes ... [02:33] sure. take your time. [02:34] yeah, I decided not to rediff the patch, but to redo it from scratch ... [02:43] what is the difference between vserver and usermode linux? [02:44] micah: UML has for every instance its own kernel. [02:45] and no shared resources, like files, memory, etc ... [02:45] what is the benefit of sharing resources if you want them separated for security anyways? [02:46] not trying to troll, just trying to understand :) [02:46] Bertl: btw. I was able to successfully md+lvm my drives, thanks for the help earlier [02:50] micah-> `mount --bind` for one [02:55] micah: no problem .. ur welcome [02:55] if you put two or more vservers on a shared partition, you can share about 80% of the vserver installation, leaving each vserver at a size of 20-30MB (without customer data) [03:00] Bertl, like a rock [03:00] Bertl, spawning new context, setting root, exit. [03:00] about 20 processes doing that infinitely, about 10 processes catting /proc/*/status [03:00] 19:01:53 up 4:46, 5 users, load average: 331.30, 123.96, 75.62 [03:00] looks good ... [03:02] can a vserver support it's on IPTables rules? [03:02] kungfuftr, no [03:02] question@all how should limits be presented in /proc//? [03:03] subdirectory for things to be limited (ie: cpu, mem, etc.) an a file within each for each vserver which just holds a value [03:03] hmm, that would pretty blow procfs I guess ... [03:04] we have about 12 possible limits defined, currently ... [03:04] Action: nathan_ hasnt even looked at the limits [03:04] I was thinking about something more like /proc/meminfo ... [03:05] maybe /proc//limits [03:05] xid? [03:05] xid = context id ;) [03:05] Bertl, isnt /proc/xid going to collide namespaces with /proc/pid? [03:05] is /proc/ the current fashion? [03:05] or were you going to clarify it? [03:06] hmm, actually it's /proc/virtual/ ... sorry ... [03:06] oh ok [03:06] Bertl, is this just going to be a getter or a setter too? [03:06] ah by the way, you can test those proc entries ... [03:06] this is only for reading, setting is done via syscall command [03:07] well... how bout /proc/virtual//limits/ (all files with values) [03:07] Bertl, if its just for reading why not just use one file per xid that is easily parsed? [03:08] nathan_-> becuase there's already a level of seperation for each [03:08] iirc [03:08] hmm, kungfuftr: what are your arguments _agains_ a /proc/virtual//limit file similar to /proc/meminfo [03:09] s/agains/against/ [03:10] Bertl-> it requires parsing... having a seperate file for each different limit makes it a lot simplier to code [03:10] hmm but in that case, we would need three files for each limit ... [03:11] how so? [03:11] hmm wrong, four files ... [03:11] we define a min/soft/hard and current [03:11] nah... seperated values [03:12] 0 300 350 119 [03:12] and then you need a tool to display them at one page, which is the only thing you probably do with that interface ... [03:19] hmm, okay, any other opinions? [03:20] perhaps a numeric value setup for caps? [03:21] writeable? [03:21] please elaborate ... [03:22] so let's say CAP_NET_RAW is xxxx(0/1)xx boolean... you can echo "xxxx1xx" to turn it on or "xxxx0xx": to turn it off [03:22] hhhmmm... is the sort of thing that sysctl would be perfect for [03:22] tell me if i'm pasting black again [03:22] hmm, you can't turn a capability 'on' [03:22] (no pun intended) [03:23] sorry... forgive my lack of coding skill :-( [03:23] capabilities are remove only ;) [03:23] even if your xid is 0? [03:24] and you have CAP_SYS_ADM? [03:24] infowolfe-> you turn it off by setting the limits to 0 [03:25] well, actually it depends on CAP_SETPCAP which allows to transfer them ... [03:25] but what would you use that interface for? [03:26] I mean what would you be able to do, what you can't do with the current one? [03:26] like "echo 1 > /proc/sys/net/ipv4/ip_forward" ? [03:26] i guess it wouldn't work, since you can't add capabilities on the fly anyway [03:26] (perhaps a security issue?) [03:28] okay noel, we got something to test ... [03:28] :) [03:28] brand new, never tested before ... [03:29] yeah. [03:30] just a final check on my side ... [03:30] sure. [03:32] http://vserver.13thfloor.at/Experimental/patch-2.4.23-vs1.3.x-ml0.08.diff [03:33] but I expect it to be 'not perfect' ;) [03:34] patching file fs/binfmt_elf.c [03:34] patching file fs/binfmt_som.c [03:34] patching file fs/exec.c [03:34] patching file fs/proc/array.c [03:34] Hunk #1 FAILED at 395. [03:34] 1 out of 1 hunk FAILED -- saving rejects to file fs/proc/array.c.rej [03:34] can't find file to patch at input line 183 [03:34] Perhaps you used the wrong -p or --strip option? [03:34] The text leading up to this was: [03:34] -------------------------- [03:34] |diff -NurpP --minimal linux-2.4.23-vs1.3.2.5/fs/proc/virtual.c linux-2.4.23-vs1.3.2.5-ml0.05/fs/proc/virtual.c [03:34] |--- linux-2.4.23-vs1.3.2.5/fs/proc/virtual.c Sat Jan 3 23:10:10 2004 [03:34] |+++ linux-2.4.23-vs1.3.2.5-ml0.05/fs/proc/virtual.c Sun Jan 4 01:26:55 2004-------------------------- [03:34] first is clear. its the manual change. but then? [03:35] hmm, you didn't forget the 1.3.2 patch? [03:35] args. wrong dir...:( sorry. [03:35] yes you are right. [03:38] applied and compiling... [03:41] ahh, rss seems wrong, but vm looks okay ... [03:43] the line in kernel/fork.c:154 is wrong ... [03:44] mm->rss = 0; [03:44] should be that ... [03:44] instead of the vm_rss... stuff [03:45] ok checking... [03:47] again. you mean s/mm->rss/vm_rss? right now its mm->rss = 0; [03:48] if it's mm->rss = 0, then you forgot to apply the ml0.08 patch ... [03:50] args. sorry for so stupid. I was in the wrong kernel dir again.:( [03:51] no problem .. you get used to it after working with 1000+ kernels ;) [03:51] oh then I have so kernel to do.:) [03:52] 154 is: vx_rsspages_sub(mm, mm->rss); [03:52] yeah, that change was wrong .. so put back in mm->rss = 0; again [03:52] got to go, by all [03:52] cu ozan! [03:52] cu ozan [03:52] ozan (~ozan@dsl81-215-18120.adsl.ttnet.net.tr) left irc: Quit: bzzt [03:53] hmm as a matter of fact, it looks really good now ... [03:54] nathan: please could you adapt the killer to query the 'new' /proc/virtual//* files ... [03:58] okay, I'm going to release 1.3.2.5 as 1.3.3 ... [03:59] Bertl, yep [03:59] :) [03:59] ahh, maybe we should test the changes on the ck1 kernel too ;) [04:00] that would actually allow a whole new class of races (using preemtion ;) [04:00] which ulimit is now possible: -l -m or -v [04:01] neither nor ... [04:01] this version only does accounting ... [04:01] ah ok. [04:01] the limits are there, but set to unlimited ... [04:01] Bertl, you want me to do it with your new 1.3.3 or with the one i am running now? [04:02] nathan_: what? [04:02] Bertl, query the /proc/virtual/*/* files [04:02] hmm, that would be a GoodThing in any case ... [04:02] you could test on vs1.3.2.5 + ml ... or you could 'just' test on ck-1 + 1.3.2.5 [04:03] ck1 would be interesting, as it should improve the scheduling ... [04:04] O(1) and preemtion enabled ... [04:05] noel: you are booted with the 'new' kernel? [04:05] Bertl, a series of deferred deletes but stable so far [04:05] Bertl: yepp. its runing. [04:06] okay start a server ... [04:06] then look into /proc/virtual//* [04:06] already done. the usuabl 3 vserver are runing. [04:06] Unable to handle kernel NULL pointer dereference at virtual address 00000010 [04:06] printing eip: [04:06] c015b54a [04:06] # cat /proc/virtual/101/limit [04:06] VM: 00014910/-1 [04:06] VML: 00000000/-1 [04:06] RSS: 00005925/-1 [04:07] >>EIP; c015b54a <===== [04:07] >>ebx; c57c7388 <_end+533bec4/383abb9c> [04:07] >>ecx; c015bd30 [04:07] >>edx; dc2c7fa0 <_end+1be3cadc/383abb9c> [04:07] >>esi; f6bde654 <_end+36753190/383abb9c> [04:07] >>ebp; dc2c7f68 <_end+1be3caa4/383abb9c> [04:07] hmm, stupid leading zeros ... well change that pretty soon ... [04:07] >>esp; dc2c7f50 <_end+1be3ca8c/383abb9c> [04:07] Trace; c015bd30 [04:07] Trace; c015bead [04:07] Trace; c015bd30 [04:07] Trace; c0109283 [04:08] hmm, interresting, this is killer on /proc/virtual? [04:08] or what oops am I looking at? [04:08] Bertl, this is killer+ipv4root with another series of processes catting /proc/virtual/*/* [04:08] that oops came up from bash [04:08] Process bash (pid: 2586, stackpage=dc2c7000) [04:09] ah okay, so the /proc/virtual/*/* isn't protected ... [04:09] this is on the 1.3.2.5 right? [04:09] Bertl, this is on whatever we have created over the past two days [04:09] hehe [04:10] I was actually supsecting this, because there are no locks IIRC in that code, yet ... [04:11] so maybe we should fix that one too ... [04:13] ok guys. its 2.15 here and I'm going to bed. testing will be continued. thx. [04:13] thank you ... [04:14] and have a good night ... cu [04:16] is anyone awake? [04:17] i'd like to figure out if there's a way for me to use find to find anything that is a hardlinke [04:17] hardlink* [04:17] hmm, well that would be hard .... [04:18] you can find inodes with more than one links ... with -nlink [04:41] Bertl-> there's another good reason to seperate limits into seperate files... you can symlink them [04:42] hmm, what application would that have? [04:43] say you have different 'types' of customers that have different levels of limits... you could then symlink the limits to preset files like "mem.basic, mem.medium, mem.advanced", etc. [04:44] that wouldnt work [04:44] oh yeah... there's a 'current' value too [04:44] hmm, I don't even understand what you are talking about ;( [04:44] much better off writing userspace tools to manage 'profiles' of customers [04:45] Bertl, ln -s /etc/mem.medium /proc/virtual//mem [04:45] Bertl, obviously wouldn work but i think thats what he thinks would work [04:45] that isn't possible with any proc entry ... [04:45] never was, never will be ... [04:46] as bert already said too, the proc interface isnt going to be used as a setter either way. [04:46] fir nought [04:47] monako (~monako@ts1-a109.Perm.dial.rol.ru) joined #vserver. [04:47] hi monako! [04:48] nathan_: I see a problem with the proc entries locking scheme ... [04:48] Bertl, the lack thereof or with the one you are working on? [04:49] what if an app decides to 'hold' a proc inode, there is no callback, when the inode is released ... [04:49] hmm [04:49] Bertl, doesnt the kernel manage that for us by deferring the delete? [04:50] yep, that _is_ the problem ... [04:50] if I pass a reference to the vx_info, and get() it, there will be no put() [04:51] Bertl, so process X keeps /proc/virtual//status open, gets destroyed while it is still held by X is the situation we are talking about? [04:51] yep, when/how would I release it ,.,, [04:52] hmm [04:52] I see two possible workarounds: [04:52] a) only pass the context id, not the vx_info ... [04:52] b) detect that this inode is deleted (somehow) and do not use the data ... [04:54] seems to be the xid would be easiest implementation? [04:54] yup, everything is available ... [04:54] but I'm not sure the semantics are correct ... [04:54] consider an app, grabbing xid=100 .. [04:55] context is destroyed and recreted ... [04:55]