1282177865 Q * manana Read error: Connection reset by peer
1282177872 J * manana ~mayday090@84.17.25.149
1282177912 Q * pacholeq Read error: Connection reset by peer
1282180181 J * david_ ~david@d003176.adsl.hansenet.de
1282180473 M * david_ is there a repository for ubuntu 10.10 marvic that contains a kernel with linux-vserver? Something like linux-image-vserver?
1282181185 N * Bertl_zZ Bertl
1282181194 M * Bertl back now ..
1282187566 Q * Piet Ping timeout: 480 seconds
1282188168 J * Piet ~Piet__@28IAABFEX.tor-irc.dnsbl.oftc.net
1282189138 J * balbir_ ~balbir@122.167.250.37
1282189449 Q * zbyniu Ping timeout: 480 seconds
1282189818 J * zbyniu ~zbyniu@ip-62.181.188.13.static.crowley.pl
1282192549 Q * allquixotic Quit: Farewell!
1282194484 M * Bertl off to bed now ... have a good one everyone!
1282194490 N * Bertl Bertl_zZ
1282195443 J * mtg ~mtg@vollkornmail.dbk-nb.de
1282197934 J * ncopa ~ncopa@180.40.189.109.customer.cdi.no
1282197980 J * ard ~ard@gw-tweakb16.kwaak.net
1282198688 Q * derjohn_mob Ping timeout: 480 seconds
1282201686 J * ghislain ~AQUEOS@adsl2.aqueos.com
1282202562 J * petzsch ~markus@dslb-094-222-077-213.pools.arcor-ip.net
1282202839 J * derjohn_mob ~aj@213.238.45.2
1282203279 Q * balbir_ Ping timeout: 480 seconds
1282204074 J * ntrs ~ntrs@77.28.174.11
1282204543 J * balbir_ ~balbir@122.167.253.166
1282205520 J * kir ~kir@swsoft-msk-nat.sw.ru
1282206925 Q * mcp Remote host closed the connection
1282206988 J * mcp ~mcp@wolk-project.de
1282208194 J * petzsch1 ~markus@dslb-094-222-180-135.pools.arcor-ip.net
1282208539 Q * petzsch Ping timeout: 480 seconds
1282209595 N * DoberMann[ZZZzzz] DoberMann
1282210138 Q * arekm Quit: Changing server
1282210155 J * arekm arekm@carme.pld-linux.org
1282210329 Q * kir Quit: Leaving.
1282210968 M * david_ is there a 'linux-image-vsever' for ubuntu 10.10 marvic that contains a kernel with linux-vserver? Maybe a repo?
1282211201 M * pmjdebruijn probably not?
1282211206 M * pmjdebruijn most of us compile their own kernels
1282211609 M * Alteisen david_: http://www.linux-vserver.org/Installation_on_Ubuntu
1282212101 M * david_ Alteisen: ty, I had a look there, but the repo only supports up to lucid. No maverick yet.
1282212130 M * david_ Anyone in here named christoph lukas? (maintainer of the ubuntu vserver repo)
1282212389 Q * infowolfe Ping timeout: 480 seconds
1282212402 M * david_ which distribution is the recommended one for using vserver?
1282212465 M * pmjdebruijn david_: why were you interested in maverick in the first place? it's alpha?
1282212470 M * pmjdebruijn david_: why not lucid?
1282212484 M * pmjdebruijn anyhow we run it on debian lenny with our own 2.6.27.47 kernel
1282212533 M * david_ pmjdebruijn: I want to use btrfs, which is much improved in the current marvic
1282212556 M * pmjdebruijn david_: btrfs isn't production ready either
1282212560 M * Alteisen i would also suggest debian stable with own kernel (vanilla + vserver-patch)
1282212615 M * david_ I've had debian lenny for a while but lots of things didnt work on vservers and even the nfs always broke. So I wanted a more up to date os. 
1282212638 M * pmjdebruijn just don't use the shitty debian kernel
1282212648 M * pmjdebruijn anyhow
1282212649 M * Alteisen pmjdebruijn: :-)
1282212659 M * pmjdebruijn for a new setup I'd probably use Ubuntu Lucid with my own baked kernel
1282212665 M * pmjdebruijn or Debian Squeeze
1282212707 M * david_ your pretty sure its the kernel, hu? My last baked kernel is years ago. I had lots of problems using that kernel.
1282212744 M * david_ So I assume I again will break my system by building a broken kernel
1282213558 M * Alteisen david_: you will definitly break your system using development filesystems
1282213678 M * david_ Alteisen: btrfs is in developement, yes. And it is not aimed for production use, yet, yes! But since the fs and their problems are in the kernel I hope that its going to be improved with every new kernel and the bugs disappear instead that the bugs are on the harddisc. May I hope so?
1282213916 M * david_ When I build my own kernel, then 2.6.35.2 + vs2.3.0.36.31 is recommended or did I miss something?
1282214043 M * daniel_hozac filesystem corruption is to be expected for a development filesystem.
1282214175 M * Alteisen david_: yes, you may hope
1282214239 M * Alteisen but what is hope in a production environment? i guess that is not a good base to rely on.
1282214305 M * david_ Alteisen: this is my homeserver, so I can test for your production system ;)
1282214322 M * daniel_hozac a home server where you don't care about your data?
1282214322 M * david_ and of course I do regular backups
1282214334 M * david_ ^--
1282214481 M * Alteisen david_: at your home, you can do as you like
1282214866 Q * Piet Remote host closed the connection
1282214912 J * Piet ~Piet__@28IAABFUV.tor-irc.dnsbl.oftc.net
1282214965 Q * ntrs Ping timeout: 480 seconds
1282215176 J * mrkiko ~mrkiko@host153-105-dynamic.50-82-r.retail.telecomitalia.it
1282215189 M * mrkiko Hi all!
1282215233 M * mrkiko A queston/consideration - I'm a blind user (using brltty), which makes use of the TIOCSTI ioctl for some operations related to the braille terminal
1282215268 M * mrkiko and vserver doesn't allow my context 0 to use it I think (better, I can't use it in the "real" kernel)
1282215285 M * mrkiko Looking at the patch I noticed the change that disables it unless the context has some flags
1282215299 M * mrkiko but how can I set flags for the main kernel itself?
1282215337 M * mrkiko Or may I proceed simply modifying the intended line in tty_io.c?
1282215355 M * daniel_hozac that's only for changing those properties on a terminal that you are not on.
1282215367 M * daniel_hozac e.g. for changing it on tty4 if you are on tty5, which requires root.
1282215369 M * mrkiko infact
1282215371 M * mrkiko brltty uses them 
1282215386 M * mrkiko for transmitting "fake input" to the actual tty in which I am
1282215394 M * mrkiko (brltty is a Daemon)
1282215397 M * daniel_hozac that's a separate process that doesn't have the tty as the controlling tty?
1282215410 M * mrkiko yes
1282215425 M * daniel_hozac if it runs as root, then that check won't affect you anyways.
1282215436 M * mrkiko mhm
1282215443 M * mrkiko yes, it runs as root
1282215456 M * mrkiko I may look if the forked child of the process are root also
1282215478 M * mrkiko yes
1282215481 M * mrkiko they are running
1282215508 M * mrkiko sorry but it seems the check affects me looking at the source code, even if I'm not very competent in this materia
1282215792 M * daniel_hozac well, it really should be vx_capable(CAP_SYS_ADMIN, VXC_TIOCSTI) in any case.
1282216590 J * ktwilight ~keliew@91.176.89.182
1282216813 Q * ktwilight_ Ping timeout: 480 seconds
1282217467 M * mrkiko Now I'll look at the line again
1282217524 M * mrkiko daniel_hozac: so you suggest me trying change the line?
1282217537 M * mrkiko if it works I  would be happy sending some mails / patches
1282217594 M * daniel_hozac Bertl_zZ will probably wake up soon.
1282217636 M * mrkiko thank you
1282217657 M * mrkiko also because I noticed something I didn't read before
1282219701 N * Bertl_zZ Bertl
1282219705 M * Bertl morning folks!
1282219839 M * Bertl mrkiko: so, what's the problem/solution?
1282219916 Q * petzsch1 Quit: Leaving.
1282220627 M * mrkiko Bertl: ahaha
1282220646 M * mrkiko Bertl: no... the problem is the following - I use brltty (and a braille display to use my system)
1282220660 M * mrkiko BRLTTY is running in the MAIN context, the "treal" kernel
1282220671 M * Bertl okay
1282220674 M * ard were is vserver.13thfloor.at located?
1282220680 M * mrkiko brltty uses TIOCSTI
1282220705 M * mrkiko donation from mhm... I don't remember :)
1282220719 M * Bertl ard: us
1282220727 M * ard rose web services
1282220729 M * ard ah ok :-)
1282220761 M * mrkiko Bertl: and brltty uses that IOCTL to send fake input to terminals - it's very important for the correct behaviour of the device itself
1282220765 M * ard that's why the rtt is about 200ms
1282220774 M * mrkiko so I looked at the vserver patch
1282220784 Q * fLoo^ Ping timeout: 480 seconds
1282220790 J * fLoo^ fufu@188-194-120-232-dynip.superkabel.de
1282220797 M * mrkiko and saw the modifications introduced ... but at this point I'm not able to understand it all 
1282220813 A * ard thinks rose web hostings pipe is full
1282220828 M * Bertl well, daniel_hozac is right, it should be vx_capable() instead of the || check
1282220842 M * mrkiko yeah
1282220849 M * mrkiko so that's a bug...?
1282220892 M * Bertl kind of, but the question is, does this bug affect you or do you have a different need anyways
1282220925 M * Bertl the problem is, as you mentioned, the TIOCSTI is able to 'inject' characters
1282220927 M * mrkiko no no 
1282220933 M * mrkiko or well
1282220947 M * Bertl so, at some point, we considered it a security risk
1282220953 M * mrkiko the problem is only I can't use correctly my braille display with this situation
1282220975 M * Bertl because a guest could inject some characters, which get then execxuted on the host
1282221000 M * Bertl IIRC, daniel_hozac was working on a proper workaround in userspace for that (util-vserver wise)
1282221025 M * Bertl so the TIOCSTI check in the kernel was just a quick fix anyways
1282221025 M * mrkiko probably the right solution would be to disallow guests to do so ( I saw the related flags in the documentation), still allowing hosts processes to do it (is it possible?)
1282221035 M * mrkiko Bertl: ... oh - kepep in mind I'm a newbie :)
1282221058 M * Bertl np, looking at the code is the first step :)
1282221129 M * mrkiko then, knowing the risk: may I simply remove that check? Or I am going to "kill" the system ? 
1282221176 M * Bertl you can simply remove it, but you also can wait a minute and try a proper patch
1282221241 M * Bertl i.e. a delta which 'should' fix the issue for you too 
1282221349 M * mrkiko Bertl: oh - it was just to avoid disturbing; I love trying and overall learning
1282221360 M * mrkiko and, I don't disappreciate reading docs
1282221372 M * Bertl http://vserver.13thfloor.at/ExperimentalT/delta-tiocsti-fix01.diff
1282221392 M * Bertl this should do the 'right' thing ...
1282221481 M * mrkiko ok
1282221485 M * mrkiko trying
1282221488 M * Bertl i.e. you should get full TIOCSTI functionality on the host (as root) and you should be able to enable it with the context capability (VXC_TIOCSTI) in a guest
1282221504 M * mrkiko but it will take a lot - I can't read properly all 
1282221537 M * Bertl take your time, do you use a serial console btw?
1282221553 M * mrkiko no
1282221555 M * mrkiko a normal console
1282221570 M * Bertl with early brltty, I presume?
1282221579 M * mrkiko and the software (brltty) uses the serial port to communicate with the device
1282221594 M * mrkiko yes
1282221642 M * Bertl just curious, because most blind folks I know have switched to a reader which handles 'normal' ascii (maybe yours already does) and use them for serial console setups
1282221661 J * ntrs ~ntrs@77.28.174.11
1282221729 M * mrkiko mhm
1282221734 M * mrkiko bocal reader or braille display?
1282221746 M * mrkiko *vocal* reader
1282221757 M * mrkiko fix01.diff ok - does fix02.diff exist? (maybe I missed it )
1282221780 M * Bertl actually most use a simple braille reader which can buffer a certain amount of lines
1282221791 M * Bertl i.e. line oriented not vocal
1282221844 M * mrkiko mhm
1282221847 M * mrkiko Don't know
1282221858 M * mrkiko maybe because it requires less software support
1282221864 M * mrkiko but at least here in never heard of them
1282221868 M * Bertl anyway, was just my curiosity ...
1282221879 M * mrkiko some rquire minimal software assistance, but all of them require something being running
1282221894 M * mrkiko oh - I'mm curious also now :)
1282222028 M * mrkiko recompiling the kernel now after applying needed patches
1282222039 M * mrkiko I'm using 2.6.35.2 as now
1282222042 M * Bertl should take only a few minutes
1282222329 M * mrkiko i think so 
1282222410 M * Bertl hmm, I see there is a CONFIG_A11Y_BRAILLE_CONSOLE in the kernel
1282222436 M * Bertl but it seems to 'only' support the VisioBraille device for now
1282222475 M * mrkiko ahahah... ok 
1282222478 M * mrkiko Now I understdoo
1282222482 M * mrkiko *understood*
1282222540 M * mrkiko but still - the control it gives you is very very rudimental and aniway the buffering depends on the kernel console infrastructure
1282222564 M * mrkiko so it seems it's a viable way of proceeding for depserate situations
1282222620 M * Bertl well, probably the best way is to have a real serial console connected to another machine with whatever reader software required
1282222633 M * mrkiko can you tell me the meaning of <vservername>/interfaces/<intf>/dev ?
1282222654 M * mrkiko infact
1282222669 M * Bertl it is the 'interface device' which the address is to be assigned to/removed from
1282222688 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1282222702 M * Bertl i.e. if you specify e.g. 'eth0' there, then util-vserver will add the IP to eth0 on guest startup and remove it on guest shutdown
1282222731 M * mrkiko ok
1282222732 M * mrkiko perfect
1282222736 M * Bertl the alternative is 'nodev' which simply means 'do nothing' for util-vserver ...
1282222739 M * mrkiko I kexec and come back
1282222744 M * mrkiko thank you to be so helpful
1282222748 M * mrkiko never knew so helpful people
1282222749 Q * mrkiko Quit: leaving
1282222761 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1282222789 J * ntrs_ ~ntrs@77.29.199.167
1282222799 Q * hijacker Remote host closed the connection
1282222883 J * mrkiko ~mrkiko@host153-105-dynamic.50-82-r.retail.telecomitalia.it
1282222885 M * mrkiko ok
1282222887 J * hijacker ~hijacker@213.91.163.5
1282222888 M * mrkiko works fineeeee
1282222906 Q * Chlorek Quit: Reconnecting
1282222908 J * Chlorek cokolwiek@c.sed.pl
1282222972 M * Bertl mrkiko: excellent! thanks for testing!
1282223230 Q * ntrs Ping timeout: 480 seconds
1282223361 M * mrkiko I noted that for some reasons, even if I specify a device which doesn't have a link /i.e. - no cable inserted in the network card), my vserver is able aniway to communicate with the external world
1282223379 M * mrkiko I will study next days how this all work
1282223431 M * Bertl that is quite expected with default linux configs
1282223448 M * Bertl i.e. you will get the same behaviour with an unpatched kernel
1282223473 M * mrkiko oh - I'm using a vanilla+vserver kernel right now, to be clear
1282223534 Q * hijacker Remote host closed the connection
1282223564 M * Bertl yes, and if you leave out the Linux-VServer patch, you get the same behaviour :)
1282223593 M * mrkiko ah
1282223594 M * mrkiko ok
1282223609 M * Bertl i.e. an address assigned to eth0 doesn't per se mean that the packets will use eth0
1282223660 M * Bertl the simplest case you can test on the host system is to ping an address assigned to the host from another address assigned to the host (possibly on a different interface)
1282223684 M * Bertl you will see that all traffic there goes through 'lo' (check counters or use tcpdump)
1282223749 M * Bertl if you want to restrict traffic to certain interfaces, you have to use reverse path filter or iptables rules
1282223900 M * mrkiko ok ok ... I understood
1282223921 A * ard always says that the linux ipv4 stack is one big pile of ip addresses
1282223925 M * mrkiko the same goes when you estabblish a ppp connection
1282223933 M * mrkiko and you try to ping the public IP address you have , right?
1282223945 M * ard the only reason to put it on an interface is because then you also implicitly have the routing specified :-)
1282223990 M * Bertl actually the only reason is that you _have_ to put it somewhere :)
1282224016 A * ard always uses lo :-)
1282224031 M * Bertl lo is an interface too ...
1282224066 M * ard unfortunately ipv6 really does depend on which interface it is configured on, because else something basic like neighbour discovery doesn't work
1282224104 M * ard and it also doesn't support naming the ip addresses :-(
1282224111 M * Bertl in ipv6 everything is bigger^Hbetter :)
1282224112 J * hijacker ~hijacker@213.91.163.5
1282224138 M * ard http://miss-edina.kwaak.net/getsixxed.html :-)
1282224195 M * mrkiko ard: you use lo ad dev in the vserver so
1282224277 M * ard I echo lo > interface;echo <vservername> > name
1282224283 M * ard and echo 32 > mask
1282224285 M * ard :-)
1282224299 M * ard in the correct /etc/vservers/<*>/interfaces/<*> directory
1282224315 M * Bertl and using 'dev' instead of interface .... details
1282224322 M * ard if your server is not multihomed then it will always work
1282224330 M * ard sowwy :-(
1282224364 M * mrkiko a beautiful thing of vserver is that even if it isn't not completely documented, you can learn out of it a lot of things 
1282224404 M * Bertl it _is_ completely documented ... you have the source :)
1282224407 M * ard actually the incantation I use is something like vserver XX build  <stuff> --interface XX=lo:ip/32
1282224462 M * Bertl note that using /32 is not always the best idea, and xx= (creating an alias) is not really needed/useful nowadays
1282224515 M * ard it is: if you do ip a ls on the host you have a direct overview which ip belongs to which vserver
1282224554 M * ard thats about the only reason I use them...
1282224646 M * ard before I used vserver I never bothered naming my IP's. But thanks to vserver I've got a lot of ip's :-)
1282224659 M * Bertl grep . /etc/vservers/*/interfaces/*/ip
1282224711 M * ard that shows what is configured, but not what is actually running :-)
1282224730 M * Bertl that's what 'ip a' is for
1282224743 M * ard yes but now ip a gives me:
1282224747 M * ard     inet 10.54.29.40/32 scope global lo:sorry
1282224753 M * ard and 15 more :-)
1282224780 M * Bertl yeah, well, a simple script could provide that info as well
1282224785 M * ard correct :-)
1282224791 M * Bertl and also check for configured/missing IPs btw
1282224801 M * ard and in the case of network namespaces that I am now using, ip a doesn't tell anythging
1282224823 M * Bertl unless you enter the 'correct' namespace that is
1282224830 M * ard heh, I can't even find my vlans from the host namespace
1282225244 M * mrkiko oh oh
1282225258 A * mrkiko will document itself on how to use network namespaces with vserver
1282225535 M * mrkiko does vserver use PID namespaces? I can't tell it right now since the only duplicate PID is init, but probably it's an exception
1282225564 M * ard you can enable the namespaces you want
1282225568 M * ard except 1
1282225572 M * ard dunno which one
1282225598 M * mrkiko "enable" -> in the kernel?
1282225610 M * ard no, just configure in /etc/vservers/*/spaces
1282225610 M * daniel_hozac PID namespaces are not yet used.
1282225629 M * daniel_hozac or supported.
1282225635 M * mrkiko ah ok 
1282225639 M * Bertl pid isolation is the way it works atm
1282225653 A * ard thinks that's the best way to go
1282225717 M * mrkiko I saw vserver around at least 10 years ... but still - why isn't it accepted in the main kernel? (hoping not to boot a flameware :D )
1282225776 M * Bertl mainly because mainline didn't want isolation/jails till recent year(s)
1282225814 M * Bertl and once isolation became part of the virtualization hype, mainline started doing their own thing
1282225836 M * Bertl we are using most of it (as long as it works as expected)
1282226098 M * Bertl so basically the answer to your question is: for political reasons :)
1282226219 Q * mtg Quit: Verlassend
1282226300 Q * david_ Quit: Lost terminal
1282226560 M * mrkiko :)
1282226573 M * mrkiko Bertl: one day it would be beautiful
1282226586 N * biz_ biz
1282226613 M * Bertl one day, Linux-VServer will be obsolete, till then, we'll provide the best solution around :)
1282226725 M * Chlorek one day linux and computers will be obsolete and we will back into the wilderness
1282226735 M * biz Hello Bertl, I've just read about process state "H" being your creation: http://www.mail-archive.com/vserver@list.linux-vserver.org/msg01858.html :-)
1282226765 M * biz I've encountered a problem where nginx workers enter this state, while no hardlimits are set for the guest: http://nginx.org/pipermail/nginx/2010-June/020834.html
1282226768 M * Bertl biz: do you see it with a recent kernel?
1282226800 M * biz Bertl: using patch-2.6.32.9-vs2.3.0.36.29.2-grsec2.1.14-20100312.diff
1282226815 M * biz (see the reply/analysis of Igor Sysoev)
1282226848 M * Bertl give me a second to check
1282226903 M * biz take your time, the report is 2 months old ;)
1282226915 A * biz didn't have time to investigate further
1282226935 M * daniel_hozac have you tried without grsec?
1282226940 M * daniel_hozac is it reproducible?
1282226965 M * biz it's very hard to reproduce (see bug report), and no... did not test it without grsec
1282227023 M * harry that's always the best thing to do first...
1282227058 M * harry grsec is a huge patch, so is vserver... (well, they are 60/40... sort of)
1282227079 M * harry so it would be easiest to isolate in which of the 2 the problem resides
1282227089 M * harry makes bugtracking so much easier ;)
1282227215 M * biz I can do it in the next few days if there is not something "obvious" which is revealed by the reply of Igor
1282227292 M * ard Hmmm, are there dlimit accounting problems in vs2.3.0.36.30.4?
1282227311 M * ard as in: It increases, but it doesn't seem to decrease enough
1282227359 Q * hijacker Quit: Leaving
1282227446 M * Bertl biz: yep, the 'H' is a bug in the 2.6.32 Linux-VServer patch
1282227469 M * biz :-)
1282227485 M * Bertl it actually means that the task is a zombie
1282227524 M * Bertl i.e. it is a wrong information, but nothing which would affect behaviour
1282227561 M * biz ok, I suspected that because it doesn't react on anything besides SIGKILL (and nginx has signal handlers registered)
1282227714 M * Bertl i.e. it is shifted, 'H' means zombie (Z) and 'Z' means dead (X)
1282227834 M * biz uhm... so does this shifted state affect anything in regards to further signal delivery? (i.e. is it really a nginx bug?)
1282227871 M * Bertl it shouldn't affect anything but tools which look at /proc output to show the state of a process
1282227957 M * ard Weird: vdlimit says space_used is 9562020 and df shows 38G in use
1282227960 M * biz well, having a "H" process in ps output then means it actually is "Z" which means it would be a nginx bug?
1282228016 M * Bertl guess so, but I'll upload a patch to correct this shortly
1282228050 M * Bertl so you can re-test, but I'd also advise to test without grsec, as it might be the cause for blocked signals
1282228145 J * hijacker ~hijacker@213.91.163.5
1282228219 M * biz Bertl: ok just give me a link to the patch.. I'll first test without grsec and if it's gone I'll retest with grsec (if harry can integrate the change)
1282228253 M * Bertl http://vserver.13thfloor.at/ExperimentalT/delta-tstate-fix01.diff
1282228330 M * biz thanks
1282228376 M * Bertl you're welcome!
1282228674 M * ard cool
1282228692 M * ard deletes are added to the dlimits instead of subtracted in the following case:
1282228707 M * ard create some large file
1282228712 M * ard then:
1282228713 M * ard test1:~# sleep 50 < /extra/test160m 
1282228732 M * ard then: rm test160m
1282228749 M * ard at the moment of the rm, space_used increases with X blocks
1282228762 M * Bertl is the file created inside the guest?
1282228765 M * ard yes
1282228777 M * ard I check with vdlimit
1282228781 M * Bertl so it was accounted once when you created it (correctly)?
1282228825 M * ard before: space_used=181216 after creation: space_used=345540, after deletion: space_used=508904, and now the sleep has finished: space_used=345060
1282228848 M * Bertl interesting ...
1282228859 M * ard :-)
1282228882 M * ard 2.6.33.6-vs2.3.0.36.30.4-d64-i7
1282228884 M * Bertl could you strace -fF it for me please?
1282228898 M * ard the rm?
1282228908 M * Bertl both, the sleep and the rm
1282229026 M * ard http://paste.linux-vserver.org/16613
1282229044 M * daniel_hozac Bertl: does ext4 not have tagging?
1282229051 M * daniel_hozac or is tagging missing in some kernels?
1282229064 M * Bertl recent kernels should have ext4 tagging
1282229085 M * ard heh, it is an ext4 partition :-)
1282229097 M * daniel_hozac i'm on an old 2.6.34 kernel... i guess i should upgrade :-)
1282229105 M * ard heheh
1282229112 A * ard uses 2.6.33.6
1282229117 A * ard wants to go 2.6.35.2
1282229127 M * Bertl daniel_hozac: yeah, that would be a good idea, but what issue exactly are you observing?
1282229128 M * ard bnx2+bonding means immenent MII death
1282229147 M * daniel_hozac i was just trying to test this, but mounting with tag doesn't appear to actually mount with tag.
1282229165 M * Bertl what does testfs report?
1282229186 M * ard well, lsxid works on 2.6.33.6 and I skipped the 2.6.34 versions ;-)
1282229410 J * petzsch ~markus@dslb-094-222-180-135.pools.arcor-ip.net
1282229662 M * Hollow hey folks! i have to reboot the server with the website/ftp/etc to update the kernel
1282229670 M * Hollow should be a matter of some minutes
1282229675 M * daniel_hozac cool
1282229679 M * Bertl hopefully to 2.6.35.2 ?
1282229708 M * Hollow nope, 2.6.33
1282229717 M * Bertl eek, you sure about that?
1282229767 M * Hollow yep, why?
1282229784 M * Bertl because IMHO it is quite broken, especially regarding I/O
1282229790 M * Hollow vserver-stat is not working, even with cgroups, and all the new cgroup stuff needs to be tested before i use it in production
1282229822 M * Hollow well, i have it running on about 50 machines, and it's working quite well :)
1282229834 M * daniel_hozac vserver-stat works fine here.
1282229922 M * Hollow # vserver-stat 
1282229922 M * Hollow open(memory.usage_in_bytes): No such file or directory
1282229922 M * Hollow open(memory.usage_in_bytes): No such file or directory
1282229922 M * Hollow CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
1282229927 M * Hollow oops, 4 lines ;)
1282229940 M * daniel_hozac well
1282229940 M * Bertl omg. omg. 5 lines in total!
1282229955 M * daniel_hozac your initscripts probably aren't correct.
1282229962 M * daniel_hozac or, you haven't reexecuted them since the upgrade.
1282229970 M * Hollow i have, just now
1282229973 M * Hollow but maybe they are wrong
1282229976 M * daniel_hozac then the former :-)
1282230126 M * Hollow daniel_hozac: do you know what's causing the error? i think you added the cgroup stuff to the gentoo init script
1282230135 M * daniel_hozac well
1282230138 M * daniel_hozac do you have /dev/cgroup?
1282230148 M * daniel_hozac do you have the memory controller in your kernel?
1282230153 J * dna ~dna@dslb-094-222-120-121.pools.arcor-ip.net
1282230154 M * daniel_hozac what does vserver-info say?
1282230171 M * daniel_hozac also, which pre release are you running?
1282230230 M * daniel_hozac note, util-vserver is the initscript you care about here.
1282230254 M * Hollow daniel_hozac: yes, i have /dev/cgroup, even a memory.usage_in_bytes entry, i have 0.30.216_pre2906 running
1282230262 M * daniel_hozac you need 2910
1282230275 M * Hollow ah, good to know
1282230276 M * Hollow :)
1282230315 M * daniel_hozac 2910 + util-vserver start + restart of guests should do the trick.
1282230325 A * ard is going to do some zumba so see you later (in case bertl was asking more info ;-) )
1282230341 M * Bertl ard: nah, thanks for now ...
1282230343 M * Hollow ok, i will try that on my local test machine, and then maybe 2.6.35 can be used on the lv host ;)
1282230354 M * Bertl 2.6.35.2 please
1282230358 M * Hollow ok
1282230388 M * _Shiva_ Bertl: 2.6.35.2 has some regressions...
1282230403 M * Bertl some essential fixes :)
1282230437 M * _Shiva_ Bertl: https://bugzilla.kernel.org/show_bug.cgi?id=16588 
1282230461 M * Hollow we'll have IPv6 after the reboot btw, if anyone wants the mirror to have IPv6
1282230535 M * _Shiva_ Hollow: will you bump the vserver-utils ebuild in the main portage tree to pre2910, too?
1282230579 M * Hollow _Shiva_: most likely ;)
1282230623 M * _Shiva_ Hollow: rename the ebuild-file is enough to bump ;-) at least it was in my local overlay ;-)
1282230954 M * Bertl well, it won't hurt to add the patch proposed by Linus
1282231215 M * Bertl Hollow: but if you give me a few minutes, I should have a patch for 2.6.36-rc1 ...
1282231317 Q * ntrs_ Read error: Connection reset by peer
1282231339 J * ntrs_ ~ntrs@77.28.164.41
1282231368 M * Hollow Bertl: ok
1282232779 Q * dna Read error: Connection reset by peer
1282232801 J * dna ~dna@dslb-094-222-120-121.pools.arcor-ip.net
1282232990 J * dna_ ~dna@dslb-094-222-208-124.pools.arcor-ip.net
1282232991 Q * derjohn_mob Ping timeout: 480 seconds
1282233282 Q * dna Ping timeout: 480 seconds
1282233855 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1282233958 M * Guy- is there a way to start a vserver guest ioniced?
1282233990 M * daniel_hozac /etc/vservers/<guest>/ionice/{class,priority}
1282234000 M * Guy- ah, I missed that
1282234007 M * Guy- great, thanks
1282234022 M * Bertl just add or remove charged particles :)
1282234030 M * Guy- :D
1282234714 Q * balbir_ Ping timeout: 480 seconds
1282235247 J * dna__ ~dna@dslb-088-074-204-052.pools.arcor-ip.net
1282235247 Q * dna_ Read error: Connection reset by peer
1282235258 J * balbir_ ~balbir@122.172.33.242
1282236227 Q * manana Remote host closed the connection
1282237536 M * Hollow Bertl: do you think 2.6.36-rc1 is usable for production or should i use the patch from linus with 2.6.35.2?
1282237582 M * Bertl hard to tell, the 2.6.35 is running fine here for some while
1282237595 M * Bertl the 2.6.36-rc1 is really fresh
1282237639 M * Bertl the patch is test compiling right now
1282237673 M * Hollow ok, i can test it on my local machine of course, but for production i'll stick to 2.6.35 then
1282237684 M * Bertl okay, np
1282239800 J * imcsk8 ~ichavero@evdomip-27-70.iusacell.net
1282241530 Q * imcsk8 Quit: This computer has gone to sleep
1282241544 J * geos_one ~chatzilla@chello084115149052.4.graz.surfer.at
1282241859 M * Hollow Bertl, daniel_hozac: 2.6.35.3-rc1-vs2.3.0.36.31 with pre2910 works now, thanks
1282241881 M * Bertl great!
1282241891 M * Hollow _Shiva_: i'll commit pre2910, but i'll wait for 2.6.35.3 before updating the kernel ebuild
1282242008 M * Hollow Bertl: when the patch for 2.6.36 is ready give me a note, i'll give it a try too
1282242264 M * Bertl okay, currently fixing up the virt time stuff
1282242279 M * Bertl rest looks already promising ...
1282242313 M * Bertl I might even do a pre without the virt time, if you got some time to test (right now)?
1282242365 M * Hollow ok
1282242457 M * trippeh_ Bertl: Hey, noticed a bunch of radeon stuff got mixed in the 2.6.35.2 patch in Experimental
1282242485 M * trippeh_ Some kbuild autogenerated files I presume
1282242515 M * Bertl interesting, but possible ... i.e. the cleanup scripts might not get all
1282242549 M * Bertl got a list which files those are?
1282242677 M * Bertl daniel_hozac: I see 203 and 223 fail on ext4 (with recent kernel) but it reports the tag option at mount
1282242843 M * Hollow Bertl: btw, there is no support for IPv6 lback remap, or am i missing something?
1282243104 M * ard Bertl : 2.6.35.2-vs2.3.0.36.31-d64-i7 doesn't have the vdlimit leak
1282243112 M * ard at least not in my testcase ;-)
1282243144 J * imcsk8 ~ichavero@201.174.32.227
1282243148 M * daniel_hozac Hollow: nope.
1282243195 M * ard The http://vserver.13thfloor.at/Experimental/delta-tiocsti-fix01.diff is used to help with vserver ... enter?
1282243204 M * ard or is it some other problem it fixes?
1282243499 M * Bertl it fixes a host issue
1282243615 M * Bertl trippeh_: seems make mrproper misses those
1282243752 M * trippeh_ drivers/gpu/drm/radeon/*_reg_safe.h ;)
1282243776 M * ard pff... the amount of kernelthreads....
1282243781 M * ard root      5934  0.0  0.0      0     0 ?        S    20:46   0:00  \_ [flush-9:2]
1282243781 M * ard root         1  0.6  0.0  10384   736 ?        Ss   20:33   0:06 init [2]  
1282243788 M * ard thats from a ps faux...
1282243825 M * ard 320 kernel threads
1282243847 M * Bertl yeah, about one for each device or so :)
1282243864 M * ard and processor :-)
1282243873 M * ard Dell R610 blade
1282243928 Q * ncopa Remote host closed the connection
1282243936 M * ard (I mean 16 threads per device :-) )
1282243957 M * Bertl Hollow: http://vserver.13thfloor.at/ExperimentalT/patch-2.6.36-rc1-vs2.3.0.36.32-pre1.diff
1282244054 M * Bertl reiserfs seems to cause a bug trace .. but I'm not sure if that isn't mainline related :)
1282244124 M * Bertl hmm, seems we got a config.tmp now as well 
1282244401 J * ntrs__ ~ntrs@77.28.167.0
1282244699 M * Hollow Bertl: compiling now ... will reboot the lv host meanwhile
1282244834 Q * ntrs_ Ping timeout: 480 seconds
1282245220 M * Hollow ok, looks like everything is back up
1282245262 M * Bertl great! thanks!
1282245537 M * Hollow ah, damn .. i forgot to enable the memory cgroups
1282245539 M * Hollow d'oh ;)
1282245889 Q * geos_one Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100818131223]
1282245933 J * hijacker_ ~hijacker@87-126-142-51.btc-net.bg
1282247218 M * Hollow Bertl: reiserfs oopsed, everything else passed the tests
1282247260 M * Bertl yeah, I have to try reiserfs without the Linux-VServer patch
1282248721 J * derjohn_mob ~aj@d046217.adsl.hansenet.de
1282251486 Q * bonbons Quit: Leaving
1282251771 Q * dna__ Quit: Verlassend
1282252595 Q * hijacker_ Quit: Leaving
1282253690 Q * petzsch Quit: Leaving.
1282255094 Q * ntrs__ Ping timeout: 480 seconds
1282255224 Q * FireEgl Read error: Connection reset by peer
1282255947 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com
1282257257 Q * ghislain Quit: Leaving.
1282258721 J * petzsch ~markus@dslb-094-222-180-135.pools.arcor-ip.net
1282259244 Q * micah Remote host closed the connection
1282259544 Q * dannf Ping timeout: 480 seconds
1282259629 J * dannf ~dannf@utter.lackof.org
1282259797 J * micah ~micah@micah.riseup.net
1282260196 Q * petzsch Read error: Connection reset by peer
1282260990 J * BenG ~bengreen@cpc6-aztw22-2-0-cust100.aztw.cable.virginmedia.com
1282261045 Q * BenG 
1282261576 J * infowolfe ~infowolfe@c-67-166-127-67.hsd1.ut.comcast.net
1282262065 J * bma_ ~bma@thunderkeys.net
1282262069 Q * Guest123 Read error: Operation timed out
1282262073 J * Snow-Man_ ~sfrost@tamriel.snowman.net
1282262096 N * bma_ Guest183
1282262190 Q * Snow-Man Ping timeout: 480 seconds