1190073778 M * Bertl_oO mstrobert: just means you have a quite old kernel and old tools using dynamic context (e.g. typical for older debian setups) updating and/or assigning a proper context number should fix that
1190075911 J * virtuoso_ ~s0t0na@ppp91-122-24-164.pppoe.avangard-dsl.ru
1190076322 Q * virtuoso Ping timeout: 480 seconds
1190077113 Q * coderanger_ Quit: coderanger_
1190077729 Q * Piet Remote host closed the connection
1190077827 J * Piet ~piet@tor.noreply.org
1190078328 Q * Piet Quit: Piet
1190078445 Q * zLinux Remote host closed the connection
1190080131 Q * roym Ping timeout: 480 seconds
1190080293 Q * morten Ping timeout: 480 seconds
1190080431 Q * nox Ping timeout: 480 seconds
1190080468 Q * Loki|muh Ping timeout: 480 seconds
1190080487 J * morten ~morten@213-133-125-57.clients.your-server.de
1190080490 J * Loki|muh loki@satanix.de
1190080675 J * nox ~nox@static.88-198-17-175.clients.your-server.de
1190080910 J * coderanger_ ~coderange@c-65-96-210-168.hsd1.ma.comcast.net
1190081075 J * n01101111x ~nox@static.88-198-17-175.clients.your-server.de
1190081158 Q * nox Remote host closed the connection
1190081158 N * n01101111x nox
1190081167 Q * bzed Ping timeout: 480 seconds
1190081726 M * Bertl_oO off to bed now ... have a good one!
1190081730 N * Bertl_oO Bertl_zZ
1190082207 Q * arachnist Ping timeout: 480 seconds
1190082498 Q * quasisane Read error: Connection reset by peer
1190082626 J * quasisane ~user@c-76-118-191-64.hsd1.nh.comcast.net
1190082817 Q * quasisane Read error: Connection reset by peer
1190084281 J * quasisane ~sanep@c-76-118-191-64.hsd1.nh.comcast.net
1190084550 Q * hparker resistance.oftc.net oxygen.oftc.net
1190084550 Q * tzafrir resistance.oftc.net oxygen.oftc.net
1190084550 Q * Supaplex resistance.oftc.net oxygen.oftc.net
1190084552 J * hparker ~hparker@linux.homershut.net
1190084552 J * tzafrir ~tzafrir@62.90.10.53
1190084552 J * Supaplex ~e@166-70-62-194.ip.xmission.com
1190084823 Q * Supaplex resistance.oftc.net oxygen.oftc.net
1190084823 Q * tzafrir resistance.oftc.net oxygen.oftc.net
1190084823 Q * hparker resistance.oftc.net oxygen.oftc.net
1190084841 J * hparker ~hparker@linux.homershut.net
1190084841 J * tzafrir ~tzafrir@62.90.10.53
1190084841 J * Supaplex ~e@166-70-62-194.ip.xmission.com
1190087696 J * micah_ ~micah@micah.riseup.net
1190087765 Q * micah Read error: Connection reset by peer
1190088113 Q * micah_ Read error: Connection reset by peer
1190088114 J * micah ~micah@micah.riseup.net
1190088439 J * Ashsong ~mstone@teach.laptop.org
1190088456 M * Ashsong Bertl_zZ: ping
1190088498 M * Ashsong when you wake up, I have a fun bug for you. see http://paste.lisp.org/display/47876
1190088531 M * Ashsong The upshot is that rsync onto a 'setattr --iunlink' hardlink on JFFS2 does not preserve group id.
1190088536 M * Ashsong Not sure why yet.
1190088548 M * Ashsong Anyway, I'll talk to you tomorrow.
1190088651 Q * ensc Remote host closed the connection
1190092121 M * daniel_hozac Ashsong: the second rsync doesn't do anything here.
1190092132 M * daniel_hozac which is to be expected, as there are no differences.
1190093795 Q * hparker Quit: g'nite
1190093921 Q * besonen_mobile Ping timeout: 480 seconds
1190094174 J * besonen_mobile ~besonen_m@71-220-234-148.eugn.qwest.net
1190097113 J * sharkjaw ~gab@158.36.44.106
1190097228 J * dna ~dna@86-227-dsl.kielnet.net
1190098897 J * arachnist arachnist@088156185052.who.vectranet.pl
1190099145 Q * sharkjaw Remote host closed the connection
1190099233 J * sharkjaw ~gab@158.36.44.106
1190099366 Q * sharkjaw Remote host closed the connection
1190099419 J * sharkjaw ~gab@158.36.44.106
1190101428 J * friendly12345 ~friendly@ppp121-44-239-215.lns2.mel4.internode.on.net
1190101440 J * gcj ~chris@cpc1-cmbg7-0-0-cust497.cmbg.cable.ntl.com
1190101856 Q * phreak`` Ping timeout: 480 seconds
1190101869 Q * Hollow Ping timeout: 480 seconds
1190102267 J * Hollow ~hollow@proteus.croup.de
1190102276 J * meebey meebey@booster.qnetp.net
1190102301 Q * nanonyme Quit: leaving
1190102483 J * phreak`` ~phreak``@deimos.barfoo.org
1190103080 J * bzed ~bzed@devel.recluse.de
1190103718 N * Bertl_zZ Bertl
1190103721 M * Bertl morning folks!
1190104371 M * Bertl Ashsong: pong?
1190104414 M * Bertl Ashsong: judging from the fact that you contact me, I assume the 'bug' is not that rsync does something wrong here, but more that rsync tries? to set the gid, but somehow fails, yes?
1190104511 M * Bertl Ashsong: if so, can we extract the commands which lead to this misbehaviour, and try to trigger it with a few simple chown/chgrp or so?
1190105408 J * DavidS ~david@vpn.uni-ak.ac.at
1190105438 J * meandtheshell ~markus@85.127.108.167
1190105865 Q * coderanger_ Ping timeout: 480 seconds
1190106881 M * DavidS thanks guys! since yesterday the failover on the two servers works fine
1190106917 M * DavidS now we have two nodes with heartbeat and a shared storage (SAN) which are configured active/active (i.e. each is running services)
1190106933 J * gcj_ ~chris@fen-fw.aptivate.org
1190106949 M * DavidS if one of them fails, the other one takes over the VG, mounts everything, configures the IPs and starts all VServers.
1190106964 M * neuralis Ashsong: it's a bit late for michael to be up :)
1190106965 M * neuralis er
1190106967 M * neuralis Bertl: --^
1190106979 M * Bertl DavidS: excellent!
1190106984 M * gcj_ morning all :-)
1190106994 M * Bertl neuralis: hmm, yeah, probably for you too :)
1190107030 M * neuralis i have a pot of coffee and a pile of work that say otherwise
1190107182 M * DavidS yeah, and thanks to namespace cleanup it really works too
1190107243 M * DavidS we already tried this setup last year, but when moving services back from the take-over node, it failed to release all mounts
1190107277 M * DavidS but now we finally upgraded to etch+backported kernel with 2.2 patch :)
1190107289 M * Bertl hehe
1190107306 M * daniel_hozac namespace cleanup is a userspace thing.
1190107442 M * Bertl hey daniel_hozac! is it hard to add a v2 network structure to 0.30.215?
1190107500 M * daniel_hozac hmm?
1190107515 M * Bertl well, I think we want a mask for ranges too
1190107532 M * Bertl which basically means, we have to add one more ip field
1190107554 M * DavidS still, sarge has .204, sarge-backports .210 none of which are really new, i believe
1190107595 M * daniel_hozac hmm, what would the mask for ranges do?
1190107610 M * Bertl define the 'network' for the source ip selection
1190107710 M * baldy moin guys
1190107737 M * Bertl morning baldy!
1190107855 M * daniel_hozac hmm, wouldn't the prefix work for that?
1190107941 M * daniel_hozac and is mask strictly a network mask?
1190107944 M * Bertl what prefix?
1190107965 M * daniel_hozac i thought it was supposed to allow for e.g. "every other IP in this network" things.
1190107980 M * daniel_hozac         uint16_t prefix;
1190107986 M * Bertl for ipv4?
1190108003 M * daniel_hozac ah, sorry, i was looking at the match structs.
1190108042 M * Bertl a prefix would work, but I don't think it's worth the efford
1190108059 M * daniel_hozac the match structs already have all we need, no?
1190108071 M * Bertl i.e. I'm fine if userspace handles a prefix, but in the kernel it's much simpler to use a mask
1190108082 M * Bertl yeah, those should be fine
1190108151 Q * Hollow Ping timeout: 480 seconds
1190108181 Q * bzed Ping timeout: 480 seconds
1190108202 M * daniel_hozac well, it's not hard to add another API.
1190108216 Q * meebey Ping timeout: 480 seconds
1190108218 Q * phreak`` Ping timeout: 480 seconds
1190108319 M * Bertl I think we are not ready for the match part yet, no?
1190108341 M * daniel_hozac not really.
1190108431 J * Hollow ~hollow@proteus.croup.de
1190108483 J * phreak`` ~phreak``@deimos.barfoo.org
1190108496 J * meebey meebey@booster.qnetp.net
1190108784 Q * gcj_ Quit: later
1190108802 J * bzed ~bzed@devel.recluse.de
1190109448 M * renihs match party? :p
1190109460 M * renihs ah lol :)
1190110042 J * ktwilight_ ~ktwilight@169.108-66-87.adsl-dyn.isp.belgacom.be
1190110387 Q * ktwilight Ping timeout: 480 seconds
1190110819 J * Piet ~piet@tor.noreply.org
1190111235 J * ktwilight ~ktwilight@193.73-66-87.adsl-dyn.isp.belgacom.be
1190111527 Q * ktwilight_ Ping timeout: 480 seconds
1190111660 Q * DavidS Quit: Leaving.
1190112262 M * Bertl daniel_hozac: ping?
1190112305 T * Bertl http://linux-vserver.org/ | latest stable 2.2.0.3, 2.0.3-rc3, devel 2.3.0.21, stable+grsec 2.0.2.1, 2.2.0.3 | util-vserver-0.30.214 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;)
1190112394 M * daniel_hozac pong?
1190112407 M * Bertl baggins: please check if 2.3.0.21 fixes the issues for you
1190112420 M * Bertl daniel_hozac: ah, wasn't sure you are still? up ...
1190112426 M * baggins Bertl: thanks, I'll do
1190112428 M * daniel_hozac well, i'm in school now ;)
1190112440 M * Bertl ah, you are back to europe?
1190112472 M * daniel_hozac yeah, i got back august 18th.
1190112506 M * Bertl daniel_hozac: completely missed that ... anyway, please have a look at the changes when you find some time, I think it should cover all relevant cases
1190112525 M * Bertl (added some debug info too :)
1190112619 M * daniel_hozac have you managed to fix the hang with splice?
1190112680 M * Bertl haven't investigated that one yet, but will do so in a few minutes :)
1190112690 M * daniel_hozac okay :)
1190112776 M * daniel_hozac the changes look fine to me.
1190112806 M * Bertl great! let's see how they do for baggins ...
1190112877 M * Bertl daniel_hozac: you observed the hangs with ext2/3 too, right?
1190112900 M * Bertl s/too//?
1190112968 M * daniel_hozac yeah
1190112987 M * daniel_hozac i never got past testing ext2, as it hung there ;)
1190113026 M * Bertl interesting ... IIRC, I did the full test suite ...
1190113232 M * Bertl right after 213, yes?
1190113542 M * daniel_hozac yeah.
1190113731 M * baggins Bertl: ERROR: "ip_v4_find_src" [net/dccp/dccp_ipv4.ko] undefined!
1190113764 M * Bertl who uses dccp? :)
1190113794 M * Bertl yeah, we should export it too :)
1190113801 M * baggins I like to have all modules built :)
1190113835 M * Bertl ah, I see, to make the kernels as slow as distro kernels :)
1190113900 M * baggins nah, modules doesn't slow down
1190113912 M * baggins just make it as big as distro kernels ;)
1190113924 M * Bertl that is what you think!
1190113953 M * daniel_hozac depends on your PoV, i guess.
1190113954 M * Bertl add EXPORT_SYMBOL_GPL(ip_v4_find_src);
1190113967 M * Bertl to kernel/vserver/inet.c, at the end
1190113973 M * baggins dccp was the only place, I disabled it for now
1190114059 M * Bertl daniel_hozac: and sys_splice/do_splice() worked even under limits?
1190114067 M * daniel_hozac right.
1190114071 M * Bertl (userspace side I mean)
1190114188 M * daniel_hozac strace and wchan also showed nothing for the process, so i guess it could just be a bug in my touch.
1190114209 M * Bertl hmm?
1190114249 M * daniel_hozac though if it's a userspace bug, the process should respond to kill -9...
1190114272 M * daniel_hozac strace -p <pid> didn't output anything, and /proc/<pid>/wchan contained 0.
1190114317 M * Bertl the thing is, I see no 'touch' in the task list (magic sysrq) only bash sitting in do_wait()
1190114344 M * daniel_hozac do you see the 100% CPU?
1190114364 M * Bertl well, qemu is using up 100%, so yes
1190114380 M * Bertl the script doesn't return or break here ...
1190114380 M * daniel_hozac ah, just one console?
1190114389 M * daniel_hozac okay.
1190114419 M * Bertl will extract the relevant test and do some kernel debugging there
1190114918 Q * Piet Remote host closed the connection
1190114960 J * Piet ~piet@tor.noreply.org
1190115714 M * baggins Bertl: quick test shows that It Works :)
1190115977 M * Bertl good!
1190116008 J * jmcaricand root@d77-216-139-107.cust.tele2.fr
1190116040 M * Bertl baggins: thanks for testing!
1190116108 J * roym ~user@adsl-065-006-164-142.sip.mia.bellsouth.net
1190116120 M * Bertl wb jmcaricand! roym!
1190116269 M * roym morning Bertl
1190117405 J * Julius ~julius@p57B27808.dip.t-dialin.net
1190118821 Q * Aiken Quit: Leaving
1190120333 J * hparker ~hparker@linux.homershut.net
1190121373 P * friendly12345 
1190122102 J * paranoiac ~paranoiac@chello213047155237.5.sc-graz.chello.at
1190122236 Q * FireEgl Read error: Connection reset by peer
1190122489 M * paranoiac I've a strange problem with PAM limits and vservers, getting lot of rlimit messages in auth.log. There are some reports of the same problem in the net, but they did not satisfy me. Are there some vserver developers around here, I guess I could give some new information on that topic.
1190122633 M * renihs just write it in here, they will read it :)
1190122644 M * renihs but Bertl is around afaik 
1190122654 M * renihs 2 hours ago that is at least :p
1190122771 M * Bertl indeed ...
1190122795 M * Bertl paranoiac: well, depending on your kernel, there can be several reasons for this
1190122813 M * paranoiac @PAM: it seems that the vserver reacts different when started from sysv-init compared to  startup from bash
1190122845 M * Bertl paranoiac: to narrow it down, what kernel and tools are you using atm?
1190122944 J * DavidS ~david@vpn.uni-ak.ac.at
1190123132 M * paranoiac The kernel is a 2.6.21-1-vs2.2.0, but I dont know a method to find version of util-vservers
1190123168 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa
1190123207 M * Bertl vserver --version :)
1190123285 M * paranoiac Thanks, version is 0.30.213
1190123415 M * Bertl okay, let's check something, regarding your config
1190123490 J * ema ~ema@fw.galliera.it
1190123531 M * Bertl paranoiac: for a test, try to add SYS_RESOURCE to your bcapabilities
1190123540 M * Bertl (and restart the guest)
1190123602 M * paranoiac Just before doing more testing, I send you some testdata, just a moment
1190123608 M * Bertl okay, np
1190123797 Q * arachnist Quit: bbl
1190123804 M * paranoiac Test methods: wrote a small program to dump the rlimits of the
1190123838 M * paranoiac current process. The program is started as cron job every minute, output written to /tmp/limit-dump
1190123852 M * Bertl ulimit wasn't sufficient?
1190124052 M * paranoiac I checked ulimit again, ulimit would have done it, but when I tried first I did not see that it is the same with my program. (my prog just dumps all limits from 0..255 in numeric .. 18 lines in total)
1190124093 M * Bertl okay
1190124105 M * Bertl and what did you observe?
1190124106 M * paranoiac Result: when vserver is started from sys-v init, then limits are as follows:
1190124143 M * paranoiac Limit 11: hard 2048, soft 2048
1190124151 M * paranoiac Limit 12: hard 819200, soft 819200
1190124161 M * paranoiac Limit 13: hard 0, soft 0
1190124166 M * Bertl pastebin?
1190124176 Q * Johnnie Ping timeout: 480 seconds
1190124221 M * paranoiac no real irc client yet, using telnet
1190124242 M * Bertl nice, I'd suggest to go for irssi
1190124275 M * paranoiac When vserver started from bash via vserver xx start or after vserver-enter xx   /etc/init.d/cron restart:
1190124285 M * paranoiac Limit 11: hard -1, soft -1
1190124293 M * paranoiac Limit 12: hard -1, soft -1
1190124302 M * paranoiac Limit 13: hard 20, soft 20
1190124313 M * paranoiac All other limits are the same
1190124334 M * Bertl okay, and what arch are you on? x86
1190124338 M * paranoiac It seems that limits in vserver guest apply only when staretd from sysvinit. With manual restart limits do not apply
1190124344 M * paranoiac i386
1190124373 M * paranoiac Problem reproduced on two different native i386 systems with ubuntu and in vmware image with vserver kernel
1190124385 M * paranoiac (thanks for client suggestion, I try downloading)
1190124410 M * Bertl I assume you somehow end up with 'host' limits in one case
1190124440 M * Bertl 13 is the nice value
1190124460 M * paranoiac yes
1190124460 M * Bertl 11 and 12 are sigpending and msgqueue
1190124474 M * paranoiac could be, have to look up.
1190124487 M * Bertl the nice value can easily be worked around with IGNEG_NICE
1190124550 M * Bertl the other two look like they could be ipc namespace related
1190124591 M * Bertl but in any case, adding the desired limits to the config should do the trick
1190124602 M * paranoiac PRIVMSG #vserver :I would know some ways (using pam_limits) to supress the warnings.
1190124668 M * paranoiac But I', startled that different ways of starting vserver can cause different limits/permissions for the programs running within.
1190124685 M * Bertl inside a guest, by default, even root is not permitted to raise the limits (without SYS_RESOURCE), so if pam tries to set limits above the current guest limits, you have a problem
1190124726 M * Bertl in one case, I assume, the guest limits are not there, thus, no problem when pam tries to raise them
1190124833 Q * sharkjaw Quit: Leaving
1190124836 M * paranoiac PRIVMSG #vserver :I find it cool to limit the processes withn vserver from outside when the mechanism is somehow transparent. In this case the restart of a vserver gives different limits to all processes in the vserver. Can this be used to bypass all limits by a malicious user or attacker?
1190124905 M * Bertl if you specify the limits in the config, a guest restart (regardless of from inside or outside) will apply the proper limits
1190124926 M * Bertl so IMHO, that cannot be exploited for anything (or did I miss something?)
1190125489 J * arachnist arachnist@088156185052.who.vectranet.pl
1190125561 M * paranoiac My thinking was: a vserver is started from init, so some limits apply to all processes inside the vserver. This is also true for the process starting cron (a shell running as root in vserver), so the cron daemon is started with reduced limits. When I now enter I also get a shell as user root in vserver, but when I start cron from this shell different limits apply. From that I cannot create a big security breach. At most an atta
1190125643 M * Bertl ah, well, entering a guest (with enter or exec) is something only an admin should do, and of course, running services from such a shell should be given some consideration
1190125659 M * paranoiac In this case he could possibly evade security restrictions, e.g. open devices in real promiscous mode, read kernel memory, .. 
1190125665 M * Bertl nevertheless, IIRC, recent tools will apply the guest configured limits too
1190125688 M * Bertl paranoiac: nah, I really doubt that
1190125691 M * paranoiac since which version?
1190125701 M * paranoiac the tools)
1190125707 M * Bertl daniel_hozac probably knows more here ...
1190125729 M * paranoiac thanks for the tip
1190125970 M * paranoiac Ok, I'll try some of your suggestions tomorrow and see what a upgrade can do also.
1190125983 M * paranoiac bye
1190126084 M * Bertl you're welcome! cya!
1190126466 Q * paranoiac Ping timeout: 480 seconds
1190127553 J * lilalinux ~plasma@dslb-084-058-219-250.pools.arcor-ip.net
1190127860 J * MEMUS ~memus@slack.org.pl
1190127905 M * MEMUS mhm have someone got a problem with grsec + vserver and "proc already mounted" ?
1190128158 M * Bertl probably you?
1190128195 M * MEMUS ;]
1190128209 M * Bertl have you tried without grsec yet?
1190128433 M * MEMUS no :) i'll check it but i wanna with grsec :] brb ;p
1190128436 Q * MEMUS Quit: leaving
1190128732 Q * jmcaricand Remote host closed the connection
1190130320 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190130329 M * Bertl wb cl4sh!
1190130361 M * cl4sh :)
1190130364 M * cl4sh Hi all
1190130373 M * cl4sh ive got next problem
1190130377 M * cl4sh :P
1190130386 M * Bertl well, let's hear :)
1190130398 M * cl4sh i cant emerge net-tools under guest
1190130409 M * Bertl how so?
1190130412 M * cl4sh ive got message like that
1190130437 M * cl4sh http://paste.linux-vserver.org/6624
1190130468 M * cl4sh i was try to emerg r11 and there was the same message
1190130484 M * renihs thats the useless part of the log :)
1190130488 M * Bertl looks gentoo specific to me
1190130492 M * renihs it is :)
1190130513 M * renihs you might wanna tail /var/tmp/portage/sys-apps/net-tools-1.60-r13/temp/build.log
1190130524 M * cl4sh ok maybe  ishould pset from begin sorry
1190130541 M * renihs but unlikely its vserver related :)
1190130738 M * cl4sh one moment
1190131182 M * cl4sh http://paste.linux-vserver.org/6628
1190131213 M * cl4sh sorry for strange signs
1190131232 M * cl4sh at beginning
1190131264 M * Bertl those are control codes :)
1190131279 M * cl4sh yes
1190131348 M * cl4sh its becuse i will use firefox to open build log
1190131414 M * cl4sh and waht do you think about that errors?
1190131435 M * Bertl xgettext: error while loading shared libraries
1190131444 M * Bertl libexpat.so.0: cannot open shared object file: No such file or directory
1190131453 M * Bertl looks to me like libexpat is missing :)
1190131466 M * cl4sh :)
1190131473 M * cl4sh simple answer
1190131504 M * cl4sh where i can find libexpat ? or how?
1190131515 M * Bertl I would try to 'emerge' it, no?
1190131561 M * cl4sh there are no ebuilds
1190131583 M * Bertl maybe some gentoo folks can help you there, I have _no_ idea :)
1190131613 M * Bertl here I would do: 'urpmi libexpat'
1190131631 M * cl4sh :)
1190131934 M * Bertl daniel_hozac: FYI: Jens just confirmed that the splice stuff is a mainline issue, and should be fixed in 2.6.23* (which seems to be true)
1190131961 J * coderanger_ ~coderange@c-65-96-210-168.hsd1.ma.comcast.net
1190132336 M * cl4sh Bertl ; problem solved
1190132344 M * cl4sh Bertl : :)
1190132421 M * blizz heyho
1190132440 M * blizz i'm planning to install a fresh new debian 4.0 installation on a dedicated root server
1190132465 M * Bertl cl4sh: congrats!
1190132488 M * blizz looks like the util-vserver package is still a bit outdated for stable debian?
1190132515 M * blizz 0.30.212 in etch but 0.30.214 in sid ;-)
1190132534 M * Bertl as usual, yes :)
1190132559 M * blizz well, there's also 0.30.213 in etch-backports..
1190132568 M * blizz any recommendation on which one i should use?
1190132581 M * blizz i never had debian as a host system for vservers :-)
1190132583 M * Bertl depends on what kernel you are going to install
1190132602 M * Bertl the 'ancient' kernels debian uses, should be fine with 0.30.213
1190132657 M * blizz 2.6.18 in etch, 2.6.21 in etch-backports and 2.6.22 in sid
1190132673 M * blizz so 0.30.214 requires the sid kernel, i guess
1190132693 M * Bertl no, but I would say, the sid kernel requires 0.30.214 :)
1190132724 M * blizz ahh, that way
1190132731 M * Bertl note: I do not know what kernel actually is in sid
1190132765 M * blizz from looking at packages.debian.org i can say.. it seems to be 2.6.22
1190132781 M * blizz it's called "linux-image-vserver-686" with version 2.6.22
1190132824 M * blizz so maybe i should ask the debian guys whether it's safe to install etch and use the sid kernel + vserver-utils
1190133161 M * Bertl yeah, well, could be everything from a forward ported vs2.0.2 to 2.2.0.3 or even 2.3.x
1190133419 M * DavidS 2.6.21 uses 2.2
1190133436 M * DavidS search in the changelog.Debian for "vserver"
1190133540 M * DavidS according to http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.22-4/changelog , sid's current 2.6.22-4 has 2.2.0.3
1190133594 M * DavidS whils 2.6.21-6 (which is in lenny and etch-backports) has 2.2.0
1190133668 M * Bertl i.c. tx!
1190134222 M * yang hey Bertl do you know anything about asterisk strings?
1190134265 M * yang I have these 2 lines:
1190134266 M * yang exten => 600,1,Set(MONITOR_FILENAME=${REC_DIR}${TIMESTAMP}-${EXTEN}-${CALLERID}-out)
1190134269 M * yang exten => 600,2,Monitor(wav,${MONITOR_FILENAME},mb)
1190134291 M * yang and it drops files into / instead of /var/spool/asterisk/monitor
1190134361 M * Bertl no idea :)
1190134537 M * yang :/
1190134584 M * blizz thanks bertl and davids
1190134585 M * Bertl maybe ask some asterisk folks?
1190134588 Q * ema Read error: Connection reset by peer
1190134762 J * jmcaricand ~jmcarican@d83-179-238-91.cust.tele2.fr
1190134785 M * daniel_hozac Bertl: ah, great! do you have any reference, or should i just google?
1190134918 M * DavidS blizz, Bertl: sure, np
1190134968 J * MEMUS memus@slack.org.pl
1190135058 M * Ashsong Bertl: morning.
1190135059 M * Bertl daniel_hozac: nah, nothing except private communication yet
1190135089 M * Ashsong Bertl: I contacted you because I know you have better insight into the workings of the VFS layer than I do. 
1190135146 M * Ashsong We haven't figured out yet if the bug is in rsync, in the VFS, in the dirent cache, or in several of these.
1190135150 M * Bertl Ashsong: so we already _know_ it is a kernel issue?
1190135156 M * Ashsong Bertl: we do not yet know that.
1190135189 M * Ashsong I am suspicious, though. I'm currently reading through strace to try to test that hypothesis
1190135219 M * Bertl ah, okay, so I would suggest to try to reproduce the issue with simple tools
1190135219 M * Bertl i.e. without rsync
1190135219 M * Bertl okay, let me know if you find something
1190135235 M * Ashsong Bertl: rsyncing once gives the incorrect GID, but rsyncing again on top of the incorrect file gives the correct file
1190135249 M * Ashsong however, it's not reproducible across all machines.
1190135255 M * Ashsong (yet)
1190135267 M * Ashsong Bertl: anyway, I shall endeavor to get better information.
1190135419 Q * meandtheshell Quit: Leaving.
1190135614 J * ensc ~irc-ensc@p54B4CA9C.dip.t-dialin.net
1190135711 M * MEMUS asdf
1190135716 M * MEMUS ups sry
1190135727 M * Borg- your root password?
1190135754 M * MEMUS u can try ;p
1190135796 M * Bertl Ashsong: could you try the same with a non-vserver kernel too?
1190135827 M * Bertl Ashsong: it could be a jffs2 issue similar to the one we already observed
1190135906 Q * rob-84x^ Ping timeout: 480 seconds
1190136045 M * blizz debian guys say: don't use sid packages in etch :-)
1190136078 M * daniel_hozac that's what backports is for...
1190136157 M * blizz yeah, they said that, too
1190136249 M * blizz backports seem to be fine :-)
1190136267 M * blizz 0.30.213 and a not-so-ancient kernel from the testing distribution ;-)
1190136299 M * daniel_hozac 0.30.214 will be uploaded as soon as it's possible, from what i can tell.
1190136326 M * daniel_hozac speaking of which, micah: you'll want http://svn.linux-vserver.org/projects/util-vserver/changeset/2610
1190136364 J * ema ~ema@fw.galliera.it
1190136578 M * Bertl I uploaded a 2.6.23-rc6-vs2.3.0-pre1 patch for the impatient folks ... the scheduler stuff is removed for now, and xfs is broken, but CoW limits are working :)
1190136594 J * Piet_ ~piet@tor.noreply.org
1190136738 M * micah daniel_hozac: thanks... if I upload that now, the migration of 0.30.214 to testing (and thus to backports) will be delayed by 10 days... I am guessing this fix is worth that?
1190136747 M * micah also, i can bump the priority up so it halves that time
1190136781 M * daniel_hozac well, that fix isn't too interesting for sid/lenny as AFAIK the kernels there don't support dynamic contexts anyway.
1190136797 M * daniel_hozac i was mostly referring to the backport.
1190136806 M * Bertl okay, off for today, have to get up really early tomorrow ... cya!
1190136812 M * daniel_hozac good night!
1190136813 N * Bertl Bertl_zZ
1190136814 A * micah waves to Bertl_zZ 
1190136841 M * micah daniel_hozac: ah, so I should apply that patch to the 0.30.214 backport that I do
1190136847 M * micah if I understand you correctly
1190136862 M * daniel_hozac right
1190136896 A * micah is going to check on the ia64 buildd and why it is holding up that migration
1190136992 J * Piet__ ~piet@tor.noreply.org
1190137006 Q * Piet Ping timeout: 480 seconds
1190137136 Q * Piet_ Ping timeout: 480 seconds
1190137203 N * Piet__ Piet
1190137925 Q * cl4sh Quit: [BX] Choosey moms choose BitchX!
1190137961 M * Ashsong Bertl_zZ: ping
1190137973 M * Ashsong pretty sure it's a kernel bug in utimes() now
1190137980 M * daniel_hozac oh?
1190137985 M * daniel_hozac why's that?
1190137992 M * Ashsong I'll show you the strace()
1190138047 Q * lilalinux Remote host closed the connection
1190138103 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net
1190138195 M * Ashsong http://paste.lisp.org/display/47900
1190138223 M * Ashsong examine the st_gid field before and after the utimes()
1190138224 M * daniel_hozac hmm.
1190138235 M * daniel_hozac that is indeed very peculiar.
1190138262 M * Ashsong now to figure out why :)
1190138297 M * daniel_hozac hmm, that's odd.
1190138307 M * Ashsong is there a mistake?
1190138318 M * daniel_hozac i don't see us setting the uid/gid anywhere in cow_break_link.
1190138407 M * micah there are reserved syscalls for arm now?
1190138408 M * Ashsong daniel_hozac: I'm not saying that it's a vserver bug yet.
1190138429 M * Ashsong just that it's a kernel bug, and that Bertl was very helpful debugging a similar problem last time I had trouble :)
1190138441 M * daniel_hozac micah: hmm?
1190138473 M * micah daniel_hozac: I got an email from someone saying that they can use util-vserver/patched kernel on a NSLU2 box without any problems
1190138492 M * micah when previously we didn't build on arm because there weren't any reserved syscalls in the kernel for that arch
1190138501 M * daniel_hozac i think we've had syscall numbers reserved for all arches for a few years now.
1190138517 M * micah odd, well... then I dont see any reason why we aren't building arm :)
1190138628 Q * ema Quit: leaving
1190138696 M * daniel_hozac Ashsong: well, it's me saying that :)
1190138725 M * Ashsong daniel_hozac: thanks for looking at it.
1190138786 M * daniel_hozac we actually don't preserve anything other than the mode.
1190138832 M * daniel_hozac IMHO we should keep at least uid, gid and ctime.
1190139200 N * Ashsong Ashsong|lunch
1190139259 Q * Julius Quit: Verlassend
1190140133 Q * jmcaricand Quit: KVIrc 3.2.4 Anomalies http://www.kvirc.net/
1190140777 Q * Piet Remote host closed the connection
1190141444 Q * coderanger_ Quit: coderanger_
1190141899 Q * MEMUS Quit: leaving
1190142626 Q * Pazzo Quit: ...
1190143114 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190143141 J * ema ~ema@fw.galliera.it
1190143815 J * rob-84x^ rob@submarine.ath.cx
1190144047 Q * morten Ping timeout: 480 seconds
1190144898 J * coderanger_ ~coderange@wireless-58.media.mit.edu
1190144902 Q * coderanger_ Remote host closed the connection
1190144934 J * coderanger_ ~coderange@1cc-dhcp-156.media.mit.edu
1190145094 J * Piet ~piet@tor.noreply.org
1190145261 Q * Wonka Quit: vserver basteln
1190145839 J * coderanger__ ~coderange@wireless-58.media.mit.edu
1190146047 Q * Piet Remote host closed the connection
1190146150 J * Piet ~piet@tor.noreply.org
1190146256 Q * coderanger_ Ping timeout: 480 seconds
1190147332 J * Aiken ~james@ppp121-45-250-174.lns2.bne4.internode.on.net
1190147556 Q * dna Quit: Verlassend
1190148455 J * zLinux ~zLinux@88.213.29.156
1190148608 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33
1190149407 Q * cl4sh Quit: leaving
1190149606 Q * bonbons Quit: Leaving
1190150342 Q * FireEgl Read error: Connection reset by peer
1190150932 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190151109 Q * cl4sh 
1190151292 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa
1190151964 J * yarihm ~yarihm@84-75-130-73.dclient.hispeed.ch
1190152026 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190152199 Q * cl4sh 
1190152200 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190152266 Q * cl4sh 
1190152268 J * cl4sh ~cl4sh@qik.ds.pg.gda.pl
1190152897 Q * Piet Remote host closed the connection
1190152954 J * Piet ~piet@tor.noreply.org
1190152960 Q * Piet Remote host closed the connection
1190153001 J * Piet ~piet@tor.noreply.org
1190153376 Q * hparker Quit: Quit
1190153724 Q * Baby Read error: Connection reset by peer
1190153868 J * hparker ~hparker@linux.homershut.net
1190154274 J * Baby ~miry@195.37.62.208
1190155414 Q * ema Quit: leaving
1190157761 Q * yarihm Quit: Leaving
1190158003 Q * ard Ping timeout: 480 seconds