1139876130 J * grant mep@p509196C5.dip0.t-ipconnect.de
1139876541 J * mnemoc_ ~amery@200.75.27.51
1139876550 Q * grant_ Ping timeout: 480 seconds
1139876650 Q * mnemoc Ping timeout: 480 seconds
1139876650 N * mnemoc_ mnemoc
1139877189 Q * angel4u Read error: Connection reset by peer
1139878224 M * Skram SENTIEN asterisk # traceroute google.com
1139878224 M * Skram traceroute: Warning: google.com has multiple addresses; using 72.14.207.99
1139878224 M * Skram traceroute: raw socket: Operation not permitted
1139878230 M * Skram is that a vserver 'thang'?
1139878231 M * Skram BRB
1139878602 M * mnemoc you need a capability to send 'raw' packages like which traceroute send
1139878752 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com
1139878946 P * stefani I'm Parting (the water)
1139879129 N * ebiederm ebiederm_oO
1139879566 M * Skram mnemoc: eh... so a vserver or a overall linux problem
1139879617 J * toomy Kuwait@195.39.129.61
1139879636 P * toomy 
1139879656 M * Skram mnemoc: anyway to fix it ;)
1139879870 M * daniel_hozac Skram: CAP_NET_RAW in bcapabilities. but you probably don't want that, as that will let the vserver sniff all of your traffic...
1139879890 M * Skram this is a administrative vps so that doesnt matter.
1139879905 M * Skram Well, I mean it is the companies vps.
1139879924 M * Skram put that in /etc/vservers/name/bcapabilities ("cap_net_raw")?
1139879937 M * daniel_hozac yep.
1139879945 M * Skram requires a restart of the vps?
1139879984 M * Skram *sigh* okay.
1139879985 M * Skram traceroute: findsaddr: Can't find interface "eth0"
1139879986 M * Skram welp.
1139880016 M * Skram SENTIEN / # ifconfig | grep eth0
1139880016 M * Skram eth0      Link encap:Ethernet  HWaddr 00:14:22:72:A1:4D  
1139880017 M * Skram eth0:20   Link encap:Ethernet  HWaddr 00:14:22:72:A1:4D 
1139880018 M * Skram weird.
1139880053 M * daniel_hozac no interface hiding?
1139880061 M * Skram uhmmm
1139880097 M * daniel_hozac or does the vserver have an address on eth0 as well as the address of eth0:20?
1139880105 M * Skram Right
1139880124 M * Skram hercules / # ifconfig | grep eth0:20
1139880124 M * Skram eth0:20   Link encap:Ethernet  HWaddr 00:14:22:72:A1:4D  
1139880135 M * Skram hercules is the host
1139880353 M * daniel_hozac so ifconfig in the guest does show an IP address for eth0?
1139880385 M * Skram it shows an ip addr for eth0:20
1139880418 M * Skram traceroute iax2.fwdnet.net -i eth0:20
1139880423 M * Skram but whats a long term fix?
1139880432 M * Skram hrmm
1139880438 M * daniel_hozac install another traceroute ;)
1139880449 M * daniel_hozac one that doesn't rely on obsoleted kernel interfaces.
1139880449 M * Skram hmm okay
1139880456 M * Skram Okay
1139880513 M * daniel_hozac (or, fix the one you're using)
1139880518 M * Skram Right
1139880520 M * Skram I will
1139880525 M * Skram or write something to the users about that
1139880528 J * Power Kuwait@195.39.129.61
1139880541 M * Skram wow.. people are having apache problems, well my people are.. i have to reboot apache and the ram goes back down
1139880610 M * daniel_hozac httpd with mod_<insert your favorite scripting language here> can use quite a bit of RAM.
1139880759 M * Skram but when i restart apache it goes back down.
1139880778 M * daniel_hozac right.
1139880955 M * daniel_hozac it hasn't run any scripts right after a restart.
1139880984 M * Skram right okay.
1139881002 M * Skram well then what would the fix be
1139881014 M * daniel_hozac more RAM? :)
1139881018 M * Skram not to rush, but if its bad to load, which im not sure if they are doing..
1139881031 M * Skram is it better to load so the stats are more accurate?
1139881058 M * daniel_hozac load what?
1139881073 M * Skram scripting modules
1139881110 M * daniel_hozac you usually gain features as well as performance by having the modules loaded.
1139881160 M * Skram okay
1139881174 M * Skram i think they are autoloaded by default
1139881710 J * Kuwait-Girl okey@195.39.129.61
1139881796 M * Kuwait-Girl #kuwait
1139881916 Q * Kuwait-Girl Quit: 
1139882192 P * Power 
1139884601 Q * _mountie Remote host closed the connection
1139885251 M * Skram Hi.
1139885308 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1139885603 M * Skram If I provide the script, could we run a bot which echoes what happens in the #gentoo-vserver on irc.freenode.net and this channel?
1139885614 M * Skram I mean echo it IN this channel
1139886668 M * mugwump if you do that, why have two channels?
1139887366 M * mnemoc what sense does it make having a second channel anyway?
1139888696 J * k3Rn weasel@tor.noreply.org
1139889207 Q * k3Rn Quit: 
1139889244 M * shuri no sense....
1139889267 J * k3Rn weasel@tor.noreply.org
1139889285 Q * k3Rn Remote host closed the connection
1139889329 J * k3Rn weasel@tor.noreply.org
1139890133 Q * k3Rn Quit: 
1139890273 J * k3Rn ~kernone@tor-irc.dnsbl.oftc.net
1139890279 Q * k3Rn Quit: 
1139890770 J * k3Rn ~kernone@tor-irc.dnsbl.oftc.net
1139890887 Q * k3Rn Quit: 
1139890890 J * k3Rn ~kernone@tor-irc.dnsbl.oftc.net
1139890947 Q * k3Rn Quit: 
1139890971 J * k3Rn thiesi@tor-irc.dnsbl.oftc.net
1139891092 Q * brc_ Ping timeout: 480 seconds
1139891150 Q * k3Rn Quit: 
1139891262 J * k3Rn thiesi@tor-irc.dnsbl.oftc.net
1139891383 Q * k3Rn Quit: 
1139891420 J * k3Rn ~kernone@82.94.251.206
1139892428 Q * k3Rn Ping timeout: 480 seconds
1139892483 J * W0nka produziert@chaos.in-kiel.de
1139892545 M * mugwump Bertl, http://vserver.utsl.gen.nz/patches/utsl/2.6.16-rc2-vsi/  # my patches, plus "difference" patches corresponding to each part of the split
1139892570 Q * Wonka Read error: Connection reset by peer
1139892994 M * mugwump http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=commit;h=cfa35b5faff83dc785318f889d8ab5861915d852 # vs2.1.0.11 via combined patch - note "tree" sha1 sum
1139893028 M * mugwump http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=commit;h=d3d5a3d7f64e517db1008500c552a78b8cfe41b5 # vs2.1.0.11 via vserver-include + vs2.1.0.9 split + 9-11 deltas + 'leftovers' patch
1139893038 M * daniel_hozac not 2.1.1-rc4? ;)
1139893050 M * mugwump no, that's against an ancient kernel version
1139893072 M * mugwump like, 2.6.15.4 or something
1139893111 M * daniel_hozac yeah, 4 days old, can't have that! ;)
1139893139 M * mugwump it's jurassic!
1139893146 M * mugwump the world has moved on!
1139893233 M * mugwump Seriously, though - I just don't want to rebase backwards; I'm currently using 2.6.16-rc2
1139893260 A * mugwump hmms
1139893286 M * mugwump actually, I could rebase 2.1.0.11 against 2.6.15.4, then compare that to the result of the 2.1.1-rc4 patch
1139893439 M * mugwump hmm, is the kernel source not utf8?
1139893541 M * ebiederm_oO Gnerally the kernel source is simply ascii.
1139893555 N * ebiederm_oO ebiederm
1139893559 M * daniel_hozac the deltas should be around /Experimental/ too.
1139893601 M * ebiederm I think there are a few files that are in various extended ascii like iso-8859-1 or utf8.
1139893655 Q * shuri Ping timeout: 480 seconds
1139893708 M * mugwump I'm just noticing Herbert's name getting excessively munted here and there.  I blame python ;)
1139893777 M * ebiederm munted? maybe you mean mentioned?
1139893858 M * mugwump sorry, NZ slang for "all messed up"
1139893895 M * ebiederm Now it becomes clear.
1139893967 M * ebiederm I'm a little surprised I haven't heard that one before.   It sounds like dialect and not slang the way you said it.
1139894106 J * shuri ~shuri@64.235.209.226
1139894128 M * mugwump yes, dialect is a more accurate term for it
1139894168 M * ebiederm I obviously have not read enough stories from New Zealand :)
1139894525 M * ebiederm Anyway have a good night folks.
1139894531 N * ebiederm ebiederm_zZ
1139894532 M * mugwump sleep well ebiederm 
1139895140 J * cemil ~cemil@defiant.wavecon.de
1139895567 A * mugwump goes to Taichi
1139895583 M * Skram i need bash helo
1139895585 M * Skram :(
1139896399 Q * shuri Quit: Quitte
1139897114 J * Kelafein Kellan_M_S@24-107-191-186.dhcp.stls.mo.charter.com
1139897157 P * Kelafein 
1139899148 P * anonc adios
1139900929 J * meandtheshell ~markus@85-125-231-156.dynamic.xdsl-line.inode.at
1139902686 M * nox how can i provide good info about a kernelpanic?
1139902704 M * nox just had one on 2.6.15.4-vs2.0.2-rc2
1139902788 M * nox should i recompile with CONFIG_VSERVER_DEBUG ?
1139903308 J * anonc ~anonc@staffnet.internode.com.au
1139904553 M * harry just for fun... http://harry.ulyssis.org/patch-2.6.14.6-vs2.1.0-grsec2.1.7.diff.gz
1139904590 M * harry it's the same as the last one... but not applies to 2.6.14.6 (some offsets are adjusted, but it works perfectly)
1139904601 M * harry s/not/now/
1139905072 J * prae ~prae@ezoffice.mandriva.com
1139905265 N * Bertl_zZ Bertl
1139905269 M * Bertl morning folks!
1139905291 M * Bertl nox: panic means oops which means stack/register trace
1139905304 M * Bertl nox: providing that is a good start
1139905502 M * nox wb Bertl! ok i read a bit about stack tracing and will provide asap
1139905535 M * nox http://blog.borho.net/howto_being_a_guru.html <- lol
1139905622 Q * shedi Quit: Leaving
1139905670 M * Bertl nox, well, of course, using the VSERVER_DEBUG stuff can help a lot too
1139905777 M * nox 512 histsize or more?
1139905845 M * Bertl what console do you have? serial?
1139906281 M * nox Bertl: yes
1139906293 M * Bertl okay, then 512 is fine
1139906711 M * Bertl nox: do you remember (or have captured) some parts of the trace?
1139906810 M * nox no just plugged a monitor to be sure it was one ... coulnd't figure out
1139906890 M * nox but was one. kernel was new started and it happend while moving a directory (don't know if this is related)
1139907413 M * nox Bertl: if you have an idea how to stress it, tell me it is a test machine
1139907436 M * Bertl kernel building, benchmarks, bonnie ...
1139907475 M * nox cpuburn also? or doesn't help?
1139907499 M * nox well load wasn't high that time it crashed
1139907502 M * Bertl well, usually cpu bound code doesn't cause too many issues, except if it is hardware related
1139907566 M * nox hmm should do memtest before to exclude the possibility of defect ram
1139907582 M * Bertl couldn't hurt
1139907736 M * nox the fs is moved to is xfs, maybe that could be related also
1139907783 M * Bertl well, xfs IMHO isn't the stablest one
1139907803 M * Bertl but as I said, the oops should at least give some hints
1139907932 M * nox hmm "isn't the stablest one" is something i don't wanna hear in relation of a fs
1139907951 M * Bertl well, reiserfs and xfs have two general issues:
1139907969 M * Bertl - they are not linux kernel code, so hard to read and easy to get wrong
1139907990 M * Bertl - they are somewhat maintained outside the tree
1139908026 M * Bertl so this usually leads to modifications in mainline constantly breaking them, until somebody reports it and they get fixed again
1139908075 M * nox makes sense
1139908097 M * nox had some problems with reiser about 4 years ago
1139908208 M * nox xfs i am using on my fileserver (non vserver) for nearly 2 years without any problems
1139908257 M * nox so there is no alternative to ext[23] ?
1139908295 M * Bertl there are all kinds of alternatives ... you can even use VFAT :)
1139908310 M * Bertl (or hfs+ :)
1139908375 M * nox vfat has some issues on a fileserver *g*
1139908405 M * Bertl see, that's the thing, some filesystems have _some_ issues :)
1139908411 M * nox what about jfs?
1139908433 M * Bertl well, I added xattr support recently :)
1139908468 M * nox it is not maintained by ibm anymore?
1139908566 M * Bertl again, it is maintained out of line ...
1139908596 M * Bertl http://jfs.sourceforge.net/
1139909484 J * tudenbart ~willi@xdsl-81-173-171-167.netcologne.de
1139909512 M * Bertl welcome tudenbart!
1139909703 J * shedi ~siggi@tolvudeild-204.lhi.is
1139909729 M * nox Bertl: what is a good histsize for netconsole?
1139909792 M * Bertl 64 probably
1139909940 Q * dothebart Ping timeout: 480 seconds
1139910115 J * brc_ bruce@20151178197.user.veloxzone.com.br
1139910143 M * Bertl welcome shedi! brc_!
1139910156 M * shedi hi Bertl 
1139911837 J * Smutje_ ~Smutje@xdsl-87-78-59-208.netcologne.de
1139911974 Q * Smutje Ping timeout: 480 seconds
1139911974 N * Smutje_ Smutje
1139912129 M * tudenbart hy Bertl 
1139912134 M * daniel_hozac Bertl: did you see http://daniel.hozac.com/vserver/delta-vs_pid-fix01.diff yesterday? or did you already fix that? (2.1 tree)
1139912167 M * Bertl daniel_hozac: saw it, currently working through the still missing changes and 2.6.16 sync
1139912206 M * daniel_hozac Bertl: arch/mips/kernel/linux32.c is missing #include <linux/vs_cvirt.h>
1139912224 M * daniel_hozac (those are the only ones my script picked up)
1139912250 M * Bertl okay, I ahve something else which your script could do (once I have the next patch ready)
1139912275 M * Bertl daniel_hozac: mount.h was removed from fs.h (15/16)
1139912312 M * Bertl I suspect we have a bunch of 'extra' mount.h includes in .15
1139912782 Q * tudenbart Ping timeout: 481 seconds
1139912888 M * daniel_hozac so you want to clean files that have linux/fs.h and linux/mount.h? what about linux/namespace.h (also includes linux/mount.h, but in both versions)?
1139912898 J * Loki_muh loki@satanix.de
1139913219 Q * Loki|muh Ping timeout: 480 seconds
1139913324 M * Bertl daniel_hozac: ah, that would be fine too, but finally I just want to remove includes we added (not the mainline ones, at least not in the vserver patch :)
1139913515 M * daniel_hozac so just remove the unnecessary linux/mount.h from the vserver patch? should be a lot easier :)
1139913561 M * Bertl yes, but don#t let me stop you from removing dumplicate includes in mainline :)
1139913751 Q * FireEgl oxygen.oftc.net arion.oftc.net
1139913751 Q * zobel oxygen.oftc.net arion.oftc.net
1139913751 Q * Smutje oxygen.oftc.net arion.oftc.net
1139913751 Q * kilian oxygen.oftc.net arion.oftc.net
1139913751 Q * DuckMaster oxygen.oftc.net arion.oftc.net
1139913751 Q * Duckx oxygen.oftc.net arion.oftc.net
1139913751 Q * harry oxygen.oftc.net arion.oftc.net
1139913751 Q * SuperLag oxygen.oftc.net arion.oftc.net
1139913751 Q * cohan oxygen.oftc.net arion.oftc.net
1139913751 Q * Adrinael oxygen.oftc.net arion.oftc.net
1139913751 Q * Psy0rz_ oxygen.oftc.net arion.oftc.net
1139913751 Q * jkl oxygen.oftc.net arion.oftc.net
1139913751 Q * andrew_ oxygen.oftc.net arion.oftc.net
1139913751 Q * Snow-Man oxygen.oftc.net arion.oftc.net
1139913751 Q * weasel oxygen.oftc.net arion.oftc.net
1139913751 Q * Hunger oxygen.oftc.net arion.oftc.net
1139913751 Q * brc_ oxygen.oftc.net arion.oftc.net
1139913751 Q * meandtheshell oxygen.oftc.net arion.oftc.net
1139913751 Q * cemil oxygen.oftc.net arion.oftc.net
1139913752 Q * mnemoc oxygen.oftc.net arion.oftc.net
1139913752 Q * baggins oxygen.oftc.net arion.oftc.net
1139913752 Q * BartVB oxygen.oftc.net arion.oftc.net
1139913752 Q * michal_ oxygen.oftc.net arion.oftc.net
1139913752 Q * monrad oxygen.oftc.net arion.oftc.net
1139913752 Q * mire oxygen.oftc.net arion.oftc.net
1139913752 Q * sladen oxygen.oftc.net arion.oftc.net
1139913752 Q * hallyn oxygen.oftc.net arion.oftc.net
1139913752 Q * micah oxygen.oftc.net arion.oftc.net
1139913805 J * Smutje ~Smutje@xdsl-87-78-59-208.netcologne.de
1139913805 J * brc_ bruce@20151178197.user.veloxzone.com.br
1139913805 J * meandtheshell ~markus@85-125-231-156.dynamic.xdsl-line.inode.at
1139913805 J * cemil ~cemil@defiant.wavecon.de
1139913805 J * mnemoc ~amery@200.75.27.51
1139913805 J * FireEgl Atlantica@Atlantica.Tcldrop.US
1139913805 J * zobel zobel@zobel.irc.ftbfs.de
1139913805 J * baggins baggins@kenny.mimuw.edu.pl
1139913805 J * kilian kk@projects.verfaction.de
1139913805 J * BartVB ~BartVB@84.35.54.120
1139913805 J * DuckMaster ~duckx@195.75.27.158
1139913805 J * Duckx ~duckx@195.75.27.158
1139913805 J * michal_ ~michal@www.rsbac.org
1139913805 J * harry ~harry@d515321D1.access.telenet.be
1139913805 J * monrad ~mikkel@213083190131.sonofon.dk
1139913805 J * mire ~mire@183-166-222-85.COOL.ADSL.VLine.verat.net
1139913805 J * sladen paul@starsky.19inch.net
1139913805 J * SuperLag ~aaron@38.99.66.175
1139913805 J * weasel weasel@weasel.noc.oftc.net
1139913805 J * andrew_ ~andrew@tnlug.linux.org.tw
1139913805 J * hallyn ~xa@c-24-11-243-196.hsd1.in.comcast.net
1139913805 J * jkl eric@c-67-172-156-116.hsd1.co.comcast.net
1139913805 J * Psy0rz_ ~psy0rz@lounge.datux.nl
1139913805 J * Snow-Man ~sfrost@kenobi.snowman.net
1139913805 J * Adrinael adrinael@hoasb-ff09dd00-79.dhcp.inet.fi
1139913805 J * cohan ~cohan@koniczek.de
1139913805 J * micah ~micah@69.90.134.205
1139913805 J * Hunger Hunger.hu@Hunger.hu
1139913875 M * daniel_hozac should i wait for the next patch?
1139913891 M * Bertl yes, please, will take only a few minutes
1139913900 M * daniel_hozac ok, fine, i'll get some lunch then.
1139913912 M * Bertl excellent idea :)
1139914107 Q * brc_ Ping timeout: 480 seconds
1139914176 J * lilalinux ~plasma@80.69.35.186
1139914182 M * Bertl wb lilalinux!
1139914507 Q * monrad Read error: Connection reset by peer
1139915041 J * grant_ mep@p509196C5.dip0.t-ipconnect.de
1139915043 Q * distortion Read error: Connection reset by peer
1139915172 J * distortion distortion@junipero.3sheep.com
1139915247 M * daniel_hozac ok, added a snippet to find-problems.sh for this.
1139915351 Q * grant Ping timeout: 480 seconds
1139915781 M * Bertl daniel_hozac: okay, patches (3 of them) are there, usualy place
1139915784 M * Bertl -y
1139915822 M * daniel_hozac 2.6.16-rc2-vs2.1.1-rc2? why rc2?
1139915826 M * Bertl will now focus on 2.6.16-rc2-vs2.0.2
1139915858 M * Bertl daniel_hozac: because I had a 'broken' rc1 :)
1139915865 M * daniel_hozac ah, heh, ok.
1139915922 M * Bertl do your worst, regarding cleanup, I will not schedule them for testing right now, but after your input was added
1139916304 J * monrad ~mikkel@213083190131.sonofon.dk
1139916331 M * Bertl welcome monrad!
1139916334 M * Bertl Vudumen: ping!
1139916639 M * daniel_hozac http://daniel.hozac.com/vserver/delta-mount-clean01.diff
1139916643 M * daniel_hozac http://daniel.hozac.com/vserver/delta-vs_pid-fix02.diff
1139916682 M * daniel_hozac i didn't change kernel/vserver/namespace.c, but that includes all three (mount.h, fs.h and namespace.h)
1139916754 M * Bertl and to which branch do they apply?
1139916766 M * daniel_hozac 2.6.15.4-vs2.1.1-rc5
1139916777 M * daniel_hozac will check the others next.
1139916782 M * Bertl k
1139917037 M * Bertl vs2.0.2-rc4 is actually missing the mount.h from fs.h
1139917064 M * Bertl and 2.6.16-rc2 seems to not need mount.h in fs.h
1139917170 M * daniel_hozac i found no problems in 2.0.2-rc4.
1139917180 M * Hollow olla
1139917216 M * Bertl daniel_hozac: okay, IMHO 2.0.2-rc4 needs a mount.h included in fs.h (after the atime check is added)
1139917227 M * Bertl hey Hollow!
1139917318 M * daniel_hozac Bertl: yeah, probably are other files depending on fs.h including mount.h as well...
1139917583 Q * zobel Ping timeout: 480 seconds
1139917667 M * daniel_hozac Bertl: 2.6.16-rc2-vs2.1.1-rc2 is also clean.
1139917687 M * Bertl hmm .. hmm, sure?
1139917711 M * daniel_hozac according to the script.
1139917738 M * Bertl could you verify ./arch/ia64/ia32/sys_ia32.c regarding vs_pid.h?
1139917763 M * daniel_hozac yep.
1139917808 M * daniel_hozac there seems to be no need for vs_pid.h in that file though.
1139917838 M * daniel_hozac (the script only does checks the other way, for missing files)
1139917867 M * Bertl hmm .. why does 2.6.15.4-vs2.1.1-rc5 need it then?
1139917915 J * zobel zobel@2001:7b8:385::2
1139917916 M * daniel_hozac 2.6.15.4 has find_task_by_pid in there, 2.6.16-rc2 does not.
1139917927 M * Bertl interesting ...
1139917931 M * Bertl okay, so be it
1139917955 M * daniel_hozac seems there was a lot of find_task_by_pid elimination from arch/* in general in 2.6.16-rc2.
1139918010 Q * ComplexMind Ping timeout: 480 seconds
1139918062 J * ComplexMind ~ComplexHo@cpc1-brig3-6-0-cust194.brig.cable.ntl.com
1139918471 Q * Vudumen Quit: perverz.hu reszeling in progressz vagy mi\
1139919288 M * Hollow Bertl: just re-read what you told me about the new scheduler.. rate2/interval2 are added when the cpu is idle, regardless of the if the bucket is empty, or not?
1139919319 M * Bertl yes
1139919347 M * Bertl that's the only way to get fair distribution
1139919364 M * Hollow yes means the bucket doesn't matter
1139919366 M * Hollow ?
1139919367 M * Hollow :)
1139919377 M * Bertl well, that was your question, no?
1139919419 M * Bertl to clarify: the bucket state does not matter
1139919431 M * Hollow ok :)
1139919610 J * PilatomiK ~tek@ADijon-151-1-113-202.w83-203.abo.wanadoo.fr
1139919619 M * Bertl welcome PilatomiK!
1139919632 M * PilatomiK ola ola
1139919732 A * Bertl .o( why keep folks always mentioning the bad debian devels? :)
1139919991 M * nox Bertl: http://pastebin.com/554147  bonnie did the trick (;
1139920043 M * Bertl hmm, pretty short trace ...
1139920112 M * Bertl nox: do you have the kernel build tree at hand?
1139920150 M * nox Bertl: the src? or what do ya mean?
1139920159 M * Bertl yes, the src with the vmlinux
1139920170 M * nox yes
1139920188 M * Bertl I assume you have a 3/1 split selected, yes?
1139920207 M * nox yes standard
1139920225 M * Bertl let's try 'addr2line -e vmlinux c02053dc'
1139920337 M * nox addr2line: 'a.out': No such file
1139920365 M * Bertl you do that in the build tree, where the vmlinux is
1139920418 M * nox /usr/src/linux-2.6.15.4-vs2.0.2-rc2 and /usr/src/linux-2.6.15.4-vs2.0.2-rc2/arch/i386/boot/compressed/vmlinux say the same
1139920455 M * Bertl well, maybe your addr2line is broken/strange/whatever
1139920495 M * nox GNU addr2line 2.16.91 20060118 Debian GNU/Linux
1139920521 M * Bertl linux-2.6.16-rc2-vs2.1.x-P1]# addr2line -e vmlinux c0000000
1139920521 M * Bertl ??:0
1139920544 M * Bertl (non-debian :)
1139920555 M * Aiken the above error is complaining about a.out missing when it should be complaining about vmlinux missing
1139920570 M * nox omg forgot -e *blush*
1139920577 M * nox ll_rw_blk.c:0
1139920603 M * Bertl okay, nevertheless the binutils are still broken
1139920612 M * Bertl (which is not unexpected)
1139920696 M * Bertl http://sourceware.org/bugzilla/show_bug.cgi?id=2096
1139920710 M * nox and which is debugging and not panic related. right?
1139920718 M * Bertl so, let's try the gdb thingy, yes?
1139920775 M * Bertl (or alternatively, patch your binutils)
1139920811 M * nox hmm sorry gdb thingy?
1139920898 M * Bertl did you check the url I pasted?
1139920930 M * Bertl it should show you how to use gdb for the thing addr2line is supposed to do
1139921059 M * nox gdb vmlinux  just gives me a kind of shell (gdb)
1139921088 M * Bertl yup, now do
1139921099 M * Bertl l *0xc02053dc
1139921120 M * nox No symbol table is loaded.  Use the "file" command
1139921142 M * nox i am so a bloody newbie sorry
1139921159 M * Bertl hmm, could be that your kernel does not include the information
1139921171 M * Bertl could you upload the .config file somewhere?
1139921308 M * Hollow Bertl: what is the difference between the current hard sched, and fairsched? if i distribute 100% cpu equally to 5 guests, or give 5 guests a weight of 1/5 each, doesn't seem to make any difference
1139921339 J * tek_ ~tek@ADijon-151-1-93-169.w83-196.abo.wanadoo.fr
1139921381 Q * s25 Quit: Leaving
1139921386 M * Bertl welcome tek_!
1139921417 M * Bertl Hollow: which set of interval/rate values?
1139921444 M * Hollow ehm.. dunno
1139921449 M * nox Bertl: http://linuxkun.de/vserver/config-2.6.15.4-vs2.0.2-rc2-debug
1139921453 M * Bertl tx
1139921463 M * Hollow just in theory
1139921475 M * Hollow how shuold i generate numbers when i don't understand the theory yet :P
1139921490 M * Bertl hehe ... well
1139921502 M * Bertl let me give you an example
1139921531 M * Bertl let's assume that we have a 1/4th setting for two guests
1139921557 M * Hollow hard or fair?
1139921563 M * Bertl then they will be limited to 25% cpu each, given that amount is available
1139921568 M * Hollow ok
1139921575 M * Bertl normal setting as we had it before
1139921602 M * Bertl unfortunately they will not be able to use more than 50% CPU together, even if the machine is otherwise idle
1139921627 M * Hollow mhm
1139921641 M * Bertl nox, let's enable the following (for the next try :)
1139921648 M * Bertl CONFIG_DEBUG_INFO=y
1139921682 M * Bertl CONFIG_KALLSYMS_ALL=y
1139921710 M * Bertl Hollow: now, this is where the new set of values comes into play
1139921744 M * nox Bertl: ok
1139921744 M * Bertl let's assume the first guest has 1/2 set there
1139921755 Q * PilatomiK Ping timeout: 480 seconds
1139921761 Q * Aiken Quit: Leaving
1139921785 M * Bertl now it will be able to use up to 100% CPU given that the other guest is not running, or 75% cpu if it is running
1139921810 M * Hollow running means started, or not-idle
1139921818 M * Bertl not-idle
1139921865 M * Bertl if you set 1/2 for the second one too, they will reach 50% each if hogging
1139921994 M * Hollow hm
1139922063 M * Bertl I know, it is too powerful and too advanced for mere mortals, we should use the OVZ slices :)
1139922066 M * Hollow i.e. if rate2/interval2 are set, rate/interval do not matter at all?
1139922094 M * Bertl no, the rate/interval are distributed in timely fashion
1139922106 M * Bertl (i.e. as time passes by, tokens are added)
1139922125 M * Bertl when the cpu gets idle, we do a short jump into the future
1139922150 M * Bertl the only difference is, we do not use the rate/interval for this 'skipped' time, but the rate2/interval2
1139922265 M * Hollow so, we just give it extra resource if we're idle.. and this diel resources are distributed according to r2/i2?
1139922277 M * Bertl yup, precisely
1139922301 M * Bertl and we skip at least the minimum time interval required to get one process going
1139922337 M * Bertl all this now happens per cpu so that no locking or coordination is required
1139922357 M * Hollow and if we're not idle, it is limited go down until the bucket is empty and r/i applies
1139922368 M * Hollow s/is limited/will/
1139922407 M * Bertl parse error :)
1139922421 M * Bertl if the cpu is not idle, the normal rules will apply :)
1139922435 M * Bertl (no time will be skipped, r/i will be used)
1139922457 M * Hollow if the process is not idle, the (probably) full bucket, because of r2/i2 will decrease until r/i applies
1139922478 M * Bertl no, r/i will _alway_ apply as time goes by
1139922481 M * Bertl +s
1139922501 M * Bertl but the context will run as long as there are tokens in the bucket
1139922525 M * Hollow so, if r2/i2 would limit below r/i, what would happen?
1139922551 M * Bertl r2/i2 is not used for normal token handling, only for the artificially skipped time
1139922578 M * Bertl and both, r/i and r2/i2 do not have any effect on the way the token bucket is limited
1139922583 M * Hollow that's the point i guess... how can you advance time? are you a magician? :)
1139922609 M * Hollow and how much time is advanced?
1139922621 M * Bertl well, let me put it this way: that's the simplified explanation so that folks understand what happens
1139922647 M * Bertl at least so much time that one process can be scheduled
1139922649 M * Hollow that would me make nervous in your case :)
1139922692 M * Hollow maybe i should just implement the config options and let the user understand it :)
1139922754 M * Bertl well, I'd suggest to do the following:
1139922778 M * Bertl - have an interface which allows to set all values to the users liking
1139922797 M * Bertl - make a few simplified settings similar to the slices 
1139922812 M * Bertl I'll help you with the simplified cases when you get there
1139922859 M * Bertl okay patch-2.6.{15.4,16-rc2}-vs2.{0.2,1.1}-rc*.diff have been updated
1139922886 M * W0nka where are those?
1139922888 M * Hollow well, i'd prefer to understand the issue...
1139922903 M * Bertl W0nka: http://vserver.13thfloor.at/Experimental/
1139922914 M * W0nka ah, there
1139922919 M * W0nka nice...
1139922920 M * Bertl Hollow: okay, keep asking ...
1139922939 M * Hollow will reread what we have so far first..
1139923011 M * Bertl Hollow: a look at the kernel code could be helpful too
1139923089 M * Hollow jee, somehow the organization of the wiki changed alot lately..
1139923402 M * Bertl daniel_hozac: okay, going to schedule the patches for plm, please double check that I haven't forgotten something you gave me ...
1139923633 M * Bertl plm ids 4993-4996
1139923708 M * Bertl Hollow: gentoo puts /vservers in /var?
1139923713 M * Hollow Bertl: is r2/i2 is not used for token handling means the bucket does not grow by r2 each i2?
1139923718 M * Hollow Bertl: no
1139923735 M * Bertl *phew* for a short moment I was worried
1139923750 M * Hollow i do on my dev machine because my / is only 512M
1139923759 M * Hollow but default is /vservers
1139923782 M * Hollow but the user can choose this at compiltation time
1139923791 M * Bertl okay, that's fine
1139923808 M * Bertl r2/i2 are just used for the magic time warp
1139923823 M * Bertl no warp, no tokens from r2/i2 :)
1139923859 M * Hollow but how many tokens are put into the bucket if the time is advanced? none?
1139923895 M * Bertl (warp-time/i2)*r2
1139923915 M * Hollow and how do you get warp-time?
1139923930 M * Bertl when the cpu is idle, we do the time warp :)
1139923960 M * Hollow how do you calc how much time to warp?
1139923973 M * Bertl it's astounding, time is fleeting ... Madness takes it toll ..
1139924009 M * Hollow and i still wonder how one can advance time
1139924012 M * Bertl well, we _know_ how much we have to skip to get at least one process running, that's the amount we actually skip
1139924065 M * Hollow ah, it takes at least r/i*tokens_min ticks, right?
1139924166 M * Bertl well, actually MIN[i2*(tokens_min-tokens)/r2](n)
1139924166 M * Hollow hm.. no
1139924167 M * Hollow :)
1139924256 M * Hollow in other words, we have to advance until r/i has filled the bucket until tokens_min
1139924293 M * Bertl yeah, just for r2/i2 (to be precise)
1139924318 M * Hollow ah.. ic
1139924391 M * Hollow so, if r2/i2 < r/i would mean r2/i2 would never fill the bucket until min because r/i has done that already, right?
1139924411 M * Bertl no, because the 'time warp' is not real
1139924429 M * Bertl i.e. while the time is skipped, r/i does not contribute
1139924437 M * Hollow mhm
1139924450 M * Bertl okay, let me try another explanation
1139924456 M * Hollow no, i got it :)
1139924482 M * Bertl anyway, for the folks reading up and having no clue :)
1139924511 M * Bertl the basic mechanism is a 'cup' and a 'bucket'
1139924515 M * Hollow so, if the bucket is empty, and we have idle cpu, we add r2/i2 tokens -> process becomes schedulable again -> it gets further tokens from r/i
1139924558 M * Bertl the bucket has a hole, which drives the tasks (water power :)
1139924570 M * Hollow heh
1139924602 M * Bertl the scheduler now uses the cup to refill the bucket, one cup every interval
1139924608 M * Hollow but each interval drink rate liters water..
1139924643 M * Bertl are you going to mess up my trivial and intuitive analogon?
1139924651 M * Hollow no, sorry :)
1139924657 M * Bertl okay, let's restart:
1139924666 M * Bertl the basic mechanism is a 'cup' and a 'bucket'.
1139924687 M * Bertl the bucket has a hole, where water runs out to drive tasks
1139924703 M * Bertl the scheduler adds a cup of water every interval
1139924736 M * Bertl now consider many such buckets, and the scheduler checks all of them
1139924781 M * Bertl also let's add the contrain that the water level in a bucket has to be at least soandso high to drive the tasks
1139924818 M * Bertl (i.e. below that, the water will run out, but will not be able to start a once stopped task)
1139924859 M * Bertl the scheduler has individually different cups for each bucket, and different buckets for each context
1139924901 M * Bertl now when it happens that all buckets are empty/below the required minimum, and nothing goes, the scheduler does something strange:
1139924962 M * Bertl it replaces the set of cups by different ones, makes a cool guess how many cups  would be required to get at least one bucket filled (to min) again
1139924998 M * Bertl and fills up all buckets with the same amount of (different) cups
1139925051 M * Bertl (it does this within an isntant) and as soon as the first process runs (i.e. bucket reached min) it changes back all the cups to the old set
1139925089 M * Bertl the size of the cup is the rate, the interval is the time between cups
1139925111 M * Bertl for the idle time, no real time passes
1139925137 M * Bertl (well, probably needs some refinement but I guess it somewhat explains what happens)
1139925216 M * Hollow what happens if all r2/i2 don't sum up to 1? is it just the percentage that counts?
1139925240 M * Bertl doesn't matter, it is only used for the idle time
1139925284 M * Hollow but during idle time all buckets get refilled, right? (at least all with idle time set)
1139925301 M * Bertl yep, but again, according to r2/i2
1139925348 M * Hollow ok, then "it replaces the set of cups by different ones" would be the r2/i2's, right?
1139925371 M * Bertl what really happens is a little more complicated, as all this has to happen smoothly and as sideffect, as you do not want the scheduler to go around and visit every bucket
1139925393 M * Bertl Hollow: yes, that's correct, the r/i -> r2/i2 is the cup change
1139925414 M * Hollow and according to r2/i2 it guesses which bucket will be at min first
1139925431 M * Bertl yup, precisely
1139925440 M * Hollow seems like i got it
1139925528 M * Hollow i think the "time advances" is confusing... the thing with refilling in idle times made it understandable for me at least ;)
1139925984 M * Hollow Bertl: back to our example above: two contexts with r/i = 1/4, means 25% cpu at hogging
1139926021 M * Hollow now, if i set idle time for the first one r2/i2 = 1/2, would result in 75%/25% at hogging, right?
1139926036 Q * shedi Quit: Leaving
1139926081 M * Bertl yup
1139926127 M * Hollow now, if i set idle time for the second context as well to r2/i2 = 1/4, that would result in 62,5%/37,5%, right?
1139926222 M * Bertl hmm, no, actually 58.2/41.6
1139926253 M * Bertl (fractions deleted and not summing up to 100 here)
1139926286 M * Bertl thing is, 25% would be given to each one when running
1139926318 M * Bertl and 1/4 : 1/2 is a third for the second one
1139926338 M * Bertl so 25%+25% running, plus 1/3 of 50% for the second
1139926360 M * Bertl make 25+50/3 ~ 41.6
1139926362 M * Hollow and 2/3 for the first.. hm.. ok, i see my flaw..
1139926637 Q * tek_ Remote host closed the connection
1139927116 M * Hollow Bertl: is http://home.xnull.de/misc/sched.txt correct?
1139927388 M * Bertl assumed that all contexts will hog:
1139927390 M * Hollow hm, guess i made the same error as before..
1139927403 M * Bertl VX1: ((2/5)*(1/2)/(1/2+1/4+1/5)+1/5)*100 = 41.0526315700
1139927425 M * Bertl VS2: ((2/5)*(1/4)/(1/2+1/4+1/5)+1/5)*100 = 30.5263157800
1139927443 M * Bertl VX3: ((2/5)*(1/5)/(1/2+1/4+1/5)+1/5)*100 = 28.4210526300
1139927490 M * Hollow hm, i got no fractions but still the same result without them
1139927528 M * Hollow where is that (2/5) from?
1139927546 M * Bertl that's 1-(1/5+1/5+1/5)
1139927555 M * Hollow ah
1139927644 M * Bertl the first simplification one can do is make r2=r and i2=i
1139927671 M * Bertl this will give the same token distribution for active and idle time
1139927762 M * Bertl another interesting approach is to give a minimum amount to each guest, e.g. 1/10th distributed evenly over all of them
1139927796 M * Bertl (with r/i) and then use the r2/i2 to make classes (silver, gold, platinum)
1139927864 M * Bertl in your case that would be: r/i = 1/30 for all of them
1139927897 M * Bertl and r2/i2 = 1/2, 1/4 and 1/8 (for example
1139927936 M * Bertl of course, similar result would be with: r2/i2 = 4, 2, 1
1139928004 M * Hollow but it's still the users job to ensure not to give more than 100% if he wants garantees, right?
1139928105 M * Bertl yes, definitely
1139928156 M * Bertl as long as SUM[r/i](n) <= 1 you have guaranteed rates
1139928171 M * Bertl note: r2/i2 doesn't matter here
1139928181 M * Hollow yup..
1139928197 M * Hollow r2/i2 is only used to get the percentage for the idle refills..
1139928295 M * Bertl yup
1139928316 M * Hollow wow, i understand the scheduler!
1139928403 M * Bertl congrats!
1139928597 M * Hollow ok, a completely different question... regarding configuration in vserver-utils i noticed that if we use dietlibc we cannot easily use things like mysql or ldap as backends because these libraries are not built against diet.. but i definitely would prefer some sort of database which is easily searchable etc... what's your opinion on this?
1139928693 M * Bertl well, I'm not very happy about mysql or ldap (as I consider them bloated) but it should not be a problem to link the libraries dynamically, even with dietlibc
1139928730 M * Bertl a simple but generic method would be to separate the data retrieval from the command stuff
1139928743 M * Bertl i.e. make the backend communicate via e.g. sockets or so
1139928757 M * Bertl (could as well be pipes and ASCII)
1139928770 M * Hollow well, we could also implement some file based database for vsevrer-utils, or look for some which can easily be integrated into the vserver-utils tar..
1139928782 M * Bertl berkey db?
1139928790 M * Hollow it's just that users would lose the ability to edit them by hand i guess
1139928790 M * Bertl *berkley
1139928837 M * Hollow berkley or whatever, i don't know any of these so i'd have to look for one first anyway
1139928892 J * Dr4g dr4g@82-40-43-86.cable.ubr06.uddi.blueyonder.co.uk
1139928925 M * Bertl welcome Dr4g!
1139928944 M * Snow-Man Alright.
1139928951 M * Snow-Man Got an interesting question.
1139928959 M * Snow-Man I'm using vservers and am reasonably happy with them.
1139928996 M * Snow-Man At the moment I've got full Debian installs (more or less) in each vserver.
1139929012 M * Snow-Man Yet I'm only running either Postgres or Apache in each vserver (not both)
1139929018 M * Dr4g lol Bertl, do you ver sleep ?
1139929035 M * Bertl Dr4g: yup, I do :)
1139929055 M * Hollow every time i search for dietlibc related topics in google, i get vulnerability reports... :)
1139929059 M * Snow-Man I'm wondering if it's possible to have vservers act more like a chroot in that I can use the binaries from the host system instead though.
1139929112 M * Bertl Snow-Man: well, how do you use host binaries in chroots?
1139929146 M * Snow-Man hrrmmmm.
1139929150 M * Snow-Man Maybe I'm being dumb.
1139929169 M * Bertl no, the idea is old, and what you are looking for (actually) is unification
1139929198 M * Bertl but, usually you do not want to unify with the host
1139929221 M * Snow-Man nah.
1139929279 M * Snow-Man I need to figure out a better way to do these upgrades.
1139929299 M * Bertl something like vrpm would be useful there ...
1139929315 M * Snow-Man Unfortunately (well, or fortunately, kind of), I've hacked up the vservers quite a bit from the 'standard' setup.
1139929331 M * Snow-Man So just running apt-get update, apt-get upgrade wouldn't be likely to work very cleanly.
1139929339 Q * mef Remote host closed the connection
1139929347 M * Snow-Man Things like, the only users inside the vserver are, fe, root and postgres. :)
1139929361 M * Bertl maybe argue some vdpkg and get micah/enrico to do something like that?
1139929368 J * mef ~mef@targe.CS.Princeton.EDU
1139929372 M * Bertl wb mef!
1139929382 M * mef hey
1139929401 M * Snow-Man Bertl: The problem is that anything using dpkg is going to want to run postinst scripts (probably) which may get very confused by the changes I've done (to improve security)
1139929417 M * Snow-Man Bertl: And could get upset about not being able to do things (like create device nodes)
1139929471 M * Bertl well, it seems to work for the install, no?
1139929496 M * Snow-Man Bertl: err, the install wasn't done in a vserver...
1139929504 M * Snow-Man It was done using regular chroot.
1139929516 M * Bertl and the vdpkg would use similar :)
1139929527 M * Snow-Man Or maybe it wasn't, but either way, the problem is it's like this:
1139929535 M * Snow-Man install -> hack up lots of stuff -> further upgrades break
1139929549 M * Snow-Man I suppose I could not hack it all up.
1139929554 M * Bertl well, maybe rsync?
1139929555 M * Hollow Bertl: do you know cdb?
1139929567 M * Bertl Hollow: nope
1139929570 M * Snow-Man Bertl: That's the kind of thing I was thinking about actually.
1139929597 M * Hollow it's used in qmail and djbdns.. it's a read-only library implementation.. very slim (and probably fast)
1139929609 M * Hollow *read-only database
1139929620 M * Snow-Man Does mean I have to basically do a new install, hack that up, and then figure out what to rsync.
1139929624 M * Hollow and you create the database from normal text files
1139929648 M * Snow-Man Maybe I'll just not hack the system up so much, since otherwise I could probably get the upgrades to work.
1139929666 M * Snow-Man There's some risk, but it's probably worse to not be doing regular updates.
1139929679 M * Hollow but it's probably hard to set any values automatically
1139929710 M * Bertl Hollow: is it from djb?
1139929714 M * Hollow yup
1139929725 M * Bertl well, then I'd suggest to keep your hands off :)
1139929730 M * Hollow lol
1139929738 M * Hollow why?
1139929748 M * Hollow i already use libowfat :)
1139929756 M * Hollow which is a gplized version of his libraries
1139929762 M * Bertl djb probably has a completely own idea how databases have to work, and of course it is the _only_ way how they work
1139929796 M * Hollow *gg*
1139929800 M * Hollow if it works...
1139929811 M * Hollow but i guess the read-only is not appropriate for us
1139929814 M * W0nka djb sucks
1139930586 M * Bertl Hollow: http://vserver.13thfloor.at/Devel/PAT-2.1.1/delta-vnet-fix01.diff
1139930609 M * Bertl but only the devel branch is affected, stable should show 'the right' thing
1139930688 M * Hollow heh, yeah..l that's the fix i suggested back then.. :)
1139930702 M * Bertl well, it is now understood :)
1139930727 M * Hollow ok, what about some now proc implementation you told me?
1139930731 M * Hollow s/now/new/
1139930742 M * Bertl didn't happen yet ...
1139930762 M * Hollow what was it about?
1139930777 M * Bertl sequencer interface probably, maybe moving to debugfs too
1139930819 M * Hollow ok, don't know both of the, but i guess you'll explain it once we use it :)
1139930833 M * Bertl sure
1139931705 J * shedi ~siggi@inferno.lhi.is
1139931777 M * Roey hey all
1139931778 M * Roey Bertl
1139931780 M * Roey shedi, hollow
1139931795 M * matti Bertl: OMG, djb stuff?
1139931801 M * Roey what's that?
1139931805 M * shedi hi hi Roey 
1139931813 M * Roey heh :)
1139931820 M * Bertl hey matti! Roey!
1139931827 M * Roey Bertl:  you're always so positive!
1139931828 M * matti Bertl: This guy have it's own idea "how to stuff should work" about almost everything.
1139931859 M * matti Bertl: I think, that even coffee machine in his world works different ;]
1139931868 M * Bertl I'm sure about that :)
1139931870 A * matti hates djb...
1139931917 M * Roey what's djb?
1139931934 M * matti Roey: Believe me, ya don't want to know.
1139931947 M * Roey heh, alright.
1139931955 M * matti :>
1139931980 M * Hollow hey Roey, and bye all, i need a "creative break" ;)
1139931995 M * Roey Do you guys think that  vserver might be a non-integrated approach, and that the Linux kernel could stand to grow some better abilities to limit processes?
1139931996 M * matti Bye Hollow, enjoy break.
1139932000 M * Roey ciao Hollow!
1139932019 M * Roey Like, for instance, limiting which other process one process can see.
1139932066 M * Bertl well, the 'see' part is not the only thing which is important
1139932087 M * Bertl of course you could do some complicated n:m rule set who sees whom 
1139932111 M * Bertl but there is no real point in doing so, except for the fun of doing it ... 
1139932151 M * Roey hmm
1139932155 M * Bertl a more important details (currently addressed by ebiederm) is that you want 'independant' pids per guest
1139932162 M * Roey aside from the abstraction stuff.
1139932181 M * Bertl (which are a prerequisite for snapshoting and migration)
1139932200 M * Roey snapshotting how so?
1139932219 M * Bertl well, that's something a lot of folks are working on
1139932295 M * Roey what exactly
1139932298 M * Roey is there a homepage?
1139932367 M * Bertl google will find some for you
1139932461 M * Bertl http://www.ncl.cs.columbia.edu/research/migrate/ (e.g.)
1139932536 M * Roey thanks :)
1139932539 M * Bertl IBM is doing their own thing
1139932572 M * Roey I wonder if this clashes with mosix & openmosix.
1139932585 M * Bertl well, for sure it does :)
1139932618 M * Roey because mosix affords the same thing, essentially....
1139932625 M * Roey process migration amont networked machines.
1139932639 M * Bertl well, only partially
1139932751 M * Roey mosix is only partial, you say?
1139932763 M * Bertl mosix keeps a head node
1139932768 M * Roey oh I didn't know that
1139932777 M * Roey it would be nice if you could have checkpointing for fault tolerance
1139932779 M * Roey knock out a node
1139932782 M * Roey and the other nodes keep going.
1139932802 M * Roey and I saw checkpointing on that IBM page you referred to me
1139932829 M * Bertl (that was columbia, not ibm)
1139932853 M * Roey oh, ok.
1139932891 M * mef bertl: any further contact with the columbia folks?
1139932899 M * Bertl nope
1139932905 M * Roey "Our experimental results for migrating pods used for running a standard user's X windows desktop computing environment and for running an Apache web server show that these kinds of pods can be migrated with subsecond checkpoint and restart latencies."
1139932907 M * Roey interesting.
1139933915 N * ebiederm_zZ ebiederm
1139933946 M * Bertl morning ebiederm!
1139933951 M * ebiederm morning.
1139934085 J * dothebart ~willi@xdsl-213-196-242-186.netcologne.de
1139934134 M * Bertl wb dothebart!
1139934283 M * ebiederm Hmm. subsecond checkpoint and restart latencies...  That must mean the applications don't use any ram to speak of.  Which is typical of desktop workloads.
1139934285 M * Roey hey ebiederm 
1139934285 M * Roey :)
1139934359 M * Bertl ebiederm: well, just depends on the ram/bus/IO speed, no?
1139934431 M * ebiederm Bertl:  The program is important too.  There are programs that have a big enough working set to fill an entire machine.
1139934445 M * ebiederm For any given machine.
1139934456 M * ebiederm Hmm....
1139934504 M * ebiederm I guess memory and I/O speeds are fast enough if you just care about migration a second or a couple seconds could be enough.
1139934642 M * ebiederm Basically you can do just about everything quickly until you get disks involved.
1139934826 M * phreak`` Bertl: did my mail to the ml get through ?
1139934863 M * Bertl hmm, which one?
1139934892 M * phreak`` Bertl: Re: [Vserver] Vservers and RAID (5 & hard)
1139934896 A * Bertl wonders why everybody ask him, while there are almost realtime archives :)
1139934911 M * phreak`` bah, yeah *g*
1139934943 M * Bertl yup, it did get through, and it shocked me for an instant
1139934946 Q * ebiederm Quit: Leaving
1139934962 M * Bertl luckily Hollow could explain that this is not true :)
1139934995 M * Roey phreak``:  someone running raid /in/ a vserver!?
1139935000 J * ebiederm ~eric@ebiederm.dsl.xmission.com
1139935010 A * ebiederm bad mouse!
1139935031 M * Bertl ebiederm: ah, and I thought it was the cat? :)
1139935070 M * Roey the cat's suspended in an ebiedermatic emulsion
1139935090 M * ebiederm I seem to remember this conversation.....
1139935095 M * Roey well yes
1139935098 M * Roey I just can't get over it
1139935105 M * Roey I chuckle just reading your nick
1139935109 M * Roey perhaps there is something wrong with me.
1139935111 M * Roey I apologize.
1139935111 M * ebiederm Was this conversation just restared from an old checkpoint?
1139935134 M * ebiederm :)
1139935166 M * Roey ebiederm:  heheheh :)
1139935375 M * ebiederm All seems quiet on the Kirill front today.
1139935389 M * Bertl yup
1139935491 M * ebiederm Bertl: You mentioned security holes in /proc?
1139935530 M * Bertl yup, it's basically full of them :)
1139935539 M * ebiederm Bertl: In what sense.
1139935548 M * Bertl it's the non-proc stuff
1139935556 Q * prae Quit: Execute Order 69 !
1139935561 M * ebiederm Oh.  Ok.
1139935563 M * Bertl which usually assumes that uid=0 is fine
1139935581 M * Bertl cd ..
1139935585 M * Bertl *oops*
1139935593 M * matti ;-p
1139935616 M * ebiederm sysfs largely has the same problem :(
1139935621 M * Bertl yup
1139935725 M * ebiederm I am currently looking for issues more serious than setting the permissions wrong.
1139935734 M * ebiederm Not that problem permissions aren't serious.
1139935890 M * ebiederm There are currently a lot of stupid things like not caching /proc/self in the dcache....
1139935922 M * phreak`` Bertl: yeah *g* I noticed it immediately after I sent the mail ..
1139935997 M * ebiederm Bertl how do you handle the security issues in /proc?
1139936035 M * Bertl vprocunhide
1139936049 M * Bertl we basically hide away all entries by default
1139936063 M * Bertl then have a set of _known good_ entries to bring bag
1139936066 M * Bertl *back
1139936307 M * ebiederm I suspect you could do about as well by inserting a check for CAP_SYS_ADMIN in the proc_file_write in generic.c ...
1139936346 M * Bertl would work only for a part of it, but a larger part, yes
1139936385 M * ebiederm What is ironic is that for the common files in /proc when we are done are likely to remain and become per process. :)
1139936636 Q * shedi Quit: Leaving
1139936678 M * daniel_hozac that turned out to be a really long nap...
1139936714 M * Bertl gee, now you missed everything :)
1139937032 J * bonbons ~bonbons@83.222.39.180
1139937437 M * ebiederm Bertl:  I am about ready to go back and exam the plan9 way of doing permissions.
1139937504 M * ebiederm Plan9 has does everything with just unix permissions.
1139937564 M * ebiederm But it has 2 well know root users.  The local root and the remote root.... (or were they sally and bob?)
1139937606 M * ebiederm Anyway I think being able to set an owner, and having a default owner might interroperate better with the rest of unix world.
1139937657 M * ebiederm Then replace caps by groups... or something like that.
1139937714 M * Bertl ahem, well, actually I'd prefer to replace uid=0 checks by caps :)
1139937817 M * ebiederm Well if we could map the problem into the normal unix permission domain it would likely be easier to deal with and fewer people would get it wrong.
1139937856 M * Bertl well, would open a can of worms for VPS/jail approaches
1139937857 M * ebiederm But yes.  More resolution on the permissions is definitely needed.
1139937884 M * Bertl you simply cannot take away uid=0 from guests, but you can do so with certain capabilities
1139937916 M * ebiederm Bertl: For VPS/jail approaches you set CLONE_NEWUID or whatever and then UID == 0 simply doesn't map to the other UID == 0.
1139938009 M * ebiederm Anyway something to ponder...  
1139938075 M * ebiederm I know for the general case we need to solve it but so far I don't :)
1139938133 M * Bertl okay, have to leave now ... will be back in the evening ...
1139938135 M * ebiederm I wonder if we need to place a capabilities bitmap on kobjects for sysfs?
1139938138 M * ebiederm Later.
1139938152 M * ebiederm Although I though it was evening in your timezone already :)
1139938156 M * Bertl guess first we need finer grained caps ...
1139938163 M * Bertl later
1139938167 N * Bertl Bertl_oO
1139938299 M * daniel_hozac hmmm, where did the name_to_dev_t issues come from?
1139939154 J * Viper0482 ~Viper0482@p5497762D.dip.t-dialin.net
1139940326 J * liquid3649_ ~Viper0482@p549758A0.dip.t-dialin.net
1139940327 M * daniel_hozac oh, because of #include <linux/mount.h> in linux/fs.h. but then, why aren't we getting it on the devel series?
1139940781 Q * Viper0482 Ping timeout: 480 seconds
1139940995 Q * bonbons Quit: Leaving
1139941323 J * cdrx ~legoater@pixpat.austin.ibm.com
1139942651 Q * gerrit Ping timeout: 480 seconds
1139944282 J * prae ~benjamin@sherpadown.net
1139944945 Q * cdrx Ping timeout: 480 seconds
1139944952 J * gerrit ~gerrit@bi01p1.co.us.ibm.com
1139946058 J * Doener doener@i5387C8A7.versanet.de
1139946135 J * bonbons ~bonbons@83.222.39.180
1139946856 Q * SuperLag Quit: brb
1139947043 J * SuperLag ~aaron@38.99.66.175
1139948073 J * shedi ~siggi@inferno.lhi.is
1139948370 J * Vudumen vudumen@217.20.138.14
1139948376 Q * Vudumen Quit: 
1139948986 Q * FireEgl Quit: Bye...
1139949678 M * mugwump oh, hey, thanks for the 2.1.1-rc3 against 2.6.16-rc2
1139949695 M * mugwump I'll get a delta of that into my repo soon.  Any chance of a split?  :)
1139949793 J * cdrx ~legoater@pixpat.austin.ibm.com
1139950537 M * Roey daniel_hozac:  hi
1139950538 M * Roey daniel_hozac:  hey
1139950545 M * Roey daniel_hozac:  I thought I recognized your nick from somewhere
1139950552 M * Roey you're a member of MOTU right?
1139950564 M * daniel_hozac what's MOTU?
1139950590 M * Roey master of the universe
1139950594 M * Roey oh
1139950596 M * Roey daniel holbach maybe?
1139950598 M * Roey dunno
1139950612 M * daniel_hozac never even heard of that :)
1139950641 M * Roey ok :)
1139950751 Q * lilalinux Remote host closed the connection
1139950752 J * FireEgl Atlantica@Atlantica.DollarDNS.Net
1139950869 J * Aiken ~james@tooax7-237.dialup.optusnet.com.au
1139951425 Q * gerrit Ping timeout: 480 seconds
1139951792 Q * liquid3649_ Quit: bin raus, 
1139952758 Q * bonbons Quit: Leaving
1139952804 J * gerrit ~gerrit@bi01p1.co.us.ibm.com
1139953360 P * meandtheshell 
1139953390 M * ebiederm Darn.  I just found a justification for my task_refs....
1139953439 M * ebiederm  /proc needs them, or else you can suck up all of the memory on your box by forking and opening files in /proc.
1139953588 M * mugwump task_refs ?  refs to individual task_struct's ?
1139953607 M * mugwump include/linux/vs_context.h:20: error: dereferencing pointer to incomplete type
1139953616 M * ebiederm mugwump: Yes.
1139953619 M * mugwump ^^ I just don't understand that error
1139953658 M * ebiederm The core problem is that task_struct is large.
1139953671 M * ebiederm mugwump: What does line 20 look like?
1139953683 M * ebiederm The error sounds reasonable.
1139953701 M * mugwump I'm just not sure why it does that after adding the debugging patch but not before
1139953722 M * Doener mugwump: declaration of a struct is given but no definition, I'd say
1139953723 M * mugwump ah, except that the debugging patch changes the function to be a #define
1139953733 M * ebiederm mugwump: So if you are going to hold a reference to struct_task indefinitely you need some kind of indirection so the task_struct can be freed.
1139953750 M * Doener that's fine for passing pointers around, but not for using them (like foo->bar)
1139953770 M * mugwump line 20 of this revision: http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=blob;h=fb21a11a47925043c801b1ecd7d2487ea2ba3907;hb=d09bd3def9ecf130ec2390b9dc74e229b651c1a5;f=include/linux/vs_context.h
1139953796 M * mugwump basically it's the atomic_inc()
1139953808 M * Doener it's the vxi->vx_usecnt
1139953812 Q * gerrit Ping timeout: 480 seconds
1139953830 M * Doener you need to include the header for struct vx_info
1139953853 M * Doener (probably in the file that includes vs_context.h, not sure though)
1139953855 M * mugwump I think in the main patch vserver/debug.h includes a lot
1139953915 M * mugwump yup, that's it, thanks Doener 
1139953918 M * Doener yw
1139953993 M * ebiederm Doener: Basically I have found a loop hole where I can have nr_threads*nr_files task_structs at any one time.
1139954046 M * ebiederm And since I can get around the ulimits I can likely push any machine OOM...
1139954236 M * ebiederm Although there may be an acceptable specific solution in this instance.
1139954257 M * ebiederm Instead of the general solution I was playing with earlier.
1139954404 M * ebiederm Looks like a specific solution to drop the struct task_struct pointer from the proc inode when the process is freed would be complicated.
1139954547 J * gerrit ~gerrit@bi01p1.co.us.ibm.com
1139954768 M * ebiederm I think that is a problem by I may be wrong....
1139954850 M * Skram Hi All.
1139954862 M * ebiederm hi
1139955036 M * mugwump well, the umbrella structure solves the outliving issue
1139955106 M * ebiederm mugwump:  I can trigger outliving issues without virtualization.
1139955120 M * mugwump heh
1139955122 M * ebiederm Just open a /proc/<pid> directory in proc .
1139955130 M * mugwump can you get an oops out of that?
1139955144 M * ebiederm I haven't tried yet.  All I should be able to get is an OOM.
1139955161 M * mugwump ah, right
1139955263 J * Matthew_Sayler ~chatzilla@216-80-44-159.drb-bsr1.chi-drb.il.cable.rcn.com
1139955360 M * Matthew_Sayler is there more documentation (than http://linux-vserver.org/Linux-VServer-Paper-14 #14.21 [E46] ) on CPU limiting
1139955362 M * Matthew_Sayler ?
1139955371 M * Skram CPU, not sure..
1139955373 M * mugwump yes, search for token bucket
1139955385 M * Skram I recently figured out Memory stuff.
1139955387 M * mugwump also the flower page, search for sched
1139955422 M * Matthew_Sayler thanks.  I'm finally geting off my duff and replacing ancient debian vserver packages with recent vserver stuff and looking at some of the featuresets that I can now exploit
1139955600 M * Matthew_Sayler sched_prio == "soft" scheduling, right ?
1139955659 M * mugwump they're both the same feature, it's just the soft scheduler doesn't rudely stop processes from being scheduled just because they have temporarily run out of tokens
1139955663 M * mugwump it's just a flag
1139955667 M * mugwump soft vs hard
1139955670 M * Doener sched_prio just adjusts priorities, somewhat like 'nice', as the other mode is called hard scheduling, I suppose that soft scheduling is a appropriate term
1139955693 M * Doener while the hard scheduler actually stops the context from running
1139955744 M * Matthew_Sayler some of the docs refer to "soft"
1139955754 M * Matthew_Sayler that was the only ?
1139955779 J * iW|Rebel ~rebel@host153-238.pool875.interbusiness.it
1139955842 M * iW|Rebel hi, I would need help with klogd and cpu usage.
1139955859 M * Matthew_Sayler is default no special scheduling (all processes schedules as system processes) ? or sched_prio with the defaults mentioned in http://linux-vserver.org/index.php?page=Scheduler+Parameters (1/4//15/125) ?
1139955887 M * daniel_hozac default is no special scheduling.
1139955910 M * Matthew_Sayler excellent.  I may make a note of that on the Scheduler Parameters page
1139955946 M * Doener iW|Rebel: hm, using quite an ancient kernel?
1139955975 M * iW|Rebel Linux vs1 2.6.14.3-vs2.0.1-Netsons-VS #5 SMP
1139956018 M * iW|Rebel klogd takes whole cpu. :\ 
1139956019 M * Doener hmm, that's strange... IIRC we fixed that... anyway, you can simply remove klogd
1139956029 M * Skram is cpu limiting as easy as RAM?
1139956037 M * Skram I just started litening to the conversation ;)
1139956039 M * iW|Rebel yes, by schedules
1139956069 M * iW|Rebel if I unload klogd, sysklogd will still work?
1139956080 M * Doener yes
1139956095 M * Doener you can safely remove it from your runlevels
1139956122 M * Doener (assuming that there are some package dependencies that force you to keep it installed)
1139956137 M * iW|Rebel that's the problem
1139956158 M * iW|Rebel on debian I cant uninsall klogd because sysklogd depends on it
1139956309 M * iW|Rebel no, wait I got it.
1139956403 M * michal_ http://metawire.org/~parasitical/vulns/berliospass/
1139956406 M * michal_ that's not nice
1139956409 M * daniel_hozac Doener: hmm, why isn't vx_do_syslog(2... a NOOP?
1139956602 M * iW|Rebel <Doener> hmm, that's strange... IIRC we fixed that... anyway, you can simply remove klogd
1139956614 M * iW|Rebel should I go for a differente kernel?
1139956675 M * Doener iW|Rebel: might be that I'm wrong and we just fixed some other thing, that was caused by the mad klogd...
1139956696 M * Doener are you running the vserver on a local box, with X running?
1139956714 M * daniel_hozac Doener: the virtualized kmsg is present in 2.0.1.
1139956719 M * iW|Rebel no, on a server dedicated to vservers
1139956749 M * Doener iW|Rebel: ok, i just remember that the klogd also caused the mouse to stop working...
1139956766 M * iW|Rebel ah ok, :D
1139956789 M * iW|Rebel is this bug supposed to be solved soon?
1139956803 M * daniel_hozac it is supposed to be solved already.
1139956808 M * iW|Rebel ah ok
1139956828 M * iW|Rebel should I try Development Sources?
1139956869 M * daniel_hozac that particular part hasn't changed, but it can't hurt.
1139957371 M * Doener daniel_hozac: good question, and i have no idea ;)
1139957397 M * Doener IIRC I asked Bertl the same once... I'll check my irc logs
1139957416 M * daniel_hozac hehe.
1139957473 M * Matthew_Sayler iW|Rebel -- FWIW 2.6.15.4 + 2.0.1 on Debian no problems
1139957474 M * Doener daniel_hozac: ok, there are there since 1.9.6
1139957477 M * Doener Mar 27 01:12:22 Bertl for locking the virtual syslog buffer, yet to be implemented
1139957477 M * Doener Mar 27 01:12:34 Bertl ;)
1139957482 M * Matthew_Sayler klogd exits if it starts
1139957522 M * iW|Rebel thx Matthew_Sayler. :)
1139957542 M * Doener hm, actually neither of these behaviours is what I'd expect...
1139957578 M * daniel_hozac Doener: i guess that makes sense, but since the others are just return 0; it seemed a bit strange.
1139957611 M * Doener daniel_hozac: I guess I had the same thought back then :)
1139957626 M * daniel_hozac i agree, klogd should stay running, without any problems.
1139957671 M * daniel_hozac it just wouldn't be logging anything.
1139957743 M * daniel_hozac hmm, -EPERM.
1139957776 M * Doener maybe a flag is needed? it's so long since I read that code...
1139957816 M * daniel_hozac no, it's just a vx_check(0, VX_ADMIN|VX_WATCH).
1139957822 M * daniel_hozac i guess it's failing before that.
1139957857 M * daniel_hozac security_syslog...
1139957899 M * Doener yep, VXC_SYSLOG
1139957908 M * daniel_hozac hmm, where do you see that?
1139957955 M * Doener in security_syslog (the capabilities version in include/linux/security.h)
1139957974 M * Doener well, actually cap_syslog() which is called from there
1139958005 M * Doener only 3 and 10 are allowed without it
1139958023 M * daniel_hozac ah.
1139958128 M * daniel_hozac are there any downsides of using it?
1139958194 M * Doener not any i'm aware of
1139958232 M * daniel_hozac seems like the sort of thing that util-vserver should give by default.
1139958618 J * Smutje_ ~Smutje@87.78.99.184
1139958775 Q * Smutje Ping timeout: 480 seconds
1139958775 N * Smutje_ Smutje
1139958801 Q * prae Quit: Pwet
1139959076 M * Doener i'm off to bed, good night everyone!
1139959078 Q * Doener Quit: Leaving
1139959658 Q * mkhl Quit: 
1139960100 Q * cdrx Quit: Leaving
1139960533 J * mkhl mkhl@200-153-181-170.dsl.telesp.net.br
1139960988 Q * iW|Rebel Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )
1139961511 Q * Matthew_Sayler Quit: Chatzilla 0.9.70 [Firefox 1.5.0.1/2006011112]