1121818441 M * Aiken do what I do and risk life and limb by using one of my wifes machines :) 1121819202 M * Aiken alpha rc8.1 1121819206 M * Aiken testme passes 1121819232 M * Aiken tesfs .04b passes with ext2 ext3 reiserfs 1121819790 M * eyck ..xfs? 1121819834 Q * eXplasm Ping timeout: 480 seconds 1121819902 M * Aiken don't have anything to do with xfs installed 1121820477 J * airhead ~segfault@202-6-75-165.e-centre.biz 1121820518 M * airhead is there a way to find out what caps a running vserver has? I suspect that the caps that I'm setting in the config file aren't being given to the vserver 1121821099 Q * daniel_hozac Ping timeout: 480 seconds 1121821126 J * daniel_hozac ~daniel@h56n2fls32o829.telia.com 1121822478 M * Bertl back now (in case somebody missed me) had a network outage ... 1121822594 A * Aiken had muttered something about rc8.1 + testme + testfs (ext2,ext3,resierfs) working on his alpha 1121822618 M * Bertl excellent, I have a backlog ... 1121822643 M * Bertl eyck: xfs should work fine on 2.0-rc8.1 ... 1121822645 M * Aiken ah 1121825024 M * Bertl eyck: of course you have to disable 4k stacks and preemption, otherwise xfs will bring down your host 1121826665 M * mugwump Hey, my workmate just gave me a bit of a tour through Xen 1121826686 M * mugwump It's basically Bochs without Kevin, eh? :) 1121826714 M * Bertl hehe ... well yeah ... 1121826743 M * Bertl except for the tiny detail that bochs is 100% simulation and platform independant :) 1121826759 J * eXplasm explasm@p549F788C.dip.t-dialin.net 1121826775 M * Bertl welcome eXplasm! 1121826782 M * mugwump right, sure, HALs and all that. I didn't see the point to that myself. 1121826809 M * mugwump why invent a new interface for a disk device that's just going to need a driver built for it in the guest OS? 1121827233 J * Doener_ ~doener@p54873C05.dip.t-dialin.net 1121827669 Q * Doener` Ping timeout: 480 seconds 1121827708 M * Bertl okay, I'm off to bed now ... a little tired tonight ... 1121827818 N * Bertl Bertl_zZ 1121828979 J * Aiken_ ~james@tooax7-028.dialup.optusnet.com.au 1121829305 Q * Aiken Ping timeout: 480 seconds 1121829995 N * Aiken_ Aiken 1121833835 J * bunzope bunzope@203.92.55.20 1121835404 J * _mcp ~hightower@wolk-project.de 1121835405 Q * mcp Read error: Connection reset by peer 1121835409 N * _mcp mcp 1121841426 P * bunzope 1121843683 N * BobR_oO BobR 1121847835 J * prae ~prae@ezoffice.mandriva.com 1121848205 J * Aiken_ ~james@tooax6-129.dialup.optusnet.com.au 1121848530 Q * Aiken Ping timeout: 480 seconds 1121849514 J * FaUl ~immo@hobbynuttenverzeichniss.de 1121849516 M * FaUl re 1121849550 M * FaUl someone who knows what exactly the difference between rc8 and rc8.1 is 1121849551 M * FaUl ? 1121850560 Q * MooingLemur Ping timeout: 480 seconds 1121850580 Q * Aiken_ Ping timeout: 480 seconds 1121851250 M * Hollow FaUl: delta-lock-fix02.diff 1121852417 J * jsambrook ~jsambrook@claud.plus.com 1121852448 P * jsambrook 1121852653 J * Aiken ~james@tooax8-191.dialup.optusnet.com.au 1121852822 M * FaUl Hollow: ah, thx 1121852877 N * Bertl_zZ Bertl 1121852887 M * Bertl morning folks! 1121852891 M * FaUl hey Bertl 1121853202 Q * cryo Remote host closed the connection 1121853265 M * Hollow morning Bertl! 1121853280 M * FaUl Hollow: what lock-issue does this exactly fix? 1121853307 M * Hollow *shrug* 1121853315 M * Hollow my kernel just oppsed when using lockfiles 1121853316 M * Hollow ;) 1121853335 M * Bertl change to rc8.1 1121853351 M * Hollow Bertl: yup.. i already have 1121853399 M * Bertl it's simply a NULL pointer case I didn't see (when I cleaned up the locking code9 1121853404 M * Bertl s/9/)/ 1121853480 M * FaUl mine too, will change to rc8.1 then 1121853612 M * Bertl FaUl: the exact difference is: http://vserver.13thfloor.at/Experimental/delta-locks-fix02.diff 1121853629 M * FaUl Bertl: hollow told me that before 1121853633 M * FaUl Bertl: thx anyway 1121853663 J * cryo ~say@212.86.243.154 1121853696 M * Bertl welcome cryo! 1121853939 M * Bertl FaUl: it's morning, I'm slowly waking/catching up :) 1121853975 M * FaUl Bertl: np :-) 1121853995 M * FaUl I guess its time to get my mailserver up and running again 1121854010 M * FaUl i don't know exactly how long the backup-mx will hold the mail :-) 1121854059 M * Bertl usually 5 days, no? 1121854125 M * FaUl Bertl: think so 1121854144 M * FaUl but 3 of that 5 days are gone now 1121854176 A * FaUl hates disk-failures and FaUl hates no money for backup either 1121854240 M * Bertl use Linus' backup ... 1121854508 M * FaUl Bertl: hmm, not for my mailserver :-) 1121854541 M * FaUl that works for sources, but not for systems ;-) 1121854549 M * Bertl i.c. 1121854589 M * nokoya vserver can use more than 1 ip per vserver ? 1121854601 M * Bertl yep, up to 16 currently 1121854613 M * nokoya i c 1121855060 M * FaUl bcapabilities is on cap per line? 1121855078 M * Bertl yep, similar to ccaps and flags 1121855787 Q * Aiken Quit: Leaving 1121855899 M * FaUl hmm, is there any way to debug init-problems in vservers? 1121855921 M * Bertl what kind of init problems? 1121855931 M * FaUl he starts up and than says allservices exited and shut down the vserver again 1121855954 M * Bertl and that isn't true? 1121855965 M * FaUl don't know, want to debug it 1121855981 M * Bertl hmm, try --debug then 1121855981 M * FaUl my minit should start a few servers, but i don't know if it does 1121855990 M * FaUl debug says that it starts /sbin/minit-start 1121855998 M * FaUl but nothing more 1121856006 J * erwan_ho ~erwan@konilope.dyndns.org 1121856014 M * FaUl should it say minit-start starts up dnscache/etc? 1121856065 M * Bertl well, what does /sbin/minit-start do, and does it work? 1121856081 M * Bertl welcome erwan_ho! 1121856109 M * erwan_ho hey Bertl 1121856138 M * FaUl Bertl: minit-start is a symbolic link on minit (http://www.fefe.de/minit/ i guess) 1121856160 M * Bertl yeah, I know minit .. the question is more, did you test your setup? 1121856170 M * FaUl nope, how should i test it? 1121856233 M * Bertl hmm, okay, let me rephrase this: do you 'hope' that your minit setup will work, or do you 'know' that it should work :) 1121856293 M * Bertl I don't remember if minit a) has a debug mode, and b) if it does write to some logfile ... 1121856395 M * FaUl Bertl: the thing is 'i hope that my minit-setup will work and it should do either, but i'm not sure. and minit has no debug mode as well as it won't write logfiles other than output to stdout, and it does not output anything (which should be ok either) 1121856461 M * Bertl well, then let's try with a/the command line (by hand) 1121856551 M * FaUl yes, will do that. but the mashine is crashed either 1121856557 M * FaUl its time for rc8.1 :-) 1121856853 M * FaUl Bertl: have you removed delta-locks-02.diff? 1121856861 M * FaUl or am i to stupid to find it? 1121857028 M * Bertl ahem, no, I moved it into FOR-2.0 :) 1121857037 M * FaUl ah :-) 1121857082 M * FaUl ok, brb, have to reboot that server 1121857087 M * FaUl it hangs hard :-) 1121857263 M * SiD3WiNDR apc masterswitch! :) 1121857575 M * FaUl you have one for free for me? 1121857585 M * FaUl ok, that oopses are gone, thats nice 1121857679 M * FaUl Bertl: is there any way to strace an vserver start? 1121857697 M * Bertl not really, as it crosses context boundaries ... 1121857708 M * Bertl but you can strace _inside_ the guest ... 1121857720 M * Bertl i.e. take the last line reported by --debug 1121857732 M * Bertl and place an strace right before the minit-start 1121858264 M * FaUl yes, but i guess i found that erro 1121858264 M * FaUl r 1121858514 Q * aba Ping timeout: 480 seconds 1121858665 J * richardw ~richard@wlan-tiwag-231-232.utaonline.at 1121858835 M * FaUl Bertl: is some strange minit-behaviour, never seen that before... 1121858843 M * FaUl but i'll look in the source for that :-) 1121858857 M * richardw hi! 1121858894 J * aba ~aba@eos.turmzimmer.net 1121858918 M * Bertl hey richardw! 1121858928 M * Bertl thanks for testing yesternight :) 1121858929 M * richardw the vserver-test script gives me this error on user-mode-linux: http://nopaste.php-q.net/148247 1121858962 M * Bertl yep, kinda expected 1121859003 M * Bertl either you configure the LEGACY_VERSION or switch to tools which are not older than one and a half year :) 1121859016 M * Bertl (e.g. 0.30.208 :) 1121859167 M * richardw hmm, damn. you're right. util-vserver is too old. 1121859198 M * Bertl it works fine back to 0.26 (with the legacy stuff all enabled) 1121859212 M * Bertl (which is about 2 years old now) 1121859232 M * Bertl welcome aba! 1121860483 Q * richardw Read error: No route to host 1121860587 J * richardw ~richard@wlan-tiwag-231-232.utaonline.at 1121860927 M * richardw hmm, damn. my host kernel (2.6.12-ck3-skas3-v8.2) crashed. is a uml guest kernel (2.6.12.3-vs2.0-rc8.1) able to do this? 1121860969 M * Bertl hmm, might be ... you probably have to ask the UML folks that ... 1121861067 M * Bertl even if the guest would call linux-vserver stuff on the host kernel (skas comes to mind) it should not hurt, as the syscall is reserved and not-implemented ... 1121861079 M * richardw i've never had such a crash with "normal" uml kernels. maybe the vserver patch is guilty ;) 1121861130 M * Bertl it might be the cause, but I don't think that UML (userspace) kernels should be able to do that, no? 1121861187 M * FaUl is it possible to do an exportfs out of a vserver? 1121861196 M * FaUl if yes - which cap do I need? 1121861221 M * Bertl you need an userspace nfs server to do that from inside the guest 1121861244 M * FaUl hmm, does userspace-nfs perform? 1121861249 M * Bertl (check the irc logs, recently some folks tested a setup) 1121861250 M * FaUl (never used it before) 1121861279 M * Bertl FaUl: well, kernel space nfs from inside is not an option, you can do that on the host though ... 1121861299 M * FaUl Bertl: i'll think about that 1121861311 M * FaUl Bertl: does kernelspace-nfs work with a portmap/etc on the guest? 1121861334 M * FaUl and just that kernelspace-nfs-foo from the host? 1121861348 J * wurd ~kvlt@modemcable181.93-202-24.mc.videotron.ca 1121861360 M * Bertl why would you like to put the portmap into the guest? 1121861370 M * Bertl welcome wurd! 1121861411 M * Bertl FaUl: and no, I don't think that the kernel nfs (on the host) will be called/register from a guest portmap 1121861533 M * FaUl Bertl: because portmap is a security-risk :-) 1121861551 M * FaUl and I try to avoid all security-risks from the host 1121861558 M * FaUl s/avoid/keep away/ 1121861573 M * aba you can export nfs via client tools inside a vserver. 1121861582 M * aba (you need to patch portmap first however) 1121861605 M * FaUl aba: nfs-server? 1121861626 M * aba FaUl: yes. A nfs-server in the vserver. 1121861665 M * FaUl aba: client-tools is that userspace-nfs-server? 1121861690 M * aba yes 1121861693 M * aba IIRC :) 1121861735 M * FaUl aba: mh, ill try userspace-nfs 1121861910 J * ps ~ps@fw-lan-transit.le1.spacenet.de 1121861931 M * FaUl hi ps 1121861936 M * ps hi 1121861979 M * ps i want to set up a vserver box but unsure what patch to use 1121862007 M * ps is 2.0rc8 useable or is it better to use the 1.9.5? 1121862015 M * Bertl vs2.0-rc8.1 (if you are using 2.6.x) 1121862020 M * FaUl ps: vserver-2.0-rc8.1 should be the way to choose if you want 2.6, 1.2.10 if you want 2.4 1121862130 M * ps ok - thanks :) 1121862143 M * FaUl aba: what exactly must i patch? 1121862169 M * FaUl sorry for asking stupid, but i've no X or something until i get the nfs-server up and running :-) 1121862193 M * FaUl i don't even have my $home :-) 1121862208 M * Bertl FaUl: $home less :) 1121862323 M * FaUl Bertl: yes :-( 1121862337 M * FaUl Bertl: just building a new fileserver :-) 1121862346 M * aba FaUl: it checks whether new requests for adding ressources come from 127.0.0.1 1121862407 M * aba this doesn't work of course 1121862413 M * Bertl might work with 127.0.0.1 as first guest ip, no? 1121862424 M * aba Bertl: perhaps. I just removed that check 1121862635 M * Bertl Vudumen: hmm? 1121862655 M * FaUl aba: have you a patched portmap for debian etch handy? 1121862661 M * aba no 1121862666 M * FaUl mh 1121862670 M * FaUl statically linked? :-) 1121862675 M * aba no 1121862680 M * FaUl fsck 1121862685 M * Bertl he's a desperate man .... 1121862693 M * aba actually, I even didn't file the patch - because it was so ugly ... 1121862702 M * FaUl where do i get the portmap sources? 1121862702 M * aba FaUl: wait a moment ... 1121862707 M * aba apt-get source portmap 1121862716 M * FaUl mh, that was to easy 1121862812 M * aba good :=) 1121862819 M * aba portmap-5/from_local.c 1121862826 M * aba @@ -163,6 +167,7 @@ 1121862827 M * aba struct sockaddr_in *addr; 1121862827 M * aba { 1121862827 M * aba int i; 1121862827 M * aba + return (TRUE); 1121862829 M * aba if (addrs == 0 && find_local() == 0) 1121862831 M * aba syslog(LOG_ERR, "cannot find any active local network interfaces"); 1121862834 M * aba that's it 1121862857 M * FaUl hehe 1121863018 M * FaUl aba: mh, is this patch realy necessary? 1121863027 M * aba FaUl: it worked for me. 1121863105 M * FaUl do you remember which the error was? 1121863132 M * aba the nfs-server couldn't authenticate with portmap. 1121863145 M * FaUl unable to register? 1121863165 M * aba I think yes 1121864121 J * bipsen ~secret@pat.progressive.dk 1121864228 M * bipsen hi - had a couple of posts to the mailing list, and was asked to file a couple of bugreports at "savannah" ... anybody care to explain whether this is a bugzilla host or something ? 1121864254 M * Pazzo hi guys! 1121864257 A * Pazzo is away: busy 1121864260 A * Pazzo is back (gone 00:00:03) 1121864283 M * Bertl bipsen: welcome! sec ... 1121864343 M * Bertl https://savannah.nongnu.org/projects/util-vserver 1121864352 M * Pazzo I'm still running vs2.0-rc5 (or rc4?) on a couple of productional hosts (unfortunately most of them are not my ones): 2-4x dual xeon 4gb, 3x p4 2,6 2gb, a few cheap hosts, p3/800 different amd's - all of them are running fine! 1121864363 M * Pazzo hey Bertl! 1121864368 M * Bertl hey Pazzo! 1121864386 M * Pazzo I'm wondering if there is any good reason to upgrade to rc8.1? 1121864420 M * Bertl http://linux-vserver.org/ChangeLog26 1121864470 M * FaUl Pazzo: yes, you have no more oopses ;-) 1121864493 M * FaUl oh, from rc5 or rc4 1121864493 M * Bertl (well, those were from rc8, unfortunately :) 1121864505 M * Pazzo Bertl: yep, thnx - already read that... but it seems that all the currently fixed oopses have been introduced after rc5 - is that right? 1121864546 M * Bertl yes, the only relevant parts for you are: xfs and uuid 1121864566 M * bipsen Bertl: Thanks - I'll register and report the bugs very soon ;-) 1121864578 M * Bertl bipsen: thank you! 1121864621 M * Pazzo hmmm... I'm not using xfs - but what's "fixed issue with virt_handler (uuid)" talking about? 1121864649 M * Bertl sysctl -a (probably segfaults on your kernel) 1121864665 M * Pazzo hehe... let's have a try :-) 1121864767 M * Pazzo yep - prints out a lot of values and then segfaults 1121864776 M * Pazzo could this cause any harm to my system? 1121864781 M * Bertl yes 1121864793 M * Pazzo :( how? 1121864806 M * Bertl it basically calls into *somewhere* inside the kernel ... 1121864816 M * FaUl so, x again ;-) 1121864818 M * FaUl yipeee 1121864823 M * Bertl usually that somewhere is not mapped, so it results in a segfault :) 1121864855 M * FaUl and $home 1121864881 M * Bertl ah, FaUl has a $home again :) 1121865038 M * Bertl Hollow: you around? 1121865045 M * Hollow Bertl: yup 1121865046 M * Pazzo (sorry, busy for some minutes, back soon) 1121865062 M * Bertl Hollow: you did test compile the kernel with gcc 4.x, right? 1121865071 M * Hollow Bertl: yep, i'm running it already 1121865095 M * Bertl k, did you get any other 'warnings' except for the one you told me about yesterday? 1121865127 M * Bertl (compile time warnings that is) 1121865171 M * Hollow Bertl: not in vserver code.. 1121865187 M * Hollow there are some warnings about foo may be used unitiailized here and there 1121865193 M * Bertl ah, excellent, so when we fix that one, we are gcc 4.x ready, right? 1121865196 M * Hollow but not in vserver 1121865199 M * Hollow yep 1121865735 M * ps mhm ich bekomm beim compilieren einen fehler .. 1121865738 M * ps drivers/char/drm/gamma_drv.c:33:19: gamma.h: Datei oder Verzeichnis nicht gefunden 1121865738 M * ps In file included from drivers/char/drm/gamma_drv.c:37: 1121865786 M * Bertl ps: channel language is english, but that looks like a bug in the gamma drm driver ... (which you probably do not need anyway) 1121865840 M * Bertl this usually happens when folks use the debian default config (which includes everything and the kitchensink) for mainline kernels 1121865873 M * ps hrhr - yes, i used the default config 1121867091 M * wurd hi, is there a way to specify a vserver's IP address, other than during the build? 1121867107 M * Bertl yes, with the config ... 1121867108 M * wurd i tried with the .conf file 1121867111 M * wurd but didnt work 1121867132 M * Bertl the .conf file is legacy config, it works for legacy guests 1121867148 M * Bertl wurd: please take the time and read _all_ the config :) 1121867155 M * Bertl s/config/docu/ 1121867201 M * Bertl (or at least the relevan parts, like the flower page: http://www.nongnu.org/util-vserver/doc/conf/configuration.html) 1121867256 M * wurd what does "legacy" mean? (..or is this question also answered in the docs?) 1121867274 M * FaUl hmm, no load at all on the server - time for mailsetup :-) 1121867281 M * FaUl and news :-) 1121867329 M * Bertl wurd: legacy means: it's more than a year old and not used anymore (but you might have an existing config if you migrate from very old tools) 1121867349 M * Bertl wurd: i.e. it is supported but depreciated ... 1121867357 M * wurd so you're saying the ".conf" method isnt used anymore? 1121867374 M * Bertl not since a year or so ... 1121867376 M * wurd it works but its not recommended? 1121867397 M * wurd (sorry, it's just that i dont master the english language very well) 1121867411 M * Bertl yes, it works, but for example the vserver .. build will create a non-legacy style config 1121867429 M * wurd i didnt use a build 1121867451 M * wurd uhm.. well, in fact, yes i did 1121867457 M * Bertl (the legacy config only supports a subset of the available options) 1121867477 M * Bertl well, it supports what was available 1-2 years ago :) 1121867581 M * wurd ".conf" = legacy ? 1121867587 M * wurd ".conf" = do not use? 1121867612 M * Bertl okay, here the idea: 1121867643 M * Bertl (let me know if you do not understand anything) 1121867661 M * Bertl -a few years ago, we had the vserver tools (from jack) 1121867694 M * Bertl - and we had a vserver kernel (ctx17 and so) 1121867721 M * Bertl - then the 'new' util-vserver tools were created ... 1121867738 M * Bertl - first as replacement of the existing (unmaintained tools) 1121867757 M * Bertl - later they evolved and some things were changed/extended 1121867784 M * Bertl - at some point, enrico (the util-vserver maintainer) decided to change the config, to support more options/features 1121867803 M * Bertl - this 'new style' config is the default now 1121867831 M * Bertl - it is supported by all util-vserver tools (0.30.x) 1121867866 M * wurd and this 'new style' doesnt use vservername.conf 6 1121867867 M * Bertl - to allow for easy migration (from older tools/configs) the tools also understand the 'old' config 1121867905 M * Bertl no, this 'new style' or 'default' config uses a directory structure instead of the single config file 1121867934 M * Bertl this directory structure is described by the 'Flower Page' 1121867971 M * Bertl your guest already uses this config (as it is the default :) and has placed your config/build options there 1121868219 M * bipsen I have a problem trying to build a vserver based on WhiteBox Enteprise Linux 4.0 - I get a message like: "error: unpacking of archive failed on file /usr/bin/X11;42dd7e4d: cpio: symlink failed - No such file or directory" ; a bug somewhere ? 1121868246 M * bipsen - or just report it on savannah ?? ;-) 1121868271 M * Bertl looks like the file is missing ... 1121868293 M * Bertl (which is a problem of the rpm packages) 1121868336 M * Bertl maybe WhiteBox requires a 'basesystem' like Mandrake did some time ago? 1121868485 A * FaUl has brakfirst 1121868511 M * wurd Bertl can i please have a hint? :) 1121868523 M * wurd is the answer to my problem inside /etc/vserver? 1121868535 M * Bertl wurd: no :) 1121868555 M * bipsen yup - there is a basesystem rpm package, I'll try to add it... 1121868562 M * wurd ok :) 1121868575 M * Bertl wurd: http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1121868603 M * Bertl (use the weedpage stylesheet) 1121868620 M * wurd that's what i've been reading for the last 15 minutes 1121868631 M * wurd and everything there is in this page is about /etc/vservers 1121868669 M * bipsen Performing the following to resolve dependencies: 1121868669 M * bipsen Install: basesystem.noarch 0:8.0-4 - base 1121868687 M * bipsen Hmm... seems like basesystem already is installed due to dependency... any other ideas ? 1121868691 M * FaUl so 1121868694 M * Bertl wurd: exactly, /etc/vservers (spot the 's' :) 1121868759 M * wurd haha 1121868768 M * wurd ok, ok :) 1121868815 M * Bertl wurd: look at the interfaces section 1121868849 M * wurd so it's in /etc/vservers// then ? 1121868850 M * Bertl maybe create a guest with --interface (if you didn't do so already) and check what it did write there ... 1121868862 M * wurd because in /etc/vservers , there is no folder that has the name of my vserver :( 1121868865 M * wurd so something must be wrong? 1121868895 M * Bertl might be ... you should try one of the examples from the util-vserver page ... 1121868899 M * Bertl http://linux-vserver.org/alpha+util-vserver 1121869525 M * wurd what should i look for in this page ?? :/ 1121869551 M * wurd you mean i should rebuild my vserver? 1121869587 M * wurd i was looking for a way to set my vserver's ipadress without having to rebuild 1121869588 M * Bertl or build another one, maybe just a skeleton (and see there for the options,a s example) 1121869614 M * Bertl of course it's sufficient to change the proper entries in your existing guest 1121869642 M * Bertl (most likely, you installed the tools somewhere else, and the config is now in /usr/local/etc/vservers or wherever the tools did go) 1121869751 M * wurd what do you mean by "guest" ? 1121869776 M * wurd (yes, i have /usr/loca/etc/vservers, but its empty) 1121869801 M * Pazzo re 1121869807 M * Bertl wurd: well, you said you have 'built' a vserver guest 1121869823 M * wurd i built a vserver 1121869828 M * wurd but i dont know what you mean by "guest" 1121869829 M * Bertl wurd: and IIRC, you did that with util-vserver (vserver .. build ...) 1121869836 M * wurd yes i did a build 1121869846 M * Bertl okay, a vserver guest = vps = 'vserver' 1121869911 M * Bertl so with the build, the config is written ... 1121869940 M * Bertl you can use 'vserver-info - SYSINFO' to see the places for config, etc 1121870008 M * Pazzo Bertl: do you consider -rc8.1 to be as least as stable as -rc5? 1121870041 M * Bertl I'd says so ... we are not doing the rc game to make it less stable after all :) 1121870084 J * Blogmeister ~Blogmeist@site.lycos.de 1121870089 P * Blogmeister 1121870656 M * wurd of course it's sufficient to change the proper entries in your existing guest 1121870661 M * wurd please define 'proper entries' 1121870666 M * wurd or 'entries' 1121870790 M * Bertl this is written in all details on the flower page ... 1121870874 M * wurd but my /etc/vservers// folder doesnt exist 1121870883 M * wurd even though my vserver is functionnal 1121870888 M * wurd (i can enter it) 1121870913 M * Bertl wurd: did you read what I wrote? 1121870932 M * wurd yes i did, but i might not have understood it the way you meant it 1121870962 M * Bertl okay, go back until you find a command to show the 'places' for your tools 1121870992 M * Bertl then, please execute it, and verify that /etc/vservers/ is indeed the place you are looking for 1121871038 N * kevinp|gone kevinp 1121871099 M * kevinp Is there a quick way to see if anyone is logged in to any of the guests running on a host? 1121871101 M * wurd yes, i executed vserver-info 1121871117 M * wurd i found the cfg-Directory 1121871131 M * wurd which is, in my case, /usr/local/vserver/etc/vservers 1121871137 M * wurd and this folder is empty 1121871240 M * kevinp answer to my question: vsomething w --all 1121871307 M * Bertl wurd: then the fact that your guest starts is a bug, pelase report it to enrico :) 1121871334 M * wurd not only can i start it, but i can enter it 1121871368 M * Bertl facinating, what context id does it have? 1121871374 M * wurd lol 1121871400 M * wurd CTX, right ? 1121871416 M * Bertl no seriously, I guess you are still looking in the wrong places ... or you are using a legacy config 1121871427 M * wurd CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME DESCRIPTION 1121871427 M * wurd 0 118 1GB 114kB 35m51.28 10m20.44 21h03m44 root server 1121871427 M * wurd 49152 8 45MB 4kB m00.27 m01.60 19h55m23 1121871427 M * wurd 49153 9 49MB 4kB m00.60 m00.51 2h10m53 milleapp 1121871460 M * Bertl the 49152 one is most likely a legacy guest 1121871474 M * wurd how so ? 1121871474 M * Bertl the 49153 is a new style guest 1121871486 M * wurd well the 49153 is the one i'm entering. 1121871487 M * Bertl because it doesn't show a name in the listing ... 1121871610 M * kevinp not to interrupt, Bertl, but why is it that the legacy vserver name doesn't show up? It's defined in the old config file with VS="name", you think that would be easily accessible to any tool? 1121871653 M * Bertl yep, but since a year or so we do not read it from the config ... but from the kernel 1121871675 M * Bertl and as the legacy guests are started with 'legacy tools' they do not set it 1121871702 M * wurd can i stop this vserver? 1121871707 M * wurd (since it doesnt have a name..) 1121871731 Q * virtuoso Remote host closed the connection 1121871739 M * Bertl wurd: yes, if you know the name :) 1121871743 J * virtuoso ~s0t0na@80.253.205.251 1121871777 M * wurd argh this is driving me nuts 1121871788 M * wurd No configuration for this vserver: 1121871828 M * Bertl btw, how do you enter it? 1121871834 M * wurd vserver name enter 1121871843 M * Bertl it's called 'name'? 1121871885 M * wurd oh, THAT vserver 1121871890 M * wurd i didnt enter it 1121871907 M * wurd i didnt even know it was there and running 1121871919 M * wurd (since a minute ago when i did vserver-stat) 1121871932 M * Bertl okay, so you 'enter' the milleapp guest? 1121871947 M * wurd yes. 1121871965 M * Bertl you might try 'updatedb' followed by 'locate milleapp' then ... 1121871979 M * Bertl (make sure that (s)locate is installed :) 1121872180 Q * bipsen Quit: 1121872353 M * kevinp I've been able to stop vservers with no name before by doing a `vps -edf | grep problemctx` and then kill those processes 1121872354 Q * virtuoso Ping timeout: 480 seconds 1121872391 M * Bertl kevinp: you can do simpler with vkill 1121872420 M * Bertl (which allows you to kill all processes of a given context) 1121872422 M * kevinp ahh, yes that would be easier :) 1121872972 J * virtuoso ~s0t0na@80.253.205.251 1121873035 M * Bertl wb virtuoso! 1121873070 M * wurd [root@mxt-test2 vserver]# vserver milleapp1 start 1121873071 M * wurd No configuration for this vserver: /etc/vservers/milleapp1.conf 1121873082 M * wurd why does it insist in having a configuration file, if this method is deprecated 1121873130 M * Bertl because it doesn't have a config dir either (which causes the fallback to the legacy methods) 1121873141 M * wurd oh!! 1121873155 M * wurd do i have to create the config dir manually % 1121873156 M * wurd ? 1121873227 M * Bertl no, the tools creat it for you (when you build the guest) 1121873235 M * Bertl *create even 1121873247 M * wurd wow. 1121873262 M * wurd i just built this "milleapp1" guest 1121873296 M * Bertl just to clarify, how? 1121873318 M * wurd i will build another one right now, just to be sure 1121873756 M * Pazzo (sorry, been away once again) Bertl: thnx! so I'll give -rc8.1 a chance ;-) 1121874543 J * MooingLemur ~troy@phx200.pinchaser.com 1121874572 M * Bertl welcome MooingLemur! 1121874582 A * MooingLemur moos in return 1121874599 M * Bertl which reminds me of the mad-cow patches :) 1121874766 J * richardw_ ~richard@wlan-tiwag-231-231.utaonline.at 1121874922 Q * richardw Ping timeout: 480 seconds 1121875248 M * Bertl Doener_: let me know when you're around again ... 1121875373 M * eyck mod-cow patches? 1121875377 M * eyck what madcow patches? 1121875398 M * Bertl and a good morning to you too :) 1121875446 M * eyck oh, yes, you had a morning nap, you lucky bastard, 1121875463 M * eyck good morning, 1121875533 M * Bertl eyck: google://mad%20cow%20linux%20-disease :) 1121875584 Q * richardw_ Ping timeout: 480 seconds 1121875703 M * Doener_ Bertl: just came home 1121875755 M * FaUl hmm, that userspace-nfs performs lousy 1121875780 M * FaUl ls 1121875785 M * FaUl oops 1121875787 M * Bertl Doener_: routine kernel check showed that vx_capable is exported but not used ... did we have any reason for that? 1121875807 M * Doener_ hm, don't think so.. 1121875861 Q * ps Remote host closed the connection 1121876249 Q * eXplasm Remote host closed the connection 1121877030 M * Bertl Hollow: was it you who 'adapted' the new_syscall to c99? 1121877159 J * richardw ~richard@81.189.230.24 1121877194 M * Bertl Hollow: yeah, found it in the logs, it was you :) 1121877199 M * Bertl wb richardw! 1121879496 M * Vudumen Bertl: which version do i have to compile now and with which kernel? :) 1121879546 M * Vudumen rc 8 with 2.6.12.3? 1121879560 M * daniel_hozac rc8.1 ;) 1121879573 M * Vudumen ok :) 1121879574 M * Vudumen thanks 1121879586 M * Bertl Vudumen: is running fine on the moon :) 1121879634 M * Vudumen Bertl: cool :) 1121879660 M * Bertl btw, any explanation for: up 5:07? 1121879678 M * Vudumen yes. we got the final power cords in our racks :) 1121879688 M * Bertl ah k 1121879690 M * Vudumen now it should be okay :) 1121880378 M * Bertl Hollow: please let me know when you're around ... 1121880446 M * prae see'ya 1121880460 M * Bertl aloha prae! 1121880472 M * prae =) 1121880511 Q * prae Quit: Execute Order 69 ! 1121880671 J * morfoh ~jeru@p54BFE735.dip.t-dialin.net 1121880685 M * Bertl welcome morfoh! 1121880692 M * morfoh hi Bertl 1121880777 M * morfoh hi all, are there any known issues compiling util-vserver with the current stable version of dietlibc ? 1121880817 M * SNy ohforf'? 1121880819 M * Bertl depends on the arch, but in general, no ... 1121880819 M * SNy ;p 1121880863 M * morfoh SNy: sorry what do you mean ? :p 1121880866 M * Bertl morfoh: what arch/util-vserver version/issue do you have/see? 1121880893 M * SNy hm, was that a rhetorical question? 1121880912 M * morfoh SNy: no 1121880917 M * morfoh Bertl: x86 1121880923 M * SNy in that case: thenoobcomic.com 1121880936 M * morfoh Bertl: and 0.30.204 1121880953 M * Bertl morfoh: get 0.30.208 (while it is still hot :) 1121881030 M * morfoh Bertl: ok ... I'll check that ... thx so far 1121881086 M * Bertl nothing to thank me for yet :) 1121881096 M * morfoh Bertl: do you have an URL for a tar ball or do I have to pull it out of a repo ? 1121881133 M * Bertl http://www.13thfloor.at/~ensc/util-vserver/files/alpha/ 1121881150 M * morfoh thanks 1121881155 M * Bertl yw 1121881159 M * morfoh :) 1121881180 Q * erwan_ho Remote host closed the connection 1121882017 M * Greek0 Bertl: do you have time for some less vserver related kernel questions? I'm quite confused by your locking in the dlimit files, and IMHO it comes from not understanding the locking primatives themselves.. 1121882044 M * Bertl on my or on your side :) 1121882068 M * FaUl Bertl: what are your plans for wth now? found a way to come? 1121882082 M * Greek0 Bertl: of course on mine :) 1121882088 M * Bertl FaUl: not yet, but there might be an option nevertheless 1121882125 M * Bertl Greek0: okay, let's hear ... 1121882157 M * Greek0 Bertl: query? it's really not very vserver-related 1121882284 M * Bertl well, do you care? I don't (atm it's very quiet here) 1121882312 M * Greek0 I have no problem with it. just wanted to avoid flooding the channel with stuff noone cares about ;) 1121882372 M * Greek0 the main problem is probably that I don't understand how rcu_read_lock and spinlocks interact. 1121882505 M * Greek0 how I came to it: in kernel/vserver/dlimit.c you lock dl_info_hash_lock only when writing to the hash, not when reading from it. there you use rcu_read_lock 1121882510 M * Bertl af#define rcu_read_lock() preempt_disable() 1121882516 M * Bertl #define rcu_read_unlock() preempt_enable() 1121882522 M * Bertl s/af// 1121882590 M * Greek0 yes, I found those. they only puzzled me more, since I don't know if preemption is disabled for all cpus. i.e. if that is something like a BKL then 1121882713 M * Bertl the preemption just affects the current thread 1121882750 M * Bertl basically you 'guarantee' that the execution will not stop between rcu_read_lock() and unlock() 1121882777 M * Bertl (stop and continue with another thread that is) 1121882833 M * Greek0 ok, but what happens if another cpu fiddles with the dli hash at the same time? 1121882865 M * Bertl it can't because it would need the proper write lock 1121882927 M * Bertl well, it can add/remove stuff there 1121882948 M * Bertl which is quite fine, as the rcu aware primitives will not be harmed by that 1121882949 M * Greek0 you don't have a lock on the hash at that time. only disabled preemption on this cpu 1121882959 M * Greek0 ok 1121882998 M * Bertl so changes to the 'structure' are fine, because of the rcu primitives 1121883012 M * Bertl they ensure that whatever happens I see a consistent state 1121883020 M * Bertl (which might not be the current state) 1121883121 M * Bertl when the 'entry' itself is changed, we need locking (if it is critical) 1121883224 M * Greek0 ok 1121883372 M * Greek0 hmm. isn't there still a small race from __lookup_dl_info, where you locate the dli in the hash, to get_dl_info, where you increment its usecnt? 1121883421 M * Greek0 The preempt_disable makes the race quite small though 1121883424 J * benjamin__ ~benjamin@sherpadown.net 1121883458 M * Greek0 you'd probably hit a BUG_ON somewhere in the dli freeing logic 1121883483 M * Bertl no, we are holding the hash_lock when we hash/unhash stuff 1121883531 M * Bertl welcome benjamin__! 1121883538 M * benjamin__ Hi bertl 1121883558 N * benjamin__ bgigon|prae 1121883560 M * Bertl Greek0: and the freeing of the dl_info is done via rcu_free_dl_info() 1121883570 M * Greek0 but you can get a dli from the hash that's not on it anymore, and that is possibly in the process of being cleaned up, or am I seeing this wrong? ..ah 1121883601 M * Greek0 ah, ok.. seems to make some sense finally :) 1121883733 M * Bertl well, it was the first try I had with rcu stuff (in linux-vserver) so it's probably not that self explanatory at all ... 1121883780 M * Bertl we later moved to rcu for xid/nid too, but it was easier to do/understand with the current refcounting 1121883794 M * Bertl (and I didn't see much gain in the rcu stuff anyway) 1121883990 M * Bertl you have to bend your mind around it to verify that the setup is correct ... and the refcounting is much easier to understand/verify (at least IMHO) 1121884055 M * Doener_ well, i sometimes had to bend my mind with the refcounting, too ;) 1121884123 M * Bertl actually I was expecting this comment :) 1121884131 M * Greek0 http://greek0.net/~greek0/div/vserver-race 1121884134 M * Greek0 can't this happen? 1121884196 M * Greek0 well, it's just that you have spinlocks and rcu-locks, which makes it somewhat hard to distinguish what may or may not happen on this or another processor 1121884292 M * Bertl okay, which BUG_ON() should trigger? 1121884335 M * Greek0 BUG_ON(atomic_read(&dli->dl_usecnt)); 1121884345 M * Greek0 in __dealloc_dl_info 1121884486 M * Greek0 I guess the race may be small enough to never trigger, but I think it is there 1121884506 M * Bertl wait, you start with free_dl_info() 1121884534 M * Bertl which is actually rcu_free_dl_info() no? 1121884582 M * Greek0 yep. 1121884596 M * Greek0 CPU1: wants to access $DLI 1121884603 M * Greek0 CPU2: there the same $DLI is unhashed 1121884616 M * Bertl IBUG_ON(atomic_read(&dli->dl_usecnt)) 1121884624 M * Bertl does not exist there ... 1121884641 M * Bertl (so it can not trigger :) 1121884658 M * Greek0 __dealloc_dl_info in kernel/vserver/dlimit.c 1121884678 M * Greek0 which is run by rcu_free_dl_info 1121884682 M * Bertl ah, now you are in the next function 1121884690 M * Greek0 ursg 1121884697 M * Greek0 sorry for being blind 1121884705 M * Bertl so let's have a look under what condition that is called 1121884715 M * Greek0 didn't double check this 1121884719 M * Greek0 just saw it :) 1121884734 M * Bertl if (!usecnt) <-- condition 1121884761 M * Greek0 :) 1121884763 M * Bertl the rcu_call ensures that all CPUs had a 'pause' 1121884849 M * Greek0 yep, I was just too blind to see/remember that condition 1121884856 M * Greek0 it's tricky ;) 1121884863 M * Bertl but again, I doubt that the rcu stuff really buys us anything here, and we might just as simply convert it to refcounting as we did with xid/nid 1121884878 M * Bertl I was just too lazy to convert that yet ... 1121884923 M * morfoh Bertl: util-vserver 030.208 was build smoothly with dietlibc 0.29 ... thx again ;) 1121884954 M * Bertl morfoh: you're welcome! have fun! 1121884969 M * morfoh yes ... I'll :) 1121885007 M * morfoh I'm preparing a small dietlibc based vserver host system atm 1121885023 M * Greek0 Bertl: wouldn't read/write spinlocks on the hash be easier? 1121885107 M * Bertl that would do for the hash, but not for the (de)allocations 1121885181 M * Bertl morfoh: sounds good! 1121885206 M * morfoh yeah! it's allmost finished 1121885318 M * Bertl Greek0: btw, it might be interesting to show that rw locks are faster/better than simple spinlocks 1121885415 M * Greek0 well, you get rid of contention in the readonly case.. 1121885477 M * Bertl patches are welcome :) 1121885491 M * Greek0 for the hash? or for what? 1121885508 M * Greek0 I still don't see why rw spinlocks on the hash won't do it, actually 1121885525 M * Bertl xid/nid hashes and if you want to convert the dlimit, then there too of course 1121885570 M * Bertl feel free to go crazy, don#t expect the patches to make it into 2.0 (unless they are really trivial) 1121885595 M * Greek0 yep. I'll try if I find time 1121885606 M * Greek0 would be cool if I made it through at least, though 1121885686 M * Greek0 I'm at about 40% of the huge patch now.. given my current reading speed and time (3 hours on the train every monday when I go to vienna), I should be done in about 3-4 weeks.. 1121885714 M * Bertl you are reading through the broken down version or the all-in-one patch? 1121885761 M * Greek0 all in one. I started with that one since I didn't know the split up series existed. and when you told me I was already at 15% or something and didn't want to stop 1121885780 M * Bertl oh well :/ 1121885828 M * Greek0 well, till now it works quite well, except my continuous "Bertl, got some time for kernel questions"-sessions ;) 1121885870 M * Greek0 the fs stuff is pretty clear to me up to now, except why/how vroot works, but that's just minor priority for me now. 1121885874 M * Bertl well, those are very welcome .. it's always good to question implementations ... 1121885892 M * Greek0 well, I doubt mine are really good ;) 1121885999 M * Bertl regarding vroot, it's quite simple: it's the minimum required to satisfy the quota tools (i.e. make them believe they are talking with a real block device) and to proxy those ioctls to the real device in a secure manner 1121886069 M * Bertl http://vserver.13thfloor.at/Experimental/DEL-vs2.0-rc6.1/29_vroot.diff 1121886079 M * Greek0 hmm yes. the main problem here is again that I don't understand the infrastructure behind it. I just don't know how it works at the user and the kernel level 1121886099 M * Greek0 ie. why setting quota in the vserver won't affect the host 1121886102 M * Bertl you know how losetup/loop works? 1121886141 M * Greek0 yep, I see what vroot does, just now why it works with quota in the expected way :) 1121886145 M * Bertl ah, on vs2.0 it will affect the host ... per context quota is not implemented yet 1121886152 M * Greek0 ah, ok 1121886178 M * Bertl but even if you make a separate partition for each guest, it's not secure to provide the real block device to them 1121886228 M * Greek0 what could the guest do? 1121886266 M * Bertl open the device for writing, and sneak in a few other device nodes :) 1121886332 M * Greek0 ah, nifty ;) 1121886404 M * Greek0 most of the time I actually understand your code. the biggest problem is seeing how it interacts with the rest of the kernel. and actually reading your patch is like a guided tour through the linux kernel for me :) 1121886481 M * Bertl hmm, well, there are probably better tours through the kernel .. but hey, if you like it, be my guest ... 1121886590 M * Greek0 well, probably yes. but then reading vserver I have a reason to look into the kernel. if I just grabbed some book or some online howto and started reading/hacking the kernel just for the sake of it, I'd feel even more geeky then I normally do ;) 1121886633 M * Greek0 plus, I need something to read on the train anyway. so why waste my time with prose when I can read code ;) 1121886712 M * Bertl i.c. 1121887351 M * morfoh seems that the util-vserver configure script has some problems while trying to cross-compile 1121887374 M * Bertl hmm, yes? 1121887418 M * morfoh Bertl: or it's a problem of our build kit 1121887434 M * morfoh checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables 1121887492 M * Bertl please submit them to savannah https://savannah.nongnu.org/bugs/?group=util-vserver once you're certain it's a config issue (not a cross tool issue) 1121887514 M * morfoh Bertl: ok 1121887533 M * Bertl I have to admit that I didn't try to cross compile it yet ... 1121887560 M * morfoh Bertl: don't worry :) 1121887671 M * daniel_hozac morfoh: what does the config.log say? 1121887760 M * morfoh daniel_hozac: no C++ 1121888120 M * Bertl morfoh: well, it might help if you could upload the log somewhere? 1121888337 M * morfoh Bertl: ack. I think I know the problem. configure checks for C++ and we've simply no C++ in that system build stage 1121888402 M * morfoh Bertl: does util-vserver needs it ? 1121888513 Q * tchan Remote host closed the connection 1121888518 J * tchan ~tchan@c-24-13-81-164.hsd1.il.comcast.net 1121888581 M * Bertl morfoh: for some tools, yes 1121888602 M * Bertl most stuff can be built without c++ though, but the compiler has to be c99 compliant 1121888761 M * morfoh Bertl: ic 1121888772 M * morfoh Bertl: https://trac.t2-project.org/ticket/36 <-- requested config.log 1121888899 M * Bertl cool 4 certs, all empty :) 1121889079 M * Bertl yeah, g++ is missing ... 1121889091 M * morfoh yep 1121889121 M * Bertl but I guess it's somehow specific to your environment that this causes an error 1121889130 M * morfoh Bertl: ack 1121889143 M * morfoh what tools will need c++ ? 1121889168 M * Bertl >> Build C++ programs: no (affected: vbuild, vcheck) 1121889168 M * Bertl >> Build C99 programs: no (affected: vunify, vcopy, vhashify, vdlimit) 1121889177 M * Bertl from the previous version 1121889188 M * morfoh ah ok 1121889209 M * Bertl IIRC, the 0.30.208 'requires' c99 now 1121889259 M * Bertl i386-t2-linux-gnudietlibc what's that btw? 1121889334 M * Bertl I've read the T2 page, but I wonder, why do you cross compile here? 1121889412 M * morfoh Bertl: I'm just using a very specific target atm ... not a common t2 target 1121889459 M * morfoh Bertl: atm it just cross-compiles all the stuff 1121889479 M * morfoh Bertl: normally vserver stuff isn't cross-compiled on t2 1121889494 M * Bertl yeah, but i686 -> i386 cross compiling sounds weird to me :) 1121889523 M * morfoh yes ... but I've other archs too .... this is just for testing :) 1121889551 M * Bertl k, well, then you probably want to have g++ for those too ... 1121889599 M * morfoh ack 1121889685 M * morfoh Bertl: as I said this target was just derived from my dietlibc based embedded firewall target. there everything is cross-compiled ...:) 1121890306 J * yarihm ~yarihm@80-218-5-17.dclient.hispeed.ch 1121890490 M * Bertl welcome yarihm! 1121890542 M * yarihm yo Bertl 1121892498 M * Bertl okay, I guess I'm off to bed ... maybe back later ... 1121892539 M * morfoh Bertl: good night ...sleep well 1121892554 M * Bertl tx, cya all later ... 1121892559 N * Bertl Bertl_zZ 1121894686 Q * virtuoso Ping timeout: 480 seconds 1121895179 J * Aiken ~james@tooax8-069.dialup.optusnet.com.au 1121895456 J * virtuoso ~s0t0na@80.253.205.251 1121896920 Q * daniel_hozac Quit: changing connection 1121897043 J * daniel_hozac ~daniel@c-6f1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1121897299 Q * alexx Ping timeout: 480 seconds 1121898142 Q * yarihm Quit: Leaving 1121899925 Q * Hunger jupiter.oftc.net neutron.oftc.net 1121899937 J * Hunger Hunger.hu@Hunger.hu 1121901173 Q * bgigon|prae Quit: Pwet 1121901227 J * alexx ~alexx@82.225.136.176 1121901389 Q * morfoh Ping timeout: 480 seconds 1121902542 J * angel4u Angel@Cable-82-216.TopAllNET.Ro 1121902547 M * angel4u heya 1121902574 M * angel4u someone online? 1121902644 M * richardw <-- :) 1121902678 M * angel4u :) 1121903545 M * richardw gn8@all 1121903563 Q * richardw Quit: Leaving 1121903592 Q * angel4u Quit: