1256688179 J * tam_ ~tam@gw.nettam.com
1256688192 J * agaffney_ ~agaffney@71-81-81-131.dhcp.stls.mo.charter.com
1256688202 J * menomc ~amery@shell.opensde.net
1256688222 Q * jrdnyquist synthon.oftc.net charm.oftc.net
1256688222 Q * tam synthon.oftc.net charm.oftc.net
1256688222 Q * mugwump synthon.oftc.net charm.oftc.net
1256688222 Q * mnemoc synthon.oftc.net charm.oftc.net
1256688222 Q * agaffney synthon.oftc.net charm.oftc.net
1256688222 Q * mEDI_S synthon.oftc.net charm.oftc.net
1256688222 Q * gerrit synthon.oftc.net charm.oftc.net
1256688228 J * mugwump ~samv@watts.utsl.gen.nz
1256688251 M * jpic absolutely
1256688322 Q * FloodServ synthon.oftc.net services.oftc.net
1256688330 M * Bertl well, yeah, if the running services can do that, why not
1256688355 M * Bertl but I'd expect e.g. mail or databases to overwrite eachother
1256688431 M * jpic well that's the point, but wouldn't there be problems with pidfiles or unix sockets?
1256688566 M * Bertl again, that is something userspace has to sort out
1256688622 M * Bertl a pidfile is in no way different from any other file, and unix sockets are 'local' regardless of the medium
1256688647 J * FloodServ services@services.oftc.net
1256688879 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1256688983 J * mEDI_S ~medi@255.255.255.255.li
1256689020 J * gerrit ~gerrit@ionscale.com
1256689983 M * Bertl off to bed now .. have a good one everyone!
1256689988 N * Bertl Bertl_zZ
1256690045 Q * laurent Ping timeout: 480 seconds
1256690142 J * laurent ~laurent@AToulouse-157-1-24-187.w86-201.abo.wanadoo.fr
1256693757 Q * geb Quit: /
1256695085 N * tam_ tam
1256696614 J * uva bno@114-45-238-80.dynamic.hinet.net
1256697222 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1256701334 Q * scientes Ping timeout: 480 seconds
1256701448 J * agaffney ~agaffney@71-81-81-131.dhcp.stls.mo.charter.com
1256701467 Q * laurent synthon.oftc.net oxygen.oftc.net
1256701467 Q * jrdnyquist synthon.oftc.net oxygen.oftc.net
1256701467 Q * agaffney_ synthon.oftc.net oxygen.oftc.net
1256701471 J * scientes ~scientes@174-21-219-59.tukw.qwest.net
1256701608 J * laurent ~laurent@AToulouse-157-1-24-187.w86-201.abo.wanadoo.fr
1256702099 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1256702414 J * saulus_ ~saulus@d003030.adsl.hansenet.de
1256702823 Q * SauLus Ping timeout: 480 seconds
1256702830 N * saulus_ SauLus
1256702837 Q * scientes Remote host closed the connection
1256703623 J * scientes ~scientes@174-21-219-59.tukw.qwest.net
1256703650 Q * scientes Remote host closed the connection
1256704264 J * scientes ~scientes@174-21-219-59.tukw.qwest.net
1256705241 J * Piet_ ~piet@04ZAABTIB.tor-irc.dnsbl.oftc.net
1256705306 Q * Piet Remote host closed the connection
1256705332 N * Piet_ Piet
1256708303 Q * balbir_ Ping timeout: 480 seconds
1256709184 Q * AndrewLee Remote host closed the connection
1256709572 N * Bertl_zZ Bertl
1256709576 M * Bertl morning folks!
1256711104 J * sharkjaw ~gab@90.149.121.45
1256711388 J * balbir_ ~balbir@122.248.161.59
1256712120 J * AndrewLee ~andrew@u7.hlc.edu.tw
1256712968 J * kir ~kir@swsoft-msk-nat.sw.ru
1256715599 J * ghislainocfs2 ~Ghislain@adsl2.aqueos.com
1256716135 M * Bertl off for now ... bbl
1256716139 N * Bertl Bertl_oO
1256716257 J * scientes_ ~scientes@174-21-175-109.tukw.qwest.net
1256716412 N * laurent lau
1256716669 Q * scientes Ping timeout: 480 seconds
1256716895 J * friendly ~friendly@ppp118-209-136-134.lns20.mel6.internode.on.net
1256717565 J * scientes__ ~scientes@174-21-153-224.tukw.qwest.net
1256717814 J * yarihm ~yarihm@guest-docking-nat-2-109.ethz.ch
1256717859 Q * scientes_ Ping timeout: 480 seconds
1256719253 Q * balbir_ Ping timeout: 480 seconds
1256720325 J * balbir_ ~balbir@122.248.161.59
1256720405 Q * yarihm Quit: This computer has gone to sleep
1256722288 J * BWare ~itsme@ip-80-113-1-198.ip.prioritytelecom.net
1256724435 M * lau hi, the latest util-vserver version is util-vserver-0.30.215 ?
1256724569 M * lau i can find 0.30.216 in pre-release http://people.linux-vserver.org/~dhozac/t/uv-testing/
1256724584 M * lau but http://ftp.linux-vserver.org/pub/utils/util-vserver/ points to 0.30.215
1256724589 M * lau how does this work please ?
1256724751 M * ghislainocfs2 lau: do you run debian ?
1256724858 M * ghislainocfs2 lau: if so you have my debian packages of the utils in http://www.aqueos.com/debianpackages/ like allways i do not provide any moneyback if this does not fit for you ;p
1256724884 M * ghislainocfs2 lau: if not then just compile the sources
1256725011 M * Bertl_oO lau: simple, you get one of the pre-releases (preferably the latest one), configure, compile and install it
1256725141 M * lau ok
1256726605 Q * balbir_ Ping timeout: 480 seconds
1256726608 J * yarihm ~yarihm@guest-docking-nat-1-062.ethz.ch
1256727405 Q * friendly Quit: Leaving.
1256727828 J * balbir_ ~balbir@122.248.161.59
1256728972 Q * BWare Ping timeout: 480 seconds
1256729660 J * BWare ~itsme@ip-80-113-1-198.ip.prioritytelecom.net
1256729696 N * menomc mnemoc
1256731202 J * doener_ ~doener@i59F54D25.versanet.de
1256731306 Q * doener Ping timeout: 480 seconds
1256731366 J * geb ~geb@AOrleans-253-1-64-139.w92-140.abo.wanadoo.fr
1256731868 Q * geb Ping timeout: 480 seconds
1256731878 J * geb ~geb@earth.gebura.eu.org
1256732435 J * hparker ~hparker@65.171.118.206
1256732631 Q * agaffney Read error: Connection reset by peer
1256732675 J * agaffney ~agaffney@71-81-81-131.dhcp.stls.mo.charter.com
1256732740 Q * BWare Ping timeout: 480 seconds
1256733454 J * BWare ~itsme@ip-80-113-1-198.ip.prioritytelecom.net
1256733748 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1256733783 Q * thierryp Remote host closed the connection
1256735672 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1256737427 Q * mrfree Ping timeout: 480 seconds
1256738101 Q * yarihm Quit: This computer has gone to sleep
1256738391 Q * sharkjaw Quit: Leaving
1256738630 Q * balbir_ Ping timeout: 480 seconds
1256740429 Q * agaffney Read error: Connection reset by peer
1256740517 J * agaffney ~agaffney@71-81-81-131.dhcp.stls.mo.charter.com
1256740717 Q * jrdnyquist Quit: Leaving
1256740933 Q * blues_ Ping timeout: 480 seconds
1256743691 Q * urbee Ping timeout: 480 seconds
1256743743 J * urbee ~quoteS@193.77.180.211
1256746179 Q * uva Ping timeout: 480 seconds
1256746448 J * jrdnyquist ~jrdnyquis@slayer.caro.net
1256746853 M * geb hum
1256746872 M * geb i have a problem with a 2.6.29.6-grsec2.1.14-vs2.3.0.36.14
1256746928 M * geb i have a munin script witch count process (on the host) with
1256746929 M * geb find /proc -maxdepth 1 -name '[1-9]*' -print | wc -l | sed 's/\t +//' | sed 's/ *//'
1256746950 M * geb it only show host's process
1256746954 M * geb any idea ? :)
1256747023 M * geb hum, sorry i am a fool... i simply have to run it as root
1256747136 J * balbir_ ~balbir@122.172.20.230
1256748478 J * imcsk8 ~ichavero@189.135.86.13
1256748891 N * Bertl_oO Bertl
1256748895 M * Bertl back now ...
1256748952 M * Bertl geb: well, even as root it won't see guest processes, unless it runs the above commands in xid=1
1256749006 Q * imcsk8 Quit: This computer has gone to sleep
1256749459 J * kbad ~kyle@ip-66-33-206-8.dreamhost.com
1256749507 J * Thorsten ~Thorsten@dslb-084-058-163-167.pools.arcor-ip.net
1256749553 M * kbad are you planning on having the 2.4 release be for the 2.6.31.5 kernel?
1256749680 M * Bertl probably not, but we'll see how long 2.6.31.5 lasts :)
1256749684 M * Thorsten Hi *. I just upgraded to a new kernel together with a new vserver patch: 2.6.31.5-vs2.3.0.36.21  Everything seems to work fine, just one vserver can not be started: /usr/sbin/vspace --mount --fs --new -- /usr/sbin/vserver ----nonamespace leafnode start
1256749684 M * Thorsten vsysctl: open("."): Any idea which folder the . is?
1256749758 M * Thorsten Ah, I found something: ----Bui- leafnode
1256749768 M * Bertl most likely the guest root dir
1256749787 M * Thorsten all the other top level vserver folders have ----bui- leafnode2
1256749802 M * Bertl yep, there should be no barrier on the guest root dir
1256749836 M * Thorsten Is this relevant?  [ 4053.557989] vxW: [�vsysctl�,20086:#230|230|230] did hit the barrier.
1256749864 M * Bertl it is the appropriate warning, telling you that exactly this happened :)
1256749878 M * Bertl i.e. sysctl did hit the barrier (on the guest root)
1256750064 M * Thorsten I just did a setattr --~barrier /vservers/leafnode Is this supposed to fix it or do I have an underlying problem and this is just the symptom?
1256750255 M * Bertl well, depends on what you did to get to that barrier flag, are you using debian?
1256750319 M * Thorsten ja I use debian stable. Until yesterday with the included kernel which had this problems with mixed setattr file permission. Now a self compiled recent kernel
1256750348 M * Bertl okay, so you are switching from the known-broken 2.6.26 debian kernel to a recent one?
1256750485 M * Thorsten yes!
1256750486 M * Bertl in this case, you probably have to work your way through the filesystem, as both, barrier and CoW flags are likely to be messed up, your alternatives are: reboot in the old kernel, use daniel_hozac's tool to extract the attributes, then boot the new one and apply the extracted attributes ... or, alternatively, remove all barrier attributes recursively (from all guests), then break all potential CoW links and reunify them 
1256750537 M * Bertl a third option would be to detect potential CoW files (they should have a link in the hash store) and set the proper flags on them (still the barrier has to be fixed)
1256750587 M * Thorsten Ah I see. I would prefere to clean all barrier attributes recursively "setattr -R --~barrier /vservers/"?
1256750604 M * Thorsten How do I break all CoW links?
1256750610 M * Bertl given that your guests reside on /vservers that should work
1256750663 M * Bertl probably the easiest is to look for hard links (link count > 0), remove all CoW related attributes (setattr) and then re-unify/hashify your guests
1256750700 M * Thorsten Mmm, but I may also have normal hard links? Maybe rm -r .hash ?
1256750790 M * Bertl nah, that is the worst idea :)
1256750812 M * Bertl it will remove your hash, but leave the files with broken attributes :)
1256750814 M * geb Bertl, http://paste.linux-vserver.org/13585 , do you understand what is the problem ?
1256750854 M * geb i can't also use chxid -c 1 ps aux (but vps aux works)
1256750878 M * geb ( http://paste.linux-vserver.org/13586 )
1256750901 M * Bertl yes, I understand what the problem is :)
1256750924 M * Bertl you are using the wrong command, chxid changes the tagging on files
1256750980 M * Bertl (and it doesn't find any of the files 'find' '1' '[1-9]*' ... and refuses to work on /proc :)
1256751000 M * Thorsten ok, but if I remove the hash, all vhashify links are broken, if I than remve the attributes the next vashify shoud correct everything?
1256751035 M * geb <= fool
1256751036 M * geb ;)
1256751038 M * geb thanks
1256751056 M * Bertl the first part is correct, just that the previously hashified files will not be CoW tagged atm (because of the broken debian kernel) so, they won't get broken properly
1256751100 M * Bertl so, what you actually want, assuming that your hashstore is up-to-date is to set the CoW flags on all files in the hashstore
1256751175 M * Thorsten How do I set the Cow flags? Which ones are correct? setattr --?
1256751272 M * Thorsten I guess I should only set iunlink-but-not-immutable ?
1256751281 M * Bertl --iunlink is correct for now
1256751305 M * Bertl they should show up as -UI then
1256751752 M * Thorsten I great now I can start the vserver. But hashify fails?vserver leafnode hashify
1256751752 M * Thorsten Failed to initialize unification for vserver
1256751780 M * Bertl make sure that the requirements (see FAQ) for hashify are met
1256751820 M * Bertl http://linux-vserver.org/Frequently_Asked_Questions#How_do_I_manage_a_multi-guest_setup_with_vhashify.3F
1256751940 M * Thorsten You're right, the vunify was missing O:-) Now everything seems to work :-) Thx Bertl!
1256752183 M * Bertl you're welcome!
1256753981 J * imcsk8 ~ichavero@189.135.86.13
1256754010 Q * Thorsten Quit: Leaving
1256754796 Q * kir Quit: Leaving.
1256755311 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1256755654 Q * thierryp Remote host closed the connection
1256756207 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1256758975 M * Bertl hey bonbons, did you get around taking a look at the ipv6 issues?
1256759006 M * Bertl daniel_hozac: did you do some work on the network test scripts?
1256759024 M * bonbons Bertl: not yet, been busy with other issues
1256759038 M * Bertl k, np, just asking
1256759201 M * bonbons no problem, worst case I will have to look at it when I will plan update of my server's kernel, though I don't expect that before I get my SheevaPlug running (blocked with FS on it... shall be pure logging FS though nilfs currently freezes processes :( )
1256759287 M * Bertl interesting ... like pending I/O?
1256759429 M * bonbons well more or less, for some reason nilfs thinks there is nothing to do but tasks get blocked by block layer (I submitted a report to nilfs ML)
1256759466 M * bonbons they will have a look at once things have settled down after the Tokio meeting
1256759490 M * Bertl yeah, not much used yet ...
1256759577 M * bonbons though I'm putting hopes on it to get decent random write performance combined with clean recovery after power cut
1256759642 M * Bertl well, jffs2 looked quite promising too, but somehow dropped under the radar recently
1256759744 M * bonbons well I have jffs2 on the flash chip, but it requires a MTD device... can't work with block device (and there is no direct access to NAND chips on SD cards or USB pens)
1256759802 M * Bertl there is a mtd mapper for block devices, you know?
1256759821 M * bonbons there is? Didn't know
1256759844 M * Bertl yeah, I used that one to test the jffs2 modifications for OLPC
1256759859 M * Bertl the setup code should be in testfs.sh
1256759861 M * bonbons but drawback of jffs2 is that (for now) it's damn slow mounting big FSs 
1256759876 M * Bertl correct, and not the only drawback
1256759914 M * bonbons 500MB takes a few seconds so I expect it to take a good deal longer for 2GB-4GB FS (no counting the RAM usage that goes with it)
1256759942 M * Bertl yeah, it basically pulls in all inodes at mount time
1256759962 M * bonbons yep, that's how I understood it
1256760054 J * bakins ~bakins@157.166.167.129
1256760069 M * Bertl there also was logfs, IIRC
1256760125 M * bakins I was just wondering what versions are most people running on production systems?  I've been playing almost exlusively with 2.3.0.34 on 2.6.22.19
1256760220 M * Bertl it looks like most folks have switched to 2.6.27.x by now (or the broken 2.6.26 debian), but the trend seems to go to 2.6.31.x
1256760235 M * Bertl (at least from the folks hanging around here :)
1256760250 M * bonbons I think logfs still is (but with no much activity since sprintg)
1256760375 M * bonbons and things like ACL / XATTR / File CAPs are mostly TODO items on those FSs
1256760603 M * _are__ I use the broken debian-2.6.26, mostly because I have not run in troubles with it on the systems in question. If I run in any trouble it is the most recent kernel with the most recent patch
1256760643 M * _are__ 'it is' = 'I switch to', not to lead to a misinterpretation
1256760704 M * Bertl _are__: yeah, the kernel is fine for 'light' use, as long as you do not switch to or from a different kernel
1256760746 M * Bertl bonbons: do you need them?
1256760793 M * bonbons Bertl: ACLs, yes, XATTR/File CAPs less
1256760819 Q * imcsk8 Ping timeout: 480 seconds
1256760872 M * bonbons ACLs is to get things right e.g. on web-server so apache gets read access and I can still have right owner and group for rw access (all this without having world read access)
1256761030 M * Bertl can be done with unix user/group permissions, although it's a little more efford
1256761173 M * bonbons how would you do it with unix user/group perms (without having to play complicated games with parent directories)?
1256761267 M * bonbons anyhow, if xattr is available, adding ACL or File CAPs is easy as both are stored withing xattrs :)
1256761275 M * bakins Bertl: so most 2.6.27 is only for the experimental vserver??
1256761526 M * Bertl bakins: yes, there is no stable version for those kernels .. although we are on the edge to 'devel' :)
1256761544 M * bakins Bertl: but is considered "safe" for prod?
1256761560 M * Bertl define 'safe for production'
1256761636 M * bakins like large media company running all it's webservers on it safe?
1256761693 M * Bertl I think (some) 'large media companies' run all their webservers on Windows(tm), so that is really relative :)
1256761715 M * bakins Bertl: haha ;)
1256761740 M * bakins how about "would you bet your job on it" ;) (or in this case mine...
1256761778 M * bakins Bertl: it's just such a better fit performance wise for us than xen or kvm, as you can imagine
1256761791 M * Bertl no, but I wouldn't bet 'your job' on any software which cannot be mathematically proven (i.e. is larger than a few hundred lines :)
1256761832 M * Bertl but I use recent kernels for my own servers
1256761884 M * bakins I have had 0 issues with 2.6.22, but if it's not getting any attention, I'd ratehr run what everyone else is running
1256761920 M * bakins we do have one glitch in that we have a binary kernel modules (I know, not ideal, but long story) that I'm having to hack around. trying to get vendor to fix...
1256761939 M * Bertl 2.6.22.x is considered stable, updated will only happen when we find a major bug or security issue
1256762004 M * Bertl *updates
1256762033 M * Bertl binary only kernel modules are always problematic
1256762037 M * kbad Bertl: do you only include major vserver related security fixes or all 2.6.22.19 security fixes?
1256762080 M * Bertl kbad: the Linux-VServer patch is rebased to the latest kernel, so if there are new 2.6.22.x releases, the patch will be updated
1256762121 M * Bertl but I don't think 2.6.22 is maintained anymore
1256762147 M * Bertl 2.6.27.x is in long term maintainance atm, and we keep updated to that one too
1256762171 M * bakins Bertl: so only vserevr work is on experimental? 2.6.22 was last development one mentioned
1256762216 M * Bertl 2.6.22 development is obsolete, 2.6.22.x stable is the latest stable (for now)
1256762245 M * Bertl (basically due to major mainline changes which required major changes in Linux-VServer as well)
1256762275 M * bakins So a new "stable" will be ready when it's ready, I suppsoe?
1256762317 M * Bertl kind of, but stabilization has begun, soon resulting in a new devel patch, which after further stabilization willl lead to the upcoming 2.4 stable release
1256762355 M * Bertl as usual, contributions and donations will speed up the process
1256762397 Q * AndrewLee Quit: leaving
1256762516 M * bakins Bertl: getting my head wrapped around it still... 
1256762545 M * bakins I also saw that the libvirt thing stalled? has there been anymore discussion of that?
1256762689 M * Bertl well, we are not pursuing the libvirt integration, but AFAIK, patches have been submitted a long time ago
1256762715 M * Bertl maybe somebody wants to pick it up and bother the libvirt folks long enough that they add them
1256763003 M * kbad Bertl: yeah, 2.6.22.y stopped Feb. 07 iirc
1256763046 M * kbad 08
1256763549 Q * scientes__ Ping timeout: 480 seconds
1256764313 J * yarihm ~yarihm@77-58-27-192.dclient.hispeed.ch
1256765468 P * kbad 
1256767582 J * AndrewLee ~andrew@u7.hlc.edu.tw
1256767600 Q * bonbons Quit: Leaving
1256768028 Q * geb Quit: /
1256768503 Q * AndrewLee Quit: leaving
1256768544 J * AndrewLee ~andrew@u7.hlc.edu.tw
1256769344 J * mmouse ~mmouse@office.haefft-verlag.de
1256769447 Q * Piet Remote host closed the connection
1256770164 Q * bakins Quit: bakins
1256770252 J * Piet ~piet@04ZAABUBH.tor-irc.dnsbl.oftc.net
1256771024 J * thierryp ~thierry@lns-bzn-47f-62-147-212-202.adsl.proxad.net
1256771391 Q * yarihm Quit: This computer has gone to sleep
1256771851 Q * laptopnenolod Ping timeout: 480 seconds
1256771855 Q * ghislainocfs2 Ping timeout: 480 seconds
1256772232 Q * thierryp Remote host closed the connection
1256773195 Q * tokkee Ping timeout: 480 seconds
1256773726 Q * larsivi Ping timeout: 480 seconds