1264464129 Q * dowdle Remote host closed the connection 1264465934 J * friendly ~friendly@ppp118-209-233-97.lns20.mel6.internode.on.net 1264466123 P * friendly 1264467469 M * fzylogic Bertl: do you have preemption enabled in your test kernel? 1264467672 M * Bertl I guess so, sec 1264467702 M * Bertl # CONFIG_PREEMPT_NONE is not set 1264467702 M * Bertl # CONFIG_PREEMPT_VOLUNTARY is not set 1264467702 M * Bertl CONFIG_PREEMPT=y 1264467702 M * Bertl CONFIG_DEBUG_PREEMPT=y 1264467712 M * fzylogic yeah, that's why you aren't seeing the soft CPU lockups 1264467730 M * Bertl ah, okay, easy to change then :) 1264467744 M * fzylogic hopefully that'll help you to debug it a bit more :) 1264467781 M * fzylogic I'm wondering if it's not related to the code around line 598 in kernel/signal.c 1264467797 M * fzylogic building a kernel with it commented out as we speak 1264467814 M * fzylogic that was one of the few related changes between 2.6.28.10 and 2.6.29.2 1264468223 Q * yarihm Quit: This computer has gone to sleep 1264468438 M * fzylogic that does appear to be part of the problem 1264468515 M * fzylogic that was preventing the process from even receiving a kill signal 1264468539 M * fzylogic unfortunately, the process still hangs (unless you run it via strace, in which case it exists nicely) 1264470631 M * Bertl okay, so you commented out the check and goto skip? 1264470672 M * fzylogic yeah 1264470685 M * fzylogic doesn't actually seem to fix it _every_ time which is weird 1264470690 M * fzylogic but it would never ever work before 1264470691 M * fzylogic :-/ 1264470718 M * Bertl well, the signal sent from the OOM should fail the SI_FROMUSER(info) 1264470779 M * fzylogic yeah, I don't know why it's making a difference 1264470794 M * fzylogic but I did get a pair of check_kill_permissions printks that I wasn't getting before 1264470820 M * Bertl okay, let's add some debug info there then 1264470864 M * Bertl copy the check_kill_permissions to above the check 1264470892 M * Bertl add three entries (%d) for the checks 1264470900 M * Bertl i.e. something like: 1264470909 M * Bertl vxdprintk(VXD_CBIT(misc, 7), 1264470927 M * Bertl "check_kill_permission(%d,%p,%p[#%u,%u]) %d,%d,%d", 1264470939 M * Bertl sig, info, t, vx_task_xid(t), t->pid, 1264470954 M * Bertl (info != SEND_SIG_NOINFO) ? 1 : 0, 1264470968 M * Bertl is_si_special(info) ? 1 : 0, 1264470989 M * Bertl SI_FROMUSER(info) ? 1 : 0); 1264471017 M * Bertl leave the check itself in place, so that we get the 'normal' behaviour 1264471033 M * fzylogic ok 1264471410 M * fzylogic well that caused an oops :) 1264471734 M * fzylogic yeah, null pointer deref 1264471789 M * fzylogic gotta head home now. I'll check in in the morning 1264471791 P * fzylogic 1264472289 Q * dallas Quit: dallas 1264474725 Q * SubZero 1264478196 M * Bertl off to bed now .. have a good one everyone! 1264478201 N * Bertl Bertl_zZ 1264478462 J * SauLus_ ~SauLus@d003008.adsl.hansenet.de 1264478873 Q * SauLus Ping timeout: 480 seconds 1264478873 N * SauLus_ SauLus 1264481402 J * ghislain ~AQUEOS@adsl2.aqueos.com 1264484235 Q * niki Quit: Leaving 1264489322 J * derjohn_mob ~aj@d003115.adsl.hansenet.de 1264490453 Q * derjohn_mob Ping timeout: 480 seconds 1264491285 J * niki ~niki@cpe.fe4-0-120.0x50a6de52.kdnxd4.customer.tele.dk 1264492768 J * yarihm ~yarihm@office-zrh.youngsolutions.ch 1264493497 J * derjohn_mob ~aj@213.238.45.2 1264493893 Q * zbyniu Ping timeout: 480 seconds 1264493954 J * zbyniu ~zbyniu@ip-62.181.188.13.static.crowley.pl 1264495161 J * kir ~kir@swsoft-msk-nat.sw.ru 1264495997 J * asterix ~gab@90.149.121.45 1264496259 J * SubZero ~SubZero@chello089076140236.chello.pl 1264496486 J * barismetin ~barismeti@zanzibar.inria.fr 1264497208 Q * Chlorek charon.oftc.net joule.oftc.net 1264497208 Q * barismetin charon.oftc.net joule.oftc.net 1264497208 Q * asterix charon.oftc.net joule.oftc.net 1264497208 Q * SauLus charon.oftc.net joule.oftc.net 1264497208 Q * larsivi charon.oftc.net joule.oftc.net 1264497208 Q * DelTree charon.oftc.net joule.oftc.net 1264497208 Q * padde charon.oftc.net joule.oftc.net 1264497208 Q * Loki|muh charon.oftc.net joule.oftc.net 1264497208 Q * arekm charon.oftc.net joule.oftc.net 1264497208 Q * mnemoc charon.oftc.net joule.oftc.net 1264497208 Q * ktwilight_ charon.oftc.net joule.oftc.net 1264497229 J * barismetin ~barismeti@zanzibar.inria.fr 1264497229 J * asterix ~gab@90.149.121.45 1264497229 J * SauLus ~SauLus@d003008.adsl.hansenet.de 1264497229 J * larsivi ~larsivi@47.80-202-217.nextgentel.com 1264497229 J * DelTree ~deplagne@goldorak3.eric.deplagne.name 1264497229 J * padde ~padde@patrick-nagel.net 1264497229 J * Loki|muh ~loki@satanix.de 1264497229 J * arekm arekm@carme.pld-linux.org 1264497229 J * mnemoc ~amery@shell.opensde.net 1264497229 J * ktwilight_ ~keliew@7.7-240-81.adsl-dyn.isp.belgacom.be 1264497236 J * Chlorek cokolwiek@c.sed.pl 1264497995 J * dna ~dna@170-198-103-86.dynamic.dsl.tng.de 1264500033 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1264500307 N * Bertl_zZ Bertl 1264500312 M * Bertl morning folks! 1264501135 J * thierryp ~thierry@zankai.inria.fr 1264501280 Q * gnuk Remote host closed the connection 1264503262 J * BenG ~bengreen@cpc2-aztw22-2-0-cust521.aztw.cable.virginmedia.com 1264503499 Q * pmjdebru1jn Remote host closed the connection 1264503501 J * pmjdebruijn pascal@jester.pcode.nl 1264504128 Q * yarihm Quit: This computer has gone to sleep 1264504898 Q * SubZero Ping timeout: 480 seconds 1264505214 M * hijacker_ morning 1264505459 J * emcepe ~mcp@wolk-project.de 1264505647 Q * mcp Ping timeout: 480 seconds 1264505648 N * emcepe mcp 1264505924 Q * groente Ping timeout: 480 seconds 1264506477 J * groente ~groente@shell.puscii.nl 1264506856 Q * Chlorek Ping timeout: 480 seconds 1264507736 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1264507852 Q * BenG Quit: I Leave 1264508603 Q * gnuk Remote host closed the connection 1264509584 M * Bertl off for now ... bbl 1264509588 N * Bertl Bertl_oO 1264510159 J * wibble wibble@vortex.ukshells.co.uk 1264510379 J * SubZero ~SubZero@chello089076140236.chello.pl 1264510528 J * Chlorek cokolwiek@c.sed.pl 1264511769 Q * SubZero 1264512644 J * SubZero ~SubZero@chello089076140236.chello.pl 1264512950 Q * SauLus Quit: ... the proxy is gone 1264513074 J * SauLus ~SauLus@d003008.adsl.hansenet.de 1264514071 J * BenG ~bengreen@cpc2-aztw22-2-0-cust521.aztw.cable.virginmedia.com 1264514580 Q * BenG Quit: I Leave 1264515403 Q * SubZero 1264516202 Q * asterix Remote host closed the connection 1264516202 Q * sharkjaw Remote host closed the connection 1264516963 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1264518623 J * yarihm ~yarihm@84-72-135-146.dclient.hispeed.ch 1264519358 Q * yarihm Ping timeout: 480 seconds 1264519444 J * yarihm ~yarihm@217-162-53-251.dclient.hispeed.ch 1264519515 Q * niki Quit: Leaving 1264519847 Q * FloodServ Service unloaded 1264519860 Q * auntieNeo resistance.oftc.net synthon.oftc.net 1264519860 Q * AndrewLee resistance.oftc.net synthon.oftc.net 1264519860 Q * nox resistance.oftc.net synthon.oftc.net 1264519860 Q * mEDI_S resistance.oftc.net synthon.oftc.net 1264519860 Q * sardyno resistance.oftc.net synthon.oftc.net 1264519860 Q * nkukard resistance.oftc.net synthon.oftc.net 1264519860 Q * FireEgl resistance.oftc.net synthon.oftc.net 1264519881 J * nox ~nox@nox.user.oftc.net 1264519881 J * mEDI_S ~medi@255.255.255.255.li 1264519881 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1264519881 J * sardyno ~me@pool-173-75-5-88.pitbpa.fios.verizon.net 1264519881 J * nkukard ~nkukard@196.212.73.74 1264519881 J * AndrewLee ~andrew@u7.hlc.edu.tw 1264519881 J * auntieNeo ~rewt@97-121-39-78.bois.qwest.net 1264519892 M * derjohn_mob Bertl_zZ, daniel_hozac : Who maintains the Vserver Mailing List? I think the TLS support is broken since years. I disabled TLS in my Mailserver and now the mails go through. 1264519964 J * FloodServ services@services.oftc.net 1264520003 M * daniel_hozac Hollow: does 1264521731 Q * derjohn_mob Ping timeout: 480 seconds 1264521851 J * zbyniu_ ~zbyniu@ip-62.181.188.13.static.crowley.pl 1264521851 Q * zbyniu Read error: Connection reset by peer 1264523323 J * derjohn_mob ~aj@213.238.45.2 1264525089 N * Bertl_oO Bertl 1264525095 M * Bertl Hollow: ping? 1264525129 M * Bertl Hollow: we seem to have two issues, one being the update script not running and the other being TLS support on the ML is broken 1264525293 M * Bertl daniel_hozac: can we use mem cgroups with recent util-vserver releases? 1264525340 M * Bertl because I guess I figured out what really happens on those OOM high load and sometimes host crashes after all 1264525427 N * sid4windr sid3windr 1264525466 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1264525617 M * Bertl hey bonbons, we should talk about ipv6 if you got some time ... 1264525628 J * niki ~niki@0x5553169c.adsl.cybercity.dk 1264525728 M * daniel_hozac Bertl: yeah, sure. 1264525786 M * Bertl daniel_hozac: because I think we would be better off to remove the rss limits (and if necessary add the mem/swap virtualization elsewhere) than fixing up the rss/oom issues 1264525842 M * Bertl it seems, from the code I've read that the memory cgroups do vm/rss accounting by now, in a very similar way we do (except for the error case) 1264525884 M * Bertl the problem with oom seems to be that the mainline design is based on a memory reserve which is granted in oom case to allow a task to die properly 1264525925 M * Bertl the cgroups work around that problem by adding an artificial 'delay' (kind of rate limiting) to the OOM cases 1264525948 M * Bertl which basically allows the process to die after allocating more than it is actually allowed to allocate 1264525996 M * Bertl as we do strict limits even in the (guest) OOM case, we end up in a loop killing the same process over and over (well, not actually killing it, but calculating the badness) 1264526263 M * daniel_hozac ah 1264526278 M * daniel_hozac i guess we should add mappings in util-vserver. 1264526311 M * daniel_hozac so the old settings will apply to the newer kernels, if we remove it. 1264526476 Q * pinochle Read error: Operation timed out 1264526536 M * Bertl yes, and maybe add some documentation on how to setup the memory/swap limits there 1264526544 M * Bertl (to the wiki) 1264526595 M * Bertl but I guess that could be done by somebody else (e.g. fzylogic) after testing the setup 1264526671 M * Bertl regarding ipv6, I tend to removing it from the upcoming stable again, till we have time to fix that up properly ... but maybe bonbons feels like taking another shot ... 1264526695 J * pinochle ~pinochle@67.159.48.101 1264526725 M * Bertl i.e. I'd keep it as patch and in devel/experimental, but IMHO there is no point in having a broken ipv6 in stable ... 1264526785 M * daniel_hozac what's the current status of it? 1264526852 M * Bertl AFAIK, bonbons said it's fine, other folks reported the 'known' ipv4/ipv6 collisions, I didn't have time to setup a test scenario and write the test script yet 1264527608 Q * derjohn_mob Ping timeout: 480 seconds 1264528111 Q * yarihm Quit: This computer has gone to sleep 1264528184 Q * gnuk Quit: NoFeature 1264529256 M * _Shiva_ Bertl: i'm willing to test things wrt ipv6 - just say what and how ;-) 1264529291 J * fzylogic ~fzylogic@dsl081-243-128.sfo1.dsl.speakeasy.net 1264529424 M * _Shiva_ Bertl: and regarding oom - mainline does quite a few refactoring lately from 2.6.x to 2.6.y .. from what i've read from the ChangeLogs 1264529518 Q * thierryp Ping timeout: 480 seconds 1264529595 M * bonbons Hi Bertl, I won't have time this evening, maybe tomorrow or on thursday evening. It would be nice if those people who experience issues could at least describe their scenarios so they can be reproduced... (if I get time to do so, I might try out the Kernel test project, in the hope that there are network test in there...) 1264529621 M * bonbons anyway, off for now 1264529817 J * hijacker ~hijacker@87-126-142-51.btc-net.bg 1264530056 M * Bertl okay, I'll send a message to the ML, that all ipv6 folks should report their issues (if possible with test cases) 1264530093 M * Bertl _Shiva_: okay, so simple ipv4 + ipv6 tests would already help I guess 1264530126 M * Bertl i.e. binding mapped ipv4 as well as ipv6 addresses, binding 0.0.0.0 for ipv4+ipv6 etc 1264530155 M * Bertl last time, the problem was almost entirely with binding the 'same' IP in ipv4 and ipv6 (on the same guest) 1264530178 M * Bertl ipv4 only and ipv6 only guests seem to work fine, AFAIK 1264530200 M * _Shiva_ Bertl: ok - only with 2.6.32.x? or better accross different vanilla? 1264530211 M * Bertl daniel_hozac: patched yum fails too? (see ML) 1264530246 M * Bertl 2.6.32.x (preferably latest is fine) if you want to avoid that FWR, you can test with 2.6.31.x too 1264530256 Q * barismetin Quit: Leaving... 1264530465 M * _Shiva_ would util-vserver-0.30.216_pre2864 be fine enough? 1264530532 M * fback Bertl: what issues with 2.6.32 made you go back to 2.6.31? 1264530665 M * Bertl mostly instability and I/O regressions 1264530676 J * dallas ~dallas@dsl081-243-128.sfo1.dsl.speakeasy.net 1264530700 M * Bertl for example, one of my raid setups dropped from about 120M/s to roughly 11M/s with the new async I/O mechanism 1264530767 M * _Shiva_ Bertl: it may be the "CFQ Low Latency Mode"..? or what is your queue sched? 1264530817 M * fback hm... I've noticed comparably slow I/O on my desktop... only about 230Mbps writing speed to a modern sata drive 1264530863 M * fback and it raises load to about 4 1264530882 M * fback (and it's ubuntu with tweaked 2.6.32) 1264530961 M * _Shiva_ fback: Seagate drive apparently? 1264531067 M * fback Bertl: is 2.3.0.36.28 + vanilla 2.6.32.4 the right combination to test ipv6 issues? 1264531104 M * fback _Shiva_: ST3250624AS, so it is some kind of seagate, right? 1264531115 M * _Shiva_ fback: yep - 1264531194 M * Bertl fback: yep, should be fine 1264531228 M * _Shiva_ quoting from Gentoo-Forums: "switching to zen-sources and using BFQ or FIFO scheduler with disabling NCQ (echo 1 > /sys/block/sda/device/queue_depth) help me to improve situation".. "in that case it's a bad / faulty ncq-implementation of your harddrives :idea: (seagate - I'm looking at you :wink: )" 1264531289 A * _Shiva_ is also experiencing io regressions on Seagate sata-2 drives over here.. 1264531349 M * Bertl well, I have some seagates but that specific machine is using hitachi drives 1264531361 M * Bertl and yes, CFQ is my default I/O scheduler 1264531363 M * fback _Shiva_: I have 1 in queue_depth for this drive already 1264531383 M * _Shiva_ Bertl: Seagate as a prominet but not limited to candidate 1264531392 M * fzylogic the low-latency mode can be toggled on the fly 1264531397 M * fzylogic might want to try turning it off 1264531438 M * Bertl didn't get to that point, as the kernel paniced with an OOM (in the async threads) soon after starting 1264531447 M * fzylogic hah 1264531463 M * Bertl which brings us back to the OOM issue :) 1264531494 M * Bertl I had a deep look at the code and tried to figure what happens there (with a bunch of debug messages) 1264531515 M * fzylogic same here 1264531515 M * Bertl and I guess I know what actually causes the OOM high load/panic with soft lockup issue 1264531522 M * fzylogic oh yeah? 1264531566 M * Bertl yes, basically when mainline enters OOM (on the host), it activates some memory reserves 1264531584 M * Bertl which allow the process to use up even more memory when it is dying 1264531592 M * fzylogic right 1264531626 M * Bertl as Linux-VServer has a hard limit on rss, we succeed in making the process die, but we cannot provide that memory reserve 1264531657 M * Bertl i.e. the process starts to finish whatever it is currently doing, and *bang* we end up in the OOM/select bad process again 1264531681 M * Bertl which walks the list, finds a process which is already dying and bails out with 'nothing to do' 1264531695 M * Bertl this repeats (almost) forever ... 1264531711 M * Bertl so, IMHO options there are: 1264531728 M * Bertl - raise the memory limit on guest OOM (possible exploit) 1264531747 M * Bertl - delay futher OOM situations (again, exploitable) 1264531790 M * Bertl but, I also found that the memory cgroups already handle that in a quite complicated 'rate limiting' process 1264531815 M * Bertl so, my proposal is to get rid of the rss limits completely and use the memory cgroups for that 1264531839 M * Bertl (we can add required virtualizations/settings/actions there for the guests too) 1264531866 M * fzylogic we've attempted switching to cgroups to mitigate the issues we've been having, but util-vserver wasn't always behaving as expected 1264531886 M * Bertl that's why we need some testing there I guess 1264531891 M * fzylogic yeah 1264531900 M * fzylogic and it's probably more easily fixed than the kernel :) 1264532098 M * fback _Shiva_: this seagate drive doesn't seem to report ncq 1264532142 M * Bertl fzylogic: more importantly, we would need to do something similar to the memory cgroups anyway, so we'd end up duplicating code 1264532151 M * _Shiva_ fback: mkay - is it connected "native" sata? 1264532172 M * fback _Shiva_: and there's another suspicious line regarding this drive: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doe 1264532175 M * fback sn't support DPO or FUA 1264532187 M * fzylogic ok, I'll set that up and see what bugs are in util-vserver 1264532223 M * Bertl fzylogic: so, my proposal is that you give it a try with the memory cgroups, daniel_hozac is adding a mapping to allow 'old' configs to work with that too (in the near future) and we'll try to fixup any issues there and add missing stuff for a Linux-VServer setup 1264532264 M * fzylogic I wrote cgroup support into our vserver configuration code looong ago so the config part I have taken care of 1264532266 M * Bertl if that works, we take it a step further and rip out the memory limits/accounting from the Linux-VServer kernel 1264532287 M * _Shiva_ fback: write cache is (<- should be) usually disabled on drives as it needs to be battery backed up to be safe 1264532328 M * fback _Shiva_: the other drive, wdc, switches write cache on 1264532359 M * fback _Shiva_: and yes, it is set up as AHCI(?) drive in bios 1264532386 M * Bertl I'd like to see a moderate priced large size SATA disk to achieve reasonable performance with write caches disabled :) 1264532413 M * _Shiva_ fback: maybe someone (you? ;-) ) switched on write caching on the other drive using hdparm some day earlier..? 1264532437 M * _Shiva_ Bertl: so you mean that are false readouts? 1264532478 M * Bertl with NCQ and write caches disabled, I'd expect your SATA II disk to have a raw performance of 20-30M/s 1264532482 Q * kir Quit: Leaving. 1264532487 M * fback _Shiva_: nah :-) 1264532514 M * fback _Shiva_: and I'm pretty sure hdparm isn't even installed there 1264532544 M * Bertl but you can test with bonnie++ on an ext3 to see the actual performance you are going to get there 1264532566 M * _Shiva_ fback: if it is, try readings from it: hdparm -i /dev/sd? | grep WriteCache 1264532891 M * fback AdvancedPM=no WriteCache=disabled 1264533112 M * fback hmh... kernel config should be restructured somehow... it takes hour to just skim through available options :| 1264533337 J * SubZero ~SubZero@chello089076140236.chello.pl 1264533405 M * fzylogic daniel_hozac: there? 1264534429 J * Esmil ~esmil@1110ds2-noe.0.fullrate.dk 1264534511 M * Esmil Hi, is there a git repository for easy merging of the devel vserver patch? 1264534630 M * Bertl nope 1264534664 M * Esmil Ahh, thats why didn't manage to find it on the wiki ;) 1264534696 J * balbir ~balbir@122.172.51.36 1264535128 M * Bertl Esmil: with what do you plan to merge it? 1264535140 M * Esmil The linux kernel sources 1264535160 M * Esmil Just like applying the patch, only easier if you have other patches too 1264535177 M * Bertl well, the patches are against the linux kernel, so no merging required there 1264535242 M * Esmil Well, unless you have other patches applies too ;) 1264535317 M * Marillion feel free, you became finished patches 1264535357 J * thierryp ~thierry@home.parmentelat.net 1264535629 Q * thierryp 1264535904 J * ktwilight__ ~keliew@123.55-240-81.adsl-dyn.isp.belgacom.be 1264535904 Q * ktwilight_ Read error: Connection reset by peer 1264535921 M * Esmil Ahh, git co -b vserver v2.6.32.4; patch -p1 -i ...; git add .; git commit; git co master; git cherry-pick vserver; Fix conflicts ;) 1264536397 M * Marillion to overact, wget rules, patch applied, ready to compile ;) but anyway 1264536450 M * Esmil Was that to me? 1264536534 M * Marillion i don't understood if you want in a git repo, i don't believe it 1264536584 M * Esmil Marillion: Git makes it really easy to deal with multiple patches. 1264536612 M * Marillion for what? 1264536616 M * Marillion if aren't an developer, mutch more 1264536690 M * Esmil Huh? I'm not really a kernel developer, but I do like to experiment with different kernel patches 1264536732 M * Marillion you have won, feel free :) 1264536735 M * Esmil ..like vserver for an example ;) 1264536843 M * Bertl well, no problem, shouldn't be too hard for you to keep a git repository tracking the changes we do to Linux-VServer patches ... 1264536979 M * Esmil No 1264537242 Q * fback Quit: kernel upgrade 1264537998 J * fback fback@red.fback.net 1264538135 Q * hijacker Quit: Leaving 1264538429 M * fback Bertl: seems oident still needs -a :: to bind to ipv4/v6 1264538465 M * Bertl okay, but it works without that on the host, right? 1264538549 M * fback Bertl: no idea, don't need ident service for the host :-) 1264538833 Q * Esmil Quit: leaving 1264538926 M * Hollow Bertl: i'll have a look tomorrow 1264538936 M * Bertl Hollow: tx 1264539010 M * fback Bertl: yup, binds to ::1 on host 1264539629 J * Esmil ~esmil@h59ec3773.dkkonbr.dyn.perspektivbredband.net 1264539845 M * Esmil uname -sr: Linux 2.6.32.6-vs2.3.0.36.28-freakazoid Now let the fun begin :) 1264540033 J * yarihm ~yarihm@80-219-171-55.dclient.hispeed.ch 1264540571 Q * fback Quit: tweaking 1264540991 Q * nou Ping timeout: 480 seconds 1264541033 J * fback fback@red.fback.net 1264541091 M * fback Bertl: huh, I added ipv6 interface but haven't disabled single_ip special case. Corrected this, but oidentd still requires -a :: 1264541232 J * barismetin ~barismeti@jua06-1-82-242-159-114.fbx.proxad.net 1264541556 M * daniel_hozac single_ip doesn't apply to IPv6. 1264541587 M * Bertl and with one ipv4 and one ipv6 address it should be disabled anyways 1264541747 M * fback btw, sshd binds to each ipv4 interface separately, plus to 0.0.0.0 and :: :) 1264541765 M * fback or that's what netstat reports 1264541782 M * Bertl and how does that work out in a guest? 1264541850 M * fback Bertl: ? 1264541871 M * Bertl I mean, is that working fine inside a guest? 1264541911 M * fback Bertl: that is inside a guest and I never noticed any problems 1264541921 M * Bertl ah, good 1264541925 Q * Esmil Read error: Connection reset by peer 1264541936 M * fback (with sshd, that is) 1264541999 J * DreamerC_ ~DreamerC@122-116-181-118.HINET-IP.hinet.net 1264542037 M * fback it just looks funny, that it listens on 192.168.1.2:22 and 0.0.0.0:22 and :::22 :) 1264542088 M * fback (on the host without vserver patches it listens just on 0.0.0.0 and :: no matter how many interfaces there are up 1264542104 Q * DreamerC Ping timeout: 480 seconds 1264542132 M * Bertl could you do an strace -fF for a test startup (-d) of sshd in both scenarios? 1264542145 M * Bertl (make sure that the sshd config is exactly the same) 1264542267 M * fback ok, but I'll do this tomorrow, have to go now 1264542276 M * Bertl np, thanks! 1264542287 M * fback see you 1264542621 Q * ghislain Quit: Leaving. 1264543006 J * derjohn_mob ~aj@e180193154.adsl.alicedsl.de 1264543164 Q * bonbons Quit: Leaving 1264543764 Q * dna Quit: Verlassend 1264543805 J * jrklein ~jrklein@2002:9c1a:9a2b:b:223:6cff:fe7d:120e 1264545001 Q * jrklein Ping timeout: 480 seconds 1264545039 J * nou Chaton@causse.larzac.fr.eu.org 1264545545 J * jrklein ~jrklein@2002:9c1a:9a2b:b:223:6cff:fe7d:120e 1264546026 Q * jrklein Ping timeout: 480 seconds 1264546933 J * jrklein ~jrklein@2002:9c1a:9a2b:b:223:6cff:fe7d:120e 1264548376 Q * jrklein Ping timeout: 480 seconds