1131667313 N * Bertl_zZ Bertl 1131667322 M * Bertl evening folks! 1131667377 M * anonymouse Hey Bertl 1131667460 M * Bertl anonymouse: you might consider disabling overcommitment on the server 1131667505 M * anonymouse Will that disable the RSS limits too though? 1131667607 M * Bertl no, but it should avoid OOM kills, and instead report out of memory on allocation 1131667640 M * anonymouse Aaah, OK - will that result in a "more friendly" handling of memory limits then? 1131667658 M * anonymouse It's just that my users are moaning that random processes get killed off.. 1131667658 M * anonymouse :) 1131667685 M * anonymouse I've searched linux-vserver.org and google for info about overcommitment, but can't find anything 1131667823 M * Bertl Documentation/vm/overcommit-accounting 1131667823 M * Bertl Documentation/sysctl/vm.txt 1131667828 M * Bertl Documentation/filesystems/proc.txt 1131667841 M * anonymouse Oh - it's not a vserver thing? 1131667842 M * Bertl (in your kernel tree :) 1131667864 J * cereal koepi@217.20.124.153 1131667872 M * Bertl nope, nothing vserver specific 1131667988 M * anonymouse Hmmm, this looks deep. 1131668013 M * anonymouse If I enable no overcommit, and leave it at 50% of physical, does that mean that the other 50% never gets used? 1131668129 M * Bertl leave _what_ at 50% :) 1131668129 M * anonymouse "This feature can be very useful because there are a lot of 1131668131 M * anonymouse programs that malloc() huge amounts of memory "just-in-case" 1131668131 M * anonymouse and don't use much of it. 1131668131 M * anonymouse " 1131668140 M * anonymouse I think that's what the problem is down to 1131668186 M * Bertl memory, not used, will not show up as RSS 1131668200 M * Bertl RSS _is_ per definition, memory which _is_ used 1131668203 M * anonymouse Aah, OK 1131668233 M * Bertl personally I think that if your guests experience OOM kills, then the guest limits are too low 1131668241 M * anonymouse Oh, indeed. 1131668252 M * anonymouse But I am limited in physical mem, and I have to set some limits 1131668274 M * anonymouse They are trying to run a lot of daemons in a smallish amount of mem 1131668285 M * anonymouse amavisd seems to be quite a culprit 1131668351 M * anonymouse Say there is a 100MB limit - if a prog. allocates 100MB, and uses 2MB, and another program asks for 10MB, will that fail? 1131668396 M * Bertl no, the problem is more that you can not do memory limits like you know them from real hardware, and use the benefit of sharing and/or avoid time consuming things like swapping ... 1131668440 M * Bertl let me give a few examples for the issues you encounter (or would encounter) 1131668445 M * anonymouse OK :) 1131668456 M * Bertl maybe you have a great idea how to solve them :) 1131668475 M * Bertl the current status of memory allocation/limits is: 1131668497 M * Bertl - process requests some memory, let's say 64MB 1131668514 M * Bertl - this is immediately accounted to the VM (if granted) 1131668529 M * anonymouse Can you just explain VM? 1131668535 M * anonymouse I think it means Virtual Memory 1131668540 M * Bertl - now the process starts filling up the memory with zeros 1131668547 M * anonymouse But maybe it means something else to you kernel-people 1131668560 M * Bertl (yes, VM or AS is Virutal Memory or Address Space) 1131668565 M * anonymouse OK 1131668579 M * anonymouse And VM doesn't mean swap to you? 1131668593 M * Bertl - for every page (4k on x86) overwritten with zeros, a page of RSS is required (and allocated) 1131668608 M * Bertl (no VM doesn't mean swap) 1131668626 M * Bertl (RSS means Resident Set Size) 1131668656 M * Bertl - once the RSS limit is reached the kernel does either: 1131668683 M * Bertl - a) swap out pages (if all RSS is used on the host) 1131668712 M * Bertl - b) deny any further requirests (with overcommit off) 1131668728 M * Bertl - c) kill processes to resolve the OOM issue 1131668772 M * Bertl now unfortunately a) only kicks in if you are really low on RSS, which is not always the case if 'just' the guest hits the limit 1131668793 M * anonymouse So a relates to the whole memory 1131668802 M * anonymouse Not just the chunk allocated to the vserver? 1131668818 M * Bertl yep, and b) does not apply if you already allocated the memory (overcommit) 1131668843 M * anonymouse So C is the answer currently 1131668852 M * Bertl the default ... 1131668861 M * Bertl now what solutions could be imagine: 1131668888 M * Bertl - 1) start swapping once over RSS (guest specific) 1131668916 M * Bertl - 2) ignore the RSS limit (i.e. make it soft) and take it only as hint 1131668934 M * Bertl - 3) do not allow allocation/swapping at all 1131668951 Q * eugenesan Quit: Trillian (http://www.ceruleanstudios.com 1131668954 M * Bertl now 1) sounds pretty good at first glance ... 1131668960 M * anonymouse Indeed.. :) 1131668970 M * Bertl but actually it is a nightmare on setups like yours 1131668980 M * Bertl the explanation is simple ... 1131668989 M * anonymouse But I imagine that it would need contexts in the swapping part of the code 1131668991 M * anonymouse ? 1131668997 M * anonymouse s/code/kernel/ 1131669008 M * Bertl just consider 10 guests, each having 64MB of 'RAM' assigned and 128MB of swap 1131669047 M * FaUl .oO( the harddisk will eat flaming death if at least 2 contextes will begin to swap ) 1131669049 M * Bertl further, let's assume that your guests are 'slighly' over the 64MB memory limit (otherwise they would not see OOM :) 1131669108 M * Bertl now, guest 01 gets the cpu, and writes to a page, which leads to swapping out another page in that context 1131669149 M * Bertl once the swap is finished, or even while it is going on (swaps take long), guest 02 is writing to a page, and starts another swap 1131669163 M * micah howdy all 1131669179 M * Bertl once you reach guest 10, the scheduler starts with guest 01, which again swaps in it's pages ... 1131669185 M * anonymouse And you end up with a big queue for the disks...? 1131669189 M * Bertl hey FaUl!, micah! 1131669205 M * FaUl Bertl: let me guess: the harddisk does not use TCQ and so will eat flaming death :-) 1131669229 M * Bertl anonymouse: yes, you will end up with 100% swapping, while still some RAM is available ... 1131669291 M * anonymouse Is it possible for the host to allocate some RAM as a cache for the swap, so that commonly used pages don't actually go to disk? 1131669299 M * anonymouse Or is that making it all very messy, and nasty? 1131669301 M * FaUl Bertl: is something like guaranteed ram and max usable ram thinkable? like htb allows in the traffic-shaping code? 1131669340 J * eugenesan eugenesan@bzq-219-189-203.cablep.bezeqint.net 1131669386 M * anonymouse I don't think the problem would be so bad if it wasn't **random** processes that got killed off 1131669410 M * FaUl hm, anyway. i wallpaperd the whole day and i'm realy beat-up 1131669412 M * anonymouse Because that can lead to the parent apache dying, which is worse than a spare apache server process dying 1131669422 M * anonymouse Hello FaUl , btw 1131669423 M * anonymouse :) 1131669440 M * FaUl anonymouse: just let apache respawn from the init-process :-) 1131669443 M * Bertl anonymouse: that's the probelm with OOM 1131669474 M * anonymouse Bertl, I can't give everyone the RAM they want.. :( 1131669484 M * Bertl now, one 'solution' I'm looking at, is to define a soft and hard RSS limit 1131669485 M * FaUl if the init-process got killed your system is fucket anyway :-) 1131669513 M * anonymouse FaUl, The init hasn't been killed off yet. (And shouldn't do, if I'm right.) 1131669517 M * Bertl where the soft limit would lead to 'prefered' page swapout 1131669544 M * anonymouse So in your previous example - soft = 60, and hard = 64? 1131669551 M * micah Bertl: if the result of a setattr --barrier /vservers/XXXX/.. is "Operation not permitted", what does this mean? 1131669580 M * Bertl that you are missing some capabilites or security stuff did kick in 1131669615 M * anonymouse Aren't you suppsed to set the barrier at the root vserver directory, not one of the actual vdirs? 1131669617 M * Bertl anonymouse: no, I was more thinking of something like 64MB soft, and 384MB hard (256+64 1131669618 M * micah Bertl: this is what my debian kernel tells me 1131669629 M * FaUl n8 1131669636 M * Bertl micah: strace -fF please ... 1131669672 M * anonymouse Bertl, So everything after 64MB would be swapped out 1131669705 M * anonymouse Does the host VM do all the allocation for the all the guests? 1131669713 M * anonymouse I suppose it has to 1131669715 M * Bertl would be preferred in case of swapping out 1131669717 M * micah Bertl: ioctl(3, EXT2_IOC_GETFLAGS, 0xbffffd44) = 0 1131669736 M * micah ioctl(3, EXT2_IOC_SETFLAGS, 0xb4444d44) = 0 1131669753 M * micah fchmod(3, 0) = -1 EPERM (Operation not permitted) 1131669812 M * Bertl what is the fchmod supposed to do? 1131669907 M * Bertl (looks like the legacy chmod 000 stuff :) 1131669958 M * micah ya, this is my debian 2.4 kernel test using qemu method from the other night 1131670048 M * micah does this mean that the ext2 filesystem attributes aren't working right in this kernel? 1131670256 M * Bertl no, the fchmod() is denied, and that's quite correct 1131670280 M * Bertl nobody is permitted to mess with the barrier, not even root 1131670306 M * Bertl micah: what I'm saying is, that your tools seem to do/try strange things ... 1131670311 M * Bertl (checking here now) 1131670352 M * micah Bertl: this is from using the tools in TEST_32M_public2.img 1131670407 M * Bertl # strace -fF setattr --barrier /vservers/ 1131670407 M * Bertl execve("/usr/sbin/setattr", ["setattr", "--barrier", "/vservers/"], [/* 6 vars */]) = 0 1131670410 M * Bertl lstat64("/vservers/", {st_mode=S_IFDIR, st_size=1024, ...}) = 0 1131670413 M * Bertl vserver(VCMD_00,0[0], 63) = 131073 1131670415 M * Bertl vserver(VCMD_38,2[1], 0) = 0 1131670418 Q * tchan Remote host closed the connection 1131670418 M * Bertl _exit(0) = ? 1131670448 M * Bertl so, there is no fchmod and ioctl here, might it be that your kernel is announcing a very old version? 1131670470 M * Bertl (tools have backwards compatibility built in) 1131670565 Q * shedi Ping timeout: 480 seconds 1131670621 M * micah Bertl: hmm could be... is there a way to test? 1131670681 M * Bertl what does testme.sh report (line 3/4) 1131670723 M * micah everything is working/succeeded 1131670791 M * Bertl how unusual ... no seriously, the line _above_ the first succeded test 1131670811 M * micah --- 1131670812 M * micah :) 1131670819 M * micah you mean the VCI: 1131670820 M * micah ? 1131670842 M * Bertl hmm, k, let's try something else 1131670845 M * micah Linux 2.4.27+vserver1.2.10 i686/0.30.209/0.30.209 [Ea] (0) 1131670950 M * Bertl hmm, are you absolutely sure about the tools? 1131670982 M * Bertl ah, that on 2.4.27 again! 1131670989 M * Bertl *that's 1131670996 M * micah well, I am running qemu with -hda TEST_32M_public2.img -hdc woody.img and setattr is in /usr/sbin 1131671014 J * tchan ~tchan@c-67-174-18-204.hsd1.il.comcast.net 1131671029 M * micah yeah, you must have missed that 1131671040 J * shedi ~siggi@inferno.lhi.is 1131671053 M * Bertl welcome tchan, shedi! 1131671068 M * Bertl micah: nobody uses such outdated kernels nowadays ... :) 1131671075 M * micah hehe, I wish! 1131671171 M * Bertl okay, tools do the chmod here, but do not complain 1131671181 M * Bertl (2.4.31-vs1.2.10) 1131671221 M * Bertl I'll check the conditions there ... sec 1131671223 Q * anonymouse Quit: Leaving 1131671271 M * Bertl Greek0: let me know when you want to continue :) 1131671427 M * Bertl micah: can you upload the fs/open.c of your kernel? 1131671462 M * micah Bertl: yes i can, one moment 1131671604 M * micah Bertl: http://crow.riseup.net/~micah/open.c 1131671767 M * Bertl hmm, it's quite different from a vs1.2.10 kernel? what vserver version is that? 1131671844 M * micah mmm, actually I am not positive that source has been patched, let me check 1131672418 M * micah Bertl: http://crow.riseup.net/~micah/open_2.c 1131672600 M * Bertl ah, looks much better ... 1131672615 M * Bertl and here is the _important_ difference to mainline: 1131672629 M * Bertl ---- your code 1131672629 A * micah waits with excitement 1131672630 M * Bertl /* not required, but just to make sure ;) */ 1131672630 M * Bertl if (IS_BARRIER(inode)) 1131672630 M * Bertl goto out_putf; 1131672636 M * Bertl ---- mainline 1131672642 M * Bertl /* not required, but just to make sure ;) */ 1131672642 M * Bertl if (IS_BARRIER(inode) && !vx_check(0, VX_ADMIN)) 1131672642 M * Bertl goto out_putf; 1131672656 M * Bertl --- 1131672666 M * Bertl this is in sys_fchmod() and probably others too 1131672673 M * micah thats it huh? 1131672695 M * micah would the absense of that allow for a chroot escape? 1131672704 M * micah probably since you can't set the barrier properly 1131672721 M * Bertl no, but it will block the admin from doing fchmod() 1131672738 M * Bertl but let me offer a deal here ... 1131672755 M * Bertl micah: you should know a little about debian, right? 1131672762 M * micah i should ;) 1131672783 M * Bertl okay, you remember that unfortunate machine which I tould you about (x86_64, debian :) 1131672795 M * micah yes, the sick one 1131672802 M * Bertl yep, precisely ... 1131672816 M * Bertl now, here is the deal: 1131672845 M * Bertl you provide me a delta diff (mainline 2.4.27 to your debian kernel), and fix the sick machine ... 1131672860 M * Bertl in exchange, I fix up and test your sick kernel :) 1131672872 J * menomc ~amery@200.75.27.28 1131672881 M * Bertl micah: how does that sound? 1131672984 M * micah it sounds like a good trade, but I would prefer that instead of fixing *my* kernel, you help me figure out what needs to be done so it can be fixed for debian kernels with vs. 1131672985 Q * prae Quit: Pwet 1131673004 M * micah maybe thats what you meant :) 1131673006 Q * nox Ping timeout: 480 seconds 1131673014 M * Bertl well, that is the idea, you get a 'fixed' debian kernel 1131673031 M * Bertl a simple diff, to your current version will show you the changes, no? 1131673036 Q * mnemoc Ping timeout: 480 seconds 1131673037 N * menomc mnemoc 1131673062 M * micah yeah, hopefully in a way that I can use to get the debian kernel people to adopt it 1131673070 M * Bertl (i.e. I'm not going to patch it up to 2.4.31 or so :) 1131673074 M * micah hehe 1131673087 M * micah my point is... 1131673116 M * micah we want to have a patch that we can bring to them that demonstrates a security hole+fix, so it can go into sarge 1131673131 M * micah (or horrible breakage) 1131673160 M * Bertl well, you tested chroot escapes, no? the fix for that should count, yes? 1131673184 M * micah yes, definately 1131673247 M * Bertl okay, so let me rephrase, a (probably minimal) patch to make the debian kernel testme/testfs compliant, and chroot escape safe :) 1131673276 M * Greek0 Bertl: mm, might take a bit of time, just had an fsck run to fight fs inconsistencies :-/ 1131673279 M * micah I think we are talkng about the same thing :) 1131673291 M * micah Greek0: yikes, good luck with that 1131673321 M * micah Bertl: although I am curious how sick your debian machine is :) 1131673332 M * Bertl micah: good, now for the sick machine, the issue I need to be cured is that a vanilla kernel can not be compiled properly anymore 1131673363 M * Bertl (I assume it has to do with strange dependancies and packages) 1131673379 J * nox ~nox@noxlux.de 1131673385 M * micah you get assembler errors or something? 1131673438 M * micah if you want to give me an account I can do some checking of things and compilation tests to see for myself 1131673453 M * micah (if you are comfortable with that, of course) 1131673657 M * Greek0 I just saw the full diff, not the interdiff-cripled one. 2000 lines of diff :-/ 1131673688 A * Greek0 fights the need to bang his head against the wall ;) 1131673800 M * Bertl micah: looks like you got yourself a cheap deal, so please prepare the diff (the machine seems to have recovered, i.e. reinstall of gcc/binutils did upgrade to a newer version which seems to have fixed the issues) 1131673844 M * micah ack! well, consider my offer available for the future then 1131673855 M * Bertl okay, thanks :) 1131673866 A * micah writes out an I.O.U. 1131673882 M * micah Bertl: preferred diff arguments? 1131673894 M * Bertl --NurpPbB --minimal 1131673910 M * micah wow, that really sounds like you ate something bad 1131673941 M * Bertl --BurpPbN better? 1131673947 M * micah lol 1131673990 M * micah so as you might know, the debian "2.4.27" kernel actually has security and big fixes backported from 2.4.27+ so do you want the diff against vanilla 2.4.27? 1131674009 M * micah (ie. there may be things from .28, .29, .30, .31) 1131674032 M * Bertl yep, I know, just need a reference and 2.4.27 is as good as any ... 1131674047 M * micah ok, and no vserver patches applied, just straight 1131674048 M * Bertl please remove any 'debian' dirs (if possible) 1131674065 M * Bertl no, with the debian vserver patch 1131674069 M * micah there wont be any debian directories 1131674080 M * Bertl so basically 2.4.27-X-vs1.2.10 1131674092 M * Bertl (diff against 2.4.27) 1131674119 M * micah should I be applying a vserver patch to the vanilla kernel as well? 1131674123 M * Bertl if you provide the vs1.2.10 aptch separate it's fine too 1131674290 M * micah ok, I just want to make sure I give you the right thing, i have the debian 2.4 kernel source with the debian vserver patch applied against the vanilla 2.4.27 source with no vserver patch applied, right? 1131674376 M * Bertl yep, that's fine, alternatively you can provide 1131674393 M * Bertl - a single patch which makes debian 2.4.27-X from 2.4.27 1131674404 M * Bertl - the vserver patch for the debian 2.4.27-X kernel 1131674456 M * Bertl EOL 1131674492 M * micah I will choose the first option, as it is easier 1131674499 M * Bertl okay :) 1131674789 J * menomc ~amery@200.75.27.93 1131674891 Q * mnemoc Ping timeout: 480 seconds 1131674891 N * menomc mnemoc 1131675579 M * micah Bertl: http://crow.riseup.net/~micah/debian-2.4.27+vserver1.2.10_vs_vanilla-2.4.27 1131675590 M * micah Bertl: http://crow.riseup.net/~micah/patch-2.4.27-9-vs1.2.10-2.diff.gz 1131675643 M * Bertl k, tx 1131675739 M * Bertl micah: could you check for me if there is a debian grub (v0.97 or later) for x86_64? 1131675781 J * Aiken_ ~james@tooax8-066.dialup.optusnet.com.au 1131675888 M * micah sure one moment 1131676021 M * micah x86_64 = AMD64 I believe: http://ftp.de.debian.org/debian-amd64/debian/pool/main/g/grub/grub_0.95+cvs20040624-19_amd64.deb 1131676033 M * Bertl yup, okay, so that's the latest? 1131676067 M * micah yep, it looks like it 1131676083 M * micah even for i386, its that version in debian 1131676095 M * Bertl hmm, so I have to compile it by hand then ... tx 1131676109 A * micah looks to see what the +cvs part is 1131676155 Q * Aiken Ping timeout: 480 seconds 1131676379 M * micah I wasn't aware that it was released yet, but it looks like the maintainer noted 5 days ago that he has an upload pending soon 1131676404 M * Bertl hmm, so I could get that package somehow? 1131676431 M * micah no, its not avaialble yet 1131676439 M * Bertl okay, tx 1131676441 M * micah the package maintainer hasn't uploaded it from his computer 1131676450 M * micah which probably means he is trying to fix some other bugs before doing so 1131677006 Q * Venomous Quit: KVIrc 3.2.0 'Realia' 1131679927 Q * dddd44 Read error: Connection reset by peer 1131681267 Q * monrad Quit: Leaving 1131682340 J * monrad ~monrad@213083190130.sonofon.dk 1131682504 M * Bertl micah: http://vserver.13thfloor.at/Stuff/Debian/delta-2.4.27-9-vs1.2.10-fix01.diff 1131682548 M * Bertl this brings the debian vserver up to vs1.2.10 and makes the testfs.sh succeed for ext2/3,xfs and reiser 1131682568 M * Bertl it also fixes any chroot escape issues and the tool issues you observed 1131682606 M * Bertl (the renaming is not necessary but it will allow you to incorporate future patches like 1.2.11) 1131683697 J * WeaKy ~WeaKy@nae817.emirates.net.ae 1131683704 M * Bertl welcome WeaKy! 1131683716 M * WeaKy thx 1131683769 M * WeaKy sameone here help me how i buy dedicated server from site ? 1131683819 M * Bertl hmm, you want to buy a dedicated server for linux-vserver hosting? 1131683830 M * WeaKy yes 1131683895 M * Bertl interesting ... 1131684110 M * Bertl okay, I'm off to bed now ... have a nice whatever ... cya 1131684115 M * Bertl micah: have fun! 1131684122 M * Bertl WeaKy: good luck! 1131684126 M * WeaKy Bertl 1131684128 N * Bertl Bertl_zZ 1131684129 M * WeaKy help me 1131684132 M * WeaKy then go 1131686296 M * micah Bertl_zZ: sorry, was away, I'll have a look 1131686359 M * WeaKy ? 1131687042 Q * WeaKy Quit: 1131687851 Q * Hollow Read error: Connection reset by peer 1131687854 J * Hollow ~hollow@home.xnull.de 1131690499 Q * anonymousc Remote host closed the connection 1131691505 J * spunky spunky@rdlax10-a116.dialup.optusnet.com.au 1131693503 J * andrew123 ~andrew123@210.211.131.240 1131694103 J * Aiken__ ~james@tooax6-109.dialup.optusnet.com.au 1131694111 P * spunky 1131694370 P * Aiken__ 1131694426 Q * Aiken_ Ping timeout: 480 seconds 1131694480 Q * ntrs_ Ping timeout: 480 seconds 1131696498 Q * FireEgl Read error: Connection reset by peer 1131697084 J * FireEgl ~FireEgl@2001:5c0:84dc:1:e903:d344:e2a1:5e59 1131697413 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1131699651 Q * andrew123 Ping timeout: 480 seconds 1131699779 J * andrew123 ~andrew123@210.211.131.240 1131700914 Q * lonewolff Read error: Connection reset by peer 1131700926 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131701601 J * Guest163 ~Miranda@83.215.237.5 1131703004 J * matti matti@linux.gentoo.pl 1131704253 J * Larsioa ~lars@83.97.96.195 1131704259 M * Larsioa Hello anybody online? 1131704260 M * Larsioa daniel_hozac ? 1131704268 M * Larsioa i still get Invaild aggrument on chxid 1131704274 M * Larsioa i did mount a new disk with tagxid 1131704927 Q * matti Quit: 8-X 1131705448 J * vip-vs ~vince@wc-178.r-195-85-188.essentkabel.com 1131705457 M * vip-vs hi folks 1131707265 M * Larsioa daniel_hozac ? 1131707267 M * Larsioa there? 1131708061 Q * harry Ping timeout: 480 seconds 1131709855 J * harry ~harry@d515321D1.access.telenet.be 1131710472 J * sebi ~sebi@Fd3bd.f.strato-dslnet.de 1131710517 Q * andrew123 Quit: Leaving 1131710571 Q * sebi_ Ping timeout: 480 seconds 1131711290 Q * Johnnie Quit: G'bye! 1131711876 J * anonymousc ~anonymous@staff.internode.com.au 1131713048 J * sizo janek@openbug.org 1131713049 M * sizo Hi 1131713078 M * sizo where can i set CAPS in version 2? 1131713693 J * Johnnie ~john@acs-24-154-53-217.zoominternet.net 1131713957 M * daniel_hozac Larsioa: sorry, was at school. 1131713974 M * daniel_hozac sizo: /etc/vservers//bcapabilities, as per the flower page. 1131714038 M * daniel_hozac Larsioa: could you strace that for me and put the trace online somewhere (particularly the last 50 lines or so)? 1131714042 M * sizo daniel_hozac; ah thanks 1131714182 J * mrec_ ~revenger@p54B02674.dip0.t-ipconnect.de 1131714601 Q * mrec Ping timeout: 480 seconds 1131716183 J * dddd44 dhb55@218.111.178.108 1131717404 M * Larsioa daniel_hozac: still here? 1131719329 Q * dddd44 Read error: Connection reset by peer 1131719447 M * daniel_hozac Larsioa: yeah, most of the time ;) 1131719946 Q * Larsioa Read error: Connection reset by peer 1131720001 Q * eugenesan Ping timeout: 480 seconds 1131720120 Q * Guest163 Read error: Connection reset by peer 1131720783 Q * shedi Quit: Leaving 1131722056 J * shedi ~siggi@inferno.lhi.is 1131722632 J * _mountie ~mountie@trb229.travel-net.com 1131723076 Q * mountie Ping timeout: 480 seconds 1131723655 J * protean ~Mayur@61.95.133.170 1131723703 M * protean 1131723850 N * Bertl_zZ Bertl 1131723857 M * Bertl evening folks! 1131723881 M * Bertl welcome protean! speechless? 1131723887 M * protean :) 1131723919 M * Hollow hey Bertl 1131723920 M * protean evening - just looking for some tech conversation - couldn't find one here 1131723938 M * Bertl protean: you have to be patient (see irc logs :) 1131723941 M * Hollow regarding amd64.. can i run 32 bit guests on 64 bit hosts (and vice versa)? 1131723960 M * Bertl not vice versa, but the first one is possible 1131723964 M * Hollow oki 1131723967 J * Doener doener@i5387FF80.versanet.de 1131723974 M * Hollow special requirements for the host? 1131723988 M * Bertl IA32 compatibility must be enabled 1131723996 M * Hollow in the kernel config? 1131723999 M * Bertl yep 1131724011 M * Hollow ok, thx 1131724017 M * Bertl you're welcome! 1131724020 M * Hollow i'm just building the first amd64 stages for vserver ;) 1131724111 Q * lonewolff Ping timeout: 480 seconds 1131724166 J * micah_ micah@micha.hampshire.edu 1131724172 M * protean vserver seems to be quite cool - just saw the wiki page 1131724210 M * protean going through the paper 1131724308 M * Bertl protean: k, if you have questions, just ask ... 1131724322 M * protean thnx 1131724331 M * Bertl okay, I'm translocating now ... will be back in approx two hours ... 1131724339 M * protean but first i'd like to try it on my box 1131724348 M * Bertl so be it! 1131724354 N * Bertl Bertl_oO 1131724360 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131724534 P * protean 1131724586 Q * micah Ping timeout: 480 seconds 1131724841 Q * lonewolff Ping timeout: 480 seconds 1131725031 Q * vip-vs Remote host closed the connection 1131725262 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com 1131725726 Q * _mountie Ping timeout: 480 seconds 1131726531 Q * Doener Ping timeout: 480 seconds 1131726532 J * Doener doener@i5387F16A.versanet.de 1131726545 J * Larsioa ~lars@you.are.the.lamer.la 1131726553 M * Larsioa How do i assign more ips to one virtual server in Debian= 1131726554 M * Larsioa ? 1131726645 M * mnemoc just add more subdirs on /etc/vservers/foo/interfaces/ 1131726690 M * Larsioa soo: 0 1 in interfaces/ 1131726690 M * Larsioa fx? 1131726713 M * mnemoc fx? 1131726737 M * Larsioa for example. 1131726930 M * mnemoc yes 1131728216 J * eugenesan eugenesan@bzq-219-189-203.cablep.bezeqint.net 1131728822 M * SiD3WiNDR fx is not a common abbreviation :p 1131728836 M * SiD3WiNDR (except for "effects" ;) 1131728867 A * SiD3WiNDR just realizes SFX for selfextractor should actually be SEX 1131728928 M * mnemoc e.g. :) 1131728953 M * Larsioa ye forgot. 1131728966 M * Larsioa daniel_hozac: arround? 1131730316 J * Viper0482 ~Viper0482@p549748AF.dip.t-dialin.net 1131730522 Q * shedi Quit: Leaving 1131730816 J * shedi ~siggi@inferno.lhi.is 1131731063 Q * Viper0482 Remote host closed the connection 1131731067 N * micah_ micah 1131732778 J * lilo ~lilo@lilo.usercloak.oftc.net 1131732793 Q * lilo_ Remote host closed the connection 1131733504 M * Larsioa daniel_hozac: arround? 1131733586 M * daniel_hozac sure. 1131733617 M * Larsioa should we try to fix the vdlimit problem 1131733648 M * daniel_hozac there's a vdlimit problem? 1131733684 M * Larsioa yes. I get the Invaild aggrument when i try to do the chxid on the files 1131733899 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131733915 M * daniel_hozac ah, right. did you put up an strace somewhere? 1131733936 M * Larsioa im creating a test server 1131733937 M * Larsioa hang on 1131733955 J * dos000 ~dos000@CPE00119572fd49-CM00137186e53a.cpe.net.cable.rogers.com 1131733960 M * dos000 howdy 1131733989 M * daniel_hozac hi 1131734151 N * Bertl_oO Bertl 1131734159 M * Bertl back now ... evening folks! 1131734168 M * daniel_hozac evening! 1131734204 M * dos000 hey Bertl 1131734257 M * dos000 i am still struggling with vserver and public ips 1131734273 M * Bertl daniel_hozac: have you seen, folks explicitely request help from you :) 1131734293 M * dos000 i did ! 1131734295 M * Bertl dos000: in what way? 1131734306 M * daniel_hozac hah, yes, it's bizarre ;) 1131734317 M * Larsioa /etc/vservers/.defaults/vdirbase/lars/root/.aptitude: Invalid argument 1131734318 M * Larsioa /etc/vservers/.defaults/vdirbase/lars/root/.aptitude/config: Invalid argument 1131734318 M * Larsioa /etc/vservers/.defaults/vdirbase/lars/media: Invalid argument 1131734318 M * Larsioa /etc/vservers/.defaults/vdirbase/lars/initrd: Invalid argument 1131734322 M * Larsioa chxid -c 50 -R /etc/vservers/.defaults/vdirbase/lars/ 1131734353 M * dos000 i had weird case where pacets supposed to be droped (because of ip table rules) are still visible in the guest 1131734388 M * daniel_hozac Larsioa: right, could you add strace -o chxid.strace before that command and run it again? 1131734391 M * Bertl daniel_hozac: well, actually I consider it great! (as long as it is fine for you) leaves me more time 1131734406 M * dos000 but the outbound traffic from the guest (which had a public ip) was never making it out 1131734410 M * Larsioa -bash: strace: command not found 1131734413 M * Larsioa apt-get install strace? 1131734419 M * mnemoc *g* 1131734419 M * daniel_hozac yep. 1131734478 M * Larsioa powerserv:~# strace -o chxid.strace 1131734478 M * Larsioa usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file] 1131734479 M * Larsioa bla bla 1131734485 M * Larsioa it shows the --help 1131734489 M * daniel_hozac you'll need the command after that. 1131734520 M * Larsioa chxid -c 50 -R /etc/vservers/.defaults/vdirbase/lars/ strace -o chxid.strace 1131734521 M * Larsioa ? 1131734530 M * daniel_hozac no, strace -o chxid.strace chxid -c 50 -R /etc/vservers/.defaults/vdirbase/lars/ 1131734541 M * Bertl make that strace -fF -o ... 1131734541 M * Larsioa same 1131734544 M * Larsioa with invaild aggrument. 1131734566 M * daniel_hozac chxid shouldn't fork. 1131734591 M * daniel_hozac Larsioa: right, but the chxid.strace should be full of interesting info though. 1131734593 M * Bertl Larsioa: could you do the following, and upload it too? 1131734602 M * Larsioa sec 1131734607 M * Bertl df -k && df -k /etc/vservers/.defaults/vdirbase/lars/ 1131734654 M * Larsioa Filesystem 1K-blocks Used Available Use% Mounted on 1131734654 M * Larsioa /dev/hda1 39076880 2193084 36883796 6% /etc/vservers/.defaults/vdirbase 1131734709 M * Larsioa hmm i cant get chxid to past the output into a file 1131734709 M * Larsioa hmm 1131734799 M * Larsioa ? 1131734831 M * Bertl try the following line: 1131734857 M * Bertl strace -fF -o chxid.trace chxid -c 50 -R /etc/vservers/.defaults/vdirbase/lars/ >chxid.out 2>chxid.err 1131734873 M * Bertl you should find all details in chxid.trace, chxid.out and chxid.err 1131734959 M * Larsioa http://83.97.97.61/test/chxid.err 1131735075 M * Larsioa ? 1131735162 M * Larsioa soo whats wrong 1131735171 M * Bertl Larsioa: is that your IRC client which causes those question marks on an otherwise empty line? :) 1131735183 M * Larsioa Hehe sorry. 1131735193 M * Larsioa bad habit. 1131735230 M * FaUl hmm 1131735230 M * FaUl ? 1131735492 M * Bertl Larsioa: could you also uplaod the output of 'cat /proc/mounts' on the host? 1131736499 M * Bertl Larsioa: ping? 1131736701 M * micah Bertl: thanks for the patch, can you give me a high-level idea of what the missing parts were? 1131736726 M * micah like filesystem attribute capabilities was missing, or something? 1131736755 M * Bertl give me a few minutes, I prepare something ... 1131737242 J * schak schak@dslb-082-083-038-057.pools.arcor-ip.net 1131737262 M * Bertl welcome schak! 1131737271 M * schak good evening... and how ever: a problem :) 1131737341 M * schak kara:/# vrsetup /dev/vroot/1 /vservers/v1.reiser 1131737341 M * schak ioctl(): Invalid argument 1131737373 M * schak how can i enable quotas, when the vserver-fs is a loopback-file? 1131737399 M * Bertl you still need to specify a _device_ for the vroot 1131737417 M * Bertl so for example, vrsetup /dev/vroot/1 /dev/loop/0 1131737447 M * schak ah ok... and how can i mount the file-fs to /dev/loop/0 ? 1131737467 M * schak normally i do mount /vserver/v1.reiser /vserver/v1 -o loop 1131737471 M * Bertl you do setup the loop device with losetup, and mount it in place 1131737498 M * Bertl (that is what the -o loop also does) 1131737555 M * schak ok thx. i will study the losetup manual :) 1131737575 M * Bertl should not be too hard, very similar to vrsetup (or the other way round :) 1131737665 M * schak for what do i need the vroot-devive?... i mean: why cant i do: cp -af /dev/loop/0 /vserver/v1/dev/hdv1 1131737668 M * schak -v+c 1131737688 M * Bertl for security reasons ... 1131737694 M * schak ah ok 1131737700 M * Bertl just consider the following: 1131737720 M * Bertl dd if=/some/evil/file of=/dev/hdv1 1131737736 M * Bertl then reboot the guest, and have all device nodes ... 1131737866 M * schak oh... ok... i understand 1131738192 P * Larsioa 1131738398 M * Bertl micah: http://vserver.13thfloor.at/Stuff/Debian/delta-2.4.27-9-vs1.2.10-fix02.diff 1131738422 M * Bertl (this patch contains _only_ the fixes, not the name change) 1131738482 M * mnemoc Bertl: 2.4.27? 1131738519 M * Bertl mnemoc: it's debian ... *G* 1131738612 M * schak Bertl: if you are interested: the solution is as simple as you said: losetup -f /vservers/v1.reiser 1131738720 M * Bertl great! (still looks like the lo device is missing, but hey :) 1131738731 M * mnemoc Bertl: oh, i should have guessed it :) 1131738754 M * schak "-f" searches the first available loop-dev 1131738791 M * Bertl hmm, and reports it how? 1131738813 M * mnemoc stdout? 1131738841 M * Bertl ah, good ... didn't know :) 1131738848 M * schak you have to guess it... /dev/loopX ... if nothing is in use, he will use /dev/loop0 1131739078 M * mef good evening. 1131739114 M * Bertl good evening mef! 1131739136 M * mef bertl: Andy made some good progress in making the new cpu scheduler work quite well on SMP. 1131739146 M * Bertl great! 1131739165 M * mef bertl: code will probably make it into our cvs on Monday or maybe even in a few hours. 1131739202 M * Bertl excellent, I have a few questions regarding the ckrm machine, do you ahve a few minutes? 1131739206 M * mef sure 1131739216 M * mef note that I am using it right now. 1131739235 M * mef so please hold off on rebooting over the next few hours. 1131739252 M * mef hope that is ok. 1131739496 M * Bertl yup, no problem ... 1131739551 M * micah Bertl: are those changes things that appeared in other kernels? 1131739597 M * micah I'm trying to figure out where debian went wrong, and if there are some kernel patches I can suggest to them that might be a good idea 1131739638 M * micah it doesn't look like a large number of changes which is good 1131739809 J * andrew123 ~andrew123@210.211.131.185 1131739892 M * andrew123 ello ppl http://pastebin.com/425840 << 8:-(:::::: 1131739909 M * andrew123 what does it mean? 1131740774 M * schak Bertl: how can i undo these vrsetup commands? i cant execute it twice... it says, that the ressource is busy... i made a mistake in the first execution 1131740775 M * schak kara:/vservers# vrsetup /dev/vroot/1 /dev/loop1 1131740775 M * schak ioctl(): Device or resource busy 1131740899 M * Bertl try vrsetup -d /dev/vroot/1 before 1131740914 M * Bertl (you already assigned the deivec once) 1131740929 M * schak works... thanks :) 1131741027 M * andrew123 didn anyone check my pastebin? 1131741089 M * schak yes, but i have no idea otherwise id answered :) 1131741117 M * Bertl andrew123: looks like you did not install the util-vserver tools in your path 1131741172 M * schak i have a last and very important question: which device do i mount in the /vservers/v1 directory?... the vroot-device or the loop-device? 1131741192 M * schak its nowhere documented :( 1131741232 M * andrew123 Ouchieeee ... yes indeeddieee.... i thought it didnt matter. ok will do. 1131741451 M * Bertl andrew123: great! 1131741570 M * andrew123 :( sorry 1131742542 M * schak v1:/# quotaon /dev/hdv1 1131742542 M * schak quotaon: using //aquota.group on /dev/hdv1 [/]: Die Operation ist nicht erlaubt 1131742542 M * schak quotaon: using //aquota.user on /dev/hdv1 [/]: Die Operation ist nicht erlaubt 1131742553 M * schak what is wrong there? 1131742585 M * Bertl most likely you are missing the quota capability 1131742592 M * Bertl cap_quotactl IIRC (ccaps) 1131742602 M * schak oh!... i thought this cap is old stuff 1131742724 J * ntrs_ ~ntrs@iits01188.inlink.com 1131742728 M * Bertl there was an CAP_QUOTACTL (which is old stuff indeed) 1131742746 M * Bertl schak: let me check the current name ... 1131742769 M * Bertl (btw, you can find that on the flower page) 1131742815 M * Bertl DECL("quota_ctl", VC_VXC_QUOTA_CTL), 1131742824 M * Bertl so it's quota_ctl in ccapabilities 1131742965 M * schak hehe, ok thx. i ve just been on this page, but you are quicker :) 1131742995 M * schak do i have to put quota_ctl or cap_quota_ctl in this file? 1131743077 M * Bertl just quota_ctl 1131743227 J * comdata ~comdata@D84f9.d.pppool.de 1131743255 M * comdata hello Bertl 1131743255 M * Bertl welcome comdata! 1131743290 M * schak ok... and watch this: http://nopaste.chillfactory.net/show.php?id=218 <-- is it a bug or a "feature"? 1131743370 M * comdata tested 2.6.14-vs2.0.1-rc1 on the opteron machine, it runs fine so far 1131743566 M * Bertl well, I'd consider this a feature, combined with a bug (in the administrator :) 1131743580 M * Bertl (that was for schak) 1131743588 M * Bertl comdata: great! 1131743625 M * comdata Bertl: it was your work not mine, so thanx to you 1131743690 M * Bertl comdata: you're welcome! but testing and feedback is essential, so it's no problem for me to thank you for doing so ... 1131743776 M * comdata Bertl: have you any clues what happened in the 2.1. version with the network traffic, maybe I can help with some more testing ;-) 1131743871 M * Doener Bertl: btw, was there any progress with the shaping issues that came up on the ml? 1131743984 M * Bertl comdata, Doener: are we talking about the same issue? 1131743997 M * Bertl (if so, we should investigate) 1131744046 M * comdata Bertl: I had the problem that larger transfers of data got terminated after random bytes >11000bytes 1131744048 M * Doener Bertl: uhm, i'm talking about the issue from the mailing list, where adding some shaping rules caused a mysql server to slow down to a crawl 1131744091 M * Doener (you considered it to probably be a mainline issue) 1131744114 M * Bertl comdata: okay, and that happens with 2.1 but not 2.0.x? 1131744132 M * Doener Subject: [Vserver] packet shaping with vservers 1131744174 M * comdata Bertl: had the 2.1 version installed there it happened, after switching to the 2.0.x version all was ok, no other changes in the system 1131744432 M * schak after adding the ccap i get a new error: 1131744433 M * schak v1:/# quotaon -a 1131744433 M * schak quotaon: using //aquota.group on /dev/hdv1 [/]: Kein passender Prozess gefunden 1131744433 M * schak quotaon: Quota format not supported in kernel. 1131744470 M * Bertl well, looks like your 'quota' format is not compiled in 1131744479 M * Bertl try with -F vfsv0 1131744497 M * Bertl quotaon -avug -F vfsv0 1131744529 M * Bertl comdata: okay, might be realted to the sendfile changes, do you ahve the precise versions? 1131744597 M * comdata Bertl: patch-2.6.14-vs2.1.0-rc5-prelim 1131744615 M * Bertl on 2.6.14 I presume 1131744617 M * schak Bertl: the same error occurs 1131744659 M * comdata Bertl: yes 2.6.14 1131744749 M * comdata Bertl: have to get some sleep now, maybe I find some time to get back on monday 1131744767 M * comdata good n8 everyone 1131744770 M * comdata bye 1131744787 Q * comdata Quit: Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined] 1131744787 M * Bertl night! 1131744798 M * schak http://nopaste.chillfactory.net/show.php?id=219 1131744811 M * Bertl schak: so it's probably simply not compiled in ... 1131744812 J * dos000_ ~dos000@CPE00119572fd49-CM00137186e53a.cpe.net.cable.rogers.com 1131744822 M * Bertl schak: could you check your kernel's .config ? 1131744867 M * schak kara:/etc/vservers/v1# cat /boot/config-2.6.12.6 | grep QUOTA 1131744867 M * schak CONFIG_QUOTA=y 1131744867 M * schak CONFIG_QUOTACTL=y 1131744935 M * schak the only reason i could imagine: the host is sarge, the guests are woody 1131744982 M * Bertl what about the QUOTA*FMT* 1131745114 M * schak sorry? 1131745141 M * schak is it a program, a kernel-option, a cap? 1131745216 Q * dos000 Ping timeout: 480 seconds 1131745262 M * Doener schak: grep for QFMT in your config 1131745300 M * schak kara:/etc/vservers/v1# cat /boot/config-2.6.12.6 | grep QFMT 1131745300 M * schak # CONFIG_QFMT_V1 is not set 1131745300 M * schak # CONFIG_QFMT_V2 is not set 1131745330 M * schak *sigh* 1131745470 Q * mef Remote host closed the connection 1131746004 J * dos000__ ~dos000@CPE00119572fd49-CM00137186e53a.cpe.net.cable.rogers.com 1131746383 M * Bertl Doener: okay, back to topic, the BW management 1131746416 Q * dos000_ Ping timeout: 480 seconds 1131746418 M * Bertl IMHO we do not change anything in this area, not even tagging, no? 1131746459 M * Doener not as far as i know 1131746670 M * Bertl Vudumen: tx for the reboot, any idea what caused the hang? 1131747130 J * dos000_ ~dos000@CPE00119572fd49-CM00137186e53a.cpe.net.cable.rogers.com 1131747526 Q * dos000__ Ping timeout: 480 seconds 1131747608 M * Bertl micah: those changes are purely vserver related IMHO 1131747699 J * ryker ~ryker@c-67-176-240-74.hsd1.in.comcast.net 1131747785 Q * dos000_ Quit: Leaving 1131747803 M * Bertl welcome ryker! 1131747911 M * ryker thanks 1131747913 M * ryker hi 1131748453 Q * andrew123 Quit: Leaving 1131749235 J * rocket ~rocket@134.68.220.30 1131750035 M * michal_ grz, resizing ext3 is verid task 1131750060 M * michal_ no matter how hard i would try, i fail everytime (shrinking it) 1131750224 M * Bertl hmm 1131750237 M * Bertl a) remove the journaling inode 1131750245 M * Bertl b) e2fsck the filesystem 1131750255 M * Bertl c) resize2fs the fs 1131750264 M * Bertl d) add back the jornaling inode 1131750285 M * Bertl don't forget to unmount before and remount after 1131750335 M * Bertl welcome rocket! 1131750466 Q * schak Ping timeout: 480 seconds 1131750724 M * michal_ thx, doing it more or less so but i have troubles during adjusting partition sizes 1131750761 M * michal_ fs size is 12845056 blocks (4 KB afaik) 1131750771 M * michal_ i have to convert it to fdisk blocks 1131750783 M * michal_ sector i mean 1131750797 M * michal_ sector is 512 bytes ? 1131750887 M * Bertl try dumpe2fs 1131750904 M * Bertl (provides info about your current fs) 1131751350 M * michal_ converted, for some reason it wanted 32 blocks more, added them, now it is clean ^^ 1131751380 M * Bertl good 1131751397 M * michal_ now i can go from point "d" :) 1131751412 M * Bertl make sure that you do not make the fs smaller than the partition :) 1131751430 M * michal_ yeah, keeping an eye on it 1131751444 M * Bertl I usually make the partition slightly larger, and resize the fs afterwards 1131751456 M * Bertl (this will give a perfect fit) 1131751502 M * michal_ same with me, but this time it has failed for some strange reasons (did fs 49 GB, partition 50 GB, ext2 check have said that underlying block device is... smaller ) 1131752301 Q * ntrs_ Ping timeout: 480 seconds 1131752311 J * ntrs_ ~ntrs@iits01188.inlink.com 1131752938 J * linus ~ayub@202.40.183.92 1131752966 Q * ntrs_ Ping timeout: 480 seconds 1131753000 Q * linus Quit: Leaving 1131753004 J * ntrs_ ~ntrs@iits01188.inlink.com 1131753276 Q * ntrs_ Quit: