1304467581 Q * dowdle Remote host closed the connection
1304468878 Q * hparker Quit: Quit
1304478440 Q * Piet Quit: Piet
1304481335 J * Piet ~Piet__@04ZAAA9JU.tor-irc.dnsbl.oftc.net
1304481623 J * ichavero_ ~ichavero@148.229.9.250
1304488579 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1304489828 Q * aj__ Ping timeout: 480 seconds
1304491301 J * aj__ ~aj@213.238.45.2
1304491740 J * ghislain ~AQUEOS@adsl2.aqueos.com
1304492424 J * kir ~kir@swsoft-msk-nat.sw.ru
1304494055 Q * ichavero_ Ping timeout: 480 seconds
1304494107 J * Piet_ ~Piet__@04ZAAA9R3.tor-irc.dnsbl.oftc.net
1304494513 Q * Piet Ping timeout: 480 seconds
1304494647 N * Bertl_zZ Bertl
1304494652 M * Bertl morning folks!
1304494801 M * SwenTjuln mornin'!
1304494909 J * LcKuroro ~cyril@pas38-1-82-67-71-177.fbx.proxad.net
1304495202 M * LcKuroro Hi all, i have some questions about strange kernel log with vserver! Sorry in advance for my very very very bad english :/ ! 
1304495265 M * hijacker morning
1304495295 M * Bertl LcKuroro: no problem, go ahead and ask ...
1304495417 M * LcKuroro I'm on Debian Lenny Host with 2.6.26-2-vserver-amd64 kernel and i have a debian squeeze guest
1304495433 M * Bertl okay, not the best choice of kernel
1304495453 M * LcKuroro at each ssh connection on the guest (with iptables redirect) i have "vxW: [»sshd«,922:#40000|40000|40000] messing with the procfs."
1304495464 M * Bertl i.e. it is known to be quite broken in many regards, so be careful when you upgrade ...
1304495570 M * SwenTjuln LcKuroro: can you put /etc/init/ssh.conf to http://paste.linux-vserver.org/
1304495666 M * SwenTjuln LcKuroro: usually its something like "oom never" which causes init script to try to write to /proc (and failes)
1304495667 M * LcKuroro http://paste.linux-vserver.org/19814
1304495696 M * SwenTjuln that is not the file
1304495706 M * Bertl yes, something you can work around on newer kernels by allowing the write
1304495715 M * LcKuroro yes on lenny ssh server i usually disable an oom option in /etc/default/ssh
1304495735 M * LcKuroro but on squeeze i don't find this option (and it's not the same message)
1304495736 M * SwenTjuln LcKuroro: /etc/default/ssh is obsolete
1304495751 M * SwenTjuln look into  /etc/init/ssh.conf
1304495823 M * LcKuroro http://paste.linux-vserver.org/19815
1304495940 M * Bertl basically the message just means that sshd inside the guest tried to access a procfs entry (usually write access) which isn't available for the guest
1304496013 M * ard oom_adjust usually, to prevent it from being killed first if the system is overloaded ;-)
1304496055 M * LcKuroro ah, yes good thing for ssh (in host server of course)
1304496186 M * LcKuroro i don't find the SSHD_OOM_ADJUST option on squeeze :/
1304496275 M * Bertl you options basically are: 1) ignore it, 2) keep sshd from doing that, and 3) upgrade to a newer kernel which allows for the OOM_ADJUST ccap
1304496279 M * Bertl *your
1304496288 A * ard always chooses 1
1304496298 M * ard for me the host is the OOB for the vserver ;-)
1304496312 M * ard (oob = out of band, emergency access, whatever)
1304496431 M * SwenTjuln LcKuroro: look into /etc/init/ssh.conf
1304496441 M * SwenTjuln LcKuroro: copy&paste it
1304496476 M * SwenTjuln LcKuroro: not /etc/init.d/ssh.conf (without '.d')
1304496478 M * LcKuroro i can ignore it (just have to add a logcheck ignore rules :) ), but on a 2.6.26-2-vserver kernel with lenny host and guest, i find how to disable the oom for ssh
1304496489 M * LcKuroro http://paste.linux-vserver.org/19815
1304496499 M * LcKuroro ah sorry
1304496507 M * SwenTjuln that is init.d entry
1304496524 M * LcKuroro i haven't a /etc/init/ssh
1304496558 M * LcKuroro on debian there is no  /etc/init
1304496735 J * MrTV ~timo@kl-5-060.natpat.fh-kl.de
1304496744 M * MrTV hello everyone
1304496794 M * Bertl hello
1304496796 M * LcKuroro hi
1304496810 N * Piet_ Piet
1304496811 M * daniel_hozac hey
1304496858 M * Bertl ensc: do you have a test guest for the filesystem posix caps?
1304496915 M * daniel_hozac Fedora 15 should be a good test... there are no more suid binaries, just posix caps.
1304496957 M * Bertl okay, so just build via recent util-vserver then?
1304497047 M * MrTV why is debian dropping support for vserver after squeeze? if this is written somewhere, please point me to it. 
1304497088 M * hijacker MrTV, I am not quite certain
1304497123 M * hijacker there is one guy that compiles and prepares those debian images as well
1304497135 M * hijacker i think you can use that mirror, if you like
1304497176 M * Bertl MrTV: I think because they want to favor LXC
1304497205 M * Bertl (despite the fact that LXC is not really complete yet)
1304497231 M * LcKuroro what is the difference with vserver?
1304497237 M * MrTV I know that you can compile and package everything on your own. I just wanted to know the reason ...
1304497285 M * hijacker MrTV, then you'd better ask the debian devs
1304497304 M * Bertl LcKuroro: besides the interface, which is of course different, there are a bunch of features and functionalities not present (yet), mostly isolation features
1304497338 M * SwenTjuln LcKuroro: oh....i thought that you've said you have an upstart issue
1304497341 M * MrTV hijacker, i think some of them are here in this channel
1304497346 M * SwenTjuln my mystake
1304497400 M * MrTV micah is the package maintainer of util-vserver, isn't he? 
1304497408 M * Bertl LcKuroro: basically you lose things like IP isolation, single IP special casing, light weight guests, and some minor virtualization features, but also unification and thus a great part of resource sharing
1304497535 M * LcKuroro Bertl: Thx
1304497654 M * LcKuroro I have others strange log :)
1304497673 M * LcKuroro on a vserver stop: "vxW: [xid #40000] !!! limit: ffff81007a4a6078[VM,9] = -4875 on exit."
1304497682 M * LcKuroro the code change each time of course :/
1304497697 M * LcKuroro ex: "vxW: [xid #40000] !!! limit: ffff81007a4a6078[LOCKS,10] = -2 on exit"
1304497760 M * Bertl yes, that is a debian kernel problem, one of many of course
1304497799 M * Bertl the 2.6.26 kernel was quite a disaster ...
1304497855 M * Bertl http://linux-vserver.org/Installation_on_Debian#Issues_with_Lenny.27s_2.6.26_Kernel_and_Util-vserver
1304497872 M * LcKuroro the squeeze migration is a summer project :) (on 2.6.32)
1304497887 M * LcKuroro but a big bi project :/
1304497911 M * Bertl well, no need to update the host distro, just the kernel and util-vserver and you should be fine
1304497947 M * Bertl (but be careful with the migration steps regarding filesystem)
1304498015 M * LcKuroro yes, we have a test plateforme with production "mirrors", we'll test the migration on it first
1304498578 M * LcKuroro "vxW: [»ps«,28451:#40000|40000|40000] did lookup hidden ffff81007c0da930[#0,2] »/dev/pts«." with a vps :)
1304498790 M * MrTV Bertl, why should he be careful with the filesystem ?
1304498834 M * Bertl because the 2.6.26 debian kernel is broken in this regard, so migration to and from that kernel requires special handling
1304498912 M * daniel_hozac (http://people.linux-vserver.org/~dhozac/t/save-vsdata.sh can help with that)
1304498916 M * MrTV is that described on that web page you have just pasted?
1304498991 M * MrTV i am also in the process of migrating from lenny to squeeze, so it's important for me 
1304499215 M * Bertl yep, should be described there
1304499464 M * MrTV thx
1304499473 M * Bertl np
1304500241 J * ViRUS ~mp@p54867151.dip.t-dialin.net
1304500736 Q * cuba33ci charon.oftc.net synthon.oftc.net
1304500736 Q * FIChTe charon.oftc.net synthon.oftc.net
1304500736 Q * eja charon.oftc.net synthon.oftc.net
1304500736 Q * FloodServ charon.oftc.net synthon.oftc.net
1304500736 Q * jrdnyquist charon.oftc.net synthon.oftc.net
1304500736 Q * monrad-51468 charon.oftc.net synthon.oftc.net
1304500736 Q * DreamerC charon.oftc.net synthon.oftc.net
1304500736 Q * quasisane charon.oftc.net synthon.oftc.net
1304500736 Q * imcsk8 charon.oftc.net synthon.oftc.net
1304500736 Q * ntrs_away charon.oftc.net synthon.oftc.net
1304500736 Q * thal charon.oftc.net synthon.oftc.net
1304500736 Q * LcKuroro charon.oftc.net synthon.oftc.net
1304500736 Q * ser charon.oftc.net synthon.oftc.net
1304500736 Q * tam charon.oftc.net synthon.oftc.net
1304500736 Q * Roomster charon.oftc.net synthon.oftc.net
1304500736 Q * fLoo charon.oftc.net synthon.oftc.net
1304500736 Q * puck charon.oftc.net synthon.oftc.net
1304500736 Q * MrTV charon.oftc.net synthon.oftc.net
1304500736 Q * ghislain charon.oftc.net synthon.oftc.net
1304500736 Q * hel charon.oftc.net synthon.oftc.net
1304500736 Q * _nono_ charon.oftc.net synthon.oftc.net
1304500736 Q * FireEgl charon.oftc.net synthon.oftc.net
1304500736 Q * sigue charon.oftc.net synthon.oftc.net
1304500736 Q * micah charon.oftc.net synthon.oftc.net
1304500736 Q * MooingLemur charon.oftc.net synthon.oftc.net
1304500736 Q * tolkor charon.oftc.net synthon.oftc.net
1304500783 J * MrTV ~timo@kl-5-060.natpat.fh-kl.de
1304500783 J * LcKuroro ~cyril@pas38-1-82-67-71-177.fbx.proxad.net
1304500783 J * ghislain ~AQUEOS@adsl2.aqueos.com
1304500783 J * imcsk8 ~ichavero@148.229.1.11
1304500783 J * FireEgl FireEgl@2001:470:e056:1:b066:d999:e43a:9008
1304500783 J * cuba33ci ~cuba33ci@111-240-171-155.dynamic.hinet.net
1304500783 J * sigue contempt@stole.ur.cc-number.info
1304500783 J * ser ~ser@host1.tldp.ibiblio.org
1304500783 J * micah ~micah@micah.riseup.net
1304500783 J * DreamerC ~DreamerC@122-116-181-118.HINET-IP.hinet.net
1304500783 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1304500783 J * ntrs_away ~ntrs@vault08.rosehosting.com
1304500783 J * puck ~puck@leibniz.catalyst.net.nz
1304500783 J * tam ~tam@says.screwallofyoubitches.com
1304500783 J * quasisane ~sanep@c-76-24-80-97.hsd1.nh.comcast.net
1304500783 J * Roomster ~romster@202.168.100.149.dynamic.rev.eftel.com
1304500783 J * _nono_ ~gomes@licencieux.ircam.fr
1304500783 J * thal ~thalunil@walledcity.de
1304500783 J * FIChTe ~fichte@bashpipe.de
1304500783 J * fLoo ~fLoo@irc.coresec.de
1304500783 J * eja ~user@75.110.195.31
1304500783 J * MooingLemur ~troy@ipv4.pinchaser.com
1304500783 J * monrad-51468 ~mmk@domitian.tdx.dk
1304500783 J * hel ~hel@porthos.lennackers.de
1304500783 J * tolkor ~rj@tdream.lly.earlham.edu
1304501430 P * kir Leaving.
1304507849 J * petzsch ~markus@dslb-088-075-166-221.pools.arcor-ip.net
1304512902 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1304514068 J * FloodServ services@services.oftc.net
1304514584 M * ard MrTV: As a debian "maintainer" myself I would guess that changes of the kernel are going to fast.
1304514595 M * ard I never ever install a debian-kernel. Gives me bugs ;-)
1304514623 M * ard So there is no need to package a vserver supporting debian-kernel.
1304514651 M * ard The only problem is util-vserver, and I am living too much on trunk to install any debian package.
1304514679 M * ard Daniel Hozac has made some nice packaging that is not too debian compliant though... But they work very well
1304514708 M * ard (just needs some patches in the postinst and in the vserver.functions for me...)
1304514728 M * daniel_hozac hmm?
1304514735 M * daniel_hozac submitting patches upstream means you get fixes.
1304514807 M * daniel_hozac and as far as i know the only non-Debian comliant thing is the initscripts, which honestly, seems like a bug in Debian's guidelines.
1304514814 M * ard ;-)
1304514852 M * ard the init scripts, and I would suggest the placing of the directories...
1304514881 M * ard I know that you prefer /vservers but somehow in debian they prefer /var/lib/vservers
1304514935 M * ard I can svn diff my repository (need to fix one more thing) with 2939, would you care to comment on it?
1304514942 M * Bertl I wonder if they have /var/lib/opt and /var/lib/srv as well :)
1304514958 M * daniel_hozac i suppose
1304514964 M * daniel_hozac although you know util-vserver lives in git now, right
1304514971 M * ard ehhh
1304514974 M * ard bah...
1304514979 M * ard what did I miss :-(
1304514988 M * Bertl everything :)
1304515000 M * ard that teaches me to go on vacation...
1304515071 M * ard I will git up and then ask the same question again ;-)
1304515092 M * daniel_hozac you've had vacation for two months?
1304515097 M * daniel_hozac i wish i could do that :)
1304515112 M * Bertl lucky debian maitainers :)
1304515318 M * ard Heheh, the vacation only took 2 weeks.
1304515322 M * ard But the preparation...
1304515326 M * ard Bah :-(
1304515340 M * ard anyway, my biggest problem was with the:
1304515347 M * ard enableInterfaces "$VSERVER_DIR" && have_interfaces=1 in vserver.start
1304515362 M * ard which should be run in the vspace_shared_cmd...
1304515381 M * daniel_hozac in your specific environment :-)
1304515431 M * ard Correct, but it wouldn't hurt in other environments
1304515447 M * ard It's no use to have interfaces in the wrong network namespace ;-0
1304515617 M * daniel_hozac well, it doesn't make much sense to be adding interfaces in a shared namespace.
1304515641 M * ard But it makes sense to add ip addresses in that namespace :-)
1304515680 M * daniel_hozac depends on your use-case.
1304515732 M * ard Well, it has no use to create ip addresses on the network namespace of the host. And that's my only problem.
1304515763 M * Bertl personally I'd prefer that all namespaces had unique identifiers and could be unshared/entered based on them
1304515765 M * ard I just downloaded a tar, will look at the git later...
1304515775 M * daniel_hozac i could see that being useful.
1304515787 M * daniel_hozac Bertl: well, we do!
1304515806 M * ard Bertl : vserver is the only thing that can ;-)...
1304515810 M * daniel_hozac it would be nice if mainline could figure out that that's a useful feature though
1304515825 M * ard I still have a kludge to hand over an interface to another network namespace
1304515827 M * Bertl ah right, we can do that *G* :)
1304515861 M * ard But within that network namespace I have multiple vservers
1304515877 M * ard It really works great
1304515907 M * ard And for each network namespace I have a dummy vserver just holding the interface and routing table
1304515930 M * Bertl and what's the benefit of the additional network stack?
1304515957 M * ard If you have very big servers, you can partition your server on network too
1304515972 M * ard The network is firewalled by a normal firewall
1304515999 M * Bertl don't see the need for a network namespace yet, but please go on
1304516098 M * ard Well, with multiple clients, you have multiple network zones. You want to loadbalance using externel loadbalancers
1304516116 M * ard Finally the seperation makes it all manageable
1304516130 M * ard our firewalls usually have > 100 interfaces
1304516163 A * ard helped Ben Greear to get 802.1Q in mainline
1304516226 M * ard And it was helpful :-). No more cisco's of 100k guilders.
1304516241 M * ard 20k guilders if you wanted to log on with ssh
1304516245 M * Bertl okay, and what part does the network namespace have in that?
1304516281 M * ard The seperation of one or more vservers into their own network domain
1304516319 M * ard Each network domain/namespace has it's own vlan on the server
1304516323 M * Bertl but they could as well live side by side with network isolation, no?
1304516354 M * ard No, you will need iptables... And yes, they can live side by side within that network namespace
1304516376 M * Bertl iptables is fine with network isolation as well
1304516379 M * ard I use network isolation within the network namespace
1304516397 M * ard Bertl : you don't really want to know how many we have...
1304516450 M * ard It would be hell to keep 300 iptables in sync while now we have only 10 firewall clusters
1304516488 M * Bertl that is actually an argument against network namespaces, no?
1304516492 M * ard And firewalling is a different thing, you really need a lot of memory if you are firewalling 0/0 for a public site
1304516511 M * Bertl because what you can do with a single iptables setup, you now do with N separate ones
1304516525 M * ard You have it turned around
1304516552 M * Bertl how so?
1304516565 M * ard I now have 10 firewall clusters to support with "simple" scripting. Would I have done that on the servers, I need to support 300 servers.
1304516595 M * ard And the servers can't do loadbalancing, because you can only do loadbalancing when traffic goes through, not on...
1304516600 M * Bertl so, you have 300 servers, and each of them is running several network namespaces, yes?
1304516607 M * ard yes
1304516620 M * ard well, in the end
1304516632 M * Bertl so how does that change compared to having 300 servers without network namespaces?
1304516633 M * ard migrating servers to big iron
1304516673 M * ard each of the 300 servers need a hell of an iptables and one of the worst routing tables I have ever seen
1304516686 M * ard trust me on that...
1304516711 M * ard Network namespace+ network isolation is the ideal combination
1304516738 M * ard And util-vserver support is 99.99% there :-)
1304516753 M * Bertl don't get me wrong, I'm not against network namespaces, I just don't see the big advantage in your setup (yet)
1304516810 M * ard Heheh, if you go to NL (amsterdam), I will show you around and let you see the big picture
1304516860 M * ard Diner is on me of course :-)
1304517229 M * ard (BTW: that goes for anyone involved in (util-)vserver)
1304518752 F * ChanServ +o Bertl
1304520805 F * Bertl -o Bertl
1304520897 M * MrTV ard, thank you for answering. i was awk. sorry. 
1304520996 M * MrTV i am living with the debian stock vserver kernel and had no big problems so far. 
1304521008 M * Bertl awk = away with keyboard?
1304521019 M * MrTV :)
1304521034 M * MrTV yes :)
1304521052 M * MrTV I meant afk 
1304521154 M * MrTV at the moment I am looking for a safe upgrade path of my running hosts and vservers (lenny to squeeze). I have read through the wiki page which describes the issues of the debian stock kernel to which Bertl pointed me. 
1304521227 M * MrTV I have never used unification, so at least there i should be safe.
1304521282 M * Bertl yes, just make sure to fix up the barrier then
1304521293 M * Bertl or you might end up with non-working guests
1304521342 M * MrTV non-working means , they just would not start?
1304521379 M * Bertl yes, won't start or cannot be entered
1304521424 M * MrTV what the barrier is concerned: the attributes are there. and the guest starts
1304521437 M * Bertl good then
1304521452 M * MrTV on a test host i did the dist-upgrade 
1304521537 M * MrTV so the host kernel is 2.6.32-5-vserver-amd64, the VS-API: 0x00020305 and util-vserver 0.30.215
1304521724 M * MrTV how can i check if the barrier is active?
1304521748 M * Bertl 0.30.215?
1304521757 M * Bertl you won't get far with that version
1304521781 M * Bertl i.e. I doubt that your guests are even correctly isolated atm
1304521823 M * MrTV 0.30.216-pre2864-2
1304521839 M * Bertl much better, although a few months behind
1304521840 M * MrTV i am sorry, vserver-info says 0.30.215
1304521857 M * Bertl so let's hope it is lying then :)
1304522001 M * MrTV can i test the barrier somehow ? or is it enough to see "---Bui- /vservers"  with showattr from the host?
1304522155 M * Bertl you should see it on any /path/to/guest_root/..
1304522162 M * Bertl but not at any deeper level
1304522628 M * MrTV on my test maschine i get this:
1304522630 M * MrTV [~] showattr /var/lib/vservers/
1304522631 M * MrTV ----Bui- /var/lib/vservers/
1304522631 M * MrTV ----bui- /var/lib/vservers/blackjack
1304522651 M * MrTV I only have one guest 
1304522692 M * MrTV so its just like in the example of the wiki
1304522706 M * Bertl why not simply do
1304522717 M * Bertl showattr /var/lib/vservers/blackjack/.. 
1304522736 M * Bertl it's so much easier and it will always show the correct results
1304522824 M * MrTV [~] showattr /var/lib/vservers/blackjack/..
1304522824 M * MrTV ----Bui- /var/lib/vservers/blackjack/..
1304522824 M * MrTV ----bui- /var/lib/vservers/blackjack/../blackjack
1304522834 M * Bertl perfect
1304522949 M * MrTV please forgive me if i ask in a stupid way, but i am still not sure if i understood the problem 
1304522971 M * MrTV xattr is a file system thing
1304522996 M * Bertl yep, there are a bunch of flags there, including those used for unification and the barrier
1304523031 M * MrTV and squeeze kernels intpret the flags in another way as the lenny kernel may have set it. is that right?
1304523036 M * Bertl the debian kernel used a patch where those flags got messed up
1304523050 M * MrTV interpret
1304523066 M * Bertl it was fixed a few days later, but debian did stick to the broken patches
1304523124 M * MrTV ok, so the squeeze kernel maybe doesn't honor the barrier from /var/lib/vservers/<my_guest_name> ?
1304523174 M * Bertl if you change from an older or newer kernel to the debian kernel, the flags need to be changed as well
1304523181 M * Bertl i.e. in both directions
1304523210 M * Bertl it's like the debian kernel reads an x as y and a y as x
1304523228 M * Bertl migrating to or from that kernel needs to adjust those flags
1304523294 M * MrTV I read that, but the question remains, does it suffice to get displayed ----Bui- or do I have to do something else?
1304523321 M * Bertl the tools use the kernel interface to query those flags, so what you see there is real
1304523339 M * Bertl i.e. it is the same view the kernel has on those flags
1304523360 M * Bertl rebooting with a different kernel might change that though
1304523375 M * Bertl i.e. if you check first with the old kernel, then reboot, the flags will be different'
1304523420 M * Bertl (and vice versa of course)
1304523445 M * MrTV well I wonder why i am seeing this now because i shouldn't as of what you say
1304523529 M * MrTV i didn't even know of the those problems with the debian kernel
1304523534 M * Bertl it's not easy to tell with debian, because they also have scripts running at startup, changing various things for you, IIRC, the barrier is part of that
1304523670 M * MrTV ok. because i started with standard 2.6.26-vserver, was running with that all the time and upgraded to 2.6.32-vserver now. and i didn't know of all that.
1304523713 M * Bertl not sure if that should be considered good or bad :)
1304523722 M * MrTV :)
1304523744 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1304523781 M * MrTV originally i came here because i had questions regarding the upgrade of a guest (lenny to squeeze). 
1304523807 M * MrTV the upgrade of the host went pretty fine
1304523830 J * dowdle ~dowdle@scott.coe.montana.edu
1304524139 M * MrTV thx so, far. I will proceed with this tomorrow.
1304524146 M * Bertl you're welcome!
1304524205 M * MrTV c'ya
1304524212 N * MrTV MrTV_gone
1304525553 J * bonbons ~bonbons@2001:960:7ab:0:44c0:4744:9ec6:1aa5
1304525704 M * Mr_Smoke Bertl: 33 days' uptime, and counting ! (2.6.38.2-vs2.3.0.37-rc9)
1304525708 M * Mr_Smoke Fingers crossed
1304525785 M * Bertl \o/
1304526415 Q * BenG Quit: I Leave
1304530075 M * Bertl off for a nap .. bbl
1304530091 N * Bertl bertl_zZ
1304530103 N * bertl_zZ Bertl_zZ
1304530714 Q * aj__ Ping timeout: 480 seconds
1304531843 J * aj__ ~aj@d004120.adsl.hansenet.de
1304533131 M * ser is it possible that cgroup does not enforce limits? i had two issues with one of servers which look like OOM, but OOM is not possible if cgroup works properly, as the guest has limits 10% of ram.
1304533930 J * manana ~mayday090@84.17.25.149
1304534857 Q * hparker Quit: Quit
1304535354 N * ensc Guest99
1304535363 J * ensc ~irc-ensc@p5DF2E63B.dip.t-dialin.net
1304535773 Q * Guest99 Ping timeout: 480 seconds
1304537561 Q * ncopa Quit: Leaving
1304537739 J * dowdle_ ~dowdle@scott.coe.montana.edu
1304537956 Q * dowdle Ping timeout: 480 seconds
1304538130 N * Bertl_zZ Bertl
1304538140 M * Bertl back now ...
1304538167 M * Bertl ser: OOM on guest or host?
1304538486 J * derjohn_foo ~aj@d003042.adsl.hansenet.de
1304538923 Q * aj__ Ping timeout: 480 seconds
1304539618 Q * bonbons Quit: Leaving
1304539678 J * cuba33ci_ ~cuba33ci@111-240-168-232.dynamic.hinet.net
1304540032 Q * cuba33ci Ping timeout: 480 seconds
1304540040 N * cuba33ci_ cuba33ci
1304541337 Q * manana Remote host closed the connection
1304545839 M * ser Bertl: it is a problem, i do not know - everything happens too quickly
1304545845 M * ser nothing in logs
1304545888 M * Bertl well, what OOM messages do you get?
1304545932 M * ser sorry for chaotic relation: i have no messages. everything i could see when i was once logged in during such an accident, was: (one second)
1304545991 M * ser df worked properly, but after ps: segmentation fault. after shutdown: segmentation fault
1304546007 M * ser dmesg: segm. fault
1304546039 M * ser and i had no choice and send b to sysreq
1304546051 M * ser but nothing in logs
1304546088 M * Bertl what kernel is that?
1304546110 M * ser 2.6.36.4-vs2.3.0.36.39-beng #1 SMP Wed Mar 9 12:05:40 GMT 2011 x86_64
1304546136 M * Bertl and the util-vserver used?
1304546165 M * ser 0.30.216-pre2955; Mar 26 2011, 10:28:24
1304546193 M * Bertl and what is running on the host (ignoring the guests)?
1304546208 M * ser sshd only
1304546254 M * Bertl and the segmentation fault happened on the host, yes?
1304546269 M * ser i was logged in the host only at the moment
1304546293 M * Bertl and basically no command worked properly, yes?
1304546307 M * ser df - perfectly
1304546323 M * ser but nothing more
1304546347 M * ser echo worked :)
1304546379 M * ser sync - seg. fault as well
1304546418 M * Bertl very strange, but could hint to a filesystem issue as well
1304546483 M * ser any advice how i can log more?
1304546494 M * Bertl serial console
1304546506 M * Bertl every server should have one :)
1304546558 M * ser no money
1304546575 M * Bertl nah, weak argument
1304546589 M * Bertl do you have just a single machine?
1304546603 M * petzsch dmesg
1304546608 M * ser i am poor, ovh.com is the cheapest internet provider at the planet
1304546631 M * ser but unfortunately no serial
1304546643 M * Bertl so you have only one server there?
1304546702 M * ser few but they do not provide any features until you have many of them and pay enough $$$$
1304546722 M * Bertl do you have access to the servers?
1304546726 M * ser nope
1304546738 M * ser no bios as well
1304546744 M * petzsch @ser: don't they offer a rescue system to boot from network? could be handy for hw diagnosis
1304546753 M * Bertl do they have somebody there who does stuff like inserting a cd or so?
1304546773 M * Bertl some kind of remote hands
1304546786 M * ser i can run any .iso
1304546803 M * Bertl via web, or what?
1304546821 M * petzsch sounds very "virtual"
1304546829 M * ser yes, i can put a link to .iso and it is downloaded and run
1304546846 M * ser petzsch: it is a physical machine 
1304546868 M * Bertl so it must at least have a remote management system to do that
1304546887 M * Bertl probably some kind of blade with an ilo or so
1304546900 M * ser Bertl: imho it is a sort of scripting - tftp probably 
1304546981 M * Bertl the thing is, if you have more than one machine there, and each of them has at least one serial port (which is highly likely) all you need to do is to convince somebody there (once) to daisy chain the machines with a serial crossover cable
1304546984 M * ser it dowloands an iso to remote server and run it via tftp
1304546984 M * petzsch the german ovh.de website mentions vKVM and Netboot, that would definitily help for running an fsck
1304547009 M * ser Bertl: i was chatting about it, but the answer is: no
1304547021 M * ser probably my servers are dispersed
1304547036 M * ser they have hunreds thousdands of them
1304547041 M * Bertl well, that is something which can be fixed over time
1304547058 M * Bertl anyway, if a serial console (real or virtual) is not an option
1304547071 Q * ghislain Quit: Leaving.
1304547077 M * Bertl you can still do a netconsole and a rescue kernel
1304547095 M * ser Bertl: i run all tests, memtest, cpuburn
1304547101 M * ser no problems
1304547108 M * Bertl i.e. a special kernel which is kexec-ed when your real kernel panics
1304547137 M * ser Bertl: ok so i should virtualize my own server inside something?
1304547139 M * Bertl this way you can trigger a panic via /proc and analyze the dmesg and kernel state
1304547158 M * Bertl that would be an option too, but IMHO not required
1304547188 M * ser so could you explain - link me to an example?
1304547255 M * Bertl http://lse.sourceforge.net/kdump/
1304547272 M * ser reading.....
1304547299 M * Bertl of course, it needs some testing first, i.e. I'm sure it will not work on the first try
1304547327 M * Bertl but once you got it working, you can easily debug almost all cases
1304547328 M * petzsch good night.
1304547332 Q * petzsch Quit: Leaving.
1304547429 M * ser Bertl: sure, i must learn first to know what to ask :)
1304547433 M * ser Bertl: thanks :)
1304547463 M * Bertl you're welcome!
1304547541 M * ser i need >100mbit of continous traffic and no company can do it for $200 with two 16GB/ram i7 xeon servers
1304547562 M * ser apart of ovh
1304547593 M * ser prices in the us are so high
1304547608 M * Bertl just means that you have to spend more of your time on getting a reasonable setup there :)
1304547635 M * ser Bertl: yes, great thanks for help
1304550893 Q * LuckyLuke Ping timeout: 480 seconds
1304551426 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it
1304552664 Q * monrad-51468 Server closed connection
1304552674 J * monrad-51468 ~mmk@domitian.tdx.dk
1304552735 J * radix ~radix@sslvpn.idsoftware.com