1266452681 M * sur5r daniel_hozac: after playing with testfs.sh i'm pretty sure the missing mount option was the source of the problem. thanks for pointing me in that direction
1266453190 Q * imcsk8 Quit: Leaving
1266453629 Q * dowdle Remote host closed the connection
1266456044 J * kjdash ~kjdash@cpe-72-181-170-183.tx.res.rr.com
1266456123 M * kjdash anyone have linux-vserver running on ubuntu 9.10?
1266459881 N * Bertl_zZ Bertl
1266459919 M * Bertl kjdash: Linux-VServer is fairly distro independant (host and guest) what's you problem if there is any?
1266460168 M * kjdash well, there is a ppa with ubuntu binaries for 9.10, which depends on a kernel version which isn't published
1266460255 M * kjdash ubuntu for whatever reason skipped from 2.6.31.17 to .19, and the binaries are built for .18
1266460275 M * kjdash so i dragged down the headers and such for .18
1266460436 M * Bertl hmm, why not build your own kernel?
1266460445 M * kjdash and it went fairly badly, grub gave a quick "...not found" when i tried to boot it
1266460469 M * kjdash well, that would be the answer i didn't want to hear
1266460498 M * kjdash a part of the reason one uses a distro like ubuntu is to not do those things
1266460506 M * Bertl okay, then why not take any precompiled debian/ubuntu kernel instead?
1266460543 M * kjdash i did
1266460577 M * Bertl and the prebuilt images did not work, so ... who might be the one you want to contact in this case? :
1266460578 M * kjdash i guess i am looking for validation that a particular kernel/vserver combo works on ubuntu 9.10
1266460603 M * Bertl AFAICT, all vanilla/patch versions published work with ubuntu
1266460634 M * kjdash hmm, this was a fresh install done today
1266460651 M * Bertl http://linux-vserver.org/Installation_on_Ubuntu
1266460652 M * kjdash nothing fancy
1266460660 M * kjdash yep, followed that guide
1266460686 M * kjdash the packages provided there are broken
1266460738 M * kjdash at least for 9.10/karmic
1266460740 M * Bertl then please contact Christoph Lukas
1266460759 M * kjdash i intend to
1266460768 M * kjdash just asking around first before i start filing bugs
1266460921 M * kjdash assuming i build my own kernel
1266460939 M * kjdash any known issues with upstart based distros?
1266461123 M * Bertl you need to configure some things to make upstart happy inside a guest, but on the host, a vanilla kernel should be fine ... after all, upstart is just another init process
1266461628 Q * balbir Read error: Connection reset by peer
1266462925 Q * FireEgl Ping timeout: 480 seconds
1266463760 J * FireEgl Proteus@2001:470:e056:1:223:54ff:fe89:b207
1266465649 J * SauLus_ ~SauLus@c207022.adsl.hansenet.de
1266466060 Q * SauLus Ping timeout: 480 seconds
1266466060 N * SauLus_ SauLus
1266466505 Q * Piet Ping timeout: 480 seconds
1266467066 J * Piet ~Piet__@04ZAAAHPW.tor-irc.dnsbl.oftc.net
1266469174 Q * eyck Ping timeout: 480 seconds
1266469412 J * eyck ~eyck@77.79.198.67
1266471820 J * ksn ~ksn@41.151.28.39
1266474568 J * sharkjaw ~gab@90.149.121.45
1266475722 J * ncopa ~ncopa@245.39.189.109.customer.cdi.no
1266477962 Q * Piet Remote host closed the connection
1266478005 J * Piet ~Piet__@04ZAAAHSY.tor-irc.dnsbl.oftc.net
1266478699 J * balbir ~balbir@122.248.161.59
1266480180 J * ghislain ~AQUEOS@adsl2.aqueos.com
1266480669 Q * hijacker Quit: Leaving
1266481708 J * ktwilight_ ~keliew@91.179.209.87
1266481953 Q * michal Quit: reboot
1266482001 J * ktwilight__ ~keliew@19.165-247-81.adsl-dyn.isp.belgacom.be
1266482059 Q * ktwilight Ping timeout: 480 seconds
1266482270 Q * ktwilight_ Ping timeout: 480 seconds
1266482286 J * BenG ~bengreen@cpc2-aztw22-2-0-cust521.aztw.cable.virginmedia.com
1266483000 Q * rickytato Quit: rickytato
1266484396 J * dna ~dna@p54BC9699.dip0.t-ipconnect.de
1266485889 J * yarihm ~yarihm@office-zrh.youngsolutions.ch
1266486801 J * taenzerme ~Adium@static-87-79-237-223.netcologne.de
1266487658 M * incd Hey, when connecting to vserver container, it connects to the host (not container). So I how should I route the IP? Any documentation/guides on that? Each container has its own IP.
1266487701 M * BenG you are ssh'ing in incd ?
1266487770 M * incd yeah
1266487863 J * barismetin ~barismeti@zanzibar.inria.fr
1266487916 M * incd A = container B = master. "ssh A" connects to B :/
1266488087 M * incd Ok my bad
1266488093 M * incd "RTFM" :)
1266488313 M * Bertl common issue .. np
1266488610 M * bobnormal not quite sure how the cgroup / vserver link works.  docs on the wiki at util-vserver:Cgroups suggest using the vserver name as the cgroup name.  is this an in-kernel link or something util-vserver establishes?  does the cgroup need to be configured prior to vserver <x> start, can you add a config while running?  cant find docs
1266488642 Q * dna Read error: Connection reset by peer
1266488676 M * Bertl Linux-VServer guests are a combination of all kind of namespaces, contexts, and recently cgroups too
1266488698 M * Bertl i.e. there is no 'link' between a cgroup and a network context for example
1266488716 M * bobnormal sure
1266488728 M * Bertl but util-vserver combines them into an aggregate known as 'guest'
1266488782 M * bobnormal so if i do: 'vserver <x> start' and then 'mount -t cgroup -o cpu none /cgroups' then 'mkdir /cgroups/<x>/' and start mucking with it, it will automatically take to the running vserver?
1266488797 M * bobnormal or it will already be there?
1266488814 J * dna ~dna@p54BC9699.dip0.t-ipconnect.de
1266488860 M * Bertl if a cgroup is configured for the guest, it will be create by util-vserver and the config data will be copied over, so yeah, when you start messing with that cgroup, you'll affect the guest processes
1266488921 M * bobnormal aha, you have to add a cgroup file in the /etc/vservers/<x>/ config dir .. i missed that
1266488925 M * bobnormal thanks
1266488978 M * bobnormal i've written 29 pages of docs so far ;)
1266488997 M * BenG bobnormal, you need to have /dev/cgroup mounted before you start the guest, or util-vserver won't have anywere to attach the cgroup for the guest in question
1266489015 M * bobnormal will it autodetect a mount point or must it be /dec/cgroup?
1266489025 M * bobnormal s/dec/dev/
1266489028 M * BenG it uses /dev/cgroup
1266489028 M * Bertl recent util-vserver makes the mount on host startup, IIRC
1266489042 M * Bertl (i.e. the runlevel scripts take care of that :)
1266489052 M * BenG but that's not in the Debian builds sadly
1266489075 M * Bertl well, debian also uses the 'stable' 2.6.26 abomination :)
1266489087 M * BenG but even for Squeeze
1266489104 M * BenG the build of util-vserver does not include the mainline init script
1266489125 M * BenG IIRC
1266489131 M * bobnormal adds to fstab or vprocunhide?  i only run vprocunhide at the moment.  im on gentoo.  gentoo packages are out of date too.  i voted / commented on a bug on bugs.gentoo.org today suggesting updates and offering to script automatic ebuild generation from ~harry for grsec patched versions + standard
1266489163 M * BenG bobnormal, if you run the mainline util-vserver it will sort out /dev/cgroup for you
1266489164 M * bobnormal with the gotcha that i wouldn't bother if they weren't going to be added as often i've provided ebuilds and they sit on bugs.gentoo.org for months and months and never get added to portage
1266489170 M * Bertl BenG: yeah, for whatever reason, debian cannot include the runlevel scripts provided upstream
1266489184 M * Bertl BenG: you might contact micah to include required updates
1266489195 M * BenG good point
1266489202 M * bobnormal beng: which part of util-vserver sorts it out?
1266489211 M * BenG the init script bobnormal 
1266489222 M * bobnormal name?
1266489227 M * bobnormal != vprocunhide?
1266489282 M * BenG /etc/init.d/util-vserver
1266489359 M * BenG sorry, don't know the ins and outs, I'm going to have a look now at the differences between the Debian init scripts and the upstream ones
1266489371 M * BenG see what needs to be done and then contact micah
1266489692 M * bobnormal appears from source of util-vserver 0.30.216-pre2864 that sysv/util-vserver includes cgroup mount but gentoo/util-vserver does not
1266489859 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net
1266489911 M * bobnormal from my current reading on Control Groups it seems that making a directory under a cgroup filesystem mount point defines a control group, and it is possible to either mount with one or more simultaneous Control Group subsystems (cpuacct,cpuset,cpu,memory,freezer,debug) .. 
1266489942 M * bobnormal if util-vserver forces you to have a single mount at /dev/cgroup then does it also force you to manage all resources in the same control group hierarchy?
1266489967 M * bobnormal the kernel documentation states that control groups is a multi-hierarchy, multi-subsystem design
1266489987 M * bobnormal so that you can for example manage cpu access and memory allocation for different (but not mutually exclusive) groups of processes
1266490041 M * bobnormal as a completely different question ... is it possible to provide a secure interface to a vserver that has been linked to a control group hierarchy to sub-allocate resources via control groups to task groups within the vserver?  (eg: database gets X cpu, webserver gets the rest)
1266490114 M * BenG bobnormal, have you got the cgroups system up and running yet?
1266490126 M * BenG for any of your geusts?
1266490164 M * bobnormal beng: i have a kernel and have been able to mount, but i havent yet linked in util-vserver and applied any limits to guests .. just arbitrary processes
1266490169 J * karasz ~karasz@shell.opensde.net
1266490287 M * BenG how are you achieving that bobnormal ?
1266490296 M * BenG which set of commands?
1266490365 M * BenG basically I've got my knowledge of cgroups to the level were I can see how it works for how util-vserver uses it, no further
1266490367 M * bobnormal beng: a whole lot of tests .. yesterday and today .. mostly right now i am clarifying management options between rlimit, cpu group scheduler + hard limits extension, memory + swap extension, cgroups device subsystem, etc.
1266490394 M * BenG "is it possible to provide a secure interface to a vserver that has been linked to a control group hierarchy to sub-allocate resources via control groups to task groups within the vserver"
1266490418 M * BenG that's a great question, but I think you are far more likely to be able to answer :)
1266490432 M * bobnormal haha :)
1266490473 M * BenG try getting the util-vserver way of using cgroups working, it's a very simple scheme
1266490476 M * bobnormal 2 days of reading kernel docs .. Documentation/scheduler/* .. actually highly recommended, good to understand
1266490497 M * bobnormal im just getting to grips with how util-vserver links in to it
1266490531 M * bobnormal of course in addition to control groups
1266490539 M * Bertl BenG: to answer the question :^) to the extend where cgroups implement the hierarchical structure planned, yes :)
1266490564 M * bobnormal you also have rlimit and nice to contend with, plus the fact that rlimit can limit nice, and the fact that a vserver flag by default restricts guests from setting rlimits at all
1266490576 M * bobnormal many interplaying levels of control
1266490614 M * bobnormal not so simple to approach with the current docs .. so i am trying to write some clearer ones specifically around vserver management which include references to all the different oolsets but written from an 'i wanna get X done' perspective
1266490687 M * bobnormal different tangent: i read somewhere that there's an IO bandwidth scheduler, that would be really cool to have with cgroups, but the one i found referenced doesnt seem to be in the kernel .. would be great to allocate disk IO bandwidth between vservers!
1266490738 M * BenG I did update the wiki in the end bobnormal, it's turned out to be complete gumby howto for getting cgroups working in Debian Lenny now
1266490770 M * bobnormal beng: yep i've been reading that page yesterday/today, also did some updates this morning ;)
1266490774 M * BenG you know that RSS limiting is moving to cgroups too bobnormal ?
1266490794 Q * ksn Ping timeout: 480 seconds
1266490863 M * BenG well you did if you read that page:)
1266490872 M * bobnormal beng: still reading :)
1266490949 M * Bertl the cgroup/freezer support in 2.6.32 is interesting
1266490959 M * bobnormal i think a move to cgroups from rss.soft/rss.hard is a verty good thing.  issue is around portability to/from linux + other unices i suppose
1266491006 M * Bertl not sure it is usable yet, but definitely interesting ...
1266491032 M * bobnormal anyone ever played with the device whitelisting subsystem for cgroups?
1266491043 M * Bertl daniel_hozac: also the 'device' cgroup aims to replace part of our device mapper functionality
1266491234 M * BenG bobnormal, for your manipulation of control groups, are you using command line tools, and if so which ones?
1266491256 M * Bertl probably echo :)
1266491260 M * bobnormal beng: at the moment im just using raw proc interface, i read about ptools which i'm going to try out as wlel.
1266491289 M * BenG okay, just found a cgroups-bin package
1266491410 M * BenG cgroup-bin sorry
1266491413 M * bobnormal bertl: can you explain briefly how the control groups devices subsystem / linux vserver play/don't play together, what features may differ in each, and what the plan is
1266491591 M * Bertl well, except for the cgroup namespace all the cgroup features are supposed to work and play nice with Linux-VServer guests
1266491612 Q * dna Read error: Connection reset by peer
1266491626 J * dna ~dna@p54BC9699.dip0.t-ipconnect.de
1266491629 M * Bertl naturally we are moving Linux-VServer specific features to mainline features when they are available and somewhat stable
1266491658 M * Bertl (happened with the TBS, now happening with the memory limits)
1266491667 M * bobnormal ok makes sense
1266491687 M * bobnormal i haven't read much on either yet but can you tell me if there are any significant functional differences you're aware of
1266491763 M * Bertl from our observation, the mainline frameworks are usually more complicated and more designed towards larger (big SMP/NUMA) systems
1266491800 M * BenG I've found the cgroups way of scheduling a lot easier to understand
1266491808 M * Bertl so, for example, the memory cgroup adds measureable overhead to userspace (currenlty a few percent), while the rss/vm limits Linux-VServer uses is not detectable
1266491844 M * Bertl the scheduler is probably a real improvement, although it has taken 5 revisions to get something useable there
1266491861 M * Bertl (and it still cannot do what the TBS extensions allowed :)
1266491867 M * BenG indeed
1266491913 M * bobnormal ok, specific to the device subsystem though are you aware of much difference between existing vserver functionality and the current control groups device subsystem?
1266492027 M * bobnormal im just trying to figure out whether either are spending much time looking at right now for my own requirements, ie: whether there is likely to be any significant flux in features/interface in the near future.  eg: if the cgroups device subsystem implements some vserver functionality as you mentioned earlier, i assume vserver will retain the same configuration api?  or is this endangered by feature / security model changes
1266492105 M * Bertl yes, it looks like the cgroup device subsystem implements a tiny subset of our device mapper
1266492126 M * Bertl i.e. it controls the two attributes - open and mknod - for devices
1266492146 M * Bertl (while the device mapper allows that and arbitrary mappings from one device to another)
1266492240 M * bobnormal thanks
1266492460 M * Bertl you're welcome!
1266492806 M * bobnormal bertl: other than the (~3%?) overhead of the cgroup memory subsystem, what are the core differences between the rss/vm limits Linux-VServer uses vs. that subsystem?  trying to roll this in to docs so don't want to get it wrong
1266492844 J * [Guy] ~korn@elan.rulez.org
1266492844 M * Bertl the basic approach is a little different (which explains the overhead)
1266492875 M * Bertl we do somewhat inaccurate accounting without the need to tag/mark a page/vma
1266492931 M * bobnormal bertl: the memory subsystem's kernel documentation reports that it may report inaccurately anyway, due to the batch nature of its design
1266492932 M * Bertl we also do not bother to account swap pages, instead we let the host handle paging and fake the mem/swap part for the guest view
1266492932 Q * Guy- Ping timeout: 480 seconds
1266492959 M * Bertl yes, the kernel system still has the problem of double used pages
1266492977 M * Bertl (something which happens quite often in Linux-VServer and similar setups)
1266493013 M * Bertl but the page accounting itself should be more accurate with the cgroup than with the normal rss/vm accounting
1266493052 Q * dna Read error: Connection reset by peer
1266493057 M * Bertl also, something we didn't bother to fix in the Linux-VServer rss limits is the OOM action once a guest is out of memory
1266493058 J * larsivi_ ~larsivi@47.80-202-217.nextgentel.com
1266493061 J * hijacker ~hijacker@213.91.163.5
1266493066 J * dna ~dna@p54BC9699.dip0.t-ipconnect.de
1266493073 M * Bertl this seems to be handled nicely with the cgroup memory controller
1266493147 M * bobnormal ok great
1266493200 M * Bertl I'm toying with the idea to leave the 'old' rss accounting/limits in place, but make them optional at compiletime
1266493243 M * Bertl i.e. you can disable the cgroup memory controller and still have some rss accounting and basic limits without the overhead
1266493275 M * bobnormal sounds like a good feature if it's not too hard to maintain
1266493307 M * Bertl yeah, we'll see ... haven't decided yet :)
1266493309 Q * larsivi Ping timeout: 480 seconds
1266494023 Q * sharkjaw Remote host closed the connection
1266494616 J * ksn ~ksn@41.151.7.143
1266495291 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1266495394 P * taenzerme 
1266497756 Q * thierryp Remote host closed the connection
1266499010 M * bobnormal hrrm cant seem to get cgroup working ... if i start a vserver after mounting cgroups on /cgroup there is no new cgroup created there for the vserver, and creating one manually and listing /cgroup/<guest-name>/tasks gives nothing
1266499021 M * bobnormal i have all CGROUP options compiled except NS
1266499039 M * bobnormal util-vserver and vprocunhide init scripts ran (gentoo)
1266499069 Q * ksn Ping timeout: 480 seconds
1266499082 M * bobnormal i also tried adding /etc/vservers/.defaults/cgroup/mnt containing '/cgroup' and it didnt make any difference :/
1266499585 M * bobnormal i suspect util-vserver is not finding it.  im on 0.30.216-pre2864
1266499824 M * BenG why not use the default location bobnormal ?
1266499827 M * BenG /dev/cgroup/
1266499852 M * bobnormal because i thought i had it working with that location before a reboot
1266499859 M * bobnormal apparently not :P
1266499882 M * bobnormal i can use /dev/cgroup though.  any idea how to make udev create that automagically as a normal dir at boot?
1266499908 M * bobnormal beng: also, what were the tools you used that weren't raw cgroup filesystem access, i cant find any in gentoo and ptools is apparently obsolete
1266499953 M * BenG cgroup-bin, but it wasn't that useful, it's a policy daemon
1266499963 M * bobnormal ok i will skip it then
1266499992 M * bobnormal beng: i can email you my docs so far if you want to add suggestions, you seem to be one of the primary cgroup users :)
1266500002 M * BenG http://linux-vserver.org/util-vserver:Cgroups#Making_sure_all_of_this_gets_set_up_after_a_reboot
1266500013 M * bobnormal cheers
1266500027 M * BenG I'd love to see the docs
1266500371 M * daniel_hozac you realize the util-vserver sets it up, right?
1266500397 M * daniel_hozac +initscript
1266500397 M * bobnormal daniel_hozac: i've installed a couple of versions of that on this box, at the time my kernel didnt have CGROUP support though
1266500412 M * bobnormal daniel_hozac: would that prevent proper setup?
1266500425 M * daniel_hozac no
1266500461 M * daniel_hozac as long as you don't use the Debian packages, util-vserver will take care of everything as long as /etc/vserves/.defaults/cgroup exists.
1266500479 M * bobnormal i can try a clean install with a fresh make install && make install-distribution if you like, or just retry the latter on the running system.
1266500532 M * bobnormal daniel_hozac: i just created that, then rebooted, no cgroup mounts even with gentoo util-vserver and vprocunhide init scripts running ... will double check that now after removing all files in /etc/vservers/.defaults/cgroup/* 
1266500565 M * daniel_hozac well, the gentoo initscripts probably don't do it either
1266500623 M * bobnormal ahh
1266500643 M * bobnormal i will try adding to fstab then
1266500646 J * petzsch ~markus@dslb-094-222-101-251.pools.arcor-ip.net
1266501297 M * bobnormal ooh good good :)  vserver <x> start now == /lib/util-vserver/vserver.functions: line 1490: /dev/cgroup/<x>/mnt: Permission denied ... Failed to start vserver '<x>'.  Not far now :)
1266501525 M * daniel_hozac you might want to try the Gentoo util-vserver initscript from trunk
1266501531 M * daniel_hozac it should do the right thing.
1266501539 M * bobnormal ok :)
1266502064 M * bobnormal errors mounting .. rebooting after removing fstab .. will try to figure out a patch
1266502097 M * bobnormal erp no, fstab did it
1266502105 M * bobnormal mount works on boot! thanks
1266502110 M * bobnormal now for the real test :)
1266502147 M * micah BenG: please do a file a bug if there is something missing there, and I'll make sure to get it fixed
1266502153 M * bobnormal yay! vserver starts, cgroup created :)
1266502168 M * BenG woohoo!
1266502173 M * BenG micah, cheers will do
1266502207 M * BenG basically /dev/cgroup/ needs creating and mounting if all the cgroups stuff needs to work
1266502208 M * micah BenG: i dont know anyone who uses cgroups, so your knowledge on that would be useful
1266502228 M * BenG http://linux-vserver.org/util-vserver:Cgroups#Making_sure_all_of_this_gets_set_up_after_a_reboot
1266502244 M * BenG that's the instruction for how to get Lenny to do the right things
1266502290 M * BenG whether you want the util-vserver init scripts to sort that out or not, well, I guess it's more of wishlist item than a bug
1266502338 M * daniel_hozac it's a "Debian doesn't work like other distros" bug.
1266502520 M * bobnormal am i correct to assume that free -m in a guest wont update when the cgroup memory control subsystem is used to limit memory
1266502534 M * daniel_hozac depends on your kernel.
1266502547 M * daniel_hozac there was work to get virt_mem to do that
1266502559 M * bobnormal 2.6.32.8-grsec2.1.14-vs2.3.0.36.29
1266502565 M * Bertl that's in 2.6.32-vs-latest
1266502648 M * bobnormal if i were to use vserver's rss/vm limiting then it would be reflected in the guest if virt_mem was on though?
1266502684 M * Bertl not with the latest experimental patches
1266502698 M * Bertl i.e. the virt_mem is solely cgroup based there
1266502902 M * bobnormal ok, so with this kernel i am unable to get free memory reports showing correctly in the guest at all or .. ?  set/remove virt_mem seems to affect some figures but not total
1266502989 M * Bertl I don't know what grsec changed, but with the vanilla + Linux-VServer, you can enable virt_mem and it will use the cgroup memory controller information
1266503014 M * bobnormal ok
1266504125 M * bobnormal i am switching to vanilla try try that
1266504495 M * ghislain anybody use the latest exp partches here on 2.6.32 ? i think i need to upgrade all my machines and i fear a little 2.6.32 as my first experiment showed some regressions and some network bug (vanilla related not vserver)
1266504518 M * ghislain i wondered if 2.6.32 is now better 
1266504535 M * ghislain and /or if people here use it without issues on systems
1266504558 M * bobnormal ghislain: testing only, not in production... tried .9 (must enable cgroups to compile) and .9.1 (now compiling for further testing)
1266504559 M * Bertl in general, 2.6.31 still looks better/more stable
1266504847 Q * kjdash Quit: Ex-Chat
1266506038 Q * hijacker Remote host closed the connection
1266506467 M * bobnormal with cpusets, it seems /proc/cpuinfo is visible to guests but they see all cpu cores not just the ones they have access to, is this expected behaviour and is it expected to change in future?
1266506707 M * bobnormal and /proc/stat the same
1266506711 M * Bertl it is expected behaviour, no idea if 'mainline' plans to change that in the future ... at some point, we might change that (e.g. if somebody sponsors development in this direction)
1266506727 M * daniel_hozac cpusets used to have an option to virtualize that.
1266506739 M * daniel_hozac but it was removed when it merged into mainline.
1266506762 M * daniel_hozac it existed as a separate patch for awhile.
1266506764 M * Bertl so it might be worth digging out the older patches if there is some interest :)
1266506764 M * daniel_hozac it might still.
1266506782 M * bobnormal thanks
1266506794 M * bobnormal just exploring .. :)
1266506874 M * raceme hello guys... I was wondering... Is there a way to determine from a vserver what is the name of the parent host ?
1266506915 M * Bertl not without 'help' from the admin
1266506975 M * bobnormal raceme: one technique is valid, cat /proc/version and determine kernel compilation-time hostname
1266506981 M * bobnormal raceme: this may differ though
1266507058 M * raceme in fact I have 2 hosts which may run a vserver. The idea is to know the parent from the vserver. But the two hosts share the same kernel... /proc/version will give me compilation host, not running host ?
1266507170 M * daniel_hozac try arp
1266507227 M * daniel_hozac addresses external to the host will get arp entries when you ping them, while addresses assigned to the host won't.
1266507236 M * raceme daniel_hozac: i thought about that but that means that i must have a table of hosts which are parent and not vservers
1266507270 M * daniel_hozac or a sane IP address assignment scheme
1266507270 M * Bertl well, alternatively you can simply write the name (from a guest init script) into the guest :)
1266507271 M * daniel_hozac yes.
1266507289 M * bobnormal raceme: if you are in control of the vservers, just export the host environment info to the filesystem of the guest via /etc/vservers/<vserver-name>/mtab
1266507304 M * bobnormal raceme: this can easily be shared throughout all vservers
1266507311 M * Bertl mtab?
1266507318 M * bobnormal err whatever its called
1266507335 M * bobnormal fstab
1266507336 M * raceme bobnormal: good idea I have control on the parent and vservers
1266507336 M * bobnormal sorry ;)
1266507351 M * Bertl well, fstab isn't a good idea for environment either
1266507360 M * bobnormal raceme: i use that technique to provide fixed packaging overlays to autobuild vservers for specific linux distros
1266507395 M * bobnormal bertl: why? if mounted ro from host, where's the badness?
1266507427 M * raceme is it possible to rbind directly a file like /etc/hostname ?
1266507435 M * daniel_hozac yes
1266507445 M * raceme so this is the solution :)
1266507451 M * raceme let's test that 
1266507465 M * daniel_hozac only with recent util-vserver versions though
1266507477 M * petzsch Bertl: you mentioned 2.6.31 looking better/stabler than 2.6.32 ... any known issues?
1266507504 M * Bertl I had some issues with 2.6.32 on my machines, switched back to 2.6.31.x 
1266507531 M * Bertl raid performance terrible, OOM every hour, strange swap behaviour
1266507569 M * Bertl (didn't test the last two weeks though, so that might have improved)
1266507573 J * hijacker ~hijacker@213.91.163.5
1266507702 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1266507730 M * raceme daniel_hozac: seems not to work with util-vserver from ubuntu karmic (0.30.216~r2842)
1266507740 Q * thierryp Remote host closed the connection
1266507781 M * BenG bobnormal, I'm confused about a couple of paragraphs of your documentation
1266507807 M * daniel_hozac raceme: yep, that's too old.
1266507829 J * dowdle ~dowdle@scott.coe.montana.edu
1266507856 M * raceme daniel_hozac: ok... so i'll investigate with a dir
1266507869 M * raceme thanx daniel_hozac Bertl and bobnormal 
1266508151 Q * yarihm Quit: This computer has gone to sleep
1266508592 J * dna_ ~dna@p54BC9699.dip0.t-ipconnect.de
1266508796 M * bobnormal i dont seem to be able to setattr --hide /proc/mtrr
1266508802 M * bobnormal not really critical but just curious why
1266508876 M * daniel_hozac so you can still see it from guests after running that?
1266508902 M * bobnormal err my bad :)
1266508909 M * bobnormal <-- too many consoles :)
1266508932 M * bobnormal just setting up WACOM usb tablet for X11 multiscreen
1266508936 M * bobnormal got a bit excited/distracted :)
1266508999 Q * dna Ping timeout: 480 seconds
1266509090 M * bobnormal im only 27
1266509092 M * bobnormal erp
1266509094 M * bobnormal haha
1266509096 M * bobnormal damn /query
1266509115 M * Mr_Smoke Hahaha
1266509125 M * bobnormal ;)
1266509125 M * Mr_Smoke Trying to pull chicks in #vserver ? I think not :)
1266509136 M * bobnormal discussing length of smoking habits relative to quitting difficulty
1266509139 M * bobnormal actually :P
1266509141 M * Bertl bobnormal: when you are 50, you'll know how to use /query :)
1266509171 M * Bertl (or how to avoid to have to think about it by using a smart client :)
1266509191 Q * BenG Quit: I Leave
1266509200 A * Mr_Smoke ponders about starting a client troll/flame
1266509209 M * Mr_Smoke Ah what the hell, irssi ftw :)
1266509211 M * bobnormal forward slash window new!
1266509570 M * bobnormal anything likely to die if i hide /proc/slabinfo?
1266509851 Q * balbir Ping timeout: 480 seconds
1266510343 A * Bushmills pulls out his troll protection badge
1266511561 M * Bushmills http://forthfreak.net/~l/badges/ATT314559.jpg 
1266511740 J * yarihm ~yarihm@80-219-168-39.dclient.hispeed.ch
1266511896 Q * bobnormal Quit: X11 restart for wacom goodness!
1266512048 J * imcsk8 ~ichavero@148.229.1.11
1266512503 M * Bertl nap attack ... bbl
1266512508 N * Bertl Bertl_zZ
1266513898 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1266513929 Q * barismetin Quit: Leaving...
1266515026 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1266515217 J * hijacker_ ~hijacker@87-126-142-51.btc-net.bg
1266515289 Q * ncopa Quit: Ex-Chat
1266515462 J * balbir ~balbir@122.172.110.210
1266515860 J * kjj ~kjj@pool-74-107-128-126.ptldor.fios.verizon.net
1266516500 Q * Piet Ping timeout: 480 seconds
1266516552 J * dna ~dna@p54BC9699.dip0.t-ipconnect.de
1266516861 Q * dna_ Ping timeout: 480 seconds
1266516875 Q * thierryp Remote host closed the connection
1266517101 J * Piet ~Piet__@04ZAAAICQ.tor-irc.dnsbl.oftc.net
1266517913 Q * gnuk Quit: NoFeature
1266518191 J * Secretar ~Rabbit@193.231.40.24
1266519762 Q * Secretar 
1266521626 Q * hijacker_ Remote host closed the connection
1266523197 Q * bonbons Quit: Leaving
1266523363 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1266523475 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1266524393 J * dna_ ~dna@p54BC9699.dip0.t-ipconnect.de
1266524603 Q * dna_ 
1266524744 Q * bonbons Quit: Leaving
1266524784 Q * dna Ping timeout: 480 seconds
1266524791 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1266525695 Q * yarihm Quit: This computer has gone to sleep
1266527045 J * tpo ~tpo@cable-dynamic-87-245-106-94.shinternet.ch
1266527075 Q * Bushmills Ping timeout: 480 seconds
1266527166 M * tpo we have a problem with secure-mount segfaulting under the current stable Debian vserver kernel: http://bugs.debian.org/570382
1266527236 M * tpo it seems to be related to mmap patches (CVE-2010-0291)
1266527253 M * tpo any ideas?
1266527421 M * daniel_hozac looks more like you're out of memory.
1266527542 M * tpo daniel_hozac, that never happened before the upgrade
1266527561 M * tpo how come we'd suddenly be out of memory if we were not before?
1266527594 M * tpo before == before the upgrade
1266527608 P * fback 
1266527639 J * fback fback@red.fback.net
1266527680 M * tpo we experienced this on at least two servers with together 9 vserver instances plus there is another person (Dan Gardner) who has seen the same thing
1266527729 M * tpo I have not seen any other memory related problems on those machines, however I have not looked very intensely either...
1266527872 M * daniel_hozac well, could be someone messed up the syscall.
1266527880 M * daniel_hozac do you get it with a non-Debian kernel too
1266527881 M * daniel_hozac ?
1266527964 M * tpo daniel_hozac, I have not tried that
1266528113 Q * bonbons Quit: Leaving
1266528161 J * Bushmills ~l@scarydevilmonastery.net
1266528171 Q * Bushmills 
1266528215 M * daniel_hozac the 2.6.26 kernel is known to be broken in so many ways.
1266528245 M * tpo :), that's what you get with Debian stable... ;-)
1266528259 M * daniel_hozac yes.
1266528267 M * daniel_hozac old, broken crap.
1266528943 J * yarihm ~yarihm@217.150.254.90
1266529356 Q * ghislain Quit: Leaving.
1266529520 Q * thierryp Remote host closed the connection
1266529733 Q * yarihm Quit: This computer has gone to sleep
1266529804 J * Bushmills ~l@scarydevilmonastery.net
1266530405 Q * Bushmills Read error: Connection reset by peer
1266530826 J * yarihm ~yarihm@80-219-168-39.dclient.hispeed.ch
1266531026 Q * tpo Remote host closed the connection
1266532222 J * ksn ~ksn@41.151.22.216
1266532836 J * tpo ~tpo@cable-dynamic-87-245-106-94.shinternet.ch
1266533681 J * Bushmills ~l@scarydevilmonastery.net
1266533751 M * Bushmills it seems my one-week old vserver setup is falling apart now.
1266533796 M * Bushmills seemed to have started with lots of orphaned inodes, all of them from the hashify .hash directory
1266533857 M * Bushmills fsck truncated them. until it did, there was different reporting on cumulated file sizes in .hash
1266533935 M * Bushmills now no vserver will start up anymore. should do automatically, but fail.  attempt to start any manually gives: "vcontext: execvp("/etc/init.d/rc"): Exec format error"
1266533968 M * tpo oops, rc seems b0rken
1266533977 M * Bushmills guest rc in init.d script look ok. so it seems to be a problem with the interpreter
1266533996 M * Bushmills no guest can be started anymore
1266534032 M * Bushmills i installed one new guest now, and that one does start
1266534050 M * Bushmills but none of the existing ones
1266534054 Q * ksn Ping timeout: 480 seconds
1266534115 M * daniel_hozac are you sure they were orphans?
1266534129 M * daniel_hozac maybe you deleted inodes from currently linked files.
1266534133 M * Bushmills i am sure that i read fsck reporting that they are
1266534134 M * daniel_hozac e.g. /bin/bash
1266534267 M * Bushmills hm. the problem didn't seem to start with this. when i shut down, to restart from alternative system, for a fsck, that was for a reason. at that time, all guests were still running.
1266534309 M * Bushmills i went for file system test because a backup disk, same size as system disk, run out of disk space.
1266534334 M * daniel_hozac what kernel are you on?
1266534367 M * Bushmills and it was then that i discovered a disrepancy of reported file sizes in .hash, depending on from what directory is started du
1266534382 M * Bushmills it was either 50 gig or 350 gig.
1266534386 M * Bushmills 2.6.32
1266534414 M * daniel_hozac what do you mean?
1266534428 M * Bushmills debian squeeze
1266534443 M * daniel_hozac your cwd somehow influenced your du results?
1266534466 M * Bushmills du  .hash      showed  different result than   cd .hash ; du
1266534502 M * Bushmills first number - 50 gig - would have been consistent with the actual file  sizes
1266534529 M * Bushmills second number is too much. and that's what caused the backup drive to run out of space - there wasn't that much left
1266534554 M * Bushmills before, i had another strange thing happening:
1266534572 M * Bushmills when i run chown on a file, the file would be copied
1266534577 M * Bushmills not just owner changed
1266534604 M * Bushmills indications for this are:  disk activity graph, execution time, and file date#
1266534626 M * Bushmills so a recursive chown -R took about 2 hours ...
1266534638 M * Bushmills at the end, all chowned files had recent time stamp
1266534678 M * Bushmills first i attributed that to a different cause.  but i think now that the two problems are related#
1266534723 M * Bushmills actually, symptoms of that i had yesterday already, only i failed to understand:
1266534734 M * daniel_hozac well, yea.
1266534738 M * daniel_hozac you're using COW.
1266534744 M * Bushmills after a chmod, or chown, of a file,  rsync .... yes ...
1266534777 M * Bushmills rsync would transfer the whole file, instead of just updating inode information on it
1266534779 M * daniel_hozac you can't change attributes or contents of a COW file without breaking the link.
1266534789 M * Bushmills ah
1266534824 M * Bushmills ehm ...
1266534836 M * Bushmills those files where not on guest volumes
1266534854 M * Bushmills and i cow'ed/hashified guest volumes only
1266534894 M * Bushmills part of the reason why i didn't link the causes
1266534904 M * Bushmills didn't seem to be related to vserver
1266534905 M * daniel_hozac what's a "guest volume" for you?
1266534927 M * daniel_hozac we need more specifics here.
1266534930 M * daniel_hozac less vagueness.
1266534957 M * Bushmills the /ver/lib/vservers/<guestname> directory, which appears as guest root
1266534963 M * Bushmills var
1266535029 M * Bushmills the same root dir hierarchy which is symlinked to from /etc/vservers/<guest>/vdir 
1266535100 M * daniel_hozac and the place where you noticed COW happening was where?
1266535110 M * Bushmills ok, the /usr/bin guest directory contains mostly zero size files
1266535150 M * daniel_hozac that'll make it pretty non-functioning.
1266535205 M * Bushmills in noticed that COW is involved because of fsck coming up with files from the .hash dir mostly/only. recognised because their owners are UIDs which don't exist in the host passwd file
1266535255 M * Bushmills yes. i guess those are the truncated inodes - file dates correspond to the ime of running fsck
1266535265 M * Bushmills time
1266535383 M * Bushmills i'll try to fix one guest by running through the dirs and copy zeroed files from the just now installed guest.
1266535662 N * Bertl_zZ Bertl
1266535668 M * Bertl back now ...
1266536414 M * Bushmills ok, after replacing truncated files against intact versions from the new guest allows me to start one of the borked guests again
1266536437 Q * micah Remote host closed the connection
1266536503 Q * imcsk8 Quit: Leaving
1266536741 M * Bertl Bushmills: what kernel was that (the one which might have borked your guests)?
1266536751 M * Bushmills 2.6.32
1266536763 M * Bushmills Linux verhau 2.6.32-trunk-vserver-amd64 #1 SMP Sun Jan 10 23:45:41 UTC 2010 x86_64 GNU/Linux
1266536768 M * Bushmills that's host
1266536777 M * Bertl debian kernel?
1266536783 M * Bushmills right. squeeze
1266536788 M * Bushmills stock kernel
1266536809 M * Bertl what led to the zero size files?
1266536824 M * Bushmills probably the fsck.ext3, from rescue system
1266536841 M * Bertl okay, why did you rescue boot/fsck?
1266536841 M * Bushmills it reported thousands of orphaned inodes which fsck would truncate
1266536860 M * Bushmills because reported file sizes didn't match anymore.
1266536881 M * Bushmills backup disk run out of space while it has same size as system disk 
1266536890 M * Bushmills well, mirror disk. not backup
1266536920 M * Bertl mirror means?
1266536926 M * Bushmills i run an rsync from time to time, with -avxH, and usually used space on mirror was about the same as system.
1266536936 M * Bushmills just a full duplicate of system disk.
1266536943 M * Bushmills not a backup because not incrementally saved
1266536961 M * Bertl you might want to add -S
1266536973 M * Bushmills and today, mirror needed about 300 gig more than it had
1266536987 M * Bertl and you did a clean reboot, then fsck?
1266537002 M * Bushmills right
1266537031 M * Bushmills i had hashify running from crontab before.
1266537052 M * Bushmills but the guests change very little, it was mostly the host i was busy with
1266537156 M * Bushmills most activity on host today wasn't related to vserver at all
1266537191 M * Bushmills i imported some 300 gig of data over internet, from another server, which is being phased out now.
1266537261 M * Bertl did you run a 2.6.26 debian kernel before on that machine?
1266537262 M * Bushmills it was then when I was done with that, and intended to duplicate the disk again, running rsync, that the target disc run out of space
1266537270 M * Bushmills no, never
1266537274 J * micah ~micah@micah.riseup.net
1266537277 M * Bushmills this is a fresh installation. 
1266537298 M * Bushmills i actually replaced the installation it came with against a new squeeze install
1266537404 M * Bushmills well,. not true. it came with lenny, and 2.6.26.  but there's zilch left of it now
1266537477 M * Bushmills i booted into a different system, and installed squeeze on the former lenny disk. including repartitioning
1266537519 M * Bushmills so in fact i did once, at the beginning, run it shortly with 2.6.26
1266537566 M * Bertl k, well, zero size files can have several causes