1103674488 N * _are_ are|afk 1103675581 Q * Thorsten Quit: Leaving 1103675817 J * Zoiah Zoiah@matryoshka.zoiah.net 1103676300 Q * Zoiah Ping timeout: 480 seconds 1103676570 Q * mugwump Quit: Hardware upgrade 1103677519 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1103678317 J * DuckMaster ~Duck@dyn-83-152-156-7.ppp.tiscali.fr 1103678740 Q * DuckKing Ping timeout: 480 seconds 1103686556 J * rs ~rs@imhotep.rhapsodyk.net 1103686568 M * rs hi 1103689102 Q * infowolfe Quit: leaving 1103689183 Q * mugwump Quit: Hardware change - phase II 1103691075 Q * nox Ping timeout: 480 seconds 1103691278 J * nox ~vps@213.39.193.55 1103695184 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1103696301 Q * are|afk Quit: Disconnecting 1103696849 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3, ng8.7 1103696849 T * Bertl - 1103698292 Q * mugwump Ping timeout: 480 seconds 1103698917 N * Bertl_oO Bertl 1103698926 M * Bertl morning folks! 1103698996 M * eyck morning? 8:02? 1103699018 M * Bertl well, unfortunately happens sometimes :/ 1103699112 M * rs hey Bertl 1103699136 M * Bertl hey rs, you are still up? no, you are up early, right? 1103699151 M * rs still up 1103699175 M * rs I'm still in vacation so my sleep schedule is worth than usual :o) 1103699209 M * Bertl I would like to do some tests with the networking stuff on the quad, is there any chance to get a few (about 3) additional ips? 1103699246 M * rs public ? 1103699279 M * rs should be possible 1103699312 M * Bertl not necessarily public ... 1103699344 M * rs so why don't you setup some private ones ? 1103699346 M * Bertl I just need to run a script on a different host (i.e. controller or vserver) to send packets to it (on 4 different ips) 1103699368 M * rs ok 1103699386 M * Bertl I guess private networks won't be routed, would they? maybe we could setup something to route 'special' private networks? 1103699390 M * rs so you needs routed ips 1103699410 M * Bertl or the local crossover we talked about some time ago ... 1103699420 M * rs yeah 1103699490 M * Bertl whatever is easier to do ... 1103699513 M * Bertl it's basically test packets over tcp and udp, not really high load ... 1103700095 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1103700104 M * Bertl wb mugwump! 1103700172 J * are|afk ~are@mail.foehl.de 1103701751 Q * Webmazter Quit: « Ë×Çü®§îöñ » Info~[v9.5]~ Released~[October 27, 2003]~ 1103701905 M * Bertl okay, moving out .. back later ... 1103701912 N * Bertl Bertl_oO 1103702499 M * are|afk hmm, box up again. this time /proc/net belongs to xid 106 (yesterday it had been xid 104) 1103704978 M * are|afk and up once again, disabled '/proc security', still /proc/net belongs to xid 106 (the number seems to be a random server) 1103705892 M * mugwump sounds rather unfortunate. Do you need xid tagging? 1103705998 M * are|afk hmm, it had been enabled so I didn't disable it 1103706028 M * are|afk my filesystems are seperated, so to my understanding i don't need xid tagging for normal filesystems 1103706145 M * are|afk atm it is CONFIG_INOXID_UGID24=y 1103706154 M * are|afk will disable that and check what happens. 1103706229 M * mugwump That might not be it. 1103706244 M * mugwump what do you see with: grep XID .config 1103706247 M * mugwump (in your kernel source) 1103706260 M * are|afk well, I am definitly out of options, so i wil take about any advice i can get :-) 1103706262 M * are|afk k 1103706276 M * mugwump are any of them on except that one you mentioned? 1103706324 M * are|afk no, not even there commented out. all XID stuff is in vserver section 1103706348 M * mugwump are you looking at the xid with: lsxid -d /proc/net? 1103706420 M * are|afk yesterday this failed, now that i disabled /proc security: 1103706434 M * are|afk # lsxid -d /proc/net 1103706434 M * are|afk !!ERR!! /proc/net 1103706450 M * are|afk but from logs: vxW: xid=0 did lookup hidden 00000101fc438058[#106,4026531861] »/proc/net«. 1103706477 M * mugwump xid=0 in this case just means context 0 (ie, a process not inside a vserver) 1103706494 M * mugwump have you run vprocunhide? 1103706504 M * are|afk sorry, currently stopped vservers, so the output is useless, can actueally view /proc/net 1103706648 M * are|afk started it again: 1103706652 M * are|afk # ls /proc/net 1103706652 M * are|afk ls: /proc/net: No such file or directory 1103706660 M * are|afk # lsxid -d /proc/net 1103706660 M * are|afk lstat(): No such file or directory 1103706671 M * mugwump is that inside the vserver? 1103706680 M * are|afk no, main server 1103706685 M * are|afk vxW: xid=0 did lookup hidden 00000100f85ef298[#101,4026531861] »/proc/net«. 1103706685 M * are|afk vxW: xid=0 did lookup hidden 00000100f85ef298[#101,4026531861] »/proc/net«. 1103706694 M * are|afk if i now enter ctx 101: 1103706705 M * mugwump have you run vprocunhide? (/etc/init.d/vprocunhide start) 1103706758 M * are|afk samba:/# ls /proc/net/ 1103706760 M * are|afk anycast6 dev if_inet6 ip6_flowlabel ipv6_route netlink raw rt6_stats snmp sockstat6 tcp udp6 1103706764 M * are|afk yes, ran vprocunhide 1103706831 M * are|afk lsxid utility is not avaliable in that context, if you want to, I cam get it there ofc, but basically all is visible in ctx 101 like suggested in dmesg, so I tend and belive it is actually 101 ;) 1103706843 Q * grecea Remote host closed the connection 1103706960 M * mugwump you are entering the context with vserver samba enter? 1103706965 M * mugwump If so, try this: 1103706970 M * mugwump chcontext --ctx 101 /bin/bash 1103706990 M * mugwump then look at /proc/net 1103707003 M * mugwump (ie, the main server's /proc, but from security context 101) 1103707027 M * mugwump also, compare that with /vservers/samba/proc/net from context 0 and within that shell. 1103707044 M * mugwump That will tell us whether it is a context thing or a VFS thing. 1103707075 M * are|afk works 1103707083 N * are|afk _are_ 1103707099 M * _are_ and it has always been visible from context 1 1103707117 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103707121 M * mugwump are you using namespaces? (would be set in /etc/vservers/samba/flags) 1103707154 M * _are_ only flag is 'lock' 1103707174 M * mugwump ok. so, from context 0, you can't see /proc/net or /vservers/samba/proc/net 1103707181 M * mugwump but after chcontext --ctx 101 you can see both 1103707204 M * mugwump --ctx 1 can see both, but any other context can't see anything. all correct so far? 1103707236 M * _are_ # ls /proc/net /vservers/samba/proc/net 1103707238 M * _are_ ls: /proc/net: No such file or directory 1103707238 M * _are_ ls: /vservers/samba/proc/net: No such file or directory 1103707244 M * _are_ # chcontext --xid 101 ls -d /proc/net /vservers/samba/proc/net 1103707245 M * _are_ ls: /vservers/samba/proc/net: No such file or directory 1103707245 M * _are_ /proc/net 1103707273 M * mugwump (the vserver is not running, correct?) 1103707274 M * _are_ hmm, I use xid, I just see, you suggested ctx 1103707279 M * _are_ it is running 1103707416 M * _are_ stopped it now, no difference it seems. /vservers/samba/proc/ is not mounted 1103707556 M * mugwump what exact patchlevel are you running? this is confusing me and I need to read the source to see what's going on 1103707581 M * _are_ Linux master1a 2.6.10-rc3-vs1.9.3.11.1 #1 SMP Wed Dec 22 09:23:33 CET 2004 x86_64 GNU/Linux 1103707600 M * _are_ special here: dual opteron -> 64bit system 1103707712 M * mugwump We've got some of those at work and the SysAdmin wants to put vserver on them. So, I might be able to test it then. 1103707734 M * _are_ well, it looked more stable till yesterday, same patchlevel 1103707747 M * mugwump what changed? just a reboot? 1103707748 M * _are_ changes till then: old config -> new config 1103707772 M * _are_ and before it had been /proc/net working and at some time dissapearing, now it is gone as soon as vservers are up 1103707784 M * _are_ so basically it is more consistent now 1103707790 M * mugwump heh 1103707808 M * mugwump I hope this isn't causing you serious downtime :) 1103707814 M * _are_ well, at leas now I can test stuff and don't have to wait random times within about 2h 1103707827 M * _are_ not yet, but the system should be production tomorrow :-> 1103707862 M * mugwump Try setting CONFIG_INOXID_NONE then 1103707873 M * _are_ already done, no improovement 1103707907 M * _are_ hmm, actually not booted since :-) 1103707959 M * mugwump 8-C 1103708055 M * mugwump I can only see 1.9.3.11 on Herbert's experimental site 1103708085 M * _are_ ah, .1 is my internal version 1103708090 M * _are_ sorry 1103708105 M * mugwump right, so no actual code changes 1103708115 M * _are_ no code changes, yes 1103708192 M * _are_ no change 1103708226 M * mugwump ok. so, you are definitely running a kernel that is CONFIG_INOXID_NONE=y (that you have compiled and booted into ;-)) ? 1103708241 N * Bertl_oO Bertl 1103708260 M * Bertl morning folks! 1103708262 M * _are_ yes 1103708265 M * _are_ hi Bertl 1103708272 M * mugwump evening! 1103708274 M * _are_ # ls /proc/net 1103708274 M * _are_ ls: /proc/net: No such file or directory 1103708290 M * Bertl don't worry, we'll fix that ;) 1103708294 M * _are_ this time ctx 104 is the winner: vxW: xid=0 did lookup hidden 00000100fbe72958[#104,4026531861] »/proc/net«. 1103708314 M * Bertl yes, expected something like that 1103708327 M * _are_ ctx 106 last boot 1103708348 M * Bertl give me a few minutes to get some caffeine ... 1103708353 M * mugwump This is presumably some garbage being left in an uninitialised spot... 1103708363 M * _are_ and check mailing list, posted a dmesg-snippet from shutting down vservers and ctx changes on /proc/meminfo :-> 1103708378 M * Bertl mugwump: no, it's most likely the first context looking up the inode ... 1103708414 M * _are_ Bertl: shutting down vservers i can access /proc/net, starting them again it is gone 1103708443 M * Bertl as I said, we'll fix it ;) 1103708444 J * jsambrook ~jsambrook@aelfric.plus.com 1103708454 A * Bertl is getting some caffeine ... 1103708532 M * _are_ # ls -d /proc/net ; /etc/init.d/vservers-default stop; ls -d /proc/net; /etc/init.d/vservers-default start; ls -d /proc/net 1103708532 M * _are_ ls: /proc/net: No such file or directory 1103708532 M * _are_ Stopping vservers of type 'default'.... 1103708532 M * _are_ /proc/net 1103708534 M * _are_ Starting vservers of type 'default'.... 1103708534 M * _are_ ls: /proc/net: No such file or directory 1103709018 J * ntrs__ ntrs@Dardeene-68.188.50.87.charter-stl.com 1103709018 Q * ntrs_ Read error: Connection reset by peer 1103709362 M * Bertl _are_: you have the kernel source ready? and your favorite editor? 1103709418 M * _are_ yes, both 1103709441 M * Bertl okay, let's change line 383 in fs/proc/generic.c 1103709449 M * Bertl - inode->i_xid = vx_current_xid(); 1103709464 M * Bertl + inode->i_xid = 0; 1103709574 M * _are_ done and compiled 1103709600 M * Bertl excellent ... let's see how that works out ... 1103709784 M * _are_ can see /proc/net at least 1103709792 M * Bertl ;) 1103709870 M * _are_ and the /proc/meminfo weirdo stuff is gone, too 1103709912 M * Bertl well, I said: we'll fix it ;) 1103709915 M * _are_ .-) 1103709923 M * _are_ only remainder: 1103709925 M * _are_ vxW: xid=103 did lookup hidden 00000100fbe74958[#0,4026531875] »/proc/bus«. 1103709930 M * Bertl which is fine 1103709937 M * _are_ and this looks ok to me 1103709943 M * Bertl because your xid=103 is messing with it ;) 1103709946 M * _are_ yes 1103709958 M * _are_ need to check what it tries and mess and if it breaks something 1103709976 M * Bertl funny that you are the only one reporting this issue, because it's not limited to x86_64 at all 1103710002 M * _are_ well, probably I am the only one to use ifconfig now and then. 1103710014 M * Bertl possible ... 1103710018 M * _are_ and it mainly got to notice as we had samba broadcast troubles to debug 1103710032 M * _are_ who checks ifconfig if all network works fine? 1103710038 M * Bertl right ... 1103710050 M * Bertl anyway, thanks for reporting ;) 1103710081 M * _are_ thanks for the help :-) 1103710087 M * Bertl you're welcome! 1103710101 M * Bertl btw, I'm very interested in any feedback for x86_64 1103710113 M * Bertl after all it's the 'upcoming' server arch 1103710132 M * mugwump other than smarmy "ok, I just compiled that in less than 2m" comments? 1103710139 M * mugwump :) 1103710143 M * Bertl so feel free to report the slightest anomaly ... 1103710176 J * Val ~val@gj403.loria.fr 1103710179 M * _are_ mugwump: well, I only recompiled the changed files, no make clean 1103710180 M * Val Hi 1103710188 M * Bertl _are_: it would also be nice to have a profiling run for x86_64 if you get some time for a little testing ... 1103710191 M * _are_ a full compile is still 12m30s here 1103710196 M * Bertl hey Val! 1103710201 M * Val Bertl : hey :) 1103710235 M * _are_ so kernel profiling? I just disabled that as the box froze yesterday minutes after I went out of reach of it, so took all 'experimental' stuff I don't use every day out 1103710264 M * Bertl yeah, that's fine ... just when you get around ... 1103710287 M * Bertl requires userspace 'readprofile' tool, and then you can read/reset the profile ... 1103710300 M * _are_ well, will just include it again. 1103710317 M * Bertl the profiling support itself should be fine for normal operation ... 1103710318 M * _are_ about march i get the official main server, so can do further testing then 1103710336 M * Bertl if you don't specify profile=X it's basically not detectable 1103710352 M * _are_ ok, then I decide not to be scared ;) 1103710353 M * Bertl also good things to enable by default is the spinlock checking 1103710364 M * Bertl (and the magic sysreq) 1103710387 M * _are_ magic sysreq is always enabled since i administrated a sun (Sun-A is siilar) 1103710413 M * Bertl yep 1103710463 M * _are_ Oprofile System profiling or only Profiling support? 1103710472 M * Bertl just profiling ... 1103710517 M * _are_ oh, and btw, I really like the new config way better than the old. tok me a while to find the correct documentation, but it ois much easier to handle 1103710545 M * Bertl guess that is why enrico decided to do it this way ... 1103710605 M * Bertl _are_: could you use the new xid tool on the /dev/pts entries? 1103710657 M * _are_ # /usr/local/src/vxid-0.02/vxid /dev/pts 1103710657 M * _are_ xid=-1073743848, flags=0x01000000, mask=0x00070000, /dev/pts 1103710678 M * _are_ # /usr/local/src/vxid-0.02/vxid /dev/pts/* 1103710678 M * _are_ xid=-1073743896, flags=0x01000000, mask=0x00060000, /dev/pts/0 1103710678 M * _are_ xid=393216, flags=0x01000000, mask=0x00060000, /dev/pts/1 1103710678 M * _are_ xid=393216, flags=0x01000000, mask=0x00060000, /dev/pts/2 1103710691 M * Bertl okay, thanks! 1103710702 M * _are_ i have no context 393216, afaik 1103710716 M * Bertl yeah, the values depend on the mask 1103710758 M * Bertl if the mask doesn't say anything about the xid, the xid value is undefined 1103710788 M * Bertl I'll assign default values to them to avoid confusion 1103711066 M * _are_ :-) 1103711507 J * Zoiah Zoiah@matryoshka.zoiah.net 1103711514 M * Bertl welcome Zoiah! 1103711547 M * Zoiah Hi Bertl. :) 1103712417 M * _are_ lunch. 1103712438 M * Bertl good idea! 1103712448 N * Bertl Bertl_oO 1103715411 N * Bertl_oO Bertl 1103716087 Q * t Ping timeout: 480 seconds 1103717562 J * mboman ~michael@cm48.sigma230.maxonline.com.sg 1103717751 M * Bertl welcome mboman! 1103717766 M * _are_ ok, back to easy problems: how to 'bind' mount stuff via /etc/vservers/*/fstab if it is outside the normal vserver root directory? I had the impression it was possible, but the samples there, e.g. /proc are relative to / of ... 1103717766 M * _are_ the vserver. or do I eed to use main servers /etc/fstab? 1103717771 M * mboman Hi Bertl 1103717806 M * mboman Bertl: just curious, is your greeting scripted? You always greet me as soon as I get into the channel ;) 1103717815 M * Bertl nope it is not 1103717839 M * mboman oh, so you really do like me then? ;) 1103717840 M * Bertl and it isn't as soon ... 1103717846 M * Bertl 13:12 -!- mboman [~michael@cm48.sigma230.maxonline.com.sg] has joined #vserver 1103717846 M * Bertl 13:15 < Bertl> welcome mboman! 1103717878 A * Bertl is just a friendly person ... 1103717892 M * mboman :) 1103717903 M * mboman damn I like this VMWare GSX server ;) 1103717934 M * Bertl yes? does it provide gdb stubs? serial console? 1103717961 M * _are_ mboman: I'd ike it if it supported my systems / solved my problems. unfortunately it fails both. 1103717962 M * mboman nope, but it runs windows ;) 1103717973 M * Bertl that does QEMU too ;) 1103718124 Q * Hollow Quit: Leaving 1103718151 M * Bertl _are_: hmm ... basically you could do the mount right after the namespace was created but before the chroot happens ... 1103718164 M * mboman well, i don't mean that the FOSS solutions are bad 1103718247 M * Bertl and I didn't imply that you meant something like that ;) 1103718352 M * _are_ Bertl: /etc/vservers/*/fstab.local or /etc/vservers/*/fstab i expected to be for that purpose, but seems I am wrong -> will just use /etc/fstab 1103719353 M * Bertl hmm, you should try with --debug and look what is executed .. 1103719561 J * t ~tnichols@CPE-139-168-208-77.sa.bigpond.net.au 1103719661 M * Bertl welcome t! 1103721420 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3, ng8.7 1103721420 T * Bertl - 1103722435 Q * gotcha Ping timeout: 480 seconds 1103723325 M * meebey hi all 1103723333 M * Bertl hey meebey! 1103723336 M * meebey hey Bertl 1103723340 M * meebey how are you doing? 1103723354 M * Bertl fine thanks, and you? 1103723364 M * meebey also fine 1103723369 M * meebey working on more vservers ;) 1103723389 M * meebey and got a question, does someone know if snmpd runs inside a vserver? 1103723408 M * meebey basicly it only serves host information (at least I only need host information) 1103723454 M * Bertl well, it works in and outside a vserver, but you won't get network stats for example ... 1103723473 M * meebey oh that would be my next question 1103723484 M * meebey can the snmp offer net stats inside the vserver 1103723508 M * meebey or do I need extra permissions to get that working 1103723520 M * meebey I have no idea how snmpd knows the network stats 1103723526 M * Bertl the thing is, you don't have per vserver network stats ... 1103723530 M * meebey but if ifconfig can see them, snmpd maybe too 1103723537 M * meebey oh thats no problem 1103723542 M * meebey I need the host network stats only 1103723548 M * Bertl the snmpd will work fine, it's userspace only 1103723553 M * meebey allright 1103723560 M * meebey even with virtual network interfaces? 1103723567 M * meebey only one counter= 1103723576 M * Bertl ngnet will have separate counters ... 1103723594 M * meebey hm true, ifconfig shows only one counter per physical nic 1103723600 M * meebey thats allright though for me 1103723613 M * meebey I wanna fetch CPU and network usage stats, thats all 1103723647 M * Bertl hmm, cpu is partially virtualized ... 1103723659 M * meebey hm is it? :) 1103723672 M * Bertl well, with 2.6/1.9.x at least ;) 1103723674 M * meebey probably he uses vmstat things 1103723684 M * meebey its 2.4 vs1.29 so.. 1103723693 M * meebey I dont want per vserver stats anyhow 1103723699 M * Bertl okay, no cpu virtualization there ... 1103723735 M * meebey allright 1103723739 M * meebey *installing snmpd* 1103723965 M * _are_ hmm, while copying data to the main machine with vservers running, 2.6.10rc3+vs1.9.3.11 locked up twice now. no idea why. 1103724001 M * _are_ anyone has a reference for what runs somewhat stable? 2.6.9+vs1.9.3? (has to be 2.6 for amd64) 1103724023 M * Loki|muh yes 1103724048 M * Loki|muh 2.6.9-vs1.9.3-rc5 <-- rockstable here :) 1103724057 M * Loki|muh on amd64 1103724062 M * _are_ smp? 1103724089 M * Loki|muh no 1103724129 M * Bertl _are_: locked up means not even magic-sysrq did work? 1103724139 M * _are_ yes 1103724155 M * _are_ nothing worked, even VGA signal was broken, cpu-switch complained 1103724173 M * Bertl hmm, sounds lake flakey power supply ... 1103724182 M * Bertl s/lake/like/ 1103724189 M * _are_ it is a dual power supply, so would have to be 2 broken ones 1103724222 M * Bertl could you upload your current kernel config please? 1103724264 M * Bertl did you do any hw testing yet? (like memtest or ekrnel compiling?) 1103724277 M * _are_ yes 1103724283 M * _are_ no errors 1103724364 M * _are_ http://vgn.lihas.de/config-2.6.10-rc3-vs1.9.3.11.2 1103724376 M * _are_ the .2 is an internal compile revision, no changes 1103724454 Q * Val Quit: My damn controlling terminal disappeared! 1103724567 J * infowolfe ~infowolfe@mail.xhcl.net 1103724587 P * infowolfe 1103724597 J * infowolfe ~infowolfe@mail.xhcl.net 1103724611 P * infowolfe 1103724633 J * infowolfe ~infowolfe@mail.xhcl.net 1103724636 M * Bertl _are_: you ahve a lot of strange networking stuff compiled in ... 1103724639 M * infowolfe sorry about the join/parts 1103724685 M * Bertl _are_: do you use the gb ethernet? 1103724892 M * Bertl _are_: usually you can leave CONFIG_VSERVER_HARDCPU_IDLE=y 1103724897 M * Bertl disabled 1103724942 M * _are_ I have 3 GB nics, yes 1103724955 M * _are_ 1 Fiber, 2 ethernet 1103724980 M * _are_ 2*tg3, 1*intel 1103725113 M * _are_ the hard cpu limit i enabled as some java stuff I don't trust is supposed to run on 1 of the vserver instances 1103725154 M * Bertl hard cpu is fine, HARDCPU_IDLE is not required 1103725162 M * _are_ does communication with maximum isdn speed and for this it requires 1GB minimum ram and launches 350 processes. :-> 1103725167 M * _are_ ah, ok 1103725172 M * Bertl I'd disable the netconsole unconditionally 1103725190 M * Bertl (the NAPI is broken even on x86, not to mention x86_64) 1103725213 M * _are_ have an ipmi management adaptor in the box, but the drivers are alpha, only, so not enabled, either 1103725229 M * Bertl (syscall) auditing can go 1103725260 M * Bertl remove the network stuff you don't actually use like ATM 1103725281 M * Bertl but also the bridge code if you do not need it 1103725310 M * Bertl same for ipv6 (doesn't work with linux-vserver anyway) 1103725335 M * Bertl you should also check every driver twice, if it reports _any_ warning on compile 1103725361 M * Bertl do you know what IPVS does? 1103725397 M * Bertl do you have an MPT fusion device? or some of the other SCSI controllers? 1103725478 M * _are_ 2*Adaptec, 1*LSI Raid 1103725494 M * Bertl okay, get rid of the rest ... 1103725545 M * _are_ already done. 1103725554 M * _are_ IPVS? IP Virtual Server? gone already 1103725562 M * Bertl ok ;) 1103725664 M * _are_ fsck, it froze while configuring the kernel :-/ 1103725766 M * _are_ getting an extra keyboard there, just in case it is the cpu switch. box never froze for a whole week till i brought it here. 1103725804 M * Bertl could be .. I'm still opting for a power fluctuation 1103725815 M * Bertl (not necessarily the powersupply of course) 1103725866 M * _are_ doubt that. at the place I am atm there are usually big machines running. and at the moment all go for an xmas party -> machines are turned off 1103727201 Q * serving Ping timeout: 480 seconds 1103727330 M * _are_ hmm, i just notice it crashed when it copied a ton of small files (cyrus imap server mail), are any ReiserFS extended attributes needed for vserver? 1103727349 M * Bertl hmm, you are using reiserfs? 1103727374 M * _are_ yes, so far got me the least trouble out of ext3, reiser, jfs and xfs 1103727386 M * _are_ and ext2 is no option for 2TB disk :-> 1103727394 M * no_maam xfs is usually great 1103727399 M * Bertl hum, hum .. well, not sure reiser is 64 bit clean ;) 1103727414 M * Bertl but that will cause other issues ;) 1103727414 M * no_maam at least it was on alpha and zseries 1103727433 M * _are_ xfs can be resized online? 1103727438 M * no_maam only extendet 1103727441 M * _are_ ext3 can't (else i would use that) 1103727454 M * _are_ extend is normally what I need 1103727468 M * _are_ shrink had not been poossible with lots of other unices, either 1103727501 M * Bertl okay, don't change too much at once ... remove the netpoll and unused networking stuff for now ... 1103727516 M * Bertl (as well as unused drivers in general) 1103727544 M * Bertl if you _think_ that the fs is to blame, try with an fs benchmark ... 1103727563 M * _are_ i tried fs benchmark, but nothing simulates real life :-> 1103727591 M * _are_ drivers/net/eepro100.c:2297: warning: passing arg 2 of `__writeb' makes pointer from integer without a cast 1103727595 M * _are_ i love this 1103727610 M * Bertl yep, not yet converted ... 1103727650 M * Bertl it might also be worth trying the latest bk snapshot 1103727698 M * _are_ ld: BFD 2.15 assertion fail ../../bfd/linker.c:619 1103727703 M * _are_ broken linkers? 1103727721 M * Bertl what gcc/binutils do you use? 1103727744 M * _are_ gcc version 3.3.5 (Debian 1:3.3.5-4) 1103727754 M * _are_ GNU ld version 2.15 1103727787 M * Bertl 2.15.90.0.3 here ... 1103727805 M * _are_ ld -v? 1103727815 M * Bertl # ld -v 1103727815 M * Bertl GNU ld version 2.15.90.0.3 20040415 1103727897 M * _are_ binutils 2.15-5 is max i see as info here 1103727950 M * Bertl well, what shall I say ;) 1103728934 M * Bertl okay, leaving now ... back later this evening ... 1103728943 N * Bertl Bertl_oO 1103729171 Q * mboman Quit: One day I'll get that peer and reset HIS connection! 1103731869 J * Thorsten ~Thorsten@dsl-084-057-009-215.arcor-ip.net 1103732652 Q * sebd Ping timeout: 480 seconds 1103733925 J * serving ~serving@213.186.189.208 1103737087 M * _are_ any hint on which capability is needed for shcp servers? 'Open a socket for LPF: Operation not permitted' is the error message? NET_RAW, NET_ADMIN, NET_BROADCAST or NET_BIND_SERVICE is what I would consider. 1103737206 M * _are_ NET_RAW is the answer :-) 1103737234 M * eyck what is shcp? 1103737276 M * _are_ dhcp with a typo. :-) 1103738799 M * eyck cool, uber-dhcp. 1103739550 Q * jsambrook Ping timeout: 480 seconds 1103739944 J * jsambrook ~jsambrook@aelfric.plus.com 1103740157 M * _are_ on my way home now, cu later 1103740159 Q * _are_ Quit: Disconnecting 1103740995 M * nox * 1103743423 Q * Thorsten Quit: Leaving 1103745261 J * sebd ~sebd@lesdeveloppementsdurables.org 1103745262 Q * sannes Read error: Connection reset by peer 1103750044 Q * t Ping timeout: 480 seconds 1103750066 J * t ~tnichols@CPE-139-168-208-77.sa.bigpond.net.au 1103750649 Q * berni_ Ping timeout: 480 seconds 1103751661 Q * Plug Ping timeout: 480 seconds 1103752253 J * sannes ~ace@home.skarby.no 1103752405 J * Plug ~plug@datadot.net 1103756401 J * ntrs ntrs@Dardeene-68.188.50.87.charter-stl.com 1103756596 Q * jsambrook Ping timeout: 480 seconds 1103756727 Q * ntrs__ Ping timeout: 480 seconds 1103756839 Q * ndim Read error: No route to host 1103757545 J * _are_ ~are@dsl-213-023-038-226.arcor-ip.net 1103757644 M * _are_ hi 1103759739 N * _are_ are|afk