1222992327 Q * dowdle Remote host closed the connection 1222992566 Q * chigital Ping timeout: 480 seconds 1222993133 J * chigital ~chigital@tmo-100-2.customers.d1-online.com 1222993324 J * jescheng ~jescheng@proxy-sjc-2.cisco.com 1222993356 M * jescheng i have a question about running chroot inside a guest 1222993370 M * jescheng without SYS_CHROOT, is this allowed by default? 1222993496 M * jescheng I have util-vserver 30.210, kernel 2.6.14.3 and vserver patch 2.0.1 1222993535 M * jescheng I'm able to run chroot even without SYS_CHROOT, just wondering if this is expected behavior 1222994062 J * ard ~ard@shell2.kwaak.net 1222994320 Q * quinq Remote host closed the connection 1222995736 Q * chigital Ping timeout: 480 seconds 1222996736 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se 1222996852 J * doener ~doener@i577BB014.versanet.de 1222996887 Q * androsch Ping timeout: 480 seconds 1222996957 Q * doener_ Ping timeout: 480 seconds 1222997951 J * cryptronic1 ~oli@p4FD2DD61.dip.t-dialin.net 1222998036 Q * mattzerah Ping timeout: 480 seconds 1222998321 Q * cryptronic Ping timeout: 480 seconds 1222998572 J * mattzerah ~matt@pool1-180.dyn.winshop.com.au 1223005052 Q * derjohn_mob Ping timeout: 480 seconds 1223006803 M * daniel_hozac jescheng: yes, CAP_SYS_CHROOT is given by default. 1223010778 Q * nkukard Ping timeout: 480 seconds 1223011232 J * sharkjaw ~gab@149-67-194.231210.adsl.tele2.no 1223011292 P * sharkjaw 1223012488 J * nkukard ~nkukard@196.212.73.74 1223013606 Q * jescheng Remote host closed the connection 1223013616 J * jescheng ~jescheng@proxy-sjc-2.cisco.com 1223015333 Q * duckx Remote host closed the connection 1223015365 J * duckx ~Duck@81.57.39.234 1223015878 N * ag- Guest2916 1223015911 J * pmjdebruijn pascal@jester.pcode.nl 1223016359 N * Bertl_zZ Bertl 1223016366 M * Bertl morning folks! 1223016411 M * Bertl jescheng: no, without SYS_CHROOT you won't be able to do that (but as daniel pointed out, it is given by default) 1223017177 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1223017933 J * yang yang@yang.netrep.oftc.net 1223018405 J * larsivi ~larsivi@85.221.53.194 1223021159 J * derjohn_mob ~aj@e180208019.adsl.alicedsl.de 1223022622 M * Bertl off for now ... bbl 1223022628 N * Bertl Bertl_oO 1223023022 Q * AndrewLee Remote host closed the connection 1223023069 J * AndrewLee ~andrew@flat.iis.sinica.edu.tw 1223025111 Q * puck Ping timeout: 480 seconds 1223025183 J * puck ~puck@leibniz.catalyst.net.nz 1223026928 Q * Guest2916 Ping timeout: 480 seconds 1223027709 N * phedny Guest2949 1223027709 N * Guest2516 phedny 1223028029 Q * Guest2949 Quit: vakantie \o/ 1223028029 J * ag- ~ag@fedaykin.roxor.cx 1223029068 J * quinq ~quinq@quinq.eu.org 1223030611 J * dna ~dna@111-212-dsl.kielnet.net 1223030672 Q * ag- Remote host closed the connection 1223030828 J * ag- ~ag@fedaykin.roxor.cx 1223031333 M * ktwilight_ is dns update dependent on the host machine in some way? 'cuz on all my guests, dns aren't updated for dynamic ip domains. 1223031353 M * ktwilight_ on the host, it's fine though. 1223031380 M * daniel_hozac huh? 1223031585 M * ktwilight_ dig dynamic.ip.com shows old ip in guest, but in host it shows the updated ip. 1223031614 M * fb ktwilight_: probably some cache 1223031622 M * PowerKe do they use the same dns service (/etc/resolv.conf)? 1223031628 M * ktwilight_ PowerKe, yea they do 1223031641 M * ktwilight_ nsswitch.conf has it hosts: file dns, so... 1223031645 M * ktwilight_ am not sure what else to check :/ 1223031706 M * PowerKe are you sure all dns servers are reachable from both host and guest? Maybe use dig to query each dns server and check if they're in sync 1223031714 M * PowerKe dig dynamic.ip.com @nameserver 1223031718 M * ktwilight_ hmmm 1223031720 A * ktwilight_ checks 1223031812 M * ktwilight_ yea they are reachable, but it's not sync 1223031837 M * ktwilight_ strange. 1223031870 M * ktwilight_ *phone* 1223031872 M * PowerKe if the primary is unreachable on host or guest, it could be that that one is always using the secondary 1223032115 J * chigital ~chigital@tmo-097-2.customers.d1-online.com 1223033326 Q * chigital Ping timeout: 480 seconds 1223037441 J * xdr ~xdr@gote2.27.cust.blixtvik.net 1223038101 J * matthew-_ ~ms@arkansas.doc.ic.ac.uk 1223038153 M * matthew-_ so previously, I manually specified a separate loopback interface for each vserver. And they all had different IPs. Variations on a theme of 127.$foo.0.1 1223038175 M * matthew-_ but now, I can't start them up with such an interface 1223038184 M * matthew-_ and they all get 127.0.0.1 1223038188 M * matthew-_ is this a new feature? 1223038228 M * daniel_hozac in 2.3, yes. 1223038252 M * matthew-_ so all of these loopbacks are completely private? 1223038277 M * daniel_hozac yes. 1223038299 M * matthew-_ and I shouldn't specify anything related to them in /etc/vserver/$foo/interfaces/... ? 1223038302 M * daniel_hozac no. 1223038337 M * matthew-_ and where should I have looked on the web to find this? I can't see anything much on linux-vserver.org 1223038422 M * matthew-_ mmm. I guess it is mentioned on http://linux-vserver.org/ChangeLog-2.3 1223038430 M * daniel_hozac and on the feature matrix. 1223038465 M * daniel_hozac also in the kernel's configuration, and subsequently on installation on linux 2.6. 1223038513 M * matthew-_ ahhh, so this is another failing of debian's stock vserver kernels to tell me which versions of the vserver patches they're using 1223038564 M * matthew-_ but anyway, thanks for the clarification, and the feature! 1223038628 Q * derjohn_mob Ping timeout: 480 seconds 1223039112 Q * larsivi Quit: Konversation terminated! 1223039479 Q * Aiken Remote host closed the connection 1223039791 J * yarihm ~yarihm@hg-public-dock-127-dhcp.ethz.ch 1223039943 J * hparker ~hparker@linux.homershut.net 1223040051 M * meebey could it be that the computed load average of a vserver is pretty incorrect? 1223040069 Q * captiancrash Quit: Leaving 1223040080 M * meebey host says 7 while vserver says 0.5 1223040130 M * daniel_hozac and all the running processes are in that guest? 1223040132 M * ktwilight_ PowerKe, i've done dig dynamic.ip.com @ns1.domain.org and it displays the correct info 1223040149 M * ktwilight_ so it means local cache is not sync? 1223040154 M * meebey daniel_hozac: hm there are processes on the host, but they are all idling 1223040182 M * meebey daniel_hozac: 116 processes on the host, 10 in that guest 1223040207 M * daniel_hozac meebey: so of the 10 processes in the guest, 7 are requiring CPU? 1223040208 M * meebey daniel_hozac: is that what makes the compution so different of the same load? 1223040220 M * meebey daniel_hozac: no only one, tar -xzf 1223040229 M * meebey daniel_hozac: well 2, tar + gz 1223040289 M * daniel_hozac so the rest probably comes from the host. 1223040320 M * meebey daniel_hozac: thats what I thought too for a while, but its not the case, the load average went back to 0.1 on the host as soon as the tar process was finished 1223040324 M * meebey daniel_hozac: http://putin.gsd-software.net/munin/GSD/lincoln.gsd-software.net-load-day.png 1223040339 M * meebey daniel_hozac: http://putin.gsd-software.net/munin/GSD/lincoln.gsd-software.net-vserver_loadavg-day.png 1223040350 M * meebey daniel_hozac: the red line is the vserver that had the tar process running 1223040469 M * daniel_hozac meebey: well, that doesn't mean anything. 1223040476 M * daniel_hozac you've got a bunch of kernel threads processing IO. 1223040489 M * daniel_hozac each of which contributing to the host's load average. 1223040495 M * meebey ah ic 1223040499 M * meebey like pdflush and such? 1223040508 M * daniel_hozac among others. 1223040528 M * meebey so thats why the guest doesnt see the "load" of those kernel threads, ic 1223040553 M * meebey I still need to find out why it causes that such load on the host for a example tar -xzf, but thats not vserver related :) 1223040564 M * meebey s/example/simple/ 1223040616 M * daniel_hozac why does it matter? 1223040623 M * yarihm hi everyone 1223040654 M * meebey daniel_hozac: because its an indicator of a bottleneck 1223040686 M * daniel_hozac not really... 1223040706 M * meebey daniel_hozac: quad-core with sata 1tb 32mb cache disk shouldn't be so "sensitive" with the load 1223040717 M * meebey daniel_hozac: well the loadavg is basically how much processes are waiting for IO 1223040731 M * meebey daniel_hozac: so its a I/O bottleneck 1223040734 M * daniel_hozac no, it's how many processes are in the run queue. 1223040755 M * meebey daniel_hozac: http://putin.gsd-software.net/munin/GSD/lincoln.gsd-software.net-vmstat.html 1223040764 M * meebey daniel_hozac: that proves my I/O wait though 1223040769 M * meebey +theory 1223040787 M * yarihm i was here the other day asking why it could be that vserver-stat shows a context but when trying either vserver foo [enter|exec|stop] it says 'vserver not running' ... now vserver-stat does not show the name of the vserver anymore and indeed the file containing the pid in /var/run/vservers is gone ... recreating fixes vserver-stat but vserver foo bar removes the file again. is this a known issue? that's on debian lenny, IMHO only since t 1223040787 M * yarihm he 2.6.26 kernel was introduced 1223040909 M * yarihm i somehow think that the bug is triggered by very long vserver names (22 chars in my case) 1223040949 M * daniel_hozac that's not very long. 1223040959 M * yarihm :) ok then 1223040964 M * daniel_hozac what does vuname -g --xid context show? 1223040976 M * daniel_hozac do you use a lot of symlinks all over the place? 1223040994 M * yarihm no, not particularly I think 1223041006 M * yarihm well, don't know what the customer does within his context though 1223041034 M * daniel_hozac inside doesn't matter, it's just the config that's relevant 1223041044 M * yarihm let me try to reproduce the issue ... i had to restart the context few minutes ago which I did using vkill --xid -s 9. 1223041073 M * yarihm in the config not particularly. actually it's the stock configuration created using vserver create ... -m skeleton 1223041109 M * yarihm ok, can reproduce it 1223041135 M * yarihm lvs002:~# vuname -g --xid 42010 context 1223041135 M * yarihm /etc/vservers/crawler00.cognita.cust/ 1223041149 M * yarihm before I did this: 1223041151 M * yarihm lvs002:~# vserver-stat 1223041151 M * yarihm CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1223041151 M * yarihm 42010 26 2G 634.4M 28m11s92 9m51s98 19m09s56 crawler00.cognita.cu 1223041151 M * yarihm lvs002:~# vserver crawler00.cognita.cust enter 1223041151 M * yarihm 'vserver ... suexec' is supported for running vservers only; aborting... 1223041179 M * yarihm what makes me a bit sceptic is that vserver-stat truncates the name of the context even though the terminal was big enough to show it 1223041189 M * daniel_hozac how did you start it? 1223041202 M * yarihm vserver crawler00.cognita.cust start 1223041211 M * yarihm or initially maybe with the util-vserver init-script 1223041212 M * PowerKe ktwilight_: Yes, could be that the local cache is not in sync. Maybe you should set a lower TTL in the future 1223041226 M * ktwilight_ PowerKe, ttl is set at 60 1223041248 M * yarihm daniel_hozac, should I do a strace to see whether vserver foo enter removes the file under /var/run/vservers? 1223041251 M * ktwilight_ PowerKe, and i've cycled @ns.ip.add on what i have on resolv.conf, all of 'em are sync-ed 1223041256 M * daniel_hozac yarihm: it should. 1223041270 M * daniel_hozac yarihm: your context somewhy gets an extra slash appended at the end. 1223041275 M * PowerKe and you still get resolution errors? 1223041300 M * ktwilight_ 'xactly. 1223041307 M * ktwilight_ weird, no? 1223041316 M * yarihm daniel_hozac, ah ... i see, what i often do is cd /etc/vservers and then use tab completion to do the startup ... the trailing slash doesn't trigger an error, so I always thought it would not be an issue 1223041340 M * yarihm do you think this triggers this behaviour? 1223041359 M * PowerKe ktwilight_: If you don't get a wrong reply anymore with dig, maybe it's caching in your application? 1223041370 M * daniel_hozac yarihm: yes, that'd do it. 1223041394 M * ktwilight_ PowerKe, the dig dynamic.ip.add is still wrong. when it's without @bla, it's incorrect, with @bla, it's fine. 1223041408 M * yarihm daniel_hozac, I see ... is there a way to rename a running context? 1223041450 M * daniel_hozac yarihm: vuname -s --xid -t context=/etc... 1223041496 M * PowerKe ktwilight_: so which query does dig show without @ (3rd line from bottom), must be some other than in resolv.conf? 1223041565 M * PowerKe ktwilight_: Sorry, I meant, which server does it show without @ 1223041612 M * yarihm daniel_hozac, thanks 1223041655 M * ktwilight_ PowerKe, good question 1223041660 M * ktwilight_ i've no idea... 1223041677 M * ktwilight_ i think i messed up somewhere, gimme a sec... 1223041713 M * PowerKe ktwilight_: at the end of the response, you should have a line ;; SERVER: 1.2.3.4#53(1.2.3.4) 1223041745 M * ktwilight_ SERVER: 62.212.64.122#53(62.212.64.122) 1223041764 M * PowerKe Is that different from your resolv.conf? 1223041814 M * ktwilight_ well i have 4 in resolv.conf 1223041820 M * ktwilight_ it's the first one. 1223041856 M * ktwilight_ i've re-run the everything, and all except the last resolve incorrect 1223041862 M * ktwilight_ incorrectly 1223041883 M * PowerKe Ok, so your ip is incorrect in the dns server upstream 1223041896 M * PowerKe What's the TTL you receive in the reply? 1223041898 M * ktwilight_ yup 1223041898 M * ktwilight_ :/ 1223041927 M * ktwilight_ 10800 1223041937 M * ktwilight_ if i'm reading correctly. 1223041959 M * Borg- isnt TTL 8 bit? 1223041979 M * PowerKe Borg-: dns record ttl, might be the wrong term 1223042006 M * Borg- ah :) 1223042025 M * PowerKe ktwilight_: Normally it should be decremented on each query and when it reaches 0, you'll get the new values 1223042034 M * ktwilight_ http://rafb.net/p/1rSrML17.html 1223042042 M * ktwilight_ ...?! 1223042055 M * Borg- not decremented each query but decremented 1223042069 M * PowerKe If you put the ttl to 60 in your primary server now, you'll still have to wait for the old records to expire (so you should lower your ttl in advance, before changing the ip) 1223042164 M * ktwilight_ it's hosted, so i can't change the dns ttl, except for the dynamic domain 1223042189 M * ktwilight_ so the problem, i guess, is the hosting company's dns cache? 1223042218 M * PowerKe ktwilight_: don't try to lookup an IP that way, you need to use a reverse lookup for that (in-addr.arpa domain) 1223042277 M * PowerKe dig -x (won't tell you anything useful regarding the forward lookup of your domain) 1223042316 M * ktwilight_ o 1223042320 M * PowerKe If the domain is published on the primary dns server with a ttl of 10800, you'll have to wait 3 hours for changes to propagate 1223042340 M * ktwilight_ but even after 3hrs, it's not updated :/ 1223042349 M * ktwilight_ but on the host machine, it's already updated, but not on the guests 1223042361 M * PowerKe do you have the same order in resolv.conf? 1223042369 M * PowerKe and no entry in hosts file on the host? 1223042372 M * ktwilight_ on the host machine it's perfectly fine, and the resolv.conf is exactly the same 1223042407 M * PowerKe no entry in /etc/hosts either? 1223042439 M * ktwilight_ there are entries 1223042448 M * ktwilight_ the ip hostname domain.com 1223042461 M * ktwilight_ but the host doesn't have all the guests, i guess that could be a problem? 1223042545 M * PowerKe if you're trying to resolve one of these entries, they'll be resolved using the hosts file instead of dns server 1223042628 M * ktwilight_ guests are fine, i just can't resolve a remote dynamic ip on the guests, but on the host it's fine. 1223042652 M * PowerKe and you also don't have the remote dynamic host in your hosts file? 1223042660 M * ktwilight_ yup don't have it 1223042681 M * ktwilight_ i have to change /etc/hosts everytime the ip changes?! 1223042698 M * PowerKe no, don't put it in there 1223042712 M * ktwilight_ *phew* :) 1223042716 M * PowerKe It would explain why it worked on the host, but not on the guests if you'd done that 1223042739 M * PowerKe But if you're always querying the same dns server, I don't see how the guests can receive a different response from the host 1223042768 M * PowerKe dig remote.ip @62.212.64.122 should always give the same result 1223042789 M * ktwilight_ which always does, yes. but it doesn't without @62.212.64.122 1223042793 M * PowerKe and if 62.212.64.122 is the first entry in the resolv.conf everywhere, it should always use that 1223042795 M * ktwilight_ uh, wait. no. 1223042815 M * ktwilight_ i meant doing dig remote.ip @62.212.64.122 in host and guest give two different results 1223042828 M * ktwilight_ 'xactly, so something is not right... 1223043498 Q * xdr Quit: Lost terminal 1223044064 J * derjohn_mob ~aj@e180208019.adsl.alicedsl.de 1223044094 J * xdr ~xdr@gote2.27.cust.blixtvik.net 1223044103 Q * xdr 1223044294 M * Bertl_oO PowerKe: if it is reachable, yes 1223044348 M * ktwilight_ all of 'em are reachable though. 1223044386 M * Bertl_oO well, if the first nameserver does not answer (because it is not reachable and/or not authorized), then the next one is queries 1223044391 M * Bertl_oO -s+d 1223044554 M * ktwilight_ true. but the problem is this, both host and guests have the exact same /etc/resolv.conf, however, guests doesn't resolve the correct ip of a dynamic ip domain, but host does it correctly 1223044584 M * ktwilight_ and now when i just tried dig dynamic.ip.add @name.server.ip on guest, it doesn't resolve correctly. but just now it was...??? 1223044585 M * daniel_hozac and none of them are running nscd? 1223044595 M * ktwilight_ i wouldn't know, i don't run the ns 1223044612 M * ktwilight_ uh, sorry, misread. no, none of 'em have nscd 1223044641 M * ktwilight_ including the host. 1223044782 M * ktwilight_ hm, someone had the same problem http://osdir.com/ml/linux.vserver/2003-01/msg00184.html but it was resolved by adding hte ip hostname domain in /etc/hosts :/ 1223044987 M * PowerKe Bertl_oO: He's having the same problem using @62.212.64.122, so it shows it's reachable, but it returns a different ip when connecting from a guest, compared to from the host... 1223044997 J * dowdle ~dowdle@scott.coe.montana.edu 1223045067 M * PowerKe Unless setting up something with iptables to reroute requests, I have no clue on how to get that result 1223045161 M * ktwilight_ :/ i think it's a problem on their side, since now on the host, it doesn't resolve to the correct ip too 1223045180 M * ktwilight_ life is so complicated :) 1223045188 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1223045238 M * Bertl_oO nameserver replies are quite often based on the client IP, for several reasons (one being load balancing) 1223045269 M * Bertl_oO I got the impression that the guest was using a _different_ nameserver 1223045293 M * Bertl_oO (i.e. not the one listed first in /etc/resolv.conf) 1223045421 M * PowerKe No, using @62.212.64.122 shows that it's reachable by both and it's listed first in resolv.conf for host and guest 1223045448 M * PowerKe But if he's getting wrong replies from the host as well now, that would make sense (problem upstream) 1223045558 J * hparker ~hparker@linux.homershut.net 1223045932 M * ktwilight_ hm, just fired off an email to the provider. let's see what they can come up with :) 1223045945 M * ktwilight_ could be their dns cache is borked :( 1223047233 J * ktwilight__ ~ktwilight@87.66.195.244 1223047477 Q * ktwilight_ Ping timeout: 480 seconds 1223048918 Q * yarihm Quit: Leaving 1223052064 Q * jescheng Quit: Leaving 1223054357 Q * gnuk Quit: NoFeature 1223054897 Q * nkukard Quit: Leaving 1223055004 J * nkukard ~nkukard@196-209-158-110-ndn-esr-3.dynamic.isadsl.co.za 1223058132 Q * nkukard Read error: Connection timed out 1223058496 J * nkukard ~nkukard@196-209-158-110-ndn-esr-3.dynamic.isadsl.co.za 1223058777 Q * esa Quit: Coyote finally caught me 1223059129 Q * nkukard Quit: Leaving 1223059162 J * nkukard ~nkukard@196.212.73.74 1223059368 J * ntrs ~ntrs@77.29.77.77 1223059660 J * esa bip@62.123.8.69 1223059823 Q * FireEgl Ping timeout: 480 seconds 1223060177 Q * derjohn_mob Ping timeout: 480 seconds 1223060430 J * FireEgl Proteus@4.0.0.0.1.0.0.0.6.5.0.e.0.7.4.0.1.0.0.2.ip6.arpa 1223061060 J * yarihm ~yarihm@77-56-182-18.dclient.hispeed.ch 1223062812 J * derjohn_mob ~aj@p5B23EC78.dip.t-dialin.net 1223062840 J * mrfree ~mrfree@host110-176-dynamic.32-79-r.retail.telecomitalia.it 1223065885 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1223067030 M * Bertl_oO df 1223067030 J * Aiken ~Aiken@ppp118-208-28-181.lns2.bne1.internode.on.net 1223067052 M * Bertl_oO okay, time to go to bed :) ... 1223067064 N * Bertl_oO Bertl_zZ 1223069243 J * keyser_soze ~cimarron@190.189.217.109 1223069390 Q * DLange Read error: Connection reset by peer 1223069507 J * DLange ~DLange@dlange.user.oftc.net 1223070558 Q * bonbons Quit: Leaving 1223070796 Q * dna Ping timeout: 480 seconds 1223071082 Q * FireEgl Quit: Leaving... 1223072974 P * keyser_soze 1223073015 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1223073646 Q * sladen Ping timeout: 480 seconds 1223074342 Q * ntrs Ping timeout: 480 seconds 1223074721 Q * mrfree Quit: Leaving 1223075651 J * sladen paul@starsky.19inch.net 1223076169 Q * dowdle Remote host closed the connection 1223076289 J * Piet ~piet@tor.noreply.org