1324168500 Q * petzsch Quit: Leaving.
1324169037 Q * bonbons Quit: Leaving
1324185333 M * Bertl off to bed now ... have a good one everyone!
1324185339 N * Bertl Bertl_zZ
1324193089 J * kkable ~kkable@119.194.161.74
1324195526 Q * kkable Quit: 전 이만 갑니다.
1324197700 J * petzsch ~markus@p57B63C55.dip.t-dialin.net
1324199171 Q * petzsch Quit: Leaving.
1324199877 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1324200868 J * petzsch ~markus@p57B63C55.dip.t-dialin.net
1324202256 J * bonbons ~bonbons@2001:960:7ab:0:cc10:65ce:8813:2b18
1324205806 Q * Hunger Ping timeout: 480 seconds
1324205992 J * thierryp ~thierry@home.parmentelat.net
1324206403 Q * thierryp Remote host closed the connection
1324212580 Q * petzsch Quit: Leaving.
1324213380 J * petzsch ~markus@p57B63C55.dip.t-dialin.net
1324213766 Q * geos_one Read error: Connection reset by peer
1324213886 Q * Aiken Remote host closed the connection
1324214225 N * Bertl_zZ Bertl
1324214229 M * Bertl morning folks!
1324215501 J * thierryp ~thierry@home.parmentelat.net
1324217505 Q * thierryp Remote host closed the connection
1324223477 J * geos_one ~chatzilla@chello080109195117.4.graz.surfer.at
1324226528 Q * petzsch Quit: Leaving.
1324227144 Q * Wonka Ping timeout: 480 seconds
1324227256 J * hijacker_ ~hijacker@cable-84-43-136-96.mnet.bg
1324227265 J * hijacker__ ~hijacker@cable-84-43-136-96.mnet.bg
1324227269 Q * hijacker__ Remote host closed the connection
1324228054 J * petzsch ~markus@p57B63C55.dip.t-dialin.net
1324228574 J * Wonka produziert@chaos.in-kiel.de
1324229583 J * DarkSun ~ircap@45.99.60.213.static.mundo-r.com
1324229730 Q * DarkSun autokilled: This host violated network policy. If you feel an error has been made, please contact support@oftc.net, thanks. (2011-12-18 17:35:30)
1324230092 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1324234808 Q * geos_one Ping timeout: 480 seconds
1324237560 Q * petzsch Quit: Leaving.
1324240236 J * cuba33ci_ ~cuba33ci@114-36-229-64.dynamic.hinet.net
1324240315 Q * cuba33ci Read error: Operation timed out
1324240327 N * cuba33ci_ cuba33ci
1324240385 Q * hparker Quit: I've fallen off the 'net and can't get up
1324240417 J * petzsch ~markus@p57B6380E.dip.t-dialin.net
1324240751 J * maxigas ~user@mail.szervermegoldasok.hu
1324240764 M * maxigas how do i tell the cpu usage of a linux-vserver when i have only a rootshell *inside* the vserver?
1324240866 M * Mr_Smoke top ? uptime ?
1324240879 M * Mr_Smoke if your vserver has the VIRT_CPU flag, that should do the trick
1324241002 M * maxigas hm top looks the same inside and outside the vserver. is their disadvantage setting this VIRT_CPU flag?  
1324241029 M * Mr_Smoke not that I know of
1324241033 M * Mr_Smoke but you can't set it from the inside
1324241049 M * Mr_Smoke I would as the host admin to set it for you
1324241050 M * Bertl maxigas: kernel/patch/util-vserver version?
1324241059 M * maxigas i have a root on the host machine, i just phrased my question strangely. :)
1324241083 M * Mr_Smoke aaah.
1324241120 M * Mr_Smoke then you can use vserver-stat for that, I believe
1324241130 M * maxigas wow there are all these VIRT_ flags that look good.
1324241132 M * Mr_Smoke not vserver-stat though
1324241141 M * Mr_Smoke I'm thinking of something else
1324241149 M * Mr_Smoke that thing that munin uses
1324241169 M * Mr_Smoke /proc/virtual
1324241175 M * maxigas i need to be able to tell my vserver users how to measure their own resource usage, so they can conform to the limits i have set for them.
1324241194 M * Mr_Smoke ah
1324241201 M * maxigas this is why i want to know how to measure cpu, memory and disk usage from inside the vserver.
1324241212 M * Mr_Smoke well if you need that from within the vserver I'd go with VIRT_CPU and VIRT_MEM
1324241221 M * Mr_Smoke for disk, I always use LVM
1324241241 M * Mr_Smoke but Bertl was asking for your kernel version, he will have some useful stuff to say :)
1324241406 M * maxigas 2.6.32-5-vserver-amd64 / no patch / 0.30.216-pre2864-2+b1
1324241441 M * Bertl so a 2.6.32.x kernel, debian, unknown patch, yes?
1324241588 M * maxigas how do i find out about the patch?  are you asking if i applied some patch?  as far as i know i have not.
1324241621 M * Bertl I'd strongly advise to 'upgrade' to a more recent one, and also update util-vserver, the debian kernels are known to be broken and incomplete
1324241692 M * Bertl normally kernel contains the patch version in the name, e.g.
1324241693 M * Bertl # uname -r
1324241694 M * Bertl 3.1.4-vs2.3.2.1
1324241790 M * maxigas uname -r gives what i posted above.
1324241835 M * Bertl yep, which is indicative for broken debian kernels :)
1324241889 M * maxigas why is it broken?
1324241919 M * Bertl the debian folkes asked me (recently) to advise you to file a bug report against the kernel and util-vserver whenever you discover something not working as expected
1324242001 M * Bertl (showing the same inside as outside the guest with properly configured limits is considered a kernel bug)
1324242184 M * maxigas doesn't that depend on the VIRT_ flags?
1324242200 M * maxigas what do you call "properly configured limits"?
1324242246 M * Bertl well, limits which are actually effective, i.e. limiting the guest
1324242618 M * Bertl and yes, the VIRT_* flags control the 'virtualization' of certain values, currently in use are VXF_VIRT_MEM, VXF_VIRT_LOAD, VXF_VIRT_UPTIME and VXF_VIRT_TIME
1324242653 M * Bertl VXF_VIRT_CPU is not use since 2.6.24, it was replaced by cgroups isolation
1324242872 M * maxigas i just tried this in a vserver config dir: "echo VIRT_MEM > flags" and it worked.  at least "free"  shows a realistic memory usage now.
1324242977 M * maxigas nice.  i guess VIRT_LOAD is enough for me, i don't need VIRT_CPU.  what is the VXF_ prefix?  i am looking at this page which doesn not mention it: http://linux-vserver.org/Capabilities_and_Flags
1324243016 M * Bertl VXF means that it is a process context flag
1324243057 M * Bertl (compared to VXC = process context capability, NXF = network context flag ...)
1324243090 M * maxigas ah, i see.  but then i don't have to use it in the configuration, right?
1324243135 M * Bertl no, the config contains that information in the filename
1324243297 M * maxigas i understand.  thank you very much.  so i try to set these flags, see if they work, and if they don't make a difference i should file a bug with debian against their kernel packaging?
1324243447 Q * petzsch Quit: Leaving.
1324243486 J * geos_one ~chatzilla@chello080109195117.4.graz.surfer.at
1324243605 M * Bertl I guess that's what the debian folks had in mind
1324243683 M * Bertl in general, if you have problems, it is adviseable to test with a mainline kernel + Linux-VServer patch and recent util-vserver, if the issue persists, this channel is the place to report it/ask for help
1324243711 M * maxigas OK, thanks very much.
1324243751 M * Bertl np
1324244222 Q * sannes Remote host closed the connection
1324244929 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1324245376 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1324246818 Q * hijacker_ Quit: Leaving
1324248326 J * petzsch ~markus@p57B6380E.dip.t-dialin.net
1324248572 Q * petzsch 
1324248865 Q * bonbons Quit: Leaving
1324249223 J * petzsch ~markus@p57B6380E.dip.t-dialin.net
1324249249 M * Bertl daniel_hozac: ping?
1324249263 M * daniel_hozac Bertl: pong
1324249289 M * Bertl hey, I'm experiencing a strange behaviour with a guest and util-vserver pre3004
1324249320 M * Bertl I have an initialize script, and I wanted to disable the actions done there with 'exit 0' at the beginning
1324249354 M * Bertl (assuming that this would end and signal success, but the guest fails to start
1324249367 M * daniel_hozac make sure it's executable
1324249376 M * daniel_hozac otherwise exit 0 would end the start process
1324249447 N * ensc Guest20783
1324249457 J * ensc ~irc-ensc@p4FEC662A.dip.t-dialin.net
1324249473 M * Bertl ah, I see, so the scripts are sourced when not executeable?
1324249498 M * daniel_hozac right
1324249511 M * daniel_hozac so return 0 might work better too.
1324249518 M * Bertl understood, thanks!
1324249600 Q * chrissbx Ping timeout: 480 seconds
1324249866 Q * Guest20783 Ping timeout: 480 seconds
1324250486 J * chrissbx ~chrissbx@69-196-180-202.dsl.teksavvy.com