--- Log opened pi± maj 21 00:00:02 2004 00:33:57>> chaosle [~yvan@port-212-202-168-55.dynamic.qsc.de] has quit [Quit: Leaving] 00:37:58>> taxcollector [~taxcollec@192.16.167.161] has quit [Remote host closed the connection] 00:42:39>> Doener` [~doener@pD9E1253D.dip.t-dialin.net] has joined #vserver 00:43:10>> Doener is now known as Guest16 00:43:16>> Doener` is now known as Doener 00:49:10>> serving [~serving@213.186.189.12] has joined #vserver 00:49:47>> Guest16 [~doener@pD9588666.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 00:52:32>> Bertl_oO is now known as Bertl 00:52:57< Bertl> evening everyone! 00:53:02< Doener> hi Bertl! 00:53:10< Bertl> hiaslboy: you are using modules, right? 00:53:40< Bertl> hi Doener! 00:54:16< Bertl> hiaslboy: never mind, read your line stating that ;) 00:56:24< rs_> hi Bertl ! 00:56:52< Bertl> hey rs, thought you where on vacation? 00:57:11< rs_> I am 00:57:16< rs_> :) 00:57:32< Bertl> wow! great! so you are _really_ a vserver fan! 00:57:58< rs_> hehe yes I am too =) 00:58:40< rs_> I took my vacation to do my appartement move 00:59:03< Bertl> hmm, short distance? 00:59:08< rs_> yes 00:59:44< Bertl> a friend of mine moved from Austria to Australia, and had to wait about 4 month for half of his luggage ;) 01:00:33< rs_> hehe I hope it will quicker :) 01:01:09< Bertl> yeah, well it wasn't short distance either ... 01:01:22< rs_> yep 01:05:42>> taxcollector [~taxcollec@192.16.167.161] has joined #vserver 01:05:56< Bertl> evening ryan! 01:06:01< taxcollector> Howdy! 01:08:35< rs_> Bertl: I noticed that netstat no longer list vserver established connexion, is it normal ? 01:09:03< Bertl> hmm, netstat on host? 01:10:20< rs_> no into a vserver 01:10:30< rs_> on the host I have some vservers connexion but not all 01:10:48< Bertl> hmm, should, but maybe it doesn't list bindings to 0.0.0.0 01:11:29< rs_> for exemple if you connect to a vserver and do a netstat -a you wont see your ssh connexion 01:12:18< Bertl> hmm, since when is that so? 01:12:52< rs_> dunno exactly 01:12:56< rs_> I just noticed that 01:13:13< Bertl> hmm, okay, will investigate this ... 01:13:22< rs_> also (I think it was always like that), I can see all pts 01:13:36< rs_> but it a not yet virtualized stuff is it ? 01:13:55< Bertl> pts should be virtualized ... but I'll check that too ... 01:14:13< rs_> ok 01:14:58< Bertl> if you do not read something about it in the next two weeks, please remind me ... 01:16:50< rs_> hehe ok :) 01:20:21< Bertl> I'm absolutely positive, that there is a bunch of missing things in 1.9.x just nobody noticed yet ;) 01:23:29< rs_> maybe it's because they are busy to test new features 01:44:49< rs_> is there many changes between 1.9.0.10 and 1.9.1 ? 01:45:03< rs_> I'm testing 1.9.1 and I don't know what to check 01:46:11< Bertl> important difference between 1.9.0 and 1.9.1 is the core system, so it's a stability check ... any strange segfaults or oppses are to be reported ... 01:48:53< rs_> ok 02:31:48>> ShuMaths [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 02:32:13< Bertl> hmm, shuri doing Math? 02:32:37>> ShuMaths is now known as Shuri 02:32:40< Shuri> :P 02:33:26< Shuri> i found a bug with alphatoolsą 02:33:33< Shuri> i can start a vserver twice 02:33:51< Shuri> no server already running 02:34:15< Bertl> sounds interesting ... 02:35:02< Shuri> 0 34 62.5M 6.6K 0m16s93 0m10s17 5m03s39 root server 02:35:02< Shuri> 49152 25 327.9M 15.2K 0m00s78 0m00s47 2m19s34 02:35:02< Shuri> 49153 4 7.8M 1K 0m00s13 0m00s90 1m42s98 deby 02:35:10< Shuri> i got a ghost now 02:38:21< Bertl> hmm, any chance for a complete example how to reproduce this? 02:38:37< Shuri> simple 02:38:49< Shuri> vserver deb1 start 02:38:54< Shuri> 2 times.. 02:39:20< Shuri> tree time 02:39:21< Shuri> root@primate:/usr/local/etc/vservers/suse# vserver deby start 02:39:21< Shuri> vserver 'deby' already running; aborting... 02:40:44< Bertl> and this is with 0.29.214? 02:44:18>> _shuri_ [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 02:44:19< _shuri_> humm 02:44:24< _shuri_> very strange 02:44:41< _shuri_> NAT stop to work after startin a vserve 02:45:02>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 02:45:03>> _shuri_ is now known as Shuri 02:49:35< Bertl> one bug at a time please 8-) 02:51:57< rs_> seems that you are using dynamic context ids ? 02:53:10< Bertl> yep, but tools should handle this too ... 02:53:11< rs_> I think it can happen if the vserver start didn't complete successfully 02:53:26< rs_> if the rev file isn't created 02:53:35< rs_> but some process live in the context 02:54:02< rs_> so the context exists but is unknown by the tools, it's why it doesn't have name 02:55:12< Bertl> hmm, sounds possible ... 02:55:20< rs_> Shuri: is the first vserver start work ? I mean can you enter it/connect to it etc.. 02:55:53< Medivh> hi ;) 02:56:24< Bertl> hello Medivh! 02:56:34< Medivh> reading your discussion, i wonder what advantage using dynamic context ids has anyway? 02:57:15< Medivh> (except for a bit easier management, i.e. not having to make sure no context id is allocated twice) 02:57:52< rs_> I don't see other reason :) 02:58:08< Bertl> none, they only cause troubles .. and if it wasn't for compatibility with older stuff, I'd remove them at once ... 02:58:38< rs_> maybe it could be a compile time option ? 02:59:03< rs_> like disabled by default but enablable for compatibility purpose 02:59:09< Bertl> unfortunately not atm, too many tools depend on taht ... 02:59:12< rs_> and deprecated 02:59:35< Medivh> maybe something to be considered for the future then (removing them) 02:59:52< Bertl> yep, for sure ... 03:01:08< Shuri> rs_): Shuri: is the first vserver start work ? I mean can you enter it/connect to it etc.. YES 03:01:17< rs_> not having dynamic context should make encrico's life easier :) 03:01:31< rs_> Shuri: so it's really strange 03:02:17< Shuri> humm 03:02:29< Shuri> 49152 25 328M 15.3K 0m00s88 0m00s85 29m51s34 03:02:29< Shuri> 49153 14 266.6M 6.6K 0m00s46 0m00s48 29m14s87 deby 03:02:33< rs_> but should be a dynamic context related bug 03:02:39< Shuri> the first is 52 03:02:43< Medivh> shouldn't tools catch that though? 03:02:46< Shuri> i cannot enter in it 03:02:50< Shuri> but apache run in it 03:03:10>> taxcollector [~taxcollec@192.16.167.161] has quit [Remote host closed the connection] 03:03:12< Medivh> i mean, checking if there is procs running in the allocated context, and if yes, mark the server as started? 03:03:29< rs_> you can enter by using vcontext --migrate --xid 49152 chroot /etc/vservers/deby/vdir 03:03:32< rs_> I think 03:04:13< rs_> Medivh: the problem is to make a relation between a dynamic context and a vserver configuration 03:04:18< Shuri> yes 03:04:20< Shuri> but 03:04:23< Shuri> Error, do this: mount -t proc none /proc 03:04:29< Shuri> in 52 03:04:52< Medivh> rs, i see 03:05:19< rs_> hmm strange 03:05:38< Medivh> how good i decided for using static context ids heh 03:05:59< rs_> it's maybe due to namespaces 03:06:29< rs_> try to do vnamespae --enter 49152 03:07:03< rs_> vnamespae --enter 49152 sh 03:07:14< rs_> oups 03:07:19< rs_> vnamespace --enter 49152 sh 03:10:17< rs_> Bertl: strange, vnamespace --enter xid mount show all host mount plus xid mounts instead of only xid mounts 03:10:58>> Shotygun [shotgun@shotygun.com] has joined #vserver 03:14:36>> rs_ is now known as rs 03:15:10< rs> good night dudes 03:15:36< Bertl> night rs ... 03:44:28< Shotygun> Hey Bertl 03:45:10< Bertl> evening Shotygun! 03:45:23< Shotygun> How are ya? 03:45:35< Bertl> fine , thanks, and you? 03:46:51< Shotygun> Fine as well, tired mostly *shrugs* 03:55:25< Shotygun> I'm now making a test to see how a chroot on one machine will perform if the data of the chroot will sit on another with gigabit connection between them 03:56:13< Bertl> hmm, via nfs? 03:57:40< Shotygun> Gonna test both NFS and SMB. 03:58:40< Shotygun> I am wondering if I can run vservers where the storage is central. 03:59:12< Bertl> rs is doing that via NFS ... 03:59:20< Shotygun> How are the performance? 04:00:04< Bertl> really depends on the config .. you can get decent NFS performance with tcp, and larger packet sizes, noatime etc ... 04:08:19< Shotygun> I think I will use prelink here over the production usage.. need to check this one out.. 05:16:06>> serving [~serving@213.186.189.12] has quit [Read error: Connection reset by peer] 06:01:29< Bertl> good night everyone ... cya tomorrow .. 06:01:37>> Bertl is now known as Bertl_zZ 06:07:43< Shotygun> Night Bertl_zZ 06:12:36>> Netsplit jupiter.oftc.net <-> unununium.oftc.net quits: netrose, kestrel, stupidawy, tchan, sladen, cdub, Khahan, Medivh, mcp, deadguy, (+1 more, use /NETSPLIT to show all of them) 06:13:03>> Netsplit over, joins: mcp, Khahan, netrose, kestrel, tchan, sladen, Medivh, stupidawy, deadguy, TheSeer (+1 more) 06:29:18>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: http://base2091.com] 06:54:45>> Shotygun [shotgun@shotygun.com] has quit [Remote host closed the connection] 07:10:35>> serving [~serving@213.186.189.12] has joined #vserver 09:26:17< hiaslboy> ensc: how can I configure the package state directory? 10:59:35>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has quit [Ping timeout: 480 seconds] 11:21:07>> blueshoe [~blueshoe@phylogenomics.Berkeley.EDU] has joined #vserver 11:21:29< blueshoe> is there some way i can start a vserver without assigning it an ip address at all? 11:23:31< Doener> blueshoe: hmm.. shouldn't be a problem, which tools are you using? 11:24:39< blueshoe> 0.29-4 from the debian backports 11:26:23< Doener> uhm... wait... for sure that's kind of a problem... 11:27:25< blueshoe> what is? 11:27:56< Doener> vserver without any assigned ip addresses... 11:28:22< blueshoe> ah 11:28:27< blueshoe> hmm 11:28:38< Doener> thing is, the access to the available ip address is limited only if you call chbind, and that obviously gives access to at least one ip address 11:28:44< blueshoe> well, i guess i'll stick with plan B: assign a private unused ip 11:32:01< blueshoe> so there's no way binding to any ip address off-limits without calling chbind? 11:32:26< blueshoe> s/no way/no way to make/ 11:35:02< Doener> no, context binding and ip address binding are independent things. and ip address binding is done by chbind 11:36:48< blueshoe> so its really a missing feature of chbind 11:37:00< Doener> what you could do is: simply give the vserver some random ip address, say 1.2.3.4 and in the post-start section bring down the corresponding interface 11:37:34< blueshoe> good idea 11:37:35>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has joined #vserver 11:37:54< Doener> the alpha tools have a little more 'support' for this fake 'bind to no ip address' solution, as they can be told not to bring the interface up 11:38:28< blueshoe> cool 11:39:22< blueshoe> i think i'll just stick w/the partial solution for now 11:39:28< blueshoe> thanks for your help, doener 11:40:06< Doener> you're welcome 11:40:12>> blueshoe [~blueshoe@phylogenomics.Berkeley.EDU] has quit [Quit: _] 11:53:54>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has quit [Ping timeout: 480 seconds] 11:55:15>> phil_ [~phil@i538754A8.versanet.de] has joined #vserver 11:55:18>> phil_ [~phil@i538754A8.versanet.de] has left #vserver [] 12:00:04>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has joined #vserver 12:08:49>> dany [~daniel@palaisrose-1-81-57-51-44.fbx.proxad.net] has joined #vserver 12:08:55< dany> hello 12:09:14< dany> anyone ? 12:10:12< Doener> hi dany, what's up? 12:12:46< dany> Hi 12:13:08< dany> I'playing with vserver right now 12:13:10< dany> :-) 12:13:45< dany> and I'd wanted to say that there is the problem on the patch for verser 1.9.1 12:13:55< dany> it has rejects 12:14:41< dany> on sys.c file when I apply it to kernel 2.6.6 12:14:51< Doener> rejects on vanilla? hmm... let me check that... 12:15:31< dany> I can past you the sys.c.rej if you want 12:20:27< dany> near line 451 and line 658 12:20:55< dany> I pasted the reject on the "hacker page" 12:20:56< Doener> no rejects for me... 12:21:06< dany> didn't know where to put it 12:21:23< dany> really ? 12:21:33< dany> then it's a bug in debian 12:21:50< Doener> oh wait, you're using debian kernel sources? 12:21:56< dany> yep 12:22:26< Doener> nearly every distro does its own modifications to the kernel 12:22:28< dany> it should be vanilla kernel, as they now have a separate package with their patches 12:23:10< dany> I'm gonna file a bug there then. 12:23:38< Doener> no 12:24:15< Doener> Description: Linux kernel source for version 2.6.6 with Debian patches 12:24:20< Doener> from kernel-source-2.6.6 12:24:37< dany> oh right 12:25:03< dany> I'm gonna file a bug at myself for not reading well 12:25:24< Doener> hehe, no problem with that ;) 12:25:45< dany> compile is over, I'll reboot and come back in a few minutes if everything worked 12:25:47< dany> ++ 12:25:53>> dany [~daniel@palaisrose-1-81-57-51-44.fbx.proxad.net] has quit [Quit: Leaving] 12:26:36< Doener> hmm... if he did compile the version with the rejects? 13:48:50>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has quit [Remote host closed the connection] 13:48:57>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has joined #vserver 13:51:01>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has joined #vserver 14:25:50>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 14:27:10>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 14:33:36>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has quit [Remote host closed the connection] 14:44:40>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 14:46:05>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 15:03:57>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 15:04:59>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 15:15:12>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 15:15:59>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 15:46:46>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 15:49:07>> cereal [~cereal@217.20.120.10] has joined #vserver 15:50:21>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 16:00:31>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 16:00:46>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 16:04:29>> mcp [~hightower@81.17.110.148] has quit [Ping timeout: 480 seconds] 16:04:29>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has quit [Read error: Connection reset by peer] 16:15:04>> mcp [~hightower@81.17.110.148] has joined #vserver 16:18:50>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 16:19:12>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has joined #vserver 16:22:49>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 16:23:06< Shuri> rs are you there? 16:25:53>> Bertl_zZ is now known as Bertl 16:25:58< cereal> hi Bertl 16:26:13< Bertl> morning cereal! 16:26:31< eyck> morning 16:26:49< eyck> hmm, so, time to slowly start packing 16:27:06< Bertl> hmm, packing for? 16:28:01>> _shuri_ [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 16:28:09< eyck> home? from work? 16:28:24< Bertl> ah, I.c. :) 16:28:31>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 16:28:32>> _shuri_ is now known as Shuri 16:29:39< Shuri> Bertl do you know how to endle rc script of suse 9.1 16:29:54< Shuri> i got this 16:29:56< Shuri> An error occured while executing the vserver startup sequence; when 16:29:56< Shuri> there are no other messages, it is very likely that the init-script 16:29:56< Shuri> (/etc/rc.d/rc 3) failed 16:30:04>> yarihm [~yarihm@217-162-206-157.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds] 16:30:08< Shuri> * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build 16:30:08< Shuri> method knows how to deal with this, but on existing installations, 16:30:08< Shuri> appending 'true' to this file will help. 16:30:44< Bertl> hum, what are you doing? 16:30:50< Shuri> vserver suse start 16:31:13< Bertl> okay, 'what' error occured? 16:31:43< Shuri> the vserver do not start 16:31:52< netrose> Bertl: Is there _any_ way to limit memory usage of a vserver using 1.27? 16:31:56< Bertl> side note: funny stuff @ http://www.cs.vu.nl/~ast/brown/ 16:32:07< Bertl> hi bobi! 16:32:22< Bertl> netrose: res, you can limit the memory consumtion of each task 16:32:23>> chaosle [~yvan@port-212-202-168-55.dynamic.qsc.de] has joined #vserver 16:32:28< netrose> Hi Bertl 16:32:30< Bertl> s/res/yes/ 16:32:33>> chaosle [~yvan@port-212-202-168-55.dynamic.qsc.de] has left #vserver [] 16:32:47< netrose> What about the whole vserver? 16:33:03< Bertl> this isn't possible with 1.2 and also not with default 1.3 16:33:17< Bertl> it is possible for VM and RSS in recent 1.9 16:33:45< netrose> What about using ulimit? 16:34:11< Bertl> that is the way I mentioned, basically limiting each task inside a vserver 16:34:32< Bertl> but there is no total limit for the entire server ... 16:34:55< Bertl> but you can have an upper bound this way, if you limit both number of tasks and memory for each task 16:35:26< Bertl> (sidenote RSS limits in 2.4 do not work for ulimit) 16:35:42< netrose> only VM? 16:36:08< Bertl> yep, vm is in 2.4, RSS only for certain ck (lck) and 2.6 16:37:17< netrose> Ok, so what should the ulimit line in the conf file look like? 16:37:38< netrose> HS -u 200 16:37:56< Bertl> that limits the vserver to 200 processes 16:38:16< Bertl> (with option nproc) 16:38:28< netrose> nproc? 16:38:51< Bertl> IIRC the flag is called nproc 16:39:29< Bertl> let me take a look at the code ... sec 16:39:44>> mcp [~hightower@81.17.110.148] has quit [Ping timeout: 480 seconds] 16:40:00< netrose> -v it seems 16:40:29< Bertl> yep, the flag is called 'nproc' 16:40:48< Bertl> -v sets the virtual memory ... 16:41:04< netrose> That's what I need, right? 16:41:11< netrose> Is that per process or per vserver 16:41:13< Bertl> -m should set the maximum RSS but it doesn't work in 2.4 16:41:37< Bertl> in 1.2 and the default 1.3 it is only per process 16:42:02< netrose> What do you think is a safe -m number? 16:42:18< Bertl> safe in what respect? 16:42:45< netrose> Safe so that things will not start falling apart 16:43:02< netrose> So that the daemons have enough RAM to work fine. 16:43:07< Bertl> hmm, I'd say, don't use it at all ... 16:43:34< netrose> Yes, but then someone could potentially use up all of it. I think that happened the other day and the whole server went down. 16:43:36< Bertl> thing is, some applications wrongly assume that they have unlimited address space ... (like java and such) 16:44:32< Bertl> but if you do not care about such apps, you can have a look at the applications running in a server (with ps auxwww) and take the highest number of VM used, multiply it by 2-4 and take that as limit 16:45:04< netrose> So, are you saying that apps like java and such will crash always when there is a limit? 16:45:17< Bertl> not always, but usually ... 16:46:39< netrose> One other thing I noticed. 16:46:46< Bertl> memory limits where ignored on linux for a long time now ... they are slowly getting into the kernel, and over time the applications will honor them ... 16:47:11< netrose> When you use vserver-stat there is a column named VSZ 16:47:22< netrose> Those numbers seem silly. 16:47:29< Bertl> hmm, why? 16:47:48< netrose> Almost all vservers show values between 1 and 2 GB 16:48:07< Bertl> which just means that the toal of address space consumed (VM) is almost 2GB) 16:48:16< netrose> The whole server has 2 GB so how can each one use between 1 and 2 GB. 16:48:37< Bertl> that is the problem with VM and VM accounting ... I give an example 16:48:40< netrose> And there are about 20 vservers running on the server 16:48:58< Bertl> consider an application on a normal linux host 16:49:22< Bertl> it 'allocates' 2GB of memory on a 512MB RAM machine with 512MB swap ... 16:49:38>> mcp [~hightower@81.17.110.148] has joined #vserver 16:49:47< Bertl> not possible? wrong, unless you enabled strict no overcommit ... it will succeed .. 16:50:02< Bertl> why is that possible? 16:50:15< Bertl> because the memory isn't used at this moment ... 16:50:37< Bertl> when the process uses up to the 512MB limit, the system will start swapping 16:51:04< netrose> ok. 16:51:08< Bertl> and if the process approches the 1GB limit, it will get a segfault somewhere ,.... or the system will die 16:51:35< netrose> So, really you can't tell how much RAM each vserver is using at a given moment. 16:51:38< Bertl> so the VSZ value is not the Sum of all 'allocated' virtual memory 16:51:55< Bertl> the amount of ram is the RSS 16:51:59>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Ping timeout: 480 seconds] 16:52:18< Bertl> which is also lsited in vserver-stat 16:52:23< netrose> Ok, so I should be looking at RSS instead of VSZ. Why is VSZ even there? 16:52:54< Bertl> because VM (AS) and RSS are interesting properties of a process 16:53:23< Bertl> an application 'using' 512MB of VM might have only 1M in RSS 16:53:55< Bertl> nevertheless it will cause heavy swapping, because the remaining 511MB will we paged in and out on demand ... 16:54:09< netrose> Ok. That doesn't make much sense but that's fine. 16:54:14< netrose> So... 16:54:40< netrose> If I sum all the RSS values it should show me how much RAM is used on the server right? 16:54:55< Bertl> for processes in active memory yes 16:55:23< netrose> Well, if I sum them up it doesn't even go up to 10% of what freemem says is used. 16:55:40< Bertl> because a lot of memory is used for caching and such ... 16:56:14< Bertl> look at cat /proc/meminfo 16:56:33< netrose> looking 16:58:02< netrose> Ok. It seems as if you can never really tell how much ram is really being used at a given moment and especially not on a per vserver basis. 16:58:22< netrose> So, my plan to limit the vserver's memory usage is not a very good one. 16:58:28< Bertl> well, you can tell the RSS for each vserver on 1.9 ;) 16:59:07< netrose> One other thing I just noticed. 16:59:13< Bertl> and in recent 1.9, you can also limit it in a sane way ... 16:59:38< netrose> when I use ps -auwwwx in a vserver it shows the VSZ for each process... 16:59:42>> mcp [~hightower@81.17.110.148] has quit [Ping timeout: 480 seconds] 16:59:46< Bertl> yep 17:00:09< netrose> Now, I have several httpd processes each showing 80268 bytes in the VSZ column 17:00:32< netrose> Does that mean that all httpd processes together use that much or each one. 17:01:01< Bertl> that is correct, those are threads using this amount of virtual memory, probably sharing the rss pages ... 17:01:25< netrose> So, are you saying that they all use that much? 17:01:41< Bertl> so each process uses 'that' much virtual memory, but together they might use much less RSS 17:03:03< netrose> But how can each process have the exact same value for RSZ even if some of them are doing something and others are just idling. Wouldn't you expect for those numbers to be somewhat different? 17:03:29< Bertl> no, because those are threads of the same task, the probably share all the VM space ... 17:04:14< netrose> Ok, so they do share the VM space. 17:04:26< netrose> That means that the VSZ number is for all the threads. 17:04:30< netrose> In that case... 17:04:31< Bertl> probably, but you can't tell per se ... 17:04:43< Bertl> and no the VM space amount of each task is that high 17:05:14< Bertl> look, maybe a somewhat strange analogon is required here ... 17:05:20< netrose> The accounting done by vserver-stat is incorrect because it is simply adding all those together instead of just taking into consideration one of them. 17:06:10< Bertl> think of a window: you have about 30 by 40 inches of space too look outside into the garden? 17:06:30< Bertl> how large is the are used for roses? 17:06:54< rs> re 17:07:06< Bertl> thing is, you can't really tell, and although the neighbour has a similar window, he might see the same or different things ... 17:07:19< Bertl> hello rs! 17:07:35< netrose> Ok. Are you saying that the vserver-stat should indeed just add them all up? 17:08:23< Bertl> basically I'd say it doesn't make sense to do an overall VM at all ... 17:08:49< Bertl> but it might be an interesting value which can be easily compared between vservers 17:09:34< netrose> I think, just by looking at the numbers that vserver-stat should only account for one value if there are multiple threads with the same VSZ value. 17:10:14>> mcp [~hightower@81.17.110.148] has joined #vserver 17:10:21< Bertl> well, might be that the threads use completely different memory areas, you can't tell ... 17:10:31< netrose> For example, if there are 10 httpd processes each showing 80000 in the vsz column, vserver-stat should add only 80000 instead of 800000 to the total 17:10:34< Bertl> hi mcp! 17:10:39< mcp> hey Bertl 17:11:10< Bertl> netrose: this is not more or less correct than the other way ... 17:11:35< netrose> Ok. I give up. 17:11:50< Bertl> okay, look, basically there are two boundaries 17:12:04< Bertl> the lower boundary is the maximum VM used by all processes 17:12:09< netrose> I was just thinking that it would be nice to have a way to prevent server crashes by someone using up all the available RAM and SWAP. 17:12:17< Bertl> and the upper boundary is the sum of all VM usages 17:12:49< Bertl> and the VM per se doesn't tell anything about the ram or swap usage at all 17:12:56< netrose> Is it any more possible to control the SWAP usage then? 17:13:32< Bertl> you mean, a per vserver swap limt? 17:13:36< netrose> yes 17:13:49< Bertl> and what should happen when this limit is reached? 17:14:08< rs> don't the rss limit prevent that ? 17:14:11< netrose> Or _anything_ that could prevent the whole server going down if someone uses all the available RAM and SWAP. 17:14:40< Bertl> well, that is probably successfully done by the RSS and VM limits in 1.9 17:14:40< netrose> no more forks will be allowed. 17:14:59< netrose> Yes, but that is only for 2.6, right? 17:15:03< rs> you are talking of legacy stuff ? 17:15:10< netrose> Yes, I use 1.27 17:15:14< rs> Bertl: vm limit ? 17:15:14< Bertl> we are talking of 2.4 stable ... 17:17:00< rs> Bertl: the VM limit is something different than rss limit ? 17:17:01>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has quit [Ping timeout: 480 seconds] 17:17:08< netrose> Any chance of those features being abailable on 1.27? 17:17:14< rs> how do you control that ? 17:17:19< Bertl> not unless the 2.4 kernel changes drastically 17:17:43< netrose> So, we should think upgrading all our machines to 2.6 then. 17:17:49< Bertl> you can go for the ck (lck) kernel there, but I do not see a reason for that ... 17:17:55< netrose> That's probably not going to be very easy. 17:18:12< netrose> I mean the upgrade. 17:18:28< Bertl> well depends, on my laptop it required the installation of one package ... 17:18:45< Bertl> (module-init-tools) 17:18:52< netrose> Well, most of our servers currently run RH9 17:19:14< netrose> 2.4 is building and running just fine, but we have never tried to upgrade to 2.6 17:19:26< Bertl> I guess there should be a RH9 module-init-tools too ... 17:19:57< rs> procps have to be upgraded on some old distrib like redhat 8 and debian woody 17:20:06< Bertl> netrose: but if you want to test this, just let me know, we can arrange a test run on some spare machine 17:20:40< netrose> Sure, I'd like to do that as soon as possible. 17:20:46< netrose> is 1.9.1 stable? 17:20:49< Bertl> rs: it the vds-a currently running 1.9.0 or 1.9.1? 17:21:14< Bertl> netrose: no, it's developemnt 8-) 17:21:36< netrose> Ok, then I don't think we should put that on our production machines yet. 17:21:41< rs> Bertl: 1.9.1 17:21:47< Bertl> any issues so far? 17:21:57< rs> don't think so 17:22:15< netrose> Is there any stable version for 2.6? 17:22:15< Bertl> netrose: 2.0 will be the stable release for 2.6 17:22:24< netrose> Ok. How far are we from there? 17:23:02< Bertl> currently my time to work on this is limited, because there is no funding atm ... so I'd say about 4-5 months ... 17:23:05< rs> Bertl: is the VM limit is done by AS rlimit ? 17:23:14< Bertl> yep AS == VM 17:23:18< rs> ok 17:23:31< netrose> That much? 17:23:47< netrose> Ok. I guess we'll all have to wait then. 17:23:49< rs> Bertl: this should change soon I hope :) 17:24:10< Bertl> yeah, would be fine ... 8-) 17:24:45< rs> how do find money for food atm ? 17:25:35< Bertl> I'm doing a lot of consulting recently, but that takes a lot of time ... 17:26:43< netrose> rs: right now you are running 1.9.1 and you haven't seen any problems? 17:27:11< Bertl> where I'd go for 1.9.0 at, because 1.9.1 is testing a new core allocation 17:27:18< Bertl> s/at/atm/ 17:27:42< rs> netrose: no blocking pb for moment yes 17:27:46< netrose> ok. I might try RH9 and then upgrade to 2.6 with 1.9.0 17:27:59< rs> 1.9.1 17:28:01< netrose> Just to see how the upgrade will go. 17:28:15< Bertl> yeah, and please, let us know ... 17:28:21< netrose> Absolutely. 17:28:43< Bertl> maybe even some small HowTo for upgrading RH9 would be interresting for others too ... 17:28:48< netrose> ok 17:28:54< rs> or 1.9.0.10 because it fix some bug, right bertl ? 17:29:09< netrose> Does MDK9.2 and 10.0 work as a vserver with no modifications? 17:29:32< Bertl> vserver host or guest? 17:29:36< netrose> guest 17:30:10< rs> all distrib works, but some have some tools that can't deal correctly with the kernel 17:30:28< netrose> like what for example? 17:30:47< netrose> Also, what about debian? Does it need any modifications to run as a guest? 17:30:48< rs> like I told you, procps for old distrib have to be upgraded 17:30:55< rs> but it's not the case for rh9 17:31:03< Bertl> all distros require slight modifications ... 17:31:09< netrose> no, I am talking about most recent distributions. 17:31:19< Bertl> but most of them are done by the alpha-tools automagically 17:31:31< rs> debian stable (3.0) need a procps upgrade, sarge and sid are ok 17:31:40< netrose> Well, RH7.3, 8.0, 9.0, Fedora 1 and 2 do not require any modifications. 17:31:42< Bertl> so when you do install a debian system with the debootstrap method, it will work out of the box ... 17:31:53< Bertl> netrose: yes, they do ... 17:32:02< netrose> Really? 17:32:14< Bertl> yes, ebcause for example the whole hardware detection stuff is bogous 17:32:19< netrose> Well, how do we run FC1 and FC2 then? 17:32:22< Bertl> (inside a vserver) 17:32:29< netrose> Yes, inside a vserver. 17:32:43< Bertl> aren't we talking about the guest? did I miss something? 17:32:56< netrose> Ok, if you are thinking about the /dev changes then yes. Yes, we are talking about guest OS. 17:33:41< Bertl> /dev, modules, hardware, sysv 17:33:55< Bertl> this usually has to be adapted on the guest (vserver) 17:34:01< netrose> modules? hardware? 17:34:04< netrose> sysv? 17:34:15< Bertl> modules = module loading (not allowed) 17:34:32< netrose> right, but modules are not used on the guest os anyway. 17:34:35< Bertl> hardware = any hardware access or probing (not allowed) like hwclock, or hw detection 17:34:54< Bertl> sysv = runlevel scripts for startup/reboot/shutdown 17:35:13< netrose> sysv is the same I think. 17:35:30< netrose> if I use vreboot. 17:35:46< rs> vreboot no longer exists 17:36:04< Bertl> so for MDK guest for example, I have to replace the /dev, remove the module stuff and change the runlevel scripts to not use the hardware detection and keyboard layout loading etc ... 17:36:28< Bertl> well vreboot exists, but is somewhat depreciated ... 17:36:34< netrose> Ok. I agree on those things. I was thinking about major changes. 17:36:47< netrose> As with Debian I think. 17:36:55< Bertl> no major changes required for debian .. 17:37:17< rs> Bertl: do you have some script that do this kind of modifications ? 17:37:26< netrose> But isn't debian different then the others? in regards to sysv I mean? 17:37:41< Bertl> yes debian is different in almost any regard ;) 17:38:06< netrose> So, if there is no /etc/rc3.d/ there will be problems, right? 17:38:08< Bertl> but the debain way of bootstrapping a guest works fine ... 17:38:10< rs> netrose: it's almost the same thing for sysv init 17:38:38< Bertl> netrose: recent util-vserver have become smarter ... a lot smarter ... 17:38:41< netrose> Ok. Bertl, do you have any scripts that do these changes in an existing guest? 17:39:08< Bertl> no, but as I said, alpha util-vserver should include them for several distros 17:39:29< Bertl> I use templates for my vservers and they are hand crafted/adjusted 17:39:30< rs> but it does too much for me 17:39:37< netrose> Yes, but I already have OS templates built. I don't want to rebuild them again. 17:39:52< Bertl> well, then use them, no problem with that ... 17:40:04< rs> on my side I just need tools that make the required changes on an existing bootstrap 17:40:27< netrose> I might take a look at the util-vserver then and go from there. 17:40:32< rs> I did some but I certenly missed something 17:40:39< Bertl> I'd say, talk to enrico and ask him, maybe there is an option to just do that ... 17:41:08< netrose> Does anyone have a good recent Debian template OS? 17:41:38< rs> recent ? you mean unstable ? 17:41:43< rs> or recent woody ? 17:41:49< Bertl> http://www.jvds.com/vserver/ (unteste by me ) 17:42:00< rs> Bertl: I used it for the vds-a 17:42:11< netrose> Is it ok? 17:42:14< rs> but they only have debian woody 17:42:23< netrose> Do you have more recent one? 17:42:23< rs> netrose: almost yes, with some modifications 17:42:28< Bertl> and with alpha-util-vserver 17:42:30< Bertl> # vserver build -m debootstrap * -- -d sarge # or woody 17:42:43< Bertl> will build you a brand new shiny vserver 17:42:50< rs> the /dev dir is not sanitizen for exemple 17:43:18< netrose> Bertl: Yes, but that would have to be run on an existing Debian server, right? 17:43:39< rs> I think so yes 17:43:49< rs> redhat don't have the debootstrap tool 17:44:04< rs> it's the pb of vserver-build tool 17:44:38< Bertl> netrose: no 17:44:40< rs> it not work for cross distrib building 17:44:55< rs> for what I know 17:44:59< netrose> bertl: no? 17:45:01< Bertl> you just need to install the debootstrap 17:45:11< rs> Bertl: is it exists for redhat ? 17:45:12< netrose> Where do I find debootstrap 17:46:01< eyck> google it up 17:46:04< ensc> hi, '-m debootstrap' was tested on RedHat/Fedora hosts only; I never tried it on Debian. The needed files will be downloaded automatically 17:46:15< eyck> there are rpms available 17:46:26< Bertl> hi enrico! 17:46:35< rs> ensc: so is it possible to build a FC1 under debian for ex ? 17:46:36< netrose> OK. Going to find it. 17:46:42< sladen> netrose if you run newvserver and it can't find dbootstrap, it prints out the URLs to download it from! 17:46:53< netrose> Incredible. Thanks. 17:47:12< ensc> rs: dunno; you will need rpm + an rpm'ified apt-get for Debian 17:47:33< sladen> ensc: yes, it prints the URL TO DOWNLOAD THE debootstrap.rpm from 17:47:41>> shuLa [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 17:47:45< shuLa> Bertl 17:47:49< rs> not so easy to find :/ 17:47:54>> shuLa is now known as shuri 17:48:07< shuri> got a lot of problem with 1.9.1 and alpha tools 17:48:08< shuri> ! 17:48:08< ensc> sladen: '-m debootstrap' does not need an rpm. It downloads the tarball from debian.org 17:48:15< netrose> What version of vserver-util and/or newvserver do I need? 17:48:53< ensc> netrose: 0.29.214 is the recent version of util-vserver; 'newvserver' does not exist anymore 17:48:58< ensc> shuri: which ones? 17:49:18< shuri> fisrt i can start a vserver 2 times 17:49:26< shuri> that make a ghost vserver 17:49:28< shuri> second 17:49:43< shuri> if i try to stop the running vserver the NAT stop to work 17:50:34< shuri> i can even stop a vserver 17:50:36< shuri> vserver deby stop 17:50:36< shuri> Error: /proc must be mounted 17:50:36< shuri> To mount /proc at boot you need an /etc/fstab line like: 17:50:36< shuri> In the meantime, mount /proc /proc -t proc 17:50:37< shuri> Failed to parse ps-output 17:50:37< shuri> vserver 'deby' is not running; aborting... 17:50:46< Bertl> proc security! 17:50:59< shuri> abiut ghost and NAT.. 17:51:02< shuri> about 17:51:07< rs> ensc: seems that his first problem is related to dynamic xid handling 17:51:09< shuri> this is not vproc related 17:51:10< ensc> for the first problem; please disable the 'vshelper' to exclude some bogus effects and try it again 17:51:16< netrose> ensc: will 0.29 work fine to create a debian guest os? 17:51:39< netrose> Or, how safe/tested is 0.29.214? 17:51:43< ensc> shuri: second one sounds like the secondary-interfaces-disappear problem 17:51:53< ensc> shuri: third one: did you run vprocunhide? 17:52:05< netrose> ensc: will both 0.29 and 0.29.214 work with 2.4 and 1.27? 17:52:07< sladen> ensc: sorry, I didn't write the util-vserver Debian code so I've no idea what they've done to not make it work. My code /does/ print out the URL of the aliened package--perhaps you could suggest it :-) 17:52:10< shuri> ensc i already got warning-disabled 17:52:21< ensc> netrose: afaik, 0.29 does not have debian support 17:53:13< shuri> about vproc i got etc/vservers/.defaults/apps/vprocunhide/files 17:53:20< Bertl> okay, dinenr time for me now, back in 30min 17:53:20< shuri> with /proc/ inside 17:53:27< sladen> ensc: just use these then: http://www.paul.sladen.org/vserver/debian/debian-newvserver.sh http://www.paul.sladen.org/vserver/debian/debootstrap-0.1.17.3-2.i386.rpm 17:53:29>> Bertl is now known as Bertl_oO 17:53:32>> mcp [~hightower@81.17.110.148] has quit [Ping timeout: 480 seconds] 17:53:36< ensc> shuri: do a 'touch /etc/vservers/.defaults/apps/vshelper/disabled' 17:53:53< ensc> shuri: (or whereever your /etc/vservers/ direcotry is) 17:54:04< rs> ensc: vshelper is still buggy ? 17:54:32< netrose> ensc: will both 0.29 and 0.29.214 work with 2.4 and 1.27? 17:54:39< ensc> rs: should be fixed (kernel sets a strange signal mask, but this is fixed in .214) 17:54:40 * sladen tuts at another occasion somebody has taken my code and broken it 17:54:49< rs> ok 17:54:54< ensc> netrose: I am running production servers in this combination 17:55:09< netrose> ok. thanks 17:55:35< rs> ensc: on my side, vshelper is able to stop my vserver but never restart when I run reboot command 17:55:56< ensc> rs: any log output? 17:56:54< rs> hmm 17:57:03>> _shuri_ [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 17:57:08< _shuri_> again 17:57:25< rs> ensc: no 17:57:29< _shuri_> vserver deby stop 17:57:29< _shuri_> vserver 'deby' is not running; aborting... 17:57:35< netrose> brb 17:57:36< _shuri_> then net stop to work 17:57:51>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 17:57:51>> _shuri_ is now known as shuri 17:57:57< rs> and if I try to start the vserver again I get a RTNETLINK answers: File exists 17:58:51< rs> oups now it works... 17:59:09< rs> sounds like it make some time to restart 17:59:10< ensc> rs: which initstyle are you using? 17:59:15< rs> plain 18:00:00< rs> it's the only one that work for debian and redhat right ? 18:00:16< ensc> afaik, it does not really work for redhat 18:00:26< ensc> it does too much crap 18:00:32< rs> plain ? 18:00:35< ensc> yes 18:00:45< rs> I thought it was init 18:00:48< ensc> sysv works fine here both with debian and rh/fc 18:00:58< rs> what does sysv ? 18:01:06< ensc> it calls /etc/rc.d 18:01:14< ensc> plain calls /sbin/init 18:01:36< rs> so no init is startd with sysv init ? 18:01:54< ensc> no; sysv does not enable fakeinit 18:01:59< rs> btw is it possible to put the init style in the .default directory ? 18:02:14< rs> neither plain 18:02:15< shuri> ensc how i enable vproc 18:02:25< shuri> touch /usr/local/etc/vservers/.defaults/vprocunhid 18:02:50< ensc> shuri: you have to execute the 'vprocunhide' script 18:02:52< rs> I never succeed to make fakeinit working with 1.9 patch 18:02:52>> cereal [~cereal@217.20.120.10] has quit [Remote host closed the connection] 18:02:59< shuri> and put /vproc/ do not work 18:03:51>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has quit [Ping timeout: 480 seconds] 18:05:10>> mcp [~hightower@81.17.110.148] has joined #vserver 18:06:24< ensc> rs: no, the initstyle can not be configured globally... perhaps I should add some autodetection there 18:07:03< ensc> but for most distributions, 'sysv' will be the best choice 18:07:19< rs> autodetection ? 18:07:32< rs> but whynot a default configurable value ? 18:08:04< rs> if I not put an apps/init/style file, which style is choosen ? 18:08:05< ensc> initstyle depends on the vserver, not on the system. 18:08:26< rs> yep but I want all my vserver use the same init style 18:09:17>> cereal [~cereal@217.20.120.10] has joined #vserver 18:09:17< ensc> what is, when your vserver do not support this style? 18:09:35< cereal> re 18:09:41< rs> I use the style supported by all vserver 18:09:49< rs> all distrib 18:10:22< ensc> intersection of fedora & gentoo initstyles is an empty set 18:10:40< rs> by the way, I use sysv with a debian, and the init process is running 18:10:57< ensc> probably, this is just a faked 'ps' entry 18:10:59< rs> but it's not the father of all others process, is it expected ? 18:11:14< rs> faked by the kernel ? 18:11:16< ensc> this is your system init process 18:11:18< ensc> yes 18:11:27< rs> it doesn't have the 1 pid 18:11:31>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has joined #vserver 18:11:56< rs> and vps on the host can see them 18:12:37< ensc> strange... I do not see this behavior with 2.4 18:13:38< rs> stange too, after rebooting my vserver from inside it, vps show me two time the same init process 18:14:16< rs> vps aux|grep 14.145|grep init 18:14:16< rs> root 6159 15 213.193.14.145 0.0 0.0 1272 484 ? Ss 16:09 0:00 init [2] 18:14:19< rs> root 6159 15 213.193.14.145 0.0 0.0 1272 484 ? Ss 16:09 0:00 init [2] 18:14:27< rs> funny :) 18:15:43< netrose> I installed the 2.9.214 tools and now vserver-stat does not show the names in the last column. 18:16:18< ensc> netrose: support for old-style xid -> name mapping is not implemented 18:16:23< ensc> (yet ??) 18:17:28>> Bertl_oO is now known as bertl 18:17:28< netrose> What is the "new style"? 18:17:34>> bertl is now known as Bertl 18:17:40< ensc> rs: this indicates a 'plain' initstyle... 18:17:55< netrose> vuname shows this "??? ??? ??? ??? ??? ??? ???" 18:17:58< rs> ensc: so maybe a missplaced the file 18:18:01< netrose> for any vserver 18:18:23< ensc> netrose: the style, which is used by the new 'vserver ... build' commands e.g. 18:18:29< ensc> netrose: which kernel/patch? 18:18:43< ensc> vuname is not supported by stable 2.4 18:18:44< netrose> 2.4 1.27 18:19:02< ensc> sorry... can not change this in userspace 18:19:04< netrose> ensc: will both 0.29 and 0.29.214 work with 2.4 and 1.27? 18:19:09< netrose> netrose: I am running production servers in this combination 18:19:17< ensc> it works. but not everything is supported 18:19:33< ensc> I do not need 'vuname' in my production servers 18:19:36< Bertl> which is understandable, as the stable branch is alcking a lot of reatures ... 18:19:40< netrose> Is there a document or anything online that specifies what is and what is not supported?\ 18:19:46< Bertl> yep 18:19:54< Bertl> http://www.linux-vserver.org/index.php?page=Release+FAQ 18:20:33< netrose> Ok. At least the vserver names used to be shown in vserver-stat. Not anymore. 18:21:16< ensc> [root@kosh root]# vserver-stat 18:21:16< ensc> CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 18:21:16< ensc> 0 383 3.7G 266.7K 7h04m18 2h27m01 3d35h00 root server 18:21:16< ensc> 1 1 48K 8 0m00s20 0m00s80 3d34h59 monitoring server 18:21:16< ensc> 193 7 23.1M 915 35m58s99 11m21s53 3d34h59 bmaster 18:21:16< Bertl> this is only the kernel side overview, don't know about userspace, enrico? 18:21:19< ensc> 195 9 28.2M 1.5K 0m05s38 0m02s52 3d34h59 debian-sarge 18:22:21< ensc> Bertl: I do not know about Socket Accounting, and network context is still an open issue 18:22:31< netrose> [root@colby rc.d]# vserver-stat 18:22:31< netrose> CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 18:22:31< netrose> 0 53 343.6M 11.8K 1d37h34 1d36h08 28d23h26 root server 18:22:31< netrose> 49152 30 565.2M 17.5K 59m44s40 7m39s34 28d23h25 18:22:31< netrose> 49153 52 3.3G 527.5K 4h38m53 1h10m18 28d23h24 18:22:32< netrose> 49154 23 966.8M 7.5K 49m43s68 22m07s78 28d23h24 18:22:32< netrose> 49155 86 3.2G 92.6K 5h37m56 39m02s32 28d23h24 18:22:34< netrose> 49156 34 602.6M 21.7K 2h02m46 15m37s39 28d23h23 18:22:34< netrose> 49157 33 1.8G 17.5K 12m00s80 4m32s88 28d23h23 18:22:37< netrose> 49158 50 2.2G 99.3K 11h14m21 1h13m01 28d23h23 18:22:37< netrose> 49159 38 749.5M 67.1K 7h25m04 1h01m42 28d23h23 18:22:38< netrose> 49160 113 918.3M 51.8K 14h47m28 1h37m32 28d23h22 18:22:38< netrose> 49161 50 934.4M 11.9K 2h05m12 27m31s81 28d23h22 18:22:41< netrose> 49162 77 2.3G 93.8K 6h07m20 1h23m14 28d23h22 18:22:41< netrose> 49163 63 973.2M 18.5K 4h42m46 47m19s74 28d23h22 18:22:43< netrose> 49164 21 213.6M 7.3K 1h11m17 19m19s65 28d23h21 18:22:43< netrose> 49165 31 271M 9.3K 1h09m19 19m36s51 28d23h21 18:22:44< netrose> 49167 29 1.6G 12K 44m07s35 19m15s66 28d23h20 18:22:44< netrose> 49168 38 1.8G 7.8K 10m11s64 14m40s25 28d23h20 18:22:47< ensc> netrose: these are probably old style vservers, right? 18:23:03< netrose> What do you mean by "Old style? 18:23:14< netrose> I didn't know we have different styles. 18:23:52< netrose> How do I convert them to the "new style"? 18:24:56< ensc> netrose: there is no converting script; for now, create a sample vserver with 'vserver ... build -m skeleton' on inspect /etc/vservers/.../. 18:25:36< netrose> Is the old and new style determined by the .conf file and it's format? 18:25:44< ensc> netrose: 'old style vservers' == vservers which were created with the stable tools 18:25:54< ensc> yes 18:26:35< netrose> Is there a document about the format of the new .conf file? 18:26:46< ensc> under /vservers/.../ they are the same. (at least nearly... e.g. 'vserver ... build' fixes some issues with RH initscripts) 18:27:36< ensc> yep, the flow^Wgras-page at http://www-user.tu-chemnitz.de/~ensc/util-vserver/doc/conf/configuration.html 18:27:43< rs> ensc: with 214 and 1.9.1, how do you enable initpid feature ? 18:28:35< Bertl> ensc: we have to 'redefine' the semantics of fakeinit/initpid (a little) 18:29:09< ensc> rs: add 'fakeinit' into the 'flags' file 18:29:50< ensc> rs: but this will be done automatically when the 'plain' initstyle is selected 18:30:27< ensc> Bertl: how? 18:30:59< netrose> Is there an example .conf file of the new style vservers? 18:31:08< Bertl> well, actually we have two different features ... which where somewhat combined by existing solutions ... 18:31:28< rs> netrose: the configuration file is now splited into several files 18:31:43< rs> one per directive 18:32:19< rs> "a la" Dr Bernstein :) 18:32:21< Bertl> ensc: there is the initpid, and there is the fakeinit 18:32:41< ensc> netrose: see http://www.linux-vserver.org/index.php?page=alpha+util-vserver 18:35:38< rs> Bertl: can you past you white paper URL ? 18:35:57< rs> I don't remember where to find it 18:36:04< Bertl> hmm, you mean the LT paper, about vserver? 18:36:38< rs> yep 18:36:45< Bertl> http://vserver.13thfloor.at/Stuff/PAPER-05.4.txt 18:36:56< Bertl> little outdated, will upload 06 soon ... 18:37:39< ensc> Bertl: the scripts/programs should understand this difference... 18:38:03< rs> thx 18:38:50< Bertl> ensc: hmm, well, then we have a bug somewhere ... as rs uses the initpid, but has no pid=1 inside the vserver 18:39:05< ensc> rs: which context flags do you have? 18:39:16< Bertl> instead he sees the initpid twice on vps ;) 18:39:18< rs> ensc: 15 18:40:24< rs> I try to reproduce the bug 18:41:41< rs> ensc: with sysv init style, the vshelper trick can't work, is it ? 18:41:59< ensc> rs: it should work there also 18:42:12< rs> # reboot 18:42:12< rs> 18:42:12< rs> Broadcast message from root (pts/7) (Fri May 21 17:41:10 2004): 18:42:12< rs> 18:42:12< rs> The system is going down for reboot NOW! 18:42:14< rs> init: timeout opening/writing control channel /dev/initctl 18:42:57< rs> this is in sysv init style 18:42:58< Bertl> requires reboot -f here 18:43:10< Bertl> (just an educated guess) 18:43:47< ensc> rs: vshelper is used, to synchronize 'vserver ... stop'. With sysv, I do not need such a synchronization 18:44:18< ensc> ('vserver ... stop' is a 'kill -INT ' for the plain initstyle) 18:44:49< ensc> (but '/etc/rc.d/rc 6' for sysv) 18:45:49< rs> there is the command to put in cmd.start and cmd.stop ? 18:45:58< ensc> yes 18:46:21< ensc> you can have 'start-sync' and 'stop-sync' also 18:46:23< rs> vshelper is not really easy to configure :) 18:47:28< rs> there is no doc about that, is it ? 18:47:31< ensc> this is general vserver functionality. I need a synchronization step in 'vserver ... restart' 18:48:51< ensc> the documentation for '/etc/vservers/ vserver-name / apps / init' should give some hints 18:49:00< ensc> cmd.start-sync 18:49:01< ensc> The command which is used to wait on the vserver after it has been started. Each option must be on a separate line. This file will be ignored when the 'sync' does not exist and the '--sync' option was not used. 18:50:00< rs> maybe some exemple of usual commands for each init style could helps more :) 18:50:59< ensc> I never expected that somebody would use 'plain' ;) 18:51:39< ensc> 'minit' is used by me only, and 'gentoo' does not really work 18:52:17< rs> yep but sysv init style doesn't start an init process, and I see many adentage in running init process 18:52:59< rs> reboot will work as expected, you can configure inittab to choose the default init level (debian use 2 by default, other 3) 18:53:35< ensc> initlevels are not really meaningful for vservers... 18:54:16< rs> all runlevel doesn't start same services 18:54:53< rs> it's not a big deal anyway, I'am agree 18:58:37< rs> Bertl: virtualized uptime no longer work in 1.9.1 18:58:46< rs> maybe it wasn't before 18:58:55< rs> didn't 18:59:22< rs> what about using a ticketing system for bug reports ? :) 19:07:39>> yarihm [~yarihm@217-162-206-215.dclient.hispeed.ch] has joined #vserver 19:10:27< Bertl> rs: hmm, sure? 19:10:42< rs> almost yes 19:10:54< Bertl> ad ticket: well, I did the template for bugreports, did you use it yet? 19:11:08< rs> I have the exactly same uptime on a fresh started vserver than on its host 19:11:37< rs> no I didn't, but we can't see already reported bug with your template 19:12:00< Bertl> well, there is one, the one I reported myself ;) 19:12:27< rs> :) 19:12:48< Bertl> I always suggest this in my release mails, I can't do more about it ... 19:13:07< Bertl> VXF_VIRT_UPTIME is set? 19:13:10< rs> ok I will use you template :) 19:13:28< rs> ahah, no :) 19:14:21< Bertl> btw, I'd appreciate a simple stability test on your setup (with 1.9.1) 19:15:27< rs> ok, I will send a change report to tell people to test this 19:16:07< Bertl> you could also add some atomated testing, if you are interested, I can provide some tools ... 19:16:55< rs> well I am intrested :) 19:17:26< Bertl> okay, the following test is network related, simple, not very intrusive but effective 19:18:15< Bertl> it was done by Jon Bendtsen ... 19:18:33< Bertl> #!/bin/bash 19:18:34< Bertl> ip=$1 19:18:34< Bertl> echo "TCP tp echo port" | nc -q 1 $ip 7 19:18:34< Bertl> echo "UDP tp echo port" | nc -q 1 -u $ip 7 19:18:34< Bertl> echo "TCP tp discard port" | nc -q 1 $ip 9 19:18:36< Bertl> echo "UDP tp discard port" | nc -q 1 -u $ip 9 19:18:38< Bertl> echo "TCP tp daytime port" | nc -q 1 $ip 13 19:18:41< Bertl> echo "UDP tp daytime port" | nc -q 1 -u $ip 13 19:18:44< Bertl> echo "TCP tp chargen port" | nc -q 1 $ip 19 19:18:46< Bertl> echo "UDP tp chargen port" | nc -q 1 -u $ip 19 19:18:49< Bertl> --- 19:19:20< Bertl> you configure some vservers (usually 3-5) to use inetd and enable those services 19:20:13< rs> ok 19:21:02< Bertl> then you execute the script (above) from another host, to each ip, in parallel 19:21:17< Bertl> for ip in 172.16.0.{1,2,3,4}; do 19:21:17< Bertl> ping -c 1 -i 1 $ip && ( bertl_test.sh $ip & ); 19:21:17< Bertl> done; 19:21:25< Bertl> (something like this) 19:22:30< Bertl> this will trigger udp and tcp network context switches ... 19:23:55< Bertl> services (in inetd.conf) are 19:23:58< Bertl> echo stream tcp nowait root internal 19:23:58< Bertl> echo dgram udp wait root internal 19:23:58< Bertl> chargen stream tcp nowait root internal 19:23:58< Bertl> chargen dgram udp wait root internal 19:24:01< Bertl> discard stream tcp nowait root internal 19:24:03< Bertl> discard dgram udp wait root internal 19:24:06< Bertl> daytime stream tcp nowait root internal 19:24:09< Bertl> daytime dgram udp wait root internal 19:27:08< netrose> I tried installing debian using the user-tools here's what's happening after about a couple of minutes: 19:27:09< netrose> I: Base system installed successfully. 19:27:09< netrose> umount: /usr/local/etc/vservers/.defaults/vdirbase/0000woody/dev/pts: not mounted 19:27:09< netrose> umount: /usr/local/etc/vservers/.defaults/vdirbase/0000woody/dev/shm: not found 19:27:09< netrose> umount: /usr/local/etc/vservers/.defaults/vdirbase/0000woody/proc/bus/usb: not found 19:28:07< Bertl> looks like the final reboot ... 19:28:21< rs> Bertl: it print some garbage stuff, expected ? 19:28:31< netrose> Bertl: yes. 19:28:55< Bertl> rs: depends, what stuff? 19:29:00< rs> RSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789: 19:29:00< rs> STUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:; 19:29:00< rs> TUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;< 19:29:00< rs> UVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ !"#$%&'()*+,-./0123456789:;<= 19:29:31< Bertl> yep, that's probably the chargen output ... 19:29:33< rs> it does a "nice" ascii-art :) 19:29:35< rs> ok 19:30:08< Bertl> you can discard the scipt output, as it isn't improtant at all 19:30:25< Bertl> netrose: so I'd say the guest is installed ... 19:31:17< Bertl> rs: another stability test is the following: 19:32:03< Bertl> bash -c "while true; do cat /proc/v*/[0-9]*/* >/tmp/y.log 2>&1; done" & 19:32:18< rs> inside a vserver I guess 19:32:20< Bertl> (on the host) 19:32:29< rs> oh, ok 19:32:46< Bertl> and then start something like killer or killer-nathan ... 19:32:54< Bertl> (also on the host) 19:33:02< rs> what is killer ? 19:33:34< Bertl> a programm creating new contexts in rapid sequence .. 19:33:47< Bertl> http://vserver.13thfloor.at/Experimental/ 19:34:27< Bertl> maybe it would be also interesting to adapt one of those to the network contexts ... 19:34:42< Bertl> and to the new context allocation scheme ... 19:34:58< Bertl> and be prepared to capture the oops ;) 19:35:06< rs> your bash script takes exactly 18% of the proc, strange isn't it ? 19:35:34< Bertl> damn, it was designed to taks 42% ;) 19:36:11< rs> the strange thing is that it is stuck at this value 19:36:30< Bertl> because it has to transfer the data from kernel to userspace ... 19:36:50>> _id [~id@pD951991D.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 19:37:13< Bertl> this will change when you start killer ... 19:37:19< rs> and since my /tmp is a tmpfs, it has to retransfer to the kernel, isn't it ? :) 19:38:27< Bertl> proc isn't implemented very efficiently ... 19:38:47< Bertl> (that is probably why it is somewhat depreciated) 19:39:07< rs> why don't you use /sys for vserver ? 19:39:45< Bertl> either that or netlink will be used in the future .. but the proc is easier for userspace (scripts) 19:40:02< Bertl> and sysfs via proc doesn't have any advanteage over proc 19:42:01< rs> ok I'm running killer-nathan and your bash-script 19:43:12< rs> other vservers seems to not be afected so mutch :) 19:43:22< rs> much 19:44:47< Bertl> that's the way it should be, with vserver ;) 19:45:23< rs> how many time do you want me to run this script ? 19:45:34< Bertl> which one? 19:45:40< rs> killer + bash script 19:45:48< Bertl> let them run for some hours ... 19:46:19< rs> ok 19:46:26< Bertl> the idea behind it is tro find race issues ... which are hard to trigegr ... 19:46:41>> _id [~id@pD95193A3.dip.t-dialin.net] has joined #vserver 19:46:46< Bertl> .oO( oh my clumsy fingers ...) 19:47:17< Bertl> hi _id! 19:47:39< Bertl> rs: btw I found the reason for the missing netstat info ... 19:47:54< rs> so ? 19:48:57< Bertl> yep, when a tcp connection is made, a copy of the socket is created to handle this particular connection, this socket doesn't get the context info atm, so it is listed as belongign to the host context 19:49:29< Bertl> (doesn't matter for the connection though) 19:50:05< rs> ok so it happen for all tcp connexion ? 19:50:18< Bertl> yep, for established connections 20:02:43< rs> bbl 20:03:15< Bertl> cya 20:03:21< Bertl> and thanks for testing ... 20:04:36< Bertl> ensc: do you have a moment for the init stuff and maybe the network contexts ? 20:05:15< ensc> Bertl: init stuff? 20:06:56< Bertl> initpid/fakeinit and friends ... 20:09:42< ensc> mmh... this should work already 20:09:53< ensc> (when nothing has been changed in the last kernel patches) 20:10:18< Bertl> well, I'm not sure it does, and if it does, I'm not convinced that it works as expected ;) 20:11:28< ensc> why? initpid -> process reaper, fakeinit -> getpid()==1 for the process reaper. Right? 20:11:44< Bertl> not exactly ... 20:12:23< Bertl> fakeinit without initpid, also makes sense, in this case, init from the host is blended through as pid=1 20:14:14< ensc> ah! that's why I see the wrong init in my vservers 20:15:05< ensc> seems to be broken somehow... 20:15:19< ensc> (at least on 1.27 + 2.4) 20:15:45< Bertl> yep, that is why I would like to agree on some behavioural issues first ... 20:21:49>> pflanze [~chris@gate.wyona.com] has joined #vserver 20:21:54< pflanze> Hello 20:22:10< Bertl> hello pflanze! 20:22:36< pflanze> It's cool that you're always there :) 20:23:20< Bertl> good to hear that ... 20:23:48< pflanze> I wish every software had such good support. 20:23:57< ensc> Bertl: which behaviour do you want to change/define? 20:24:18< Bertl> I'd like to have three defined cases: 20:24:35< Bertl> a) no fakeinit, no initpid 20:24:40< Bertl> b) fakeinit 20:24:58< Bertl> c) fakeinit + initpid 20:25:06< Bertl> I'm not sure if 20:25:16< Bertl> d) initpid no fakeinit does make sense ... 20:25:30< ensc> which application exists for b)? 20:26:16< Bertl> non init based vserver which wants to have pstree act sanely for example? 20:27:58< ensc> ok 20:28:04< pflanze> I'm wondering about "the source ip issue": what can I do so that the source ip of out-bound connection is set to one of the chbind ip's? (This helps with stuff like ip based access control, or iptables rules) 20:29:13< pflanze> (I remember vaguely this being discussed some time ago but I don't know the outcome) 20:31:54< Bertl> hmm, well this should be done with recent vserver patches? 20:32:34< pflanze> ah ok, still running 1.3.8 20:32:37< Bertl> ensc: maybe d) is useful for init systems not requiring init to have pid=1 ? 20:32:57< Bertl> pflanze: hmm, should also be in 1.3.8 IIRC 20:33:23< Bertl> ensc: never mind ... 20:34:08< pflanze> well, lsof showed "TCP 10.0.5.1:25->195.226.6.71:43136" and ip based access control with tcpserver (qmail) only worked when I used 195.226.6.71 (the public ip) in the config. 20:34:54< pflanze> (ipv4root: 0105000a/00ffffff 0105a8c0/00ffffff) 20:35:08< Bertl> wait a moment, you are talking about public and such? 20:35:46< pflanze> 195.226.6.71 is the only ip on eth0 20:36:00< Bertl> and 10.0.5.1 is where? 20:36:08< pflanze> nowhere - just chbind config 20:36:16< pflanze> for inside the vserver 20:36:30< Bertl> but there is an alias somewhere? 20:36:40< pflanze> /etc/hosts inside the vserver contains: 20:36:41< pflanze> 10.0.5.1 localhost 20:36:41< pflanze> 192.168.5.1 elvis-5 20:36:48< pflanze> There's no alias anywhere. 20:37:05< Bertl> so how do you expect it to work then? 20:37:06< pflanze> It's going over the loopback interface anyway, right, so why define an alias? 20:37:11< netrose> the new utils are expecting the vserver configuration to be in /usr/local/etc/vservers/remote/ 20:37:27< netrose> How do I make it look in the regular place /etc/vservers 20:37:47< Bertl> there is a config file for that, enrico? 20:38:03< ensc> netrose: which host distribution are you using? 20:38:21< pflanze> I thought aliases were only useful for "real" interfaces, not loopback - that was my conclusion from the last thinking session about this stuff. 20:38:29< pflanze> Maybe I missed one point :~) 20:38:30< ensc> with RH/Fedora/Mandrake, you could to 'rpmbuild -ta util-vserer...tar.bz2' 20:38:50< Bertl> pflanze: vserver (chbind) addresses do not define _any_ usable addresses by themselve .. 20:38:54>> click [click@gonnamakeyou.com] has joined #vserver 20:38:59< Bertl> evening click! 20:39:07< ensc> netrose: else, you would have to invoke confiugre with '--sysconfdir=/etc' 20:39:20< netrose> ok 20:39:21< Bertl> pflanze: they require the address to be available (for example ip addr show) 20:39:25< netrose> using rh9 20:40:00>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has joined #vserver 20:40:07< ensc> -ta should working there; perhaps with '--without dietlibc --without xalan' 20:40:09< rs> re 20:40:49< netrose> but will it still be able to read the old .conf files in /etc/vservers 20:40:56< ensc> yes 20:41:18< netrose> ok. then, I guess a symlink will also be sufficient. 20:41:22< netrose> right? 20:41:48< ensc> should work also 20:44:09< pflanze> Strange. I could do a "ifconfig lo:elvis5lo 10.0.5.1 up" (which did not change anything), 20:44:20< pflanze> but now I cannot add another alias to lo or remove the old one. 20:45:20< pflanze> ifconfig says "SIOCSIFADDR: File exists" 20:45:30< pflanze> "SIOCSIFFLAGS: Cannot assign requested address" 20:48:05< Bertl> hmm, are you on the host or inside a network context? 20:48:39< pflanze> On the host - ah, 20:48:41< pflanze> ipv4root: 4706e2c3/f0ffffff 0100007f/000000ff 20:49:05< pflanze> (I logged in through v_ssh) 20:49:20< Bertl> thank you for the demonstration ;) 20:49:23< pflanze> hehe 20:49:49< Bertl> I can ensure you, a lot of people will be hit by that in the future ... 20:49:58< netrose> Can somone help with a debian guest problem? 20:50:08< pflanze> netrose: maybe, I'm using debian 20:51:57< pflanze> Bertl: can I chbind anything to make ifconfig work? (and why did creating the first alias work, btw?) 20:53:17< pflanze> still this missing unbind thing I've always complained about.. =] chbind --nothing /bin/bash 20:54:24< Bertl> pflanze: get host level access to the system, for example by configuring an sshd which listens to the host ip only ... 20:54:45< pflanze> I know, that's what you told me last time, too.. 20:54:52< Bertl> there will be no such unbind thing, unless we have a capability for that ... 20:55:12< pflanze> But since overriding chbindings works when in the host context, why not add a delete option? 20:55:32< Bertl> because it's a bug that it somewhat works ... 20:55:53< Bertl> in the current implementation it will not work anymore ... 21:00:33>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has quit [Ping timeout: 480 seconds] 21:01:52< Bertl> ensc: okay, so we have a), b) and c) with the following semantics: 21:02:10< Bertl> a) nothing set, normal behaviour as on the hsot 21:02:42< Bertl> b) fakeinit set, init from host blends in, no pid faking, except for signals 21:03:02< Bertl> (they are simply blocked) 21:03:52< Bertl> c) fakeinit + initpid, init is remapped to 1, signals are handled accordingly ... when init dies, then we do? 21:04:06< Bertl> option 1) fall back to the fakeinit setting 21:04:21< Bertl> option 2) send an emergency callout via vshelper 21:04:36< Bertl> option 3) just continue without reaper&pid=1 21:04:58< Bertl> (please choose one option) 21:05:38< rs> I vote for option 2 :) 21:05:45< ensc> what means 'without reaper&pid=1'? 21:06:11< Bertl> well, pid=1 (init) will be gone, reaping might be done by the host init ... 21:07:43< ensc> signaling to vshelper is orthogonal to the other two options 21:08:19< ensc> (there are still processes without a init process) 21:09:07< Bertl> right, but what would vshelper do then? send a sigkill probably ... 21:09:32< ensc> dunno... init should not die 21:09:40< Bertl> btw, is the kernel signal to context used for bringing down a vserver? 21:09:45< ensc> I would tend to option 3) 21:09:54< ensc> yes 21:10:19< Bertl> okay, that's good, this way we should be able to bring down forkbombing vservers ... 21:10:19< ensc> at first, a SIGINT to init, and them -9 to the context 21:10:36< ensc> are we having a way to prevent forkbombs? 21:10:58< ensc> afair, you planned something like adjusting the scheduler... 21:11:44< Bertl> yeah, one plan is to make a token bucket for forking ... 21:11:57< Bertl> same goes for I/O and swap btw 21:12:47< Bertl> but I have the feeling that the logic for all that should reside in userspace ... 21:12:50< ensc> ah. this means that there is currently no way to kill a context? 21:13:05< Bertl> yes it is, sending the signal should kill a fork bomb ... 21:13:14< Bertl> (sending via the syscall) 21:13:58< ensc> sure? When forkbomb hangs in fork() in the tasklist lock, the newly created process will not see the signal from vkill... 21:14:57< Bertl> hmm, haven't tested this yet, but we can work around that easily ... 21:15:25< Bertl> (if it can happen at all) 21:16:26< ensc> how? as far as I understand, this is a general and unresolved problem in Linux (no true broadcast signals) 21:17:25>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has joined #vserver 21:17:27< Bertl> I don't see an issue there ... 21:17:45>> rs [~rs@rs.admin.rhapsodyk.net] has quit [Quit: leaving] 21:18:35< Bertl> we could for example set a flag, and let the processes die when they are scheduled again ... 21:21:06< ensc> Bertl: see http://www-user.tu-chemnitz.de/~ensc/vkill.txt 21:22:49< Bertl> you cannot lock the tasklist twice?! 21:23:15< ensc> ok, 'lock tasklist' means 'wait and lock' 21:25:14< ensc> perhaps we could copy SigPnd from parent process, but I do not know if there are sideeffects 21:25:23< ensc> or how it is solved in the kernel 21:27:23 * pflanze thinks, maybe after create new process check the parent sig mask for signal 9 and copy it to the child if set? 21:28:12< pflanze> (or even better, return right away after getting the lock if the parent has the signal 9 set) 21:28:45 * pflanze simply fantasizes 21:29:07< netrose> trying to start debian sarge after it was created. Here's the problem: 21:29:09< netrose> New security context is 49203 21:29:09< netrose> Starting system log daemon: syslogd 21:29:09< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:09< netrose> . 21:29:10< netrose> Starting kernel log daemon: klogd 21:29:10< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:11< netrose> . 21:29:11< netrose> Starting MTA: 21:29:13< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:13< netrose> exim4. 21:29:15< netrose> Starting internet superserver: inetd 21:29:15< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:17< netrose> . 21:29:17< netrose> Starting deferred execution scheduler: atd 21:29:19< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:19< netrose> . 21:29:21< netrose> Starting periodic command scheduler: cron 21:29:21< netrose> Warning: Fake start-stop-daemon called, doing nothing 21:29:23< netrose> . 21:30:57< pflanze> (netrose: seems like you have some special debian image - where start-stop-daemon has been replaced?) 21:31:15< netrose> The image was created by the 2.9.214 utils 21:32:29 * pflanze just uses a copy of a standard debian installation 21:32:50< Bertl> ensc: what is Fake start-stop-daemon? 21:32:55< netrose> fixed it 21:33:06< netrose> mv /sbin/start-stop-daemon.REAL /sbin/start-stop-daemon 21:33:10< netrose> fixes it 21:33:25< ensc> Bertl: dunno... I do not touch this. 21:33:36< ensc> perhaps done by newer debootstrap? 21:34:30< pflanze> netrose: would have been interesting what the old file looked like 21:35:09< ensc> mmh... indeed. The debian people changed there something 21:35:10< Bertl> maybe something to avoid runlevel scripts on first boot ... 21:35:43< netrose> Oh, sorry, it's gone. But you can replicate the same problem if you create a sarge installation using 2.9.214 21:35:57< netrose> I was able to repeat this behaviour 3 times. 21:36:05< ensc> # cat start-stop-daemon 21:36:05< ensc> #!/bin/sh 21:36:05< ensc> echo 21:36:05< ensc> echo "Warning: Fake start-stop-daemon called, doing nothing" 21:36:26< ensc> was not here when I tested it a month ago 21:37:23< pflanze> it's an old thing: 21:37:24< pflanze> http://lists.debian.org/debian-user/2002/12/msg01010.html 21:37:49< netrose> Is there any way I can start vservers faster? It takes a lot of time if I have to start 20-30 vservers. 21:38:10< Bertl> you can start them in parallel .. 21:38:11< ensc> netrose: new initscript starts them in parallel 21:38:51< netrose> Can I replace the old initscript with the new one without compatibillity problems? 21:39:03< netrose> 2.9.214 over 2.8? 21:39:04>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has quit [Quit: Caught signal 15, Terminated] 21:39:09< ensc> pflanze: mmh... some older debootstrap renamed them automatically probably 21:39:32>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has joined #vserver 21:39:36< ensc> netrose: there should be a legacy initscript for old vservers 21:39:47< netrose> A parallel one? 21:39:49< Bertl> ensc: maybe this is a 'first-boot' thing, and when you use init, it is ecetured? 21:39:56>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has quit [Quit: ] 21:40:22>> stupidawy [foo@you.wish.you.were.pimp.olicio.us] has joined #vserver 21:40:23< netrose> ensc: legacy initscript that will start them in parallel? 21:40:37< ensc> Bertl: no, used the same commands like a month ago (when it succeeded without additional actions) 21:40:50< ensc> netrose: no; only new style vservers will be started in parallel 21:41:23< Bertl> netrose: I'd suggest something like: 21:41:23< pflanze> http://trilldev.sourceforge.net/files/remotedeb.html 21:41:28< netrose> Is there a conversion tool that would convert the old style .conf files into the new style conf directories? 21:41:29>> lilo [levin@lilo.usercloak.oftc.net] has quit [Remote host closed the connection] 21:41:33< pflanze> says "Now, if something goes wrong here, just wipe all the files in /mnt/lfs, and run debootstrap again" 21:41:40>> lilo [levin@lilo.usercloak.oftc.net] has joined #vserver 21:41:57< Bertl> for n in ; do (vserver $n start &); sleep 2; done 21:42:35< netrose> bertl: wouldn't this put the CPU load through the roof? 21:42:46< ensc> netrose: no; had no time for it yet. and there are some things like the setup-scripts which I do not know how to handle... 21:43:12< Bertl> well, you can't have both, parallel startup _and_ low cpu usage ;) 21:44:08< netrose> Bertl: no, what i am saying is will this cause the server to be nonresponsive for a long time or maybe even crash? 21:44:42< Bertl> that is what the sleep is for, you can adjust the startup there ... 21:45:02< Bertl> maybe sleep 1 is okay for your system, maybe you need a sleep 10 21:45:18< pflanze> I'd put in -1 21:45:45< Bertl> you could also do a more advanced script and check the current load ... and if it is too hight, stop the forking (vserver start) 21:45:46< netrose> Well, the way they start now it takes about 30-40 seconds for one vserver to be started 21:46:14< ensc> most time while init is spent in sleeps. so this should not really affect performance... 21:46:36< netrose> ok. I will try that soon. 21:46:40< Bertl> netrose: just try it out, and watch the system ... 21:53:59< ensc> Bertl: regarding fakeinit: I prefer option 3) with an option to signal it with vshelper additionally 21:54:37< Bertl> hmm, okay, so we add a 'initkilled' to the vshelper commands, okay? 21:55:07< ensc> okay (when nobody knows a better name for the command) 21:55:54< Bertl> suggestions are welcome, please suggest now and don't complain later ;) 21:58:19< Bertl> initdeath, initgone, vaporinit, initexit ... 21:59:17< Zoiah> initbegone! 22:02:03< Bertl> exitus, slaughter, cease, pass, ... 22:04:32< pflanze> initus_vaporus 22:20:33< infowolfe> what does one use to count in linux? 22:20:45< infowolfe> let's say i want to know how many processes a certain user has going 22:21:06< Bertl> ps auxw | grep | wc 22:24:20< Bertl> ensc: how do I test/enable the three cases for *init* ? 22:26:15< ensc> Bertl: vattribute should understand the 'fakeinit' and 'state_init' flags (--flag ...) 22:26:39< ensc> state_init is implicated by the '--fakeinit' option at 'vcontext --migrate-self' 22:29:15< Bertl> okay, so 'vcontext --migrate-self pstree -p' uses initpid but not fakeinit? 22:29:47< Bertl> hmm, no that does noting useful it seems ... 22:30:43< Bertl> I'd like to start pstree inside a specific context, for all three cases, what would I do? 22:31:37< pflanze> infowolfe: this is probably faster for solving your particular question: perl -e 'print((scalar grep { s,^/proc/(\d+)\z,$1, and kill 0,$_ } glob "/proc/*"),"\n")' 22:31:53< pflanze> (put a su "$USER" before that) 22:32:55< ensc> Bertl: vcontext --create vattribute --flag fakeinit vcontext --migrate-self --fakeinit pstree 22:33:24< ensc> perhaps an additional '--disconnect' 22:33:56< Bertl> hmm, fakeinit and fakeinit in this line means different things, right? 22:34:27< Bertl> the second one should read initpid or am I wrong? 22:34:57< ensc> yes; latter fakeinit means init_pid 22:35:15< pflanze> Hm Bertl: somehow making my second alias creation still doesn't work even without any ip bindings. 22:35:21< ensc> historic inconsistencies... 22:35:24< Bertl> okay, so to minimize confusion, could you change that in future release ... 22:35:36< Bertl> +s 22:36:01< Bertl> pflanze: what are the commands? 22:36:03< pflanze> Bertl: but the same thing works on my laptop without vserver patch (but with kernel 2.6, admittedly) 22:36:12< pflanze> ifconfig lo:1 10.0.5.1 up 22:36:17< pflanze> ifconfig lo:2 192.168.5.1 up 22:36:25< pflanze> the first works, the second gives the error 22:36:36< pflanze> if I down the first, the second works. 22:37:03< pflanze> netmask is 255.0.0.0 22:37:16< pflanze> lo already has the usual 127.0.0.1/255.0.0.0 22:38:00< pflanze> ipv4root: 0 22:38:00< pflanze> ipv4root_bcast: 0 22:38:22< Bertl> maybe a 2.4 limitation on lo? 22:38:43< pflanze> I almost think so 22:39:22< pflanze> there's a limitation in the sources, but I thought it was for multiple totally separate interfaces 22:39:31< pflanze> (however those would have been created) 22:42:38< pflanze> ah, it was the dummy network device that has this n==2 limitation 22:42:44< Bertl> ensc: hmm, what will 'chcontext --flag fakeinit pstree' do? and what should it do? 22:43:00< pflanze> I don't see anything in /usr/src/linux/drivers/net/loopback.c so far 22:43:38< ensc> Bertl: case c) 22:44:00< ensc> case b) is not possible with the chcontext emulation 22:44:23< ensc> or... with numeric flag, it should work 22:45:04< Bertl> okay, c) sounds good to me ... 22:45:36< Bertl> pflanze: 22:45:39< Bertl> Linux (none) 2.4.26-vs1.27 #1 Wed Apr 14 17:03:03 CEST 2004 i686 unknown 22:45:39< Bertl> ··· profile done. 22:45:39< Bertl> # ifconfig lo 127.0.0.1 up 22:45:39< Bertl> # ifconfig lo:1 10.0.5.1 up 22:45:39< Bertl> # ifconfig lo:2 192.168.5.1 up 22:45:41< Bertl> # 22:46:03< pflanze> hm. I'm running 2.4.26-vs1.3.8 22:47:18< Bertl> Linux (none) 2.4.25-vs1.3.8 #6 SMP Tue Mar 2 18:56:30 CET 2004 i686 unknown 22:47:19< Bertl> ··· profile done. 22:47:19< Bertl> # ifconfig lo 127.0.0.1 up 22:47:19< Bertl> # ifconfig lo:1 10.0.5.1 up 22:47:19< Bertl> # ifconfig lo:2 192.168.5.1 up 22:47:24< Bertl> # 22:47:27< Bertl> same here ... 22:48:02< Bertl> Linux (none) 2.4.26-vs1.3.9 #45 SMP Sat May 1 04:41:43 CEST 2004 i686 unknown 22:48:07< Bertl> works also ... 22:48:19< pflanze> Does it matter that I first created the aliases from an ip-bound process? 22:48:39< Bertl> don't know ... 22:48:49< pflanze> This is "no bound ip", right?: 22:48:50< pflanze> ipv4root: 0 22:48:50< pflanze> ipv4root_bcast: 0 22:49:27< Bertl> hmm, yep 22:50:44< pflanze> does it matter that the 192.168.5.1 ip is already in use by some processes in a vserver? 22:51:18< pflanze> YEP! 22:51:36< pflanze> I just shut down the vserver where I'm using this ip, now it works. 22:53:03< Bertl> # vcontext --create vattribute --flag fakeinit vcontext --migrate-self --fakeinit pstree -p 22:53:07< Bertl> New security context is 49153 22:53:09< Bertl> pstree(1) 22:53:14< Bertl> ensc: okay, so this is working as expected, right? 22:54:05< pflanze> Bertl: I can now create the aliases even from the v_ssh login. So your test you thought I was confirming wasn't it! 22:54:19< pflanze> Once again, v_ssh did *not* hurt at all. 22:54:29< Bertl> bad luck ;) 22:54:42< ensc> Bertl: this is the '--flag fakeinit' test; reaper is not tested by this command 22:54:44< Bertl> but it will hurt in the future! we will make it hurt! *G* 22:55:25< Bertl> # vcontext --create vcontext --migrate-self --fakeinit grep init /proc/self/status 22:55:28< Bertl> New security context is 49156 22:55:30< Bertl> but this one is, right? 22:55:32< Bertl> initpid: 24 22:56:01< ensc> yes 22:56:04 * pflanze will collect decayed eggs for Bertl 22:56:48< Bertl> pflanze: save them for Bill, when he shows up to introduce the brand new ... M$-VServer ... 22:57:31< pflanze> huh, you think they are going into virtualization business too? 22:57:47< pflanze> (btw you know that the latest solaris release has something like vserver?) 22:57:56< Bertl> well, they 'recently' introduced the new powerful NT commands awk and sed ... 22:58:13< pflanze> ah yes? 22:58:27< Bertl> unleash the power of Windows NT scripting with awk and sed ... 22:59:06< Bertl> pflanze: you mean solaris slices, right? 22:59:14< pflanze> yeah 23:01:20< Bertl> ensc: 23:01:21< Bertl> # chcontext --flag fakeinit pstree -p 23:01:21< Bertl> New security context is 49158 23:01:32< Bertl> is not what is supposed to happen, right? 23:02:20< ensc> which command will be executed finally? (bash -x chcontext ...)? 23:03:30< Bertl> + /usr/sbin/vcontext --create -- /usr/sbin/vattribute --set -- /usr/sbin/vcontext --fakeinit --endsetup --migrate-self -- pstree -p 23:03:48< Bertl> (this is 0.29.213 btw) 23:09:14< ensc> ok, the traditional fakeinit flag will not be set here 23:09:40< ensc> shall I set it? 23:09:54< Bertl> yeah, otherwise we break compatibility I guess ... 23:10:07< Bertl> at least the legacy method does set it ... 23:36:10< pflanze> Bertl: source ip of outbound connection is still the one from the host (eth0). 23:36:30< Bertl> well, what did you expect? 23:36:34< pflanze> TCP 10.0.5.1:25->195.226.6.71:37139 (ESTABLISHED) 23:36:53< Bertl> there just _is_ no other ip available for outbound connections? 23:37:04< pflanze> yes there is now, with the aliases 23:37:11< Bertl> are they on eth0? 23:37:20< pflanze> no on lo 23:37:28< Bertl> lo isn't used for outbound ... 23:37:32< pflanze> ok I was wrong 23:37:38< pflanze> with my wording 23:38:00< pflanze> 10.0.5.1 and 195.226.6.71 are on the same machine 23:38:06< pflanze> 195.226.6.71 is eth0 23:38:12< pflanze> 10.0.5.1 is lo:1 23:38:29< pflanze> 192.168.5.1 is lo:2 23:38:41< pflanze> the vserver is started with the latter two ip's 23:38:54< Bertl> okay ... 23:39:07< pflanze> now I wish that I see this with lsof: TCP 10.0.5.1:25->10.0.5.1:37139 23:39:08< Bertl> how is the tcp conenction established? 23:39:25< pflanze> from inside vserver, I login with ssh, type "telnet localhost smtp" 23:39:40< pflanze> (where localhost is defined in /etc/hosts as 10.0.5.1) 23:40:01< Bertl> and what does ping localhost say? 23:40:23< pflanze> ping? from the host? or should I enable capnet? 23:40:34< Bertl> okay, take tracepath 23:41:02< pflanze> traceroute? or "iputils-tracepath" ? 23:41:12< Bertl> whatever works for you ... 23:41:46< pflanze> traceroute uses icmp ping :~) 23:42:04< pflanze> ok I have one clue: 23:42:30< pflanze> /etc/vservers/{vserver}/interfaces/{foo}/dev is set to "lo" 23:42:37< pflanze> should maybe be "lo:1" 23:42:51< pflanze> ? 23:43:00< Bertl> do not clue ;) 23:43:57< Bertl> what does telnet 10.0.5.1 25 give ? 23:44:09< Bertl> the same lsof info? 23:45:00< pflanze> vserver start says twice: 23:45:04< pflanze> Cannot find device "lo:1" 23:45:14< pflanze> it starts nonetheless, but same thing as before 23:46:15< pflanze> ensc: do the new tools *create* aliases? do they support aliases in interfaces/*/dev at all? 23:46:43< ensc> pflanze: create a file 'name' in the interfaces/.../XXX/ directory 23:46:57< ensc> pflanze: ('name' should contain the name) 23:47:28< pflanze> ah, so dev => "lo" and name => "lo:1" ? 23:48:02< pflanze> and then the alias must not exist before the start? 23:51:11< ensc> I am not sure, if name is 'lo:1' or only '1' 23:51:28< ensc> see the 'ip' documentation for details ;) 23:52:20< pflanze> vserver start says RTNETLINK answers: File exists 23:52:36< pflanze> oh, lo:lo:2 hehe 23:54:25< ensc> changing the prefix seems to be impossible 23:54:32< pflanze> yep 23:54:42< pflanze> the "name" should only be the part after : 23:54:54< pflanze> works so far, BUT only sets up one of the two interfaces 23:55:15< pflanze> maybe that's related to the start message RTNETLINK answers: File exists 23:55:56< ensc> use '--debug' to figure out the command which is creating the interface 23:56:10< ensc> or use 'ip addr' to show the current interfaces 23:58:19< pflanze> hm, yes 'ip addr' shows the respective address even after vserver stop 23:58:35< pflanze> ifconfig -a does not show any alias anymore 23:58:40>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has joined #vserver 23:58:49< JonB> Bertl: i think it is still running 23:59:02< JonB> Bertl: did you add the right ip addresses ? 23:59:13< ensc> pflanze: you should not change interface parameters for running vservers, since the following 'vserver ... stop' might not find the interface anymore 23:59:36< pflanze> ensc: ok, but how do I remove it now? man ip ? 23:59:55< ensc> basically yes. but ip does not have a man-page. --- Log closed sob maj 22 00:00:02 2004