--- Log opened wto kwi 27 00:00:56 2004 00:25:36>> click [click@gonnamakeyou.com] has joined #vserver 02:36:28>> serving [~serving@213.186.189.95] has quit [Ping timeout: 480 seconds] 03:05:27>> Netsplit jupiter.oftc.net <-> nucleon.oftc.net quits: nalfein, cereal^away, Khahan, lilo, rmoriz, UFOczek 03:05:35>> Netsplit over, joins: Khahan, UFOczek, lilo, rmoriz, cereal^away, nalfein 03:05:35>> kinetic.oftc.net changed the topic of #vserver to: http://linux-vserver.org/ | latest stable 1.27, devel 1.3.9, exp 1.9.0pre12 03:45:57>> yarihm [~yarihm@217-162-206-184.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 04:48:54>> yarihm [~yarihm@217-162-205-7.dclient.hispeed.ch] has joined #vserver 06:07:54< muisec> bah, anyone around? 08:32:51>> rs [~rs@rs.admin.rhapsodyk.net] has quit [Quit: leaving] 08:34:30>> virtuoso [~shisha@213.158.10.27] has joined #vserver 08:48:51< lilo> hi flock 08:54:28< virtuoso> hi 09:23:27>> virtuoso [~shisha@213.158.10.27] has quit [Read error: Connection reset by peer] --- Log closed wto kwi 27 09:41:16 2004 --- Log opened wto kwi 27 09:41:18 2004 09:41:18>> albeiro_ [albeiro@linux.gentoo.pl] has joined #vserver 09:41:18>> Irssi: #vserver: Total of 33 nicks [0 ops, 0 halfops, 0 voices, 33 normal] 09:41:23>> rs [rs@ice.aspic.com] has joined #vserver 09:41:28< rs> lo 09:41:56>> Irssi: Join to #vserver was synced in 38 secs 09:43:26>> Khahan [~Filbert@D5774530.kabel.telenet.be] has quit [Ping timeout: 480 seconds] 09:43:37>> Khahan [~Filbert@D5774530.kabel.telenet.be] has joined #vserver 09:44:20>> albeiro [albeiro@linux.gentoo.pl] has quit [Ping timeout: 483 seconds] 09:44:20>> Keepnick: Nickstealer left [OFTC], got albeiro back 09:48:00>> loger [~loger@213.159.118.2] has joined #vserver 10:08:02>> rs [rs@ice.aspic.com] has quit [Quit: Lost terminal] 10:09:31>> rs [rs@ice.aspic.com] has joined #vserver 10:20:54>> virtuoso [~shisha@213.158.10.83] has joined #vserver 10:21:08>> virtuoso [~shisha@213.158.10.83] has quit [Quit: ] 10:27:40>> virtuoso [~s0t0na@213.158.10.83] has joined #vserver 10:31:14>> virtuoso [~s0t0na@213.158.10.83] has quit [Quit: ] 10:32:10>> virtuoso [~s0t0na@213.158.10.83] has joined #vserver 11:01:21>> virtuoso_ [~s0t0na@213.158.11.166] has joined #vserver 11:01:22>> virtuoso [~s0t0na@213.158.10.83] has quit [Read error: Connection reset by peer] 11:26:41< rs> is enrico there ? 11:28:25>> virtuoso_ [~s0t0na@213.158.11.166] has left #vserver [] 11:31:12>> loger [~loger@213.159.118.2] has quit [Ping timeout: 480 seconds] 11:46:24>> rmoriz [rmoriz@vserver.jp] has quit [Read error: Connection reset by peer] 11:46:32>> rmoriz [rmoriz@vserver.jp] has joined #vserver 11:46:56>> serving [~serving@213.186.189.95] has joined #vserver 11:54:00>> loger [~loger@213.159.118.2] has joined #vserver 12:09:46< eyck> vd 12:15:27>> serving [~serving@213.186.189.95] has quit [Read error: Connection reset by peer] 12:20:23>> loger0 [~loger@213.159.118.2] has joined #vserver 12:21:15>> loger [~loger@213.159.118.2] has quit [Ping timeout: 480 seconds] 12:21:16>> loger0 is now known as loger 12:21:46>> monrad [~monrad@213083190231.sonofon.dk] has joined #vserver 12:28:29>> gst [~gst@eris.sysfrog.org] has joined #vserver 12:36:15>> loger [~loger@213.159.118.2] has quit [Ping timeout: 480 seconds] 12:47:53>> loger [~loger@213.159.118.2] has joined #vserver 13:00:05>> mcp [~hightower@81.17.110.148] has quit [Ping timeout: 480 seconds] 13:03:44>> monrad [~monrad@213083190231.sonofon.dk] has quit [Quit: Leaving] 13:16:46>> mcp [~hightower@81.17.110.148] has joined #vserver 14:11:27>> serving [~serving@213.186.189.95] has joined #vserver 14:42:56>> Bertl_oO is now known as Bertl 14:43:06< Bertl> morning everyone! 15:07:36< eyck> mornin' 15:08:09< Bertl> hey, how are you eyck? 15:32:41< rs> hello Bertl, how are you ? 15:33:17< Bertl> fine, thanks ... and you? 15:33:32< rs> fine too :) 15:38:32< eyck> fine, thank you, how about you? 15:39:42< Bertl> .oO( hmm .. maybe I should write uppercase ;) 15:40:09< rs> or try colors :) 15:50:17< Bertl> Color ... 15:51:29>> Doener` [~doener@p5082DD41.dip.t-dialin.net] has joined #vserver 15:51:39< Bertl> hi Doener`! 15:53:32>> ant [~ant@pD9519D68.dip.t-dialin.net] has joined #vserver 15:53:38< Bertl> hi ant! 15:53:43< ant> hi :) 15:53:53< Bertl> how are you today? 15:54:08< ant> fine, thanks 15:55:06< ant> ...except that i´ve some troubles starting a vserver with version 1.3.9 ;-} 15:55:32< Bertl> hmm ... any further details? 15:56:24>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has joined #vserver 15:56:27< ant> yes, i´m reproducing it... 15:56:43< Bertl> hi mhepp! 15:56:52< ant> hi mhepp 15:57:04< mhepp> Hello everybody! 15:57:24< mhepp> Hou! new experimental version! 15:58:29< ant> I think I am missing something when I migrated to the 1.3.x-versions. I had/have a 1.22 running fine, and i suppose the way its configures/setup changed a bit... 15:58:40< ant> i get the following error: 15:58:41>> Doener [~doener@p5082D95C.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 15:58:54< ant> # sbin/vserver test start 15:58:59< ant> readlink("/home/vservers/etc/vservers/test/run"): Invalid argument 15:59:04< ant> save_ctxinfo: readlink("/home/vservers/etc/vservers/test/run"): Invalid argument 15:59:23< Bertl> hmm, that _is_ something new ;) 15:59:26< ant> do you have any idea what I missed during the migration? 15:59:36< ant> oops ;-] 16:00:09< ant> (thats something i didn´t want to read ;)) 16:00:44< Bertl> did you update the tools too? 16:00:50< ant> i admit, that my paths are somewhat non-standard because i dind´t want to mess up the base system until i got it running... 16:01:16< ant> yes, i compiled the tools i found on the same page as version 1.3.9 16:01:34< Bertl> okay, let's check the config then ... 16:01:37< ant> the OS here is Debian woody, I had to use gcc 3.0--- 16:01:46< Bertl> vserver-info - STATUS 16:02:00< Bertl> (either on a web page, or in private please ;) 16:02:21< ant> query berty 16:02:34< Bertl> close, but no banana! 16:05:19< Bertl> okay, let's verify those pathes ... 16:05:42< Bertl> ls -lad /home/vservers /home/vservers/etc /home/vservers/etc/vservers 16:07:14< Bertl> ls -lad /home/vservers/etc/vservers/test/run 16:12:13< Bertl> hmm, I'd suggest you post a mail on the ml, and cc it to enrico, becuase I don't know what causes this behaviour ... never seen it before ... 16:13:01< Bertl> you can try to strace/'bash -x' the start/stop and see if this gives more info about it ... 16:13:08< rs> Bertl: is ít normal that /proc/mounts is unhiddable ? 16:13:16< rs> and that it show all host mounts ? 16:13:31< rs> it's a not yet implemented separation ? 16:13:32< Bertl> yep, well at least as vproc is concerned ... 16:14:31< Bertl> /proc/mounts is no file, it's a link into /proc//mounts 16:15:05< Bertl> but there is a cflag which disables /proc/mounts (or least it should ;) 16:15:20< rs> intresting, which one ? 16:15:55< Bertl> #define VXF_HIDE_MOUNT 0x01000000 16:19:40< rs> ok it works, the util-vserver flag is hidemount 16:19:59< rs> so all mounts are hidden 16:20:06< Bertl> fascinating, isn't it? 16:20:14< rs> yep :) 16:20:25< rs> I also found the SECURE_MOUNT flag name 16:20:41< rs> it the mount string into the ccapabilities file 16:21:23< rs> but didn't worked 16:23:18< rs> vserver145:~# umount /proc 16:23:18< rs> vserver145:~# mount /proc 16:23:18< rs> mount: permission denied 16:24:21< Bertl> could you check if that cap is available for the context? 16:24:44< Bertl> (in the /proc/virtual//... 16:26:24< rs> it isn't 16:28:45< Bertl> try to set it with the vccaps tool 16:28:54< Bertl> (included in the vflags package) 16:29:03< Bertl> http://vserver.13thfloor.at/Experimental/vflags-0.01.tar.bz2 16:31:01>> Shotygun [shotgun@shotygun.com] has quit [Ping timeout: 480 seconds] 16:31:20< rs> doesn't work better 16:31:33< rs> vccaps -x 15 -S 0x00010000 16:31:38< rs> cat /proc/virtual/15/status 16:31:38< rs> RefC: 35 16:31:38< rs> Flags: 0000000001000155 16:31:38< rs> BCaps: 00000000d44c04ff 16:31:38< rs> CCaps: ffffffffffffffff 16:31:40< rs> Ticks: 0 16:31:51< Bertl> vccaps uses the bit number ;) 16:32:15< Bertl> vccaps -x 15 -S 16 16:32:20< kestrel> hey herbert, i like the vproc thing...that is handy 16:32:40< Bertl> kestrel: hey, fine, which one ;) 16:32:51< rs> bvdsn02:~# vccaps -x 15 -S 16 16:32:51< rs> bvdsn02:~# cat /proc/virtual/16/status 16:32:51< rs> RefC: 13 16:32:51< rs> Flags: 0000000000000155 16:32:51< rs> BCaps: 00000000d44c04ff 16:32:53< rs> CCaps: ffffffffffffffff 16:32:56< rs> Ticks: 0 16:33:28< Bertl> hmm, you have all caps ... so it's probably a missing feature/bug ... 16:33:47< rs> all caps ? 16:33:48< Bertl> didn't see the ffffffffffffffff, at first glance ... 16:33:52< rs> I didn't set any 16:34:12< rs> I thought it was a kind of inverted mask :o) 16:34:21< Bertl> well, capabilities seem to be 'enabled' by default, with enricos tools, which isn't such a bad idea ... 16:34:44< Bertl> (similar to the posix caps ...) 16:36:59< rs> strange because he offer a way to enable them but not to disable 16:37:54< Bertl> hmm, maybe something to report .... 16:38:02< rs> yep 16:38:36< rs> another thing, you told me that you did some accounting of the network usage 16:38:54< Bertl> well, yes and no ... 16:38:55< rs> is there a way to gather these data ? 16:39:09< Bertl> what is done, is accounting of sockets ... 16:40:43< Bertl> this data can be collected from /proc/virtual//cvirt 16:40:51< Bertl> (the name will change soon) 16:41:05< rs> yes I saw this file 16:41:49< Bertl> the INET/INET6 accounting is roughly equiv to the actual network traffic ... 16:43:38< rs> nice 16:43:40>> ensc [~ircensc@ultra.csn.tu-chemnitz.de] has joined #vserver 16:43:49< ensc> hi 16:43:50< Bertl> hi enrico! 16:44:04< Bertl> we where talking about you ;) 16:44:06< rs> I don't really know how to read it but should be simple 16:44:15< rs> in bad :P 16:44:23< rs> hello ensc 16:44:38< Bertl> IIRC in/out/err 16:45:24< ensc> rs: I got your mail at the weekend (although it was dated as wednesday). xsltp the xalan xsl-processor, the stylesheet is in CVS 16:45:35< ensc> or 0.29.211 should have it too 16:45:42< rs> 211 ? 16:45:48< rs> damn I'm pretty late 16:46:46< Bertl> ensc: the default ccaps set is: 16:46:47< Bertl> 16:32 < rs> CCaps: ffffffffffffffff 16:46:54< Bertl> is that intentional? 16:46:57< ensc> Bertl: yep; current '--secure' default 16:47:22< Bertl> 16:34 < Bertl> well, capabilities seem to be 'enabled' by default, with enricos tools, which isn't such a bad idea ... 16:47:25< Bertl> 16:34 < Bertl> (similar to the posix caps ...) 16:47:28< Bertl> 16:36 < rs> strange because he offer a way to enable them but not to disable 16:47:46< ensc> can be disabled by putting '~all' into the ccapabilities file 16:48:00< rs> I think that I don't understant, full caps il less secure that none isn't it ? 16:48:15< rs> il/is 16:48:15< Bertl> rs: think like the posix caps 16:48:30< Bertl> you don't want zero caps to start with ;) 16:49:07< rs> so what will be the default without --secure ? 16:49:40< Bertl> ~0 as it is now for --secure ... probably 16:49:54< ensc> they will not be changed 16:50:03< ensc> so they will get the settings from the kernel 16:50:10< rs> Bertl: anyway, if we have all ccaps and the mount proc don't work, that's mean that the SECURE_MOUNT doesn't work the way you want, isn't it ? 16:50:58< Bertl> yep ... correct ... 16:51:18< Bertl> 16:33 < Bertl> hmm, you have all caps ... so it's probably a missing 16:51:18< Bertl> feature/bug ... 16:52:42< rs> ok sorry :) 16:53:43< Bertl> np 17:14:22< rs> ensc: should be a good idea to list all possible values for [bc]capabilites and flags files, so are you interested by such addition from my side, I will send you the diff ? 17:15:31< ensc> rs: good idea; but I changed some names in .211. See lib/[bc]caps-v13.c and cflags-v13.c 17:16:24< ensc> ok, bcaps is empty... these are the usual linux capabilities 17:16:48< Bertl> (an upper bound to them ;) 17:17:11< Bertl> rs: what is your native language? 17:17:45< rs> french 17:17:49 * ant needs to get something to eat now ;) 17:17:51< rs> why ? 17:18:12< Bertl> just asking .. because I'm in search for some native english speaker, again ;) 17:18:40>> ant [~ant@pD9519D68.dip.t-dialin.net] has quit [Quit: (I think I´ll return - Bye)] 17:19:49< rs> did you seriously thought that english was my native language ??? :o) 17:20:08< albeiro> Bertl: what do you need to translate this time ? 17:20:20< Bertl> rs: well, actually no, but nowadays you better ask ;) 17:21:37< rs> hehe :) 17:21:44< Bertl> albeiro: I'm looking for a word expressing something like the 'basic, elementary, core' features ... but in one word ... 17:21:56< Bertl> (not including the features part ;) 17:23:14< albeiro> [17:23:06] < tocharian> fundamental? 17:24:12< albeiro> [17:23:58] <@tseng> try a thesaurus with those words 17:24:12< albeiro> [17:24:00] <@scox> albeiro: base 17:24:22< albeiro> that's all from me (not me in fact) 17:24:41< albeiro> [17:23:20] <@tseng> definitive, central 17:24:52< Bertl> hum m-w changed the layout? ... first google, now they ... 17:25:28< Bertl> hmm actually 'essential' looks good ... 17:26:27< Bertl> albeiro: thanks for suggesting thesaurus ... ;) 17:26:53< albeiro> heh 17:31:32< Bertl> rs: how is you 'feeling' regarding 1.9.0pre stability? 17:32:04< Bertl> ensc: any issues with pre12? 17:32:15>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has quit [Remote host closed the connection] 17:32:28< ensc> Bertl: no, works like a charme 17:32:39< rs> seems pretty stable 17:32:57< rs> didn't got issue for moment 17:33:19< Bertl> okay, because I'm toying with the idea of actually releasing 1.9.0 this week ... 17:33:46< ensc> when LVM snapshots would be possible/stable, I would switch to 2.6 now 17:33:54< rs> should attract more testers 17:34:04< Bertl> lvm2 snapshots do not work? 17:34:34< ensc> afaik, not with the official kernel 17:38:02< rs> do you mean that vserver patch break lvm2 snapshot ? 17:39:38< ensc> no, but I do not know if the snapshot patch is stable 17:40:28< ensc> since it is not in the kernel, I guess there are still some issues 17:43:22>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 17:43:46< Bertl> hi shuri! 17:44:53< rs> Bertl: actually, completly hidding the containt of /proc/mounts break lsof :/ 17:45:22< Bertl> with namespaces, your problem will be solved in a more accurate way ;) 17:46:08< rs> I think I'm using namespace because I didn't told to util-vserver to no use it :) 17:46:32< rs> there is a way to check that ? 17:46:41< Bertl> well, in this case, you do not need to disable the /proc/mounts as it only shows the per vserver mounts, right enrico? 17:47:02< rs> wasn't the case, so maybe a don't use namespace 17:47:51< rs> oups I'm totaly wrong, namespace was disabled 17:47:57< rs> dunno why 17:48:11< ensc> Bertl: no, you still see the old mounts 17:48:56< Bertl> hmm, what did we implement the 'cleanup' for? 17:49:03< Bertl> (actually I ;) 17:49:59< ensc> Bertl: does not really work. cleanup must be executed before mount, but after cleanup I do not have 'mount' anymore 17:50:20< ensc> try 'NAMESPACE_CLEANUP=1 vserver ... start' 17:50:29< Bertl> hmm, please elaborate ... 17:50:48< Bertl> cleanup is only supposed to 'remove' unused entries ... 17:51:17< ensc> I would have to execute 'vnamespace --cleanup; mount-my-filesystems; chbind ... vcontext ... init' 17:51:49< ensc> after cleanup, the filesystem disappears and I do not have any executable (mount, chbind, vcontext...) anymore 17:52:26< Bertl> hmm, your cwd with the cleanup is? 17:52:39< rs> hum 17:52:46< ensc> /vservers/.../ 17:52:59< rs> I just tried with NAMESPACE_CLEANUP=1... 17:53:01< Bertl> so you are executing with a cwd inside the vserver? 17:53:06< ensc> or / 17:53:13< rs> seems that it break the machin 17:53:36< rs> it still responding to ping but all services are frozen 17:53:46< Bertl> looks like a panic ... 17:53:58< rs> I will seen, brb 17:54:00< rs> see 17:56:48>> gst [~gst@eris.sysfrog.org] has quit [Quit: Client exiting] 17:57:54< rs> re 17:58:13< rs> so the machin was totaly frozen but no stack trace was shown 17:58:24< rs> really strang isn't it ? 17:58:35< Bertl> hmm, did you reset it? 17:58:40< rs> yep 17:58:54< Bertl> you should force a task dump in such a case (next time) 17:59:13< rs> I can retry this on another machine 17:59:26< Bertl> is spinlock debugging enabled? 17:59:36< rs> yep it should 17:59:52< Bertl> magic sysreq too, I presume? 17:59:57< rs> yes 18:00:16< Bertl> okay, then if you can/will try it again, and try to get a task dump ... 18:05:52< rs> ok reproduced on the second machine 18:06:41< Bertl> ensc: if (p == fs->rootmnt || p == fs->pwdmnt) 18:06:41< Bertl> continue; 18:07:02< Bertl> this should preserve the pwd and the root 18:07:34< ensc> my util-vserver executables are under /usr, and I need /var and probably /tmp too 18:07:59< Bertl> okay, so is this the 'real' issue? 18:08:28< Bertl> would context tagging the vfsmounts help? 18:08:54< Bertl> could this also be used to hide 'non-context' mount without namespaces? 18:09:15< ensc> it does not help when I have only '/' or pwd 18:09:26< Bertl> (means can you adjust the tools to do the mounts from 'inside' the context before giving up the caps)? 18:11:07< ensc> the caps will be removed by /usr/sbin/vattribute or vcontext which would not be available after cleanup 18:11:47< ensc> some scriptlets will be executed after mounting the vserver 18:12:45< Bertl> what about doing the cleanup afterwards from outside? 18:13:38< ensc> how? cleanup must be done before mount 18:13:55< Bertl> can you provide a simple testline for 209 (or 211 if required) which uses the cleanup? 18:14:30< ensc> NAMESPACE_CLEANUP=1 vserver ... start 18:14:37< Bertl> ensc: ad how: well if we can do _all_ context mounts from inside, then we can cleanup only the non-context ones ... 18:15:05< Bertl> ensc: this is something which requires a completely setup vserver, not what I call a simple testline ;) 18:15:38< ensc> but I need non-context mounts after the cleanup 18:15:50< ensc> (e.g. /usr or /var or /tmp) 18:16:05< Bertl> hmm, isn't that somehow defeating the purpose? 18:16:27< Bertl> but anyways, you could do the cleanup after all other commands did run ... 18:17:26>> rs_ [rs@ice.aspic.com] has joined #vserver 18:17:48< rs_> ok I have a trace, what are you intrested for Bertl ? 18:18:02< ensc> you mean, mounting the /vserver filesystems with an anonymous context? 18:18:15< Bertl> rs: the process hanging in the semaphore or wherever ;) 18:19:17< Bertl> ensc: somehow I lost you ... the basic idea behind the namespace stuff was to replace chroot(2) right? 18:19:23< rs_> the top of the stack is follow_mount 18:19:28< ensc> Bertl: yep 18:19:44< Bertl> okay, so after chroot() your /usr /bin /etc is gone, right? 18:19:54< Bertl> at least the 'old' ones ... 18:20:14< rs_> EIP is at .text.lock.namespace... 18:20:22< ensc> I am not sure, what there is happening in the kernel. /proc/mounts lists them 18:20:26< Bertl> rs: that looks good ... 18:20:54< Bertl> ensc: yes, that is true, because they 'where' mounted and not unmounted ... 18:21:06< rs_> so there is something intresting that I can do ? 18:21:31< Bertl> rs: any more details, like the actuall trace? 18:21:46< rs_> like what ? 18:22:02< Bertl> stack lines, addresses ... etc ... 18:22:31< Bertl> looks like the namespace sem was acquired ... at least half the way ... 18:34:10>> rs_ [rs@ice.aspic.com] has quit [Quit: leaving] 18:41:29< rs> I don't understand why my serial console doesn't work :( 18:41:41< rs> I would like to past you the whole trace 18:41:46< rs> but I can't 18:41:57< Bertl> hmm, stupid question: why doesn't it work? 18:42:13< rs> dunno 18:42:28< Bertl> what did you do .. please elaborate ... 18:42:42< Bertl> checklist: 18:42:43< rs> I verified all settings but minicom still show nothing 18:42:56< Bertl> - serial line as described in my nullmodem pages? 18:43:12< Bertl> - checked serial line with two minicoms when machines are up? 18:43:31< Bertl> - + configured hardware hanshake 18:43:40< Bertl> - + configured correct baud rate 18:43:48< Bertl> - + specified correct tty port 18:43:56< Bertl> - + compiled in serial support? 18:44:02< rs> this step fail :) 18:44:51< rs> maybe because init already lock the serial device ? 18:45:14< Bertl> did you make an entry in init? 18:45:18< rs> yes 18:45:26< Bertl> on both machines? 18:45:33< rs> no! :) 18:45:58< Bertl> okay, so you should get a login prompt from the one running the init/mgetty ... 18:46:14< rs> yes I should 18:46:14< Bertl> if it didn't fail and you only got a message in the logs ... 18:47:59< rs> strang, dmesg show two serial devices 18:48:01< rs> ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A 18:48:01< rs> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 18:48:30< Bertl> which isn't that unusual, actually ... 18:49:03< rs> but this machine have only one serial port 18:49:13< Bertl> comment out the inittab line, and call telinit Q 18:49:56< rs> done 18:50:11< Bertl> now minicom should be possible ... 18:51:24< rs> not better 18:52:35< rs> the kernel as also the console set up on the serial port 18:52:43< rs> but it shouldn't interfer 18:52:48< rs> the bios too :) 18:53:30< rs> usualy this setup works perfectly but with these machine not 18:54:42< rs> gonna change the cable 19:17:43< rs> re 19:18:09< rs> works now 19:18:56>> robjs [~rob@lychee.catalyst2.com] has left #vserver [] 19:21:53< rs> http://rs.rhapsodyk.net/vserver/namespace_cleanup_crash.txt 19:22:21< Bertl> tx 19:22:36< rs> I add the memory info 19:24:50< Bertl> rs: do you have the perl command at hand? 19:24:58< rs> yep 19:25:27< Bertl> could you paste it once again, please? 19:25:37< rs> the one for memory ? 19:25:40< Bertl> yep 19:26:03< rs> perl -e '$n .= "x" x 500000 while 1' 19:26:41< Bertl> tx 19:26:54< rs> np 19:37:05< Bertl> rs, you are on pre12.1 now? 19:37:10< rs> yep 19:38:17< Bertl> http://vserver.13thfloor.at/Experimental/delta-2.6.6-rc2-vs1.9.0pre12.1-vs1.9.0pre12.2.diff 19:38:29< Bertl> that should fix the namespace oops and the memory overcommit ... 19:38:46< rs> nice 19:38:49< Bertl> (both untested ... but I have to leave now) 19:39:16< rs> me too but I will test tonight if I find some time 19:40:21< Bertl> okay, let me know ... 19:40:37< rs> ok 19:40:55< Bertl> okay, folks, leaving now, will be back later ... 19:41:01>> Bertl is now known as Bertl_oO 20:20:36>> cgone is now known as cdub 20:25:02>> rs [rs@ice.aspic.com] has quit [Quit: leaving] 20:36:11>> loger [~loger@213.159.118.2] has quit [Ping timeout: 480 seconds] 20:38:18>> loger [~loger@213.159.118.2] has joined #vserver 20:38:52>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Ping timeout: 480 seconds] 21:07:24>> cdub is now known as cgone 21:45:28>> cgone is now known as cdub 21:46:26>> netrose [netrose@24.207.228.55] has joined #vserver 21:57:06< netrose> Has anyone seen this: 21:57:28< netrose> '/dev/sda5 71805628 68722040 0 100% / 21:57:49< netrose> How can the usage be 100% when there is free space on the disk drive? 21:58:06< netrose> 'Filesystem 1K-blocks Used Available Use% Mounted on 21:58:06< netrose> /dev/sda5 71805628 68722040 0 100% / 21:58:18< netrose> Any ideas? 22:08:51< Doener`> netrose: i guess the difference is what is reserved for root 22:12:53>> Apollo [~throwaway@caracal.norcomcable.ca] has joined #vserver 22:33:52>> Doener` [~doener@p5082DD41.dip.t-dialin.net] has quit [Quit: Leaving] 22:41:33>> shuri [~shushushu@69.28.239.24] has joined #vserver 22:42:22>> netrose [netrose@24.207.228.55] has quit [Ping timeout: 480 seconds] 22:43:37>> ensc [~ircensc@ultra.csn.tu-chemnitz.de] has quit [Ping timeout: 480 seconds] 22:48:14>> Doener [~doener@p5082DD41.dip.t-dialin.net] has joined #vserver 22:54:57< Doener> Hi! 22:58:16< eyck> ho! 23:08:22>> Doener [~doener@p5082DD41.dip.t-dialin.net] has quit [Quit: Leaving] 23:11:11>> Apollo [~throwaway@caracal.norcomcable.ca] has quit [Quit: ] --- Log closed ¶ro kwi 28 00:00:11 2004