1361838597 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361838728 Q * anunnaki Read error: Connection reset by peer
1361838731 J * lua ~oo@28IAAA358.tor-irc.dnsbl.oftc.net
1361838794 Q * _urbee Ping timeout: 480 seconds
1361839243 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361839439 Q * lua Quit: '
1361839521 Q * urbee Ping timeout: 480 seconds
1361839525 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361839725 Q * _urbee Ping timeout: 480 seconds
1361839766 J * lua ~oo@9KCAAA1YW.tor-irc.dnsbl.oftc.net
1361839836 M * chrissbx| Is pm-hibernate safe with vserver?
1361839889 M * chrissbx| I just tried it and it works, except that X isn't properly active anymore
1361839923 M * chrissbx| just like when I switch to console and can't go back.
1361840312 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361840326 J * winuser b1104f5a@ircip3.mibbit.com
1361840348 M * winuser oh yeah
1361840385 M * winuser iam microsoft user
1361840411 Q * winuser 
1361840526 Q * urbee Ping timeout: 480 seconds
1361840600 M * chrissbx| I guess that's another reason to figure out how switching works.
1361840684 N * Bertl_zZ Bertl
1361840690 M * Bertl back now ...
1361840735 M * Bertl chrissbx|: this is because userspace switches console before hibernation to prevent graphic cards from messing up
1361840762 M * chrissbx| Aha makes sense
1361840808 M * chrissbx| Do you know which userspace tool induces this switch?
1361840834 M * Bertl most likely some kind of helper script
1361840861 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361840988 M * Bertl something in pm/sleep.d/*
1361841041 Q * _urbee Ping timeout: 480 seconds
1361841133 M * Bertl /usr/lib64/pm-utils/sleep.d/99video here seems to use chvt
1361841220 M * chrissbx| Thanks. Will look at the sources.
1361841242 M * chrissbx| Now going to bed.
1361841271 M * Bertl yeah, will head back to bed as well shortly ...
1361841339 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361841468 Q * urbee Ping timeout: 480 seconds
1361841626 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361841941 Q * _urbee Ping timeout: 480 seconds
1361842110 Q * urbee Ping timeout: 480 seconds
1361842114 Q * transacid Ping timeout: 480 seconds
1361842410 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361842739 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361842838 J * transacid ~transacid@transacid.de
1361843014 Q * _urbee Ping timeout: 480 seconds
1361843171 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361843440 Q * urbee Ping timeout: 480 seconds
1361843458 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361843653 Q * _urbee Ping timeout: 480 seconds
1361844299 Q * chrissbx| Ping timeout: 480 seconds
1361844352 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361844495 Q * _urbee Read error: Connection reset by peer
1361844533 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361844629 Q * urbee Ping timeout: 480 seconds
1361845154 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361845354 Q * _urbee Ping timeout: 480 seconds
1361845389 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361845635 Q * urbee Ping timeout: 480 seconds
1361845685 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361845715 M * Bertl okay, back to bed ... 
1361845721 N * Bertl Bertl_zZ
1361845995 Q * _urbee Ping timeout: 480 seconds
1361846343 Q * urbee Ping timeout: 480 seconds
1361846465 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361846470 J * clopez ~clopez@108.30.165.83.dynamic.mundo-r.com
1361846548 J * func ~oo@28IAAA390.tor-irc.dnsbl.oftc.net
1361846577 Q * func 
1361846841 Q * _urbee Read error: Connection reset by peer
1361846949 Q * lua Ping timeout: 480 seconds
1361847110 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361847414 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361847679 Q * urbee Read error: Connection reset by peer
1361847715 Q * _urbee Ping timeout: 480 seconds
1361847719 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361850886 Q * FireEgl Read error: Connection reset by peer
1361850892 J * urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361850999 Q * _urbee Ping timeout: 480 seconds
1361851444 J * _urbee ~urbee@93-103-199-233.dynamic.t-2.net
1361851724 Q * urbee Ping timeout: 480 seconds
1361851726 J * FireEgl FireEgl@2001:470:e5ad:1:45ed:32fb:9859:fcce
1361852589 Q * FireEgl Read error: Connection reset by peer
1361852622 Q * clopez Ping timeout: 480 seconds
1361853390 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com
1361860161 Q * transacid Remote host closed the connection
1361860495 J * transacid ~transacid@transacid.de
1361865267 J * Ghislain ~aqueos@adsl1.aqueos.com
1361866761 Q * nou Ping timeout: 480 seconds
1361868520 J * nou Chaton@causse.larzac.fr.eu.org
1361868998 J * nkukard_ ~nkukard@196-210-204-27.dynamic.isadsl.co.za
1361869145 Q * nkukard Ping timeout: 480 seconds
1361870015 J * BenG ~bengreen@cpc35-aztw23-2-0-cust207.18-1.cable.virginmedia.com
1361871820 M * disposab1e on my base server, i get 'no space left on device' when a program tries to save something into /tmp. when i run "df -h" tmpfs looks completely empty. How do i view how much space in tmpfs my vservers are currently consuming? I'd like to be able to identify which one to restart.
1361871838 N * disposab1e disposable
1361871851 N * Bertl_zZ Bertl
1361871855 M * Bertl morning folks!
1361871890 M * Bertl disposable: do you run df -h inside the guest?
1361871897 M * disposable your definition of morning seems to be very variable, but let's go with Good Morning now.
1361871908 M * disposable Bertl: i ran it on host.
1361871920 M * Bertl ah, so you won't see the guest's tmpfs
1361871941 M * disposable i have 50+ vservers. i can't go through all of them one by one
1361871943 M * Bertl you need to enter the guest namespace (or the guest) to check filesystems inside the guest space
1361871963 M * Bertl a simple loop would work
1361871984 M * Bertl i.e. enter guest mnt namespace (not the entire guest), run the df
1361872006 M * Bertl repeat that for each active guest (there are helper scripts for that in util-vserver)
1361872016 M * disposable how does one just enter guest mnt namespace? 
1361872040 M * Bertl with vnamespace
1361872123 M * disposable is there an easier way to get a list of current xids without using 'vserver-stat' and 'cut'
1361872134 M * Ghislain sudo vsomething vserver -- --running -- exec df -h
1361872150 M * Ghislain will list you the FS inside all running guest if that can help
1361872317 M * disposable Ghislain: that didn't return anything unfortunately. 
1361872596 M * daniel_hozac_ anything at all?
1361872656 N * daniel_hozac_ daniel_hozac
1361872696 M * disposable line feed
1361872747 M * disposable but i literally just copy pasted the line he wrote. vsomething doesn't exactly have a manual page
1361872832 M * disposable that's on util-vserver 0.30.216-pre2864-2+b1
1361872884 M * daniel_hozac do you have any running guests?
1361872916 M * Bertl works fine here (copy pasted)
1361873000 M * disposable daniel_hozac: a lot.
1361873050 M * disposable util-vserver is the version that came with debian squeeze (6.0)
1361873089 M * Bertl even shows the guest names in color on 0.30.216-pre3038
1361873621 M * Ghislain it works for me on 0.30.216-pre3038 with 3.2.21-vs2.3.2.10
1361873648 M * Ghislain try replacing running with all
1361873652 M * Ghislain --all
1361873876 M * disposable Ghislain: thank you. i've tried that already. with my ancient util-vserver it didn't work. but i've managed to get df -h to run with a simple for loop and "vserver exec"
1361874183 M * disposable i'm no closer to finding out where my tmpfs has gone. base server has 0% of tmp used and if i am to trust  "vserver -- $a exec df -h" from my loop, then none of my vservers use any of it either.
1361874266 M * Bertl well, maybe some badly designed software tries to create huge files in /tmp (inside the guest)
1361874282 M * daniel_hozac what about df -i?
1361874308 M * Bertl and as the default is 16M, it might easily run out of space and remove the file immediately after creating it
1361874551 M * disposable daniel_hozac: that looks like an iPhone version of df. they all show 1 used inode. 
1361874567 M * daniel_hozac what about /dev/shm?
1361874639 M * disposable Does overassigning tmpfs cause problems if vservers do not try to use it? i.e. my combined assignment of /tmp in all guests is over 7G but i only have 4G available.
1361874653 M * daniel_hozac no
1361874668 M * daniel_hozac you only have 4 GiB of RAM+swap?
1361874702 M * disposable i have 8G of ram on that server, 4 of which is tmpfs. and /dev/shm is also 0% used.
1361874708 M * disposable on the base server. 
1361874780 M * disposable each vserver is running pretty much just one daemon (asterisk), so there isn't much need for more ram.
1361874849 M * Bertl you have 4G of tmpfs on the host?
1361874892 M * disposable yes
1361874910 M * Bertl for what purpose?
1361874912 M * daniel_hozac half of RAM is the default for tmpfs.
1361874919 M * daniel_hozac if you don't specify size=
1361874924 M * Bertl really? nice
1361874928 M * disposable Bertl: what he said
1361875229 M * disposable looks like i will have to move the vserves elsewhere and restart the base server tonight.
1361875288 M * daniel_hozac might want to consider upgrading too.
1361875571 M * disposable daniel_hozac: i've given up on that yet. we really wanted to upgrade over christmas, which is why i asked for the single ip removal functionality in vserver kernel patches. unfortunately, the initial stability problems (lockups) have made us postopne upgrades indefinitely (for now).
1361875614 M * disposable s/i've/i haven't
1361877107 Q * Aiken Remote host closed the connection
1361877171 J * clopez ~clopez@108.30.165.83.dynamic.mundo-r.com
1361877278 J * urbee ~urbee@93-103-225-35.dynamic.t-2.net
1361877560 Q * _urbee Ping timeout: 480 seconds
1361880639 Q * BenG Quit: I Leave
1361881801 Q * ircuser-1 Ping timeout: 480 seconds
1361884473 Q * ensc Remote host closed the connection
1361884494 J * ensc ~irc-ensc@p54ADEF39.dip.t-dialin.net
1361887424 Q * tolkor Remote host closed the connection
1361888182 J * lua ~oo@659AAAZY1.tor-irc.dnsbl.oftc.net
1361888347 M * karasz disposable: vsomething df --all -- -- -h for old util-vserver
1361888394 M * karasz or maybe not :-/
1361890190 M * swenTjuln can someone guess what this kernel msg would mean? http://paste.linux-vserver.org/23327
1361890206 M * swenTjuln I get it when doing vserver <guest> enter
1361890224 M * swenTjuln oh...and it's deployed on AWS
1361891413 M * Bertl looks interesting, but I have no idea (yet) what it means
1361891429 M * Bertl could you try a recent kernel/patch and see if the issue remains?
1361891535 M * swenTjuln i'll try. Currently BenG's kernel is used
1361891542 M * daniel_hozac it's also tainted at that point, so could be anything.
1361891547 M * daniel_hozac what do you have before that?
1361891593 M * swenTjuln daniel_hozac: nothing relevant
1361891604 M * swenTjuln daniel_hozac: same error
1361891635 M * daniel_hozac same meaning it's also tainted?
1361891658 M * swenTjuln yup
1361891668 M * daniel_hozac so what tainted your kernel?
1361891732 M * Bertl 'G' is GPL module, 'D' is oops
1361891776 M * Bertl so, basically you want to go back till you find the first oops, but it might be the same as this one (or similar) just without the 'D'
1361891862 M * swenTjuln i can launch an instance for a few hours if you guys want to debug. Interested?
1361891907 M * Bertl first, let's see if it happens with a recent kernel/patch
1361891920 M * swenTjuln Bertl: understood 
1361891985 J * tolkor ~rj@tdream.lly.earlham.edu
1361892069 M * Bertl but google thinks that AWS and alignment checks coincide :)
1361892116 M * swenTjuln omg....maybe its Xen thing...
1361892119 P * swenTjuln Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is
1361892128 J * swenTjuln ~Marko@195.95.173.243
1361892150 M * swenTjuln wron shortcut :\
1361892162 M * Bertl maybe, maybe it is really a kernel problem, which just doesn't happen on typical archs
1361892442 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1361893413 J * func ~oo@659AAAZ24.tor-irc.dnsbl.oftc.net
1361893756 Q * lua Ping timeout: 480 seconds
1361894896 Q * func Ping timeout: 480 seconds
1361896102 J * aspp_lc ~aspp@ppp-225-158.24-151.libero.it
1361896129 M * aspp_lc !list
1361896310 Q * aspp_lc Quit: Sto andando via
1361897488 M * Bertl maybe we should put up a warez bot, which lists and serves the recent patches? :)
1361898285 J * bonbons ~bonbons@2001:a18:20a:1601:f5a1:863:7f75:35e3
1361898349 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1361899518 M * swenTjuln Bertl, daniel_hozac: with latest kernel/patch that error is no longer present
1361899600 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1361899710 M * Bertl okay, so I presume it was some kind of kernel issue, but got fixed upstream
1361899721 M * Bertl thanks for testing!
1361900640 J * BenG ~bengreen@212.183.128.19
1361901908 J * imcsk8 ~ichavero@148.229.1.11
1361902430 Q * BenG Ping timeout: 480 seconds
1361903351 Q * clopez Ping timeout: 480 seconds
1361903774 J * BenG ~bengreen@212.183.128.19
1361907457 J * dna ~dna@00012f5b.user.oftc.net
1361908386 Q * BenG Quit: I Leave
1361908402 J * BenG ~bengreen@212.183.128.19
1361908565 P * swenTjuln Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is
1361908575 J * swenTjuln ~Marko@195.95.173.243
1361908604 M * swenTjuln Bertl: I'm glad I can contribute
1361910093 Q * cuba33ci Read error: Connection reset by peer
1361910187 J * cuba33ci ~cuba33ci@114-36-239-30.dynamic.hinet.net
1361910523 J * clopez ~clopez@108.30.165.83.dynamic.mundo-r.com
1361914894 Q * BenG Quit: I Leave
1361915628 Q * clopez Ping timeout: 480 seconds
1361916234 J * clopez ~clopez@108.30.165.83.dynamic.mundo-r.com
1361917441 J * BenG ~bengreen@212.183.128.19
1361917821 Q * bonbons Quit: Leaving
1361918144 Q * hijacker_ Quit: Leaving
1361921302 Q * dna Quit: Verlassend