[00:26] miller7 (none@213.239.180.106) left irc: Ping timeout: 480 seconds [00:28] click (~click@virtualdesignz.net) left irc: Ping timeout: 492 seconds [00:28] Doener (~doener@p5082D3CF.dip.t-dialin.net) left irc: Quit: Leaving [01:09] master (~master@d213-94.dsl.expressnet.de) joined #vserver. [01:09] good evening [01:12] hi [01:13] ðø [01:13] hi [01:18] AHTOH (~Anton@212.1.230.115) left irc: Quit: Client exiting [01:39] Nick change: Bertl_oO -> Bertl [01:39] good evening! [01:41] Bertl, :) [01:41] *hiqs* [01:42] hi vat! how much? [01:42] 2 "hefeweizen".. not more, but nothing eat today.. [01:43] should code more, and drink less. [01:43] well, I'm eating my wienerschnitzel now, and no it's not fast food ;) [01:44] :) [01:49] good evening Bertl and bon appetite :) [01:49] njam. wienerschnitzel. [01:51] uh...forgot to apply my right name *shame* [01:51] Nick change: master -> Cyrix [01:51] anythin new on the frontline ? ;) [01:52] always ... but if you are asking specificly, no I didn't find the time to look at it ;) [01:54] np ... have alot of work at the moment too ... but i would appreciate it if we could find a solution to this till weekend ;) [01:56] guess we will, definitely ... [01:56] have to do some install stuff tomorrow morning, but tomorrow evening should be fine ... [01:57] i'm just curious ... could this be a too less caps issue ? just asking because the ping command needed caps too [01:58] hellekin (~hellekin@menilmontant-2-81-57-191-62.fbx.proxad.net) joined #vserver. [02:00] i experimented with uml-servers before .. they had no networking problems, but they caused host-kernel oops :( [02:01] Cyrix: in my opinion, something in your setup is borked, haven found what it is ... [02:02] we'll see ... sorry have to go now ... gn8 guys [02:03] night! [02:03] Cyrix (~master@d213-94.dsl.expressnet.de) left irc: Quit: Leaving [02:04] okay, any utterly important questions right now? [02:07] okay, in that case, have a good wossname, and see you all tomorrow ... [02:07] nite [02:07] Nick change: Bertl -> Bertl_zZz [02:11] hellekin (~hellekin@menilmontant-2-81-57-191-62.fbx.proxad.net) left irc: Quit: BitchX-1.0c20cvs -- just do it. [02:15] vat (vat@pD9E374CC.dip0.t-ipconnect.de) left irc: Quit: Leaving [03:01] mexcell (~root@65.126.127.3) joined #vserver. [03:01] Hello, All! [03:01] ? [03:02] Is bertl around, by chance? [03:05] mexcell (~root@65.126.127.3) left irc: Client Quit [03:09] mexcell (~root@65.126.127.3) joined #vserver. [03:09] mexcell (~root@65.126.127.3) left irc: Client Quit [03:10] mexcell (~root@65.126.127.3) joined #vserver. [03:10] mexcell (~root@65.126.127.3) left irc: Client Quit [03:28] je_ (~je@hd5e25b7f.gavlegardarna.gavle.to) joined #vserver. [03:28] je (~je@hd5e25b7f.gavlegardarna.gavle.to) left irc: Read error: Connection reset by peer [05:17] Zoiah (Zoiah@matryoshka.zoiah.net) left irc: Quit: changing servers [05:17] Zoiah (Zoiah@matryoshka.zoiah.net) joined #vserver. [07:16] noel- (~noel@pD952C425.dip.t-dialin.net) joined #vserver. [07:24] noel (~noel@p508599FD.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [07:32] Doener (~doener@p5082D3CF.dip.t-dialin.net) joined #vserver. [10:30] q [10:30] Nick change: Bertl_zZz -> Bertl [10:30] morning everyone! [10:32] moin [10:32] hi mids! [10:32] great, sorry that I missed you yesterday ... [10:33] any new observations on your part? [10:34] yes, that I suck at reproducing bugs [10:35] hehe, hey it's hard to reproduce, until now I failed too ... [10:35] but I'm pretty sure it has to do with files which are already open, when the quotaon kicks in ... [10:36] now with a quota on/off before after other services are started, it goes okay the first time; though there are still reports of invalidate: in_use/dirty after the first quotaoff [10:36] funny thing is that this seems to be ext3 specific, or did you manage to hang the machine with ext2? [10:36] and then the second time I get the bad inode error and lockup upon quotaoff [10:36] I tried once with ext2 and that worked [10:37] but I'll try a few times [10:38] I'll make my test sequence available in a few minutes, so you can check if this hangs for you, because it works for me ... [10:38] just a silly thought, but could it have been that the ext3 quota deadlock fixed was merged after the vserver q0 code instead of before it? [10:39] when I was manually fixing the failed patches, I think that there was some pieces that could have been placed both before or after another part [10:39] and because of a different architecture, speed, whatever, the deadlock doesnt occur for you, but does here [10:40] hmm, could be ... [10:48] Nick change: noel- -> noel [11:07] okay, have to leave now, will be back in a few hours ... [11:08] Nick change: Bertl -> Bertl_oO [11:08] serving (~serving@213.186.190.24) left irc: Read error: Connection reset by peer [11:30] serving (~serving@213.186.190.24) joined #vserver. [11:34] miller7 (none@213.239.180.106) joined #vserver. [11:34] hello guys [11:36] hi miller7 [11:36] hey mids [12:13] arekm_ (misiek@ikar.t17.ds.pwr.wroc.pl) joined #vserver. [12:13] arekm (misiek@ikar.t17.ds.pwr.wroc.pl) left irc: Read error: Connection reset by peer [13:03] Bertl_oO: with ext2fs quotas work okay if I put them in rc2 before and rc6 after syslogd [13:03] but when I in a shell inside the vserver run quotaon / off a few times I get the same issues as with ext3 [13:09] Nick change: Bertl_oO -> Bertl [13:09] back again ... [13:09] hi bert [13:10] hi! [13:15] mids: [13:15] ··· BAD INODE: add_dquot_ref(97f87400[100], 1) 97ad2240[100](00000000) »block100.log« [13:15] /dev/discs/disc1/part1 [/mnt/part1]: group quotas turned on [13:15] ··· BAD INODE: add_dquot_ref(97f87400[100], 0) 97ad2240[100](00000000) »block100.log« [13:15] /dev/discs/disc1/part1 [/mnt/part1]: user quotas turned on [13:16] now I'm able to reproduce this message ... [13:16] # quotaoff -vaug [13:16] ··· invalidate: in_use 97ba30a0[100]:97f87400[100] [13:16] ··· invalidate: in_use 97bb8bc0[100]:97f87400[100] [13:16] ··· invalidate: in_use 97d295e0[100]:97f87400[100] [13:16] ··· quota in use: 97a2c0a0 (1) [13:16] ··· dquot (0,1,0) dqh: 97f87400 (100) [13:16] and the hang ... [13:16] so I guess we are getting somewhere ... [13:16] how did you do it? [13:17] chcontext --ctx 100 bash -c "sleep 100 >/mnt/part1/block100.log &" [13:17] cqhadd -v -x 100 /dev/discs/disc1/part1 [13:17] and then from inside the context (100) [13:17] quotacheck -maug [13:17] quotaon -vaug [13:17] quotaoff -vaug [13:17] so it actually is the 'open' file [13:17] does the sleep have to be before the cqhadd? [13:18] not sure yet, but will check, just a minute ... [13:19] seems so ... [13:19] well, I also get it when there are no clear open files before the quotaon/off [13:20] (except maybe the quotaon/off program itself?) [13:23] let me check the code once again .. the BAD INODE should not happen at all ... [13:33] ccooke (~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com) joined #vserver. [13:34] Morning [13:34] morning! [14:10] mids: are you here? [14:10] I am, are you? [14:10] yup [14:10] I guess I have a fix ... [14:11] you know thy vi? [14:11] reasonable well [14:11] perfect ... [14:11] fs/dquot.c, line 1111 [14:12] just below : dprintk("··· dquot_initialize: #%d %p\n", (dqh)?dqh->dqh_id:0, dqh); [14:12] add the folowing: [14:13] if (dqh && !inode->i_dqh) { [14:13] printk("··· MISSING DQH: %p(%d) added %p(#%d,%d)\n", [14:13] inode, inode->i_xid, dqh, dqh->dqh_id, dqh->dqh_xid); [14:13] inode->i_dqh = dqh; [14:13] } [14:13] okay? [14:13] ok [14:14] done [14:14] and it should be the same issue for ext2/ext3 ... [14:15] I'm not sure how that went 'almost' unnoticed, but ... [14:16] guess I have to rework taht stuff for q0.13 soon ;) [14:17] ok [14:17] so recompile, reboot, retry? [14:17] or do ou have more things? [14:17] nope, that's it, basically a oneliner ... [14:18] what is this with those funny ascii characters? [14:18] it covers the cornercase, where the inode has a context id, is already opened and the quota hash comes into play ... (including quota on) [14:19] hmm, well, on _all_ my terminals, they are just dots in the middle of the character [14:19] on IRC it looks fine [14:19] but on that other box not [14:19] anyway [14:20] you get them by pressing AltR-. [14:20] no problem if you use any other char there, they are just to separate my output from other messages ;) [14:20] Action: mids never mastered terminal configuration [14:22] it's an art ... ;) [14:23] ok, upon quoteoff I still get the invalid: in_use / dirty messages [14:23] now let me quota on/off again [14:24] 3 restarts without issues [14:24] now trying to quotaon/off within the vserver [14:24] ok, second try the MISSING DQH appears [14:24] followed by BAD INODE [14:25] but no locks [14:25] will now try with ext3 [14:25] good [14:30] does /vservers directory need the chmod 000 ? [14:31] well, it doesn't need it, it's a security feature ;) [14:31] I know :) [14:31] I'm asking whether this is "fixed" :) [14:31] oh well, never hurts to chmod it to 000 [14:31] hmm, fixed like the oposite of 'broken'? [14:32] I thought that there was supposed to be change in source code so that 000 would not be needed? [14:33] well, jack envisioned the chsaferoot/chrootsafe() stuff, but enrico showed, that it can be escaped without much efford ;) [14:33] so where we stand now? [14:33] in terms of security I mean [14:33] 000 is secure. period. [14:33] cool :) [14:34] we'll add a barrier flag in the near future, to replace this ... [14:34] probably that's what I read [14:34] actually latest devel release already contains the code ... [14:35] but it's not tested yet .. [14:37] ic [14:37] from what I understood before the quota thing is fixed (or should be thoroughly tested now for the fix)? [14:37] Bertl: awesome! no more lockups with ext3 either [14:38] great, thanks for testing, and patience ... [14:38] thanks for your time [14:39] miller7: well, the quota stuff is in use for a long time now ... and it is stable without that modification, if you do not open files before you add the quota hashes ;) [14:40] the new change has to be tested for some time, but as far as I can tell, it can only make things better ... [14:41] well, I will test it anyway but I was just curious cause mids reports success so far [14:41] rationale: that codepath is never touched if you do not open files before (and keep them open while) you add quota hashes ... [14:42] probably most quota installations either do not open files before they add the quota hash, or do never turn off quota ... [14:42] e-metal® payment confirmation: Batch 32672021 [14:42] Paid To: 1193801 (Linux VServer ) [14:42] Amount: 50 Euros' worth of Gold [14:42] Memo: quota fixes [14:42] From: 503924 (Joris Bontje) [14:42] :P [14:47] right [14:48] mids: thank you very much, (confirmed) [15:20] TamaPanda (~Tamama@193.173.84.237) joined #vserver. [15:20] Hi TamaPanda! [15:21] holas [15:21] amigos ay ay ay! ;) [15:21] !si senior¡ [15:22] what is happening in vserver land? :) [15:23] well, we just fixed a long lasting quota issue ;) [15:23] heh [15:23] which was? [15:23] thanks to mids, now your quota is safe again ... (well almost) [15:24] so what was the 'issue' ? [15:24] actually using q0.12 and preferable ext3 (but also ext2) and doing funny things (not intentionally but accidentially) like openening a file, and keeping it open, while attaching a new quota hash, and turning on quota, then later on off again, will hang your machine ... [15:25] ah [15:25] (waiting for the opened file to be released, which never happens) [15:26] I think that is what happened to me... [15:26] quotaoff would ang [15:26] hang [15:26] great, another issue fixed ;) [15:26] what patch is that in [15:27] not released yet, but it's quite simple, only one (maybe two) lines of code added to fs/dquot.c [15:27] 'if file open dont bloody wait' ? :) [15:31] http://vserver.13thfloor.at/Stuff/patch-q0.12-hang-fix.diff [15:31] here is the fix, including some debug messages ... [15:32] +if (dqh && !inode->i_dqh) [15:32] +inode->i_dqh = dqh; [15:32] so basically it didnt check [15:32] would be sufficient to fix it ... [15:34] well, actually I assumed that it would be a bug() if an inode belonging to a context, is active without a quota hash (if there is a quota hash for that context) [15:34] which is reported by the 'BAD INODE' message ... [15:34] so I didn't bother with this case anymore ... [15:35] now what was wrong in my assumptions, was that there could be active inodes, before and especially while the quota hash is added ... [15:36] and in this case, we now just assign the quota hash to them ... [15:36] how would that make them hang on shutdown though [15:36] I'll have to check if that does anything evil to the quota accounting, but I guess it's handled correctly ... [15:37] the hang is a tricky sideeffect ... [15:37] basically if you want to turn quota off (while the filesystem is mounted and running, which is normal for ext2/ext3) [15:38] the kernel has to walk all inodes, and remove the reference to dquots (quota units) if there are any ... [15:39] now, an inode having a dquot ref, but no quota hash assigned, leads to freeing the dquot, but not giving up the reference to the quota hash ... [15:39] which in turn leads to a quota hash, waiting for some inodes to give up their reference ... [15:39] heh [15:39] unaligned refs are tricky yes.. [15:40] and that is the hang, some quotaoff command, waiting for some inodes, never giving up ... [15:40] hm could the quotaoff util not check on that then? [15:41] and after a few seconds just say something like "gah the refs arent giving up, go bug the quotapatch maintainer' [15:42] well, the quotaoff utility simply invokes the quotaioctl in the kernel, which never returns (waiting in D state ;) [15:42] ok so that kernel could do that :) [15:42] basically yes, but basically the quota system is broken in this regard anyway ... [15:42] Wouldnt be that hard to check if the refcount has stayed the same for a longer period of time.. [15:43] well yeah the quotasystem had to be fixed obviously, but it never helps to add safeguards for other similair problems ;) [15:43] well, it was a bug, and it should be fixed now ... [15:43] erm [15:43] never hurts [15:44] well, it's not that easy ... [15:45] when and where do you want to check? and who says that waiting for 1 min is/isn't enough? [15:45] those are the smallest issues with a 'safeguard' approach on that ... [16:04] true [16:04] but i could do a kernel log at least and no other action :) [16:04] s/i/it/; [16:08] Action: TamaPanda noticed an email on the list ;) [16:22] okay, have to leave now, cu later ... [16:23] bye bert [16:23] Nick change: Bertl -> Bertl_oO [17:25] serving (~serving@213.186.190.24) left irc: Read error: Connection reset by peer [18:39] marius (~root@port-212-202-3-179.reverse.qsc.de) joined #vserver. [18:39] hello [18:42] do thesen virtual hosts work behind routers, too? [18:44] marius (~root@port-212-202-3-179.reverse.qsc.de) left irc: Quit: using sirc version 2.211+KSIRC/1.2.4 [18:47] Nick change: Bertl_oO -> Bertl [18:47] okay, short visit, anything important? [18:48] okay, cu in a few hours ... [18:48] Nick change: Bertl -> Bertl_oO [18:58] CMaJ (~My@216.113.62.236) joined #vserver. [18:58] hi [18:59] Nick change: CMaJ -> CmajDecker [18:59] serving (~serving@213.186.190.24) joined #vserver. [19:06] CmajDecker (~My@216.113.62.236) left irc: Quit: just dont do it [19:06] Cmaj (~cmaj@3ffe:bc0:5f3:1:9999:911:c3d3:5431) joined #vserver. [19:38] hello again [19:39] can I install vservers stable on a dual SMP Intel III? [19:39] P III I mean [19:39] or there are issues with SMP? [20:02] no expert but if it compile so it should work well better try it :) [20:03] well, compiling gentoo from scratch takes 2 days so it is an issue for me :) [20:04] hehe yeas thats a fact actually smp is in for a long time [20:04] dunno if its broken [20:05] I run vservers on it [20:05] but I think I saw on the mailing list about newest kernels and vservers and SMP = problem [20:06] Linux cmaj 2.4.24-vs1.24-cjd1 #1 12:13:44 up 9 days, [20:06] humm [20:06] better w8 :) for a better answer [20:07] :) I think so too [20:07] vserver really owns [20:08] yeah [20:08] I use it for > 2 years now I think [20:09] ho me less :) a little more then a year _shuri told me about these funky stuff and i adopt it ..maybe i would have put bsd on it :) [20:11] ok i got to go finish high skool :) lol [20:55] click (~click@virtualdesignz.net) joined #vserver. [20:59] click (~click@virtualdesignz.net) left irc: Quit: be right back! [22:03] Nick change: Bertl_oO -> Bertl [22:03] hi folks! [22:06] hello Bertl! [22:06] miller7: well ad SMP on dual P3, I would suggest to use either the 2.4.25-pre7 prerelease or wait for 2.4.25 final, together with either vs1.24 or vs1.3.3 and later there should be no vserver related SMP issues .. [22:06] hi dan! [22:07] how is/was your day? [22:08] oh, it's just begun :) [22:09] but it promises to be interesting [22:09] well, then you can still hope ;) [22:09] how is yours going? [22:09] mine was a catastrophe in episodes ... [22:10] yuck [22:10] here's hoping that it gets better [22:10] in the morning I wake up and it was cold, not only outside, I'm used to that, but also inside *( [22:11] heater problem? [22:11] our central heating system was broken ... I spent halve the day fixing it ... [22:11] now I smell like smoked ham ;) [22:11] a warm smoked ham? :) [22:12] well, yes, it is warm now ... [22:12] well, that sounds tasty! :) [22:12] don't you dare and take a bite of me ... [22:12] heh [22:12] Action: Bertl hides behind the keyboard ... [22:13] Action: MrBawb drools [22:13] mmmm smoked ham [22:13] we have cats, I know how to defend myself ;) [22:14] cats with mustard [22:14] jummy [22:14] ah, cats. impenetrable defenses! [22:14] well, I'm going to go eat some lunch now :) [22:14] enjoy it ... [22:18] click (~click@virtualdesignz.net) joined #vserver. [22:19] hi click! [22:19] heya [22:19] :) [22:19] darned dns servers are too slow today, can't use my regular domains [22:19] what horror?! [22:20] ;) [22:20] not a problem anyway [22:21] are there any real problems? [22:21] nah, just solutions [22:21] :) [22:21] that's the spirit! [22:21] had to recompile chbind to support the new 'more than 16' ip's on the vservers as well [22:22] hmm, yes, are you interested in testing some range hacks? [22:22] yeah, sure [22:23] okay, nothing available yet, but I wanted to know if there is interest ... [22:23] there is, believe me. [22:23] shell-servers, ssl-vservers etc [22:23] I always believe you, especially wenn you're drunk ;) [22:24] haha darned, did I do anything stupid :D ? [22:24] <-- don't remember shite [22:24] no, was mostly harmless ... [22:24] I'm usually harmless :) [22:25] yeah, some get angry and offensive, others just funny and/or sad ... [22:25] except when seriously pissed off. Even my best friends tends to make a shadow of themselves [22:25] i get sad or happy when drunk [22:25] never been angry while drinking... hmm well, once... [22:26] what vserver version do you currently use/test? [22:26] but that was due to some other circumstances as well [22:26] running 2.4.24-1.24-1.9.13 [22:26] kernel-vserver-grsec [22:26] rock stable so far [22:26] okay, so you would prefer patches agains that kernel? [22:26] +t [22:26] nah, I can test against almost anything [22:27] okay ... good ... [22:28] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [22:28] hi mhepp! [22:28] Bertl, hi [22:29] bertl: if you want me to test some rather hair-raising patches as well, let me know - as long as it doesn't involve hardware corruption :D [22:30] ah, okay, that rules out that genetic algorithm to modify your processor then, I guess ;) [22:30] well, if it will increase its speed, overclock it without damageit's ok :D [22:53] hmm, okay, you understood what I tried to explain last time, regarding the ranges? [22:54] yup, I didn't apply it that way tho', I had to get it up fast and easy, so I added a context that holds 140 of the system ip's instead, works well [22:55] yeah, I know ... but the principle is clear? [22:56] yeah, it's like a subnet kind of [22:58] hmm, well actually you specify a start and an end for each range ... [22:58] so if you want to specify 192.168.2.3-192.168.2.20 you just specify 192.168.2.3, 192.168.2.20 [22:59] but the addresses have to follow some rules, namely: [22:59] a) start is always smaller than end ;) [23:00] b) if you want to have some descrete addresses, you need to specify one ip ranges like 192.168.2.3-192.168.2.3 (means 192.168.2.3,192.168.2.3) [23:00] c) order of ip addresses specified _is_ important ;) [23:01] d) network byte order is important too ... [23:02] is anything about that unclear? [23:02] ah yes, and you have to setup your aliases yourself, because the tools won't be able to do it ...at least not correctly ... [23:04] click: still here? [23:04] ofcourse :) [23:05] okay, interested in testing such stuff? [23:05] yeah, sure. [23:05] http://vserver.13thfloor.at/Experimental/patch-2.4.25-pre7-vs1.3.6-range-hack.diff [23:05] okay, I hacked that together, while I verified the cdrom images I burned ... [23:05] so it is not tested at all .. but it might work ;) [23:06] if you specify an uneven number of ip addresses, all but the last one are considered ranges, the last one is considered a single ... [23:07] hm, what's a better hack might actually be validating ranges with - as a separator, like 192.168.1.1-15, 192.168.1.90-110 [23:07] start with a small range, something like 10.0.0.2 - 10.0.0.5 and test if it works ... [23:07] as that's easier to mantain. [23:08] click: that would be fun, but would require to change the userspace tools, but patches are always accepted ;) [23:08] it's more effective than adding ranges separated by , [23:09] well currently ther is no ',' [23:09] you have to specify --ip 192.0.0.1 --ip 192.0.0.5 for example ... [23:09] or with the 'tools' IP="192.0.0.1 192.0.0.5" [23:10] which actually means the range 192.0.0.1-192.0.0.5 [23:10] where IP="192.0.0.1 192.0.0.5 192.0.0.7 192.0.0.10 192.0.0.12" [23:10] would mean 192.0.0.1-192.0.0.12 excluding 192.0.0.6 and 192.0.0.11 ;) [23:11] okay, I'm leaving now, have fun, I'll be back in about 100 minutes ... [23:11] Nick change: Bertl -> Bertl_oO [23:11] well, I'd rather patch the usertools and use the range I suggested, as it's easier for the users to understnad the ranges there [23:20] Doener_zZz (~doener@pD9588FD4.dip.t-dialin.net) joined #vserver. [23:28] Doener (~doener@p5082D3CF.dip.t-dialin.net) left irc: Ping timeout: 501 seconds [23:33] deadguy (deadguy@bananajoe.big.du.se) left irc: Ping timeout: 501 seconds [23:37] deadguy (deadguy@bananajoe.big.du.se) joined #vserver. [23:38] ccooke (~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com) left irc: Ping timeout: 480 seconds [00:00] --- Thu Jan 29 2004