1300669634 Q * LuckyLuke Ping timeout: 480 seconds 1300670178 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it 1300672356 Q * bsingh Ping timeout: 480 seconds 1300674142 Q * hoax Ping timeout: 480 seconds 1300674703 J * hoax U2FsdGVkX1@dhcp-077-249-151-209.chello.nl 1300679748 M * Bertl daniel_hozac: the performance issues you investigated, pointed to time keeping or similar, yes? 1300679786 M * Bertl do you have any specific function which you consider suspicious? 1300683702 J * bsingh ~balbir@122.172.12.73 1300685753 Q * ktwilight__ Read error: Operation timed out 1300687610 J * ktwilight ~keliew@91.176.191.212 1300688736 Q * bsingh Ping timeout: 480 seconds 1300691338 J * bsingh ~balbir@122.172.12.73 1300691676 Q * bsingh Read error: Connection reset by peer 1300691744 M * daniel_hozac Bertl: i saw hangs of several seconds in ktime_get_ts 1300691773 M * daniel_hozac (called from io_schedule, via delay accounting) 1300691821 M * Bertl ah yes, that's where I ended up as well 1300691861 M * Bertl looks to me like the sequencer stuff starts to bounce/oscillate under certain conditions 1300691908 M * Bertl i.e. two threads, trying to get the current time, spinning in a loop to get the 'correct' value 1300691942 M * daniel_hozac yeah 1300691995 M * Bertl the bad new ... I do not see that this would have changed in 2.6.38, although I didn't manage to trigger/observe it there yet 1300692028 M * daniel_hozac yeah, i saw that... i was hoping there would be an obvious fix there. 1300692049 M * daniel_hozac personally, in something as time-critical as time, i don't see the point of using a loop there. 1300692101 M * Bertl I think, a simple spinlock would suffice, although it might cause more contention and sync overhead 1300692117 M * Bertl but OTOH, the sequencer probably has the same overhead 1300692129 M * daniel_hozac the sequencer uses a spinlock for the writes. 1300692269 M * daniel_hozac it seems to me there has to be a better way. 1300692321 M * Bertl yeah, we should probably bring up that issue on lkml and ask specific reasons why this is coded as it is right now ... 1300692347 M * Bertl +grammar :) 1300692351 M * daniel_hozac hehe 1300692366 M * Bertl I'm almost off to bed .. so kind of tired ... 1300692392 M * Wonka sleep well 1300692405 M * Bertl I think the disk/raid setup I tested was a good trigger for older kernels 1300692425 M * Bertl I'll see if I can find a system to prepare for specific test after a pause 1300692433 M * Bertl Wonka: thanks ... 1300692435 Q * SwenTjuln Ping timeout: 480 seconds 1300692445 M * Bertl off to bed now ... have a good one everyone! 1300692449 M * daniel_hozac good night 1300692455 M * Bertl tx 1300692460 N * Bertl Bertl_zZ 1300693380 Q * derjohn_mob Ping timeout: 480 seconds 1300693713 J * petzsch ~markus@p57B63BE7.dip.t-dialin.net 1300694404 Q * petzsch Quit: Leaving. 1300694450 J * SwenTjuln ~SwenTjuln@77.111.2.36 1300694495 M * SwenTjuln it works, error msg is gone. TY 1300694511 M * SwenTjuln daniel_hozac: it works, error msg is gone. TY 1300694536 M * SwenTjuln daniel_hozac: what must I do to create dist from git 1300694537 M * SwenTjuln ? 1300694657 M * SwenTjuln I tried 'make dist' but it creates ver. 0.30.215 :\ 1300694790 M * daniel_hozac yep. as expected. 1300695463 M * SwenTjuln daniel_hozac: how would I create 0.30.216-preXXXX ? 1300695600 J * derjohn_mob ~aj@213.238.45.2 1300695629 M * daniel_hozac change configure.ac 1300695712 M * SwenTjuln oh, i see. Relevant line from mkrelease: "ver=`grep AC_INIT configure.ac | awk '{ print $2 }'`" 1300695803 N * ensc Guest1574 1300695813 J * ensc ~irc-ensc@p5DF2C0ED.dip.t-dialin.net 1300695972 Q * Guest1574 Ping timeout: 480 seconds 1300696607 Q * derjohn_mob Ping timeout: 480 seconds 1300696628 J * derjohn_mob ~aj@213.238.45.2 1300696703 J * petzsch ~markus@p57B63BE7.dip.t-dialin.net 1300697520 J * ghislain ~AQUEOS@adsl2.aqueos.com 1300697944 M * SwenTjuln daniel_hozac: update on err msg. It's still there 1300697957 M * Mr_Smoke mo'in 1300697964 M * SwenTjuln I checked at the wrong server 1300697973 M * SwenTjuln Mr_Smoke: mornin' 1300698050 Q * mikezzz Remote host closed the connection 1300698462 Q * FireEgl Ping timeout: 480 seconds 1300698752 J * bsingh ~balbir@122.172.34.78 1300698998 J * mikezzz mike@no.phear.eu 1300699336 Q * petzsch Quit: Leaving. 1300699462 M * SwenTjuln daniel_hozac: I'm far from C programmer, but is this a valid C statement: 'strcpy(filename + cgroup_len, "/memory.usage_in_bytes");' ? 1300700521 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com 1300700972 M * SwenTjuln obviously syntax is valid 1300701407 J * kir ~kir@swsoft-msk-nat.sw.ru 1300701644 Q * bsingh Ping timeout: 480 seconds 1300701794 M * SwenTjuln daniel_hozac: I've found a bug. 1300701896 M * Mr_Smoke kil it ! 1300701900 M * Mr_Smoke kill* 1300701930 M * SwenTjuln my client keeps escaping startin slash :\ : /etc/vservers/.defaults/cgroup/base is loaded with newline, so filename gets a \n in the middle(after cgroup path) 1300701949 Q * BenG Quit: I Leave 1300701969 M * SwenTjuln sry for soiling the channel 1300702056 M * SwenTjuln so the workaround would be to: echo -n "basepath" > /etc/vservers/.defaults/cgroup/base (note -n switch) 1300702178 J * bsingh ~balbir@122.167.250.133 1300702389 M * SwenTjuln Mr_Smoke: to put you at ease - it's a minor vserver-stat bug. AFAIK no functionality/security is compromised 1300702440 M * Mr_Smoke Good to hear :) 1300702464 M * Mr_Smoke Oh yeah, you wanted to have dev/cgroup// right ? 1300702937 M * SwenTjuln Yes, thats right 1300702943 M * SwenTjuln and I got it. 1300703027 M * SwenTjuln just a few bugs must get discovered/resolved. No biggie 1300703102 J * petzsch ~markus@p57B63BE7.dip.t-dialin.net 1300704203 Q * nkukard Read error: No route to host 1300704317 Q * Piet Ping timeout: 480 seconds 1300704849 J * Piet ~Piet__@04ZAAAI31.tor-irc.dnsbl.oftc.net 1300704885 J * ryker ~ryker@c-76-16-115-27.hsd1.in.comcast.net 1300705195 Q * petzsch Quit: Leaving. 1300705589 N * ensc Guest1589 1300705599 J * ensc ~irc-ensc@p5DF2C0ED.dip.t-dialin.net 1300705757 Q * Guest1589 Ping timeout: 480 seconds 1300708271 Q * bsingh Ping timeout: 480 seconds 1300708546 N * ensc Guest1593 1300708556 J * ensc ~irc-ensc@p5DF2EBCE.dip.t-dialin.net 1300708955 Q * Guest1593 Ping timeout: 480 seconds 1300709950 Q * transacid Server closed connection 1300709971 J * transacid ~transacid@transacid.de 1300710711 J * bsingh ~balbir@122.167.250.133 1300710802 Q * ryker Read error: No route to host 1300710833 J * ryker ~ryker@c-76-16-115-27.hsd1.in.comcast.net 1300711134 N * ensc Guest1598 1300711144 J * ensc ~irc-ensc@p5DF2EBCE.dip.t-dialin.net 1300711304 Q * Guest1598 Ping timeout: 480 seconds 1300712675 J * petzsch ~markus@p57B63BE7.dip.t-dialin.net 1300713233 Q * petzsch Quit: Leaving. 1300713483 Q * hijacker_ Server closed connection 1300713494 J * hijacker_ ~hijacker@213.91.163.5 1300713881 N * _are__ _are_ 1300714210 N * ensc Guest1601 1300714220 J * ensc ~irc-ensc@p5DF2EBCE.dip.t-dialin.net 1300714379 Q * Guest1601 Ping timeout: 480 seconds 1300714683 J * petzsch ~markus@p57B63BE7.dip.t-dialin.net 1300714855 J * tolkor ~rj@tdream.lly.earlham.edu 1300715028 Q * pexapor Read error: Operation timed out 1300716182 Q * petzsch Quit: Leaving. 1300716416 M * daniel_hozac Bertl_zZ: even commenting out the use of the seq lock, the problem persists for me. maybe that's just a red herring, perhaps caused by the cpu_relax. 1300717476 N * Bertl_zZ Bertl 1300717481 M * Bertl morning folks! 1300717602 M * Bertl I don't think the seq lock is to blame .. I think, if at all, then the loop in ktime_get_ts is the problem ... 1300717624 M * daniel_hozac well, the loop is due to the seq lock. 1300717629 M * daniel_hozac so i commented out the entire loop. 1300717646 M * Bertl okay, diff? 1300717655 J * dowdle ~dowdle@scott.coe.montana.edu 1300717787 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/no-seqlock-timekeeping.diff 1300717895 M * Bertl ah, okay ... 1300717949 M * daniel_hozac it's starting to look more and more like a scheduler problem to me. 1300717999 M * Bertl please report your findings upstream if possible, I think we could benefit from 'more eyes' on the issue ... 1300718042 M * daniel_hozac yeah... 1300718049 M * daniel_hozac i'm compiling 2.6.38 now to see if that helps. 1300718084 M * daniel_hozac if it does, i guess i'll do a git bisect and try to find what made it work. 1300718114 M * daniel_hozac if it doesn't, i'm reporting upstream... 1300718237 J * petzsch ~markus@p57B67A96.dip.t-dialin.net 1300718502 M * Bertl http://paste.linux-vserver.org/18894 1300718521 M * Bertl this is how it looks here on 2.6.38-rc3 (what I had to test with :) 1300718555 M * daniel_hozac yeah, that looks a lot like what i get when i commented out the seq lock. 1300718556 M * Bertl and a few hours later, system in the same condition 1300718558 M * Bertl http://paste.linux-vserver.org/18895 1300718598 M * daniel_hozac although i also see hangs in things like poll_freewait, and other things that are just supposed to wait on something. 1300718641 M * SwenTjuln daniel_hozac: have you seen a bugreport above? Is there a 'proper way' to report bugs? 1300718725 M * daniel_hozac yeah, it's already fixed. :) 1300718798 M * daniel_hozac there is the page at nongnu, i'm not sure if the trac instance at linux-vserver is setup to accept bugs as well... 1300718819 M * daniel_hozac mailing list works too 1300718825 M * daniel_hozac IRC is fine 1300718827 A * SwenTjuln is impressed 1300718829 M * SwenTjuln sweet 1300718884 M * Bertl daniel_hozac: the interesting part is, I can watch the disk activity (on that system) not only via iostat, but also directly via attached LEDs, and I see that the disks have a short burst of activity (like a tiny fraction of a second) every second or so ... 1300718920 M * Bertl while the system is 100% idle on one CPU and 100% in I/O wait on the other 1300718932 M * daniel_hozac odd. 1300718941 M * daniel_hozac are you still able to use the system when it occurs? 1300718952 M * Bertl yes, perfectly fine with that kernel 1300718958 M * daniel_hozac okay. 1300718993 M * Bertl and some time later, e.g. after an hour of those tiny bursts, the rsync continues as if nothing ever happened 1300719019 M * daniel_hozac it seems to be a strange bug for sure... 1300720479 Q * Piet Ping timeout: 480 seconds 1300720551 J * FireEgl FireEgl@2001:470:e056:1:9da5:c9c5:b69d:d8d4 1300720638 M * wurtel Hi! We're using vservers in network namespaces to isolate the vlans used in those vservers from the host system. That works pretty well. However, I'm hoping that it's possible to add a second IP to a running vserver (and to be able to remove it as well) 1300720664 M * wurtel My first attempt with something like: vnamespace -e nena --net -- ip a add 10.54.38.129/32 dev lo 1300720683 M * wurtel didn't quite work: it added the address to the vlan holder vserver 1300720713 M * uranus wurtel, http://www.linux-vserver.org/Frequently_Asked_Questions#How_do_I_assign_a_new_IP_address_to_a_running_guest.3F 1300720768 M * wurtel ah, I hadn't discovered naddress yet :) 1300720803 M * wurtel oh wait.... this requires first adding the IP to the host. That's what we don't have now 1300720851 M * wurtel currently the vserver has IP 10.54.38.34, the host has 10.54.112.28: 1300720857 M * wurtel # ip ro get 10.54.38.34 1300720857 M * wurtel 10.54.38.34 via 10.54.112.1 dev vlan2940 src 10.54.112.28 1300720869 M * wurtel the vserver is attached to vlan3007 1300721079 M * Bertl does the guest have a network context or just a network namespace? 1300721096 Q * bsingh Ping timeout: 480 seconds 1300721155 M * wurtel network context I believe (ard set it up but is now unavailable :-( ) 1300721164 M * daniel_hozac so network namespace. 1300721197 M * wurtel root@nana:/etc/vservers/nena# cat spaces/net 1300721198 M * wurtel v3007 1300721220 J * ViRUS ~mp@p579B5CDC.dip.t-dialin.net 1300721233 J * Piet ~Piet__@04ZAAAJC4.tor-irc.dnsbl.oftc.net 1300721252 M * uranus what does a network namespace actually do? I didn't find any documentation about that 1300721266 M * daniel_hozac creates another network stack. 1300721288 M * uranus so each guest gets a real own networkstack? 1300721304 M * Bertl yep, and every packet traverses two stacks 1300721311 M * wurtel each namespace does (if I understand correctly) 1300721313 M * uranus how is lo handeld inside a network namespace? 1300721316 M * Bertl (and a bridge as well :) 1300721363 M * uranus so if i want to use network namespaces, i have to create a bridge on host? 1300721396 Q * micah Remote host closed the connection 1300721399 J * micah ~micah@micah.riseup.net 1300721415 M * Bertl yep 1300721435 M * Bertl well, if you want to conenct them that is 1300721462 M * Bertl if you have a separate ethernet card for each guest, you can as well connect them via hardware 1300721484 M * wurtel or vlans, right? like here 1300721506 M * Bertl also needs hardware 1300721520 M * uranus so if i only have one networkcatd i have to use the dummy net driver inside a guest? 1300721535 M * Bertl for what? 1300721557 M * uranus to assign an public ip address for example 1300721578 M * daniel_hozac dummy would definitely not work in a network namespace... 1300721583 M * uranus oh 1300721585 M * Bertl the dummy driver will simply remove all data sent to it, and it will not provide any data as well 1300721590 M * daniel_hozac you can get away with it in a context because of how Linux networking works... 1300721617 M * uranus k 1300721624 M * Bertl if you want a guest with network stack, you either have to route or bridge the 'output' 1300721642 M * daniel_hozac wurtel: you most likely need vspace -e --net -- ip a a ; naddress --nid --add --ip 1300721674 M * Bertl which means, that there is a network context in addition to the network namespace :) 1300721688 M * uranus when using a brigde i add the bridgs name to the dev file within interfaces? 1300721714 M * wurtel daniel_hozac: Yes, that works! thanx 1300721739 M * wurtel (ip a a dev lo is what I used) 1300721872 M * wurtel ah... removing is not so simple: 1300721873 M * wurtel root@nana:~# naddress --nid nena --remove --ip 10.54.38.129/32 1300721873 M * wurtel Removing 10.54.38.129 1300721873 M * wurtel naddress: vc_net_remove(): Invalid argument 1300721883 M * daniel_hozac remove isn't supported. 1300721885 M * daniel_hozac use --set 1300721922 M * Bertl we probably should add single removes ... 1300721963 M * wurtel in what context do I need to use --set? This is now the 'ip a' output inside the vserver: 1300721964 M * wurtel paul@nena:~$ ip a 1300721964 M * wurtel 7: lo: mtu 16436 qdisc noqueue state UNKNOWN 1300721964 M * wurtel link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1300721964 M * wurtel inet 127.0.0.1/8 scope host lo 1300721965 M * wurtel inet 10.54.38.129/32 scope global lo 1300721990 M * wurtel It used to also have: 1300721991 M * wurtel inet 10.54.38.34/32 scope global lo:nena 1300722009 M * wurtel ah! --set and then the original IP 1300722021 M * daniel_hozac --set with whatever IP addresses you want the guest to have. 1300722026 M * daniel_hozac all of them. 1300722039 M * wurtel Ok, cool :) 1300722097 M * Bertl you can probably 'disable' the network context in your case, by setting a single 0.0.0.0 ip 1300722154 M * daniel_hozac IIRC, they want network contexts still. 1300722169 M * wurtel OK, but that's not what I wanted here. The point was to be able to add a service IP to one of two vservers (on different hosts) depending on which one is active or primary 1300722170 M * daniel_hozac several guests share a namespace. 1300722182 M * Bertl ah, I see 1300722206 M * Bertl so this is some kind of testing or so? 1300722231 M * Bertl (or what's the point of having an active/passive setup on the same host?) 1300722271 M * wurtel I was hoping to use this in a production environment :) On different hosts, in different locations (but sharing vlan connectivity) 1300722286 M * wurtel sort of failover thing, heartbeat etc. 1300722311 M * wurtel alternative is using keepalived with ipvs 1300722314 M * Bertl yeah, but in this case, there will be a single network context per guest, or is it more complicated than that? 1300722326 M * wurtel but I don't want automatic failovers 1300722328 M * Bertl network namespace I mean 1300722340 M * wurtel no, that's the situation 1300722351 M * wurtel no -> not more complicated 1300722464 M * wurtel what I want is that e.g. the firewall does a DNAT to the internal service IP, and that IP is available on one of the two vservers. I don't want to change anything on the firewall/whatever to change which of the two vservers is acticve 1300722521 M * wurtel so if one needs maintenance, I bring down the IP address on that vserver, and bring it up on the other. Then I can use its real ("normal") IP to do the maintenance. 1300722549 M * wurtel but I think I can use what I've learned here, I'm off to do some experiments :-) 1300722652 M * Bertl hmm ... just when I thought I would see some real use for network namespaces, there comes an use case which doesn't even remotely require them :) 1300722707 M * wurtel we use the network namespaces to be able to run multiple vservers in different VLANs on one host, so that they're isolated from each other and from the host 1300722723 M * wurtel or was that network contexts :) 1300722768 M * daniel_hozac Bertl: 2.6.38 seems to noticeably improve the situation... 1300722790 M * Bertl wurtel: well, probably a good idea if you want to waste resources, but usually the 'network isolation' done by network contexts is sufficient ... 1300722813 M * Bertl but of course, 'local' traffic will remain local there ... 1300722904 M * wurtel how do I check whether I'm using network namespaces? (sounds like a really dumb question, but someone else configured this thing :-) 1300723218 Q * ViRUS Quit: If there is Artificial Intelligence, then there's bound to be some artificial stupidity. (Thomas Edison) 1300723275 M * Bertl grep Spaces /proc/virtual//status 1300723340 M * wurtel Spaces: 5c020200 00020200 1300723521 M * Bertl #define CLONE_NEWNET 0x40000000 1300723540 M * Bertl so, yes, you are using network namespaces :) 1300723647 M * wurtel OK :-) 1300723763 Q * Romster Server closed connection 1300723796 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1300723990 M * daniel_hozac Bertl: do you have CONFIG_SCHED_AUTOGROUP enabled? 1300724044 M * Bertl nope 1300724630 Q * FireEgl Remote host closed the connection 1300724763 Q * Wonka Server closed connection 1300724764 J * Wonka produziert@chaos.in-kiel.de 1300724847 Q * Hunger Server closed connection 1300724942 J * Hunger ~Hunger@Hunger.hu 1300725412 Q * uranus Server closed connection 1300725423 J * uranus ~oli@62.152.161.117 1300725453 J * FireEgl ~FireEgl@173-25-19-139.client.mchsi.com 1300726203 Q * ncopa Server closed connection 1300726215 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no 1300726687 Q * derjohn_mob Ping timeout: 480 seconds 1300727193 J * bonbons ~bonbons@2001:960:7ab:0:d4f5:d8c6:3397:79c3 1300727389 J * ktwilight_ ~keliew@91.176.194.166 1300727579 Q * ktwilight Read error: Operation timed out 1300728496 Q * kir Quit: Leaving. 1300732291 J * manana ~mayday090@84.17.25.149 1300732484 J * GeoAnnn ~Geo@85.186.183.99 1300732531 Q * manana Read error: Connection reset by peer 1300732542 J * manana ~mayday090@84.17.25.149 1300732621 M * GeoAnnn lolllllllll http://goo.gl/TozIv 1300732638 Q * GeoAnnn autokilled: This host violated network policy. Mail support@oftc.net if you think this in error. (2011-03-21 18:37:18) 1300733087 Q * petzsch Quit: Leaving. 1300733722 M * Bertl nap attack .. bbl 1300733728 N * Bertl Bertl_zZ 1300736023 Q * ncopa Quit: Leaving 1300737988 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com 1300739289 J * pmjdebru1jn ~pascal@overlord.pcode.nl 1300739352 Q * pmjdebruijn Ping timeout: 480 seconds 1300739507 Q * Piet Ping timeout: 480 seconds 1300740111 J * Piet ~Piet__@04ZAAAJO6.tor-irc.dnsbl.oftc.net 1300743035 Q * BenG Quit: I Leave 1300743951 Q * bonbons Quit: Leaving 1300744977 J * derjohn_mob aj@88.128.3.161 1300745230 Q * arekm Ping timeout: 480 seconds 1300745262 Q * manana Remote host closed the connection 1300745441 M * DelTree is it really such a bad idea to have /etc/vservers be a specific partition ? 1300745477 J * arekm arekm@carme.pld-linux.org 1300745490 M * daniel_hozac no, but that's not really enough data to warrant one... 1300745526 Q * fback Remote host closed the connection 1300745530 J * fback fback@red.fback.net 1300745665 M * DelTree daniel_hozac: well... with lvm... I did try... but then /usr/sbin/vserver cries for its mom... 1300745708 M * Marillion daniel_hozac: do have got the util-vserver patches for testing to debian, online available? 1300745771 Q * arekm Read error: Connection reset by peer 1300745825 M * DelTree when /usr/sbin/vserver calls itself via /usr/sbin/vspace, it finds /etc/vservers empty... 1300745846 M * daniel_hozac Marillion: what? 1300745848 M * Marillion daniel_hozac: soory, i see the debian/rules, forgive me ;( 1300745887 M * daniel_hozac DelTree: huh? do you have a --debug run? 1300745907 M * DelTree daniel_hozac: I did some "bash -x"... ^_^ 1300745924 M * DelTree (and some vi /usr/sbin/vserver, too) 1300745941 M * Marillion daniel_hozac: i don't see in the tarball for util-vserver before, but now i've seen the debian directory 1300745957 M * Marillion my mistake 1300745985 M * DelTree I get Can not find a vserver-setup at '/etc/vservers/foo. 1300746012 M * daniel_hozac DelTree: did you paste it? 1300746027 M * DelTree and when I add some ls -l /etc/vservers just before that... I get it empty... like if not mounted... 1300746081 M * DelTree daniel_hozac: I can put it in some pastebin it that helps... 1300746086 M * DelTree if* 1300746112 M * daniel_hozac yes, a --debug run always helps. 1300746143 M * daniel_hozac that is why it is there. 1300746160 M * DelTree where do I put the --debug ? maybe it's more useful than my bash -x hack... 1300746174 M * daniel_hozac vserver --debug start 1300746177 M * daniel_hozac as in vserver --help 1300746198 M * DelTree ok... 1300746331 M * DelTree http://pastebin.com/XcciKAhf 1300746591 N * Bertl_zZ Bertl 1300746597 M * Bertl back now ... 1300746645 M * daniel_hozac did you start that guest before you changed your configs? 1300746695 M * DelTree oh... 1300746701 M * Bertl :) 1300746726 M * DelTree damn... 1300746829 M * DelTree triple-damn... 1300746834 M * Bertl it would be really worth to time stamp config and guest spaces ... if there was a simple way ... would catch/prevent many many issues ... 1300746890 M * DelTree got in by vserver foo exec sh, killed everything... that stopped it... restarted it... and now... it just works... 1300746912 M * DelTree so...... sorry... I've just been too rough... 1300747054 M * DelTree thanks a lot... I never would have understood why next reboot would have got it right... 1300747179 M * daniel_hozac :) 1300747402 Q * fback Ping timeout: 480 seconds 1300747587 J * fback fback@red.fback.net 1300747724 M * Marillion dh_builddeb successfully 1300747909 N * ensc Guest1657 1300747919 J * ensc ~irc-ensc@p5DF2EBCE.dip.t-dialin.net 1300748077 Q * Guest1657 Ping timeout: 480 seconds 1300748181 Q * dowdle Remote host closed the connection 1300749824 J * fback_ fback@red.fback.net 1300749892 Q * fback Read error: Connection reset by peer