1121126401 M * Bertl greetings Aiken! 1121126409 M * Aiken good morning 1121126680 M * Bertl what's up? 1121126807 Q * Jani Ping timeout: 480 seconds 1121127006 M * Aiken I'll say everything vserver is fine but just found I get to pull down one of my antennas this morning :( 1121127022 M * Bertl aha? 1121127280 M * Aiken amateur radio 1121127293 M * Bertl ah, and why so? 1121127364 M * Aiken we had bad wind on the weekend and 1 of the antennas came down, though I had fixed it yesterday but it was not quite right 1121127398 M * Bertl btw, we had two bug-fixes since yesterday :) 1121127439 M * Bertl both not really linux-vserver issues, but stuff which was exposed by linux-vserver 1121127540 M * Aiken ? 1121127550 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-2.0/delta-sysctl-fix01.diff 1121127553 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-2.0/delta-percpu-fix01.diff 1121127572 M * Bertl the first one is triggered by doing sysctl -a 1121127581 M * Bertl (which usually kills the sysctl) 1121127740 M * Aiken is there where sysctl -a ends is a segfault? 1121127783 M * Bertl yeah, it results in a call outside of the kernel (usually somewhere in page 0) 1121127815 M * Bertl basically it's fixed by the: 1121127816 M * Bertl -ctl_table fake_table; 1121127816 M * Bertl +ctl_table fake_table = {0}; 1121127830 M * Bertl but to make sure I moved the call down after the check too ... 1121128055 M * Aiken I'll try breaking the alpha shortly 1121128072 M * Aiken still hve not done much on this machine which is 1 of 2 that I really wanted vserver on 1121128362 M * Aiken that unaligned trap error is annoying, I did not get until I started playing last night 1121128392 M * Bertl try to 'force' align the hostentry to 32 or 64 bytes 1121128447 M * Aiken how long is a long on alpha (mine is still turned off)? 1121128458 M * Aiken that is the biggest I have tried forcing the alignment so far 1121128461 M * Bertl I'd say 64 bit 1121130046 J * explasm__ explasm@p549F7D40.dip.t-dialin.net 1121130477 Q * eXplasm2 Ping timeout: 480 seconds 1121130732 M * Aiken what was the patch for gethostbyname_r? 1121130741 M * Aiken in dietlibc 1121130773 M * Bertl sec 1121130805 M * Aiken just made a change to dietlibc gethostbyname and both chbind and my test case are refusing to produce an unaligned trap error :) 1121130817 M * Bertl http://vserver.13thfloor.at/Experimental/delta-diet.diff 1121130828 M * Bertl the last hunk/file 1121130875 M * Aiken I have read that before, this time I will save it so I don;t have to ask again 1121130927 M * Aiken libcruft/gethostbyname.c line 19 1121130927 M * Bertl np, I'm good at finding this stuff :) 1121130938 M * Aiken struct hostent *hostbuf __attribute__((__unaligned__)); 1121130948 M * Aiken that is the change I made 1121130980 M * Bertl hmm, sounds good, let me check that ... 1121131090 M * Aiken I am using dietlibc 0.29 1121131171 M * Aiken just in case you were curious my test case is http://pastebin.com/311604 1121131377 Q * sladen Remote host closed the connection 1121131385 J * sladen paul@starsky.19inch.net 1121131390 M * Bertl wb sladen! 1121131487 M * Bertl Aiken: hmm, but wait, that is just telling the compiler to assume it's unaligned, so it's basically papering over the issue, no? 1121131526 M * Aiken true, and even with dietlibc back to hwo it was I can not get anything to trap :( 1121131547 M * Aiken it was one of the suggested fixes I found for a trap issue, so I thought I would try it 1121131606 M * Bertl hmm, I'm currently using dietlibc-dev 0.28-3 1121131620 M * Bertl (debian dietlibc) maybe I should try with 0.29 1121131647 M * Aiken but is the compiler deal with the issue wouldn't that be better than having the trap happen? 1121131677 M * Bertl better yes, but still not perfect 1121131960 M * Aiken just make it worse, I put gethostbyname back to normal and can not get a trap error 1121131978 M * Bertl updating to testing (for dietlibc) which uses 0.29-2 1121131983 M * Bertl did fix the issue here ... 1121132014 M * Bertl what dietlibc do you use? 1121132022 M * Aiken a plain 0.29 1121132178 M * Bertl I guess the fix is by accident then ... 1121132221 M * Bertl you sure you didn't maybe build 0.29 but not isntall it last time? 1121132240 M * Bertl (i.e. that might explain why the issues are gone now?) 1121132282 M * Bertl debian/diff/dns-decoding.diff (was in 0.28-2) 1121132284 M * Aiken using dietlibc in place with installing diet in the patch 1121132304 M * Aiken as per the README 1121132313 M * Aiken patch = path 1121132326 M * Bertl yeah, well, no idea then ... 1121132327 M * Aiken am using the new diet each time 1121132593 M * Bertl rebuilding now ... 1121134236 M * Bertl okay, rebooting ... 1121134330 M * Bertl okay, traps are gone with dietlibc 0.29-2 (debian) 1121134341 M * Bertl don't ask me why, but they are ... 1121134385 M * Bertl user unaligned acc: 0 (pc=0,va=0) 1121134478 M * Aiken for something to do I built a unstripped debug dietlibc 0.28 and traced the trap errors to 1121134480 M * Aiken Line 54 of "libcruft/dnscruft2.c" 1121134480 M * Aiken starts at address 0x120001528 <__dns_gethostbyx_r_inner+148> 1121134480 M * Aiken and ends at 0x12000152c <__dns_gethostbyx_r_inner+152>. 1121134492 M * Aiken that file is different between 0.28 and 0.29 1121134515 M * Bertl those are probably the beforementioned __dns fixes 1121135634 M * Bertl okay, I guess I'm off to bed now ... have a nice one everyone! 1121135669 N * Bertl Bertl_zZ 1121138375 J * Aiken_ ~james@tooax6-124.dialup.optusnet.com.au 1121138687 Q * Aiken Ping timeout: 480 seconds 1121146281 Q * eyck Ping timeout: 480 seconds 1121146529 J * eyck eyck@81.219.64.71 1121147021 Q * eyck Ping timeout: 480 seconds 1121147264 J * Hollow ~Hollow@home.xnull.de 1121152699 J * eyck eyck@81.219.64.71 1121152714 J * Doener` ~doener@p54877D7D.dip.t-dialin.net 1121153146 Q * Doener_ Ping timeout: 480 seconds 1121153192 Q * eyck Ping timeout: 480 seconds 1121153809 J * mertins ~mertins@gateway.scheller.de 1121153824 Q * mertins Remote host closed the connection 1121153851 J * comdata ~mertins@gateway.scheller.de 1121153882 M * comdata hello 1121153906 M * comdata Hollow: read that you're the one to talk to about gentoo stuff 1121154067 M * comdata anybody on amd64 here? 1121154678 Q * comdata oxygen.oftc.net helium.oftc.net 1121154678 Q * Aiken_ oxygen.oftc.net helium.oftc.net 1121154678 Q * virtuoso oxygen.oftc.net helium.oftc.net 1121154678 Q * BWare oxygen.oftc.net helium.oftc.net 1121154678 Q * DaPhreak|aw oxygen.oftc.net helium.oftc.net 1121154678 Q * romke oxygen.oftc.net helium.oftc.net 1121154678 Q * atsab oxygen.oftc.net helium.oftc.net 1121154678 Q * Zoiah oxygen.oftc.net helium.oftc.net 1121154678 Q * maharaja oxygen.oftc.net helium.oftc.net 1121154678 Q * FaUl oxygen.oftc.net helium.oftc.net 1121154678 Q * id oxygen.oftc.net helium.oftc.net 1121154678 Q * Loki|muh oxygen.oftc.net helium.oftc.net 1121154678 Q * baggins oxygen.oftc.net helium.oftc.net 1121154679 Q * xbing oxygen.oftc.net helium.oftc.net 1121154679 Q * albeiro oxygen.oftc.net helium.oftc.net 1121154679 Q * neofutur oxygen.oftc.net helium.oftc.net 1121154679 Q * Hunger oxygen.oftc.net helium.oftc.net 1121154737 J * comdata ~mertins@gateway.scheller.de 1121154737 J * Aiken_ ~james@tooax6-124.dialup.optusnet.com.au 1121154737 J * virtuoso ~s0t0na@80.253.205.251 1121154737 J * BWare ~bware@office.intouch.net 1121154737 J * DaPhreak|aw ~phreak@styx.xnull.de 1121154737 J * romke ~romke@procyon.romke.net 1121154737 J * atsab ~as@lotes.vtu.lt 1121154737 J * Zoiah Zoiah@matryoshka.zoiah.net 1121154737 J * maharaja maharaja@ipax.at 1121154737 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1121154737 J * id ~id@relax-media.softwarezentrum.de 1121154737 J * Loki|muh loki@satanix.de 1121154737 J * baggins baggins@kenny.mimuw.edu.pl 1121154737 J * neofutur ~neofutur@neofutur.net 1121154737 J * albeiro ~albeiro@albeiro.usercloak.oftc.net 1121154737 J * xbing ~nb@dsl081-044-121.lax1.dsl.speakeasy.net 1121154737 J * Hunger Hunger.hu@levnor.hu 1121154878 J * prae ~prae@ezoffice.mandriva.com 1121154993 Q * DaPhreak|aw Read error: Connection reset by peer 1121156465 J * great ~lijian@159.226.58.96 1121156480 M * great Is there anybody who is family with linux kernel scheduler? 1121156480 M * great I want to know how to measure the performance of the scheduler 1121156480 M * great or,how to compare the performance between 2.6 and 2.4 1121156830 J * dfgdre ~kajshdf@host107.200-45-228.telecom.net.ar 1121156838 P * dfgdre 1121156887 M * SiD3WiNDR family? :) 1121156919 M * great sorry ,It should be familiar 1121157188 J * DaPhreak ~phreak@styx.xnull.de 1121158628 Q * great Quit: 1121159664 J * prae_ ~prae@gut75-1-81-57-27-189.fbx.proxad.net 1121159997 J * eyck eyck@81.219.64.71 1121160102 Q * prae Ping timeout: 480 seconds 1121161115 J * jsambrook ~jsambrook@host-62-69-64-93.bsve.net 1121161124 Q * jsambrook Remote host closed the connection 1121161252 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1121162003 J * prae__ ~prae@ezoffice.mandriva.com 1121162331 M * maharaja good morning 1121162331 M * maharaja :) 1121162339 N * prae__ prae 1121162446 Q * prae_ Ping timeout: 480 seconds 1121165339 Q * duckx Remote host closed the connection 1121166643 J * mcp ~hightower@wolk-project.de 1121166717 Q * Aiken_ Ping timeout: 480 seconds 1121167857 Q * aba Ping timeout: 480 seconds 1121167896 M * maharaja *dumdidum* waiting for bertl 1121168065 M * maharaja started iozones (just to keep a time log *g*) 1121169745 M * maharaja *crash* 1121169749 M * maharaja mhm 1121169812 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1121172696 M * maharaja when does bertl normally get up? 1121172828 Q * Hollow Remote host closed the connection 1121172851 J * Hollow ~Hollow@home.xnull.de 1121172937 J * aba ~aba@eos.turmzimmer.net 1121172968 J * renihs ~renihs___@193.170.52.70 1121173354 M * Hollow DaPhreak: ping 1121174111 M * maharaja ping! 1121174115 M * maharaja pong! 1121174115 M * maharaja :) 1121174376 Q * comdata Quit: using sirc version 2.211+KSIRC/1.3.12 1121174690 M * Hollow heh 1121174706 M * Hollow maharaja: i just reviewed his recruitment quiz ;) 1121174827 M * TheSeer renice: 20802: setpriority: Permission den 1121174829 M * TheSeer gna ;> 1121174836 M * TheSeer sometimes vservers are annoying ;) 1121174942 M * Hollow TheSeer: not the vservers are.. the tools are.. ;) 1121174952 M * TheSeer well.. okay ;> 1121174970 M * Hollow but permission denied sounds not like a utils prob anyway ;) 1121175004 M * TheSeer well.. i tried to renice a process in a vserver 1121175007 M * TheSeer which didn't work ;> 1121175012 M * Hollow by using which command? 1121175013 M * TheSeer never mind.. 1121175015 M * TheSeer renice? 1121175019 M * Hollow inside the vserver? 1121175022 M * TheSeer yep 1121175050 M * Hollow oh fun... i even don't have renice inside my vserver *g* 1121175054 M * Hollow ah... 1121175059 M * Hollow i don't have util-linux 1121175225 M * maharaja dumdidum 1121175228 M * maharaja damn those server crashes 1121176853 N * Bertl_zZ Bertl 1121176857 M * Bertl morning folks! 1121176869 M * Bertl maharaja: did the change fix your issues? 1121176894 M * maharaja no 1121176903 M * Bertl okay, glad to hear actually ... 1121176906 M * maharaja i got 2 crashes 1121176916 M * Bertl with trace? 1121176932 M * maharaja my latest trace: 1121176933 M * maharaja http://raoul.bhatia.at/~raoul/main_vs2.0rc6_2.log 1121176940 N * jonsmel_zZ jonsmel 1121176949 M * Bertl morning jonsmel! 1121176953 M * jonsmel morning 1121176963 M * maharaja crashed after ~30 minutes and running 8 xfs/ext3 iozone 1121176972 M * maharaja but i cannot confirm that iozone triggers the problem 1121177039 M * Bertl maharaja: again an incomplete trace? 1121177046 M * maharaja first crash today occured after 10hrs of uptime 1121177070 M * maharaja the one before that is strange too: http://raoul.bhatia.at/~raoul/main_vs2.0rc6.log 1121177091 M * maharaja look at the last line 1121177101 M * maharaja this is the output i captured with "minicom" and logging turned on 1121177107 M * maharaja no c/p at all 1121177128 M * maharaja i think ill exchange the ide cables today 1121177180 M * maharaja i do not think that its the disks as errors on the disk would show up in a different way, won't they? 1121177200 M * maharaja mhm 1121177221 M * maharaja somehow i get the feeling that crashes happen at full hours, where cron.hourly would run on most vservers 1121177273 M * maharaja but i'm just blindly guessing 1121177322 M * maharaja as i do not know how the kernel really operates 1121177378 M * Bertl [<80163b2d>] try_to_free_pages+0xcd/0x1c0 1121177391 M * Bertl this is a good indication that you are getting OOM kills 1121177407 M * TheSeer ouhmm.. how can a sleeping process consume CPU time? 1121177409 M * Bertl but you should get reported them in the syslog 1121177429 M * TheSeer i have a process in the TOP output that has STAT S and CPU 57% 1121177430 M * TheSeer ;> 1121177458 M * FaUl hmm, pop muesste dsniff auch bekommen 1121177460 M * FaUl oh, ww 1121177506 M * Bertl maharaja: you got rid of the higmem? 1121177514 M * maharaja Bertl: should it be visible in all syslogs, or only in a specific vserver? 1121177529 M * Bertl on the main host's syslog 1121177536 M * maharaja CONFIG_NOHIGHMEM=y 1121177536 M * maharaja # CONFIG_HIGHMEM4G is not set 1121177536 M * maharaja # CONFIG_HIGHMEM64G is not set 1121177661 M * maharaja Bertl: theres nothing in the logs (using metalog thou) 1121177856 M * Bertl okay, the only 'common' thing we saw so far is that xfs is in every trace 1121177880 M * Bertl maybe it's worth to change to ext3 for now? 1121177889 M * maharaja ill try to do that 1121177918 M * maharaja is it sufficient to create new ext3 lvs and rsync from the xfs lvs? 1121177923 M * Bertl another idea, what stack size do you use? 1121177932 M * Bertl 4k or 8k? 1121177977 M * maharaja http://raoul.bhatia.at/~raoul/config-2.6.12.2-vs2.0-rc6-main 1121177984 M * maharaja CONFIG_4KSTACKS=y 1121178159 M * maharaja i heard about problems with reiser4 and 4kstacks 1121178163 M * maharaja might that be the same for xfs? 1121178261 M * maharaja just reading about xfs 4kstack problems 1121178276 M * maharaja but: just another success story: i have CONFIG_4KSTACKS=y on two machines with 2.6.11(.4) and no problems so far. 1121178563 M * maharaja Bertl: do you suggest du compile the kernel with 8k stacks? 1121178670 M * maharaja mhm 1121178675 M * maharaja XFS is probably fine but I wouldn't try to stack on top a volume manager. 1121178675 M * maharaja The last time XFS on a md raid 5 volume the system would last 1121178675 M * maharaja about 30 seconds before spewing all sorts of weird stack traces. 1121178678 M * maharaja -- 1121178750 M * Bertl yeah, so I'd try either ext3 or 8k stacks for now ... 1121178790 M * Bertl because the stack traces look lengthy and have many levels in them ... 1121178847 M * Bertl (dm, xfs, vfs, ...) 1121178915 M * maharaja using 8k stacks helps to track the problem or will eliminate the problem? 1121178932 M * maharaja (in your opinion) 1121178948 M * Bertl later one if it is a 4k stack issue :) 1121178963 M * Bertl okay, off for now ... back later ... 1121178972 N * Bertl Bertl_oO 1121179246 Q * clc Read error: Connection reset by peer 1121179371 Q * Rushmoom Read error: Connection reset by peer 1121184262 J * hallyn ~hallyn@pixpat.austin.ibm.com 1121184414 N * Bertl_oO Bertl 1121184436 M * Bertl back now ... 1121184446 M * Bertl hallyn: evening serge! 1121184460 M * hallyn good morning :) 1121184494 M * Bertl ah, yeah, austin, texas :) 1121184508 M * hallyn not for long, it seems. 1121184522 M * hallyn looking to north a bit. 1121184542 M * Bertl i.c well won't change the timezone ... 1121184552 M * hallyn true. for once. 1121184564 M * hallyn last time in decades that a move didn't change that for me. 1121184569 M * Bertl but don#t worry, I got up three hours ago or so ... 1121184596 M * hallyn After a good day's sleep, or a short nap? 1121184606 M * maharaja re bertl 1121184610 M * Bertl hallyn: a good day's sleep ... 1121184628 M * Bertl hey maharaja, any change? 1121184758 M * Bertl hallyn: so how was your 'vaccation'? 1121184801 M * Bertl s/cc/c/ 1121184820 M * hallyn Somewhat hectic. Drive was better than the last few times, though. (lately driving through the night has really bothered me) 1121184827 M * hallyn Bertl: will you be at OLS by any chance? 1121184856 M * Bertl not that I know of (no money for that here) 1121184901 M * hallyn Yeah, long trip... THat's too bad. 1121184963 M * jonsmel hey bert, did anything change with the new utils to cause ssh to not work, I am trying to ssh to a vserver but instead of going to the actual vserver it goes to the system hosting the vserver 1121184999 M * Bertl most likely because your host is running an sshd which binds to 0.0.0.0 (adjust the Listen* directive in /etc/ssh/sshd_config) 1121185023 M * Bertl (then restart the guest) 1121185038 M * jonsmel adjust it in the vserver or on the actual system 1121185045 M * Bertl on the host 1121185065 M * Bertl (the guest is automatically restricted to its ip subset) 1121185096 M * hallyn Ok, so here's a question: do most people use the vserver-utils, or use chcontext/chbind by hand? 1121185101 M * jonsmel ok, so listenaddress is commented out 1121185120 M * jonsmel just uncomment it to bind to 0.0.0.0 1121185126 M * Bertl hallyn: 90% use the tools (but there are different tools available) 1121185141 M * Bertl jonsmel: no, that's the default (that's why it's commented out :) 1121185155 M * Bertl jonsmel: you want to bind it to host addresses only 1121185161 M * jonsmel ah, ok 1121185169 M * jonsmel type in the ip of the actual host there 1121185172 M * jonsmel gotcha 1121185173 M * hallyn Bertl: right, I'm using the vserver-utils that come by default on gentoo. Is there a concensus on some "newer" or "better" tools, or are there just different tools? 1121185199 M * Bertl currently the most up to date tools are util-vserver 0.30.207 1121185219 M * Bertl unfortunately they lack some features already present in the kernel 1121185222 M * jonsmel what if the host has two addresses it is supposed to listen on 1121185237 M * Bertl jonsmel: then you ahve to specify two bindings there 1121185257 M * jonsmel two listenaddress lines or space sperated on the one line 1121185271 M * Bertl whatever you sshd can understand (see man sshd) 1121185277 M * jonsmel ok 1121185278 M * jonsmel thnx 1121185280 M * Bertl yw 1121185308 M * hallyn So is the ioctl interface the biggest complaint you've heard re: upstreaming vserver? 1121185323 M * hallyn Or just "it's a big patch"? 1121185332 M * Bertl you mean the vserver command switch? 1121185349 M * hallyn right - you said something earlier about not wanting to argue about which ioctls are worthwhile. 1121185380 M * Bertl no the patch is not really that big (uncompressed about 600k) 1121185394 M * Bertl most kernel patches (between versions) are bigger ... 1121185410 M * hallyn Yeah - I'm walkign through it right now, trying to get a feel for just how much is in there that would be contentuous. 1121185426 M * hallyn (cause i must say it's been working great for me at home) 1121185434 M * Bertl I'd suggest to wait a minute, I can provide you a broken out version 1121185452 M * hallyn Oh? Cool! 1121185528 M * Bertl of course, everything top secret and strictly for your eyes only .. nah, just kidding :) 1121185552 M * Bertl http://vserver.13thfloor.at/Experimental/DEL-vs2.0-rc6.1/ 1121185623 M * hallyn Excellent, thanks. 1121185629 M * Bertl you're welcome! 1121185778 M * hallyn So, did you create this to send them to lkml? (I'm guessing not :) 1121185856 M * Bertl well, they are created whenever a release is going to happen 1121185866 M * Bertl it's one of my personal review methods ... 1121185880 M * Bertl but actually I thought about submitting them to lkml 1121185890 M * Bertl (just to get some feedback, and maybe new ideas) 1121185943 M * Bertl but they are categorized by thematic changes, and not as step-by-step integration 1121185961 M * hallyn right, which is more useful for trying to decide the impact, I think. 1121186023 M * Bertl more important it's helful in spotting differences between similar parts ... 1121186144 M * hallyn If you submit to lkml, could you let me know? I definately want to get involved in the discussion. 1121186153 M * hallyn I wonder whether next week being ols means it's a good or a bad time to submit :) 1121186177 M * hallyn Anyway I'll go read through that patchset a bit - thanks. 1121186211 M * Bertl I plan to submit them the next few days, either as separate mails or as link to a dir (ad ols: well, we'll see ...) 1121186308 M * maharaja Bertl: i just compiled the new kernel 1121186327 M * Bertl ah, okay, so no results yet, I guess 1121186333 M * maharaja no 1121186467 M * maharaja bertl: just finished the reboot of the new kernel (# CONFIG_4KSTACKS is not set) 1121186471 M * maharaja so lets wait and see 1121186500 M * Bertl yeah, will be interesting ... iozones? 1121186516 Q * SNy Quit: Reconnecting 1121186530 M * maharaja mhm - ill start them 1121186533 J * SNy e4bf12dfd1@bmx-chemnitz.de 1121186544 M * Bertl wb SNy! 1121186582 M * SNy reconnect with identd 1121186596 M * SNy is that a trigger you have there, Bertl? 1121186631 M * Bertl of course ... it's completely wet-ware based :) 1121186648 M * maharaja bertl: 6 iozone on xfs are running, shall i start the ones for ext3 too? 1121186661 M * maharaja i guess that does not matter as xfs seems to be the problem 1121186679 M * Bertl just to make sure start at least one on ext3 too 1121186690 M * maharaja k 1121186694 M * maharaja do you know tiobench? 1121186709 Q * prae Quit: Execute Order 69 ! 1121186713 M * Bertl yeah, did use it once, IIRC 1121186751 M * maharaja i read that ppl managed to crash a server reproducable with tiobench and 4k stacks 1121186816 M * Bertl excellent, get it :) 1121186881 M * Bertl hallyn: do you know the folks doing jfs? 1121187422 M * maharaja the only thing is, that i'm missing the post where i read that information in ;) 1121187448 M * hallyn Bertl: pple around me do. I personally don't. 1121187468 M * maharaja ah, found it 1121187500 M * maharaja so, running a tiobench 1121187508 N * hallyn hallyn_out 1121187509 M * maharaja so i think thats a pretty stressy test now :) 1121187558 M * hallyn_out Bertl: gotta run, but Shaggy (jfs guy) is in the building next to mine, if you need anything. 1121187579 M * Bertl hallyn_out: okay, cya! 1121187610 M * Bertl maharaja: yeah, sounds good ... 'm off for now, but I'll be back around midnight (CET) ... 1121187638 N * Bertl Bertl_oO 1121188939 J * Val ~val@81.56.97.153 1121188982 M * Val Hi 1121189472 M * Val what about CONFIG_XID_TAG_NFSD to (auto)mount NFS accounts inside a vserver ? 1121189647 J * prae ~prae@sherpadown.net 1121190107 J * erwan_ho ~erwan@konilope.dyndns.org 1121190962 Q * virtuoso Ping timeout: 480 seconds 1121191828 J * virtuoso ~s0t0na@80.253.205.251 1121194058 N * hallyn_out hallyn 1121194131 Q * renihs Remote host closed the connection 1121196436 M * Val automount[24879]: mount(nfs): is_local_mount: 10.10.10.67:/home/toor 1121196444 M * Val mount(nfs): toor is local, doing bind 1121196453 M * Val mount(bind): calling mkdir_path /var/lib/vservers/ns/home/toor 1121196456 M * Val mount(bind): calling mount --bind -s -o defaults /home/toor /var/lib/vservers/ns/home/toor 1121196461 M * Val well... 1121196514 M * Val using vnamespace to automount nfs /home/* isn't possible due to mount(nfs) loopback detection 1121196535 M * Val damn 1121196985 J * yarihm ~yarihm@84-73-118-59.dclient.hispeed.ch 1121197062 Q * jkl_ Ping timeout: 480 seconds 1121197206 J * jkl_ eric@c-67-165-222-86.hsd1.co.comcast.net 1121197321 Q * explasm__ Quit: Verlassend 1121197335 J * eXplasm explasm@p549F7D40.dip.t-dialin.net 1121198262 Q * Val Read error: Connection reset by peer 1121198402 J * Val ~val@81.56.97.153 1121198947 J * mef ~mef@targe.CS.Princeton.EDU 1121203422 Q * prae Quit: Pwet 1121204295 M * mef anyone running fc3 or fc4 that could tell me within which rpm package /sbin/runuser is part of.... "rpm -qf /sbin/runuser" would do the trick. Thanks. 1121204632 M * hallyn coreutils-5.2.1-31 1121204704 J * _are_ ~are@dsl-084-056-135-006.arcor-ip.net 1121204711 M * _are_ hi 1121204842 M * maharaja hi are 1121205094 Q * yarihm Quit: Leaving 1121205350 Q * hallyn Quit: leaving 1121205926 M * mef thanks 1121205929 Q * mef Remote host closed the connection 1121205997 J * Aiken ~james@tooax6-197.dialup.optusnet.com.au 1121208056 N * Bertl_oO Bertl 1121208073 M * Bertl evening folks! 1121208236 M * Val hi Bertl :) 1121208416 M * maharaja re Bertl: 1121208454 M * Bertl hey Val, maja! 1121208521 M * maharaja Bertl: i stressed the server with a couple of izone/tiobenches on xfs and 1x iozone on ext3 - no crash in 3 hours 1121208524 M * maharaja but thats no proof at all 1121208538 M * maharaja i just (once again) changed the hardware back to the very first system 1121208575 M * Bertl okay, but I agree the details point into that direction 1121208590 M * Bertl (i.e. xfs + dm + whatever >= stack 4k) 1121208665 M * maharaja i just once again started the tests 1121208769 M * maharaja -> stressing with 1x iozone@ext3, 4x iozone@xfs and 3xtiobench @xfs 1121208784 M * maharaja 2x iozone@ext3, 4x iozone@xfs and 3xtiobench @xfs 1121209522 Q * maharaja Ping timeout: 480 seconds 1121209677 Q * erwan_ho Remote host closed the connection 1121210488 M * Bertl Val: ad the automounting ... maybe you just have to 'modify' the automounter a little? 1121210517 M * Val Bertl : yes 1121210529 M * Val Bertl : i'll try a patch 1121210561 M * Val Bertl : but, for the moment, nfs-user-server inside a vserver works fine for lan hosts 1121210569 M * Val Bertl : on debian sarge 1121210598 M * Bertl excellent ... isn't there a section in ProblematicPrograms which could need some update? 1121210638 M * Val only kernel have to be up-to-date 1121210688 M * Val Bertl : i'll go to WhatTheHack next week and will make a demo box 1121210729 M * Bertl a vserver demo box? 1121210785 M * Val Bertl : all vservers in a dummy DMZ, main host firewalling, dns/www/https-connect/ftp/ntp proxy, ldap SSL/TLS SASL auth server, tftpboot server, local DNS and local Web, all services inside some vservers 1121210813 M * Bertl cool! 1121210817 M * Val automount /home on some known hosts with ldap auth 1121210832 M * Bertl btw, I found the page which might benefit from an update: http://linux-vserver.org/Linux-Vserver+FAQ 1121210835 M * Val i actualy try do add samba share witch accounts for windows 1121210859 M * Val all will be ok for WhatTheHack :) 1121210888 M * Val but i don't know if i'll had time to make an autofs patch 1121210907 M * Bertl maybe it's a simple check ... 1121210928 M * Val yes, the check is simply bad 1121210953 M * Bertl hehe, well, a lot of software out there has 'interesting' assumptions ... 1121210963 M * Val :)) 1121210965 M * Bertl and we just managed to break some of them ... 1121212150 J * maharaja ~maharaja@ipax.at