--- Log opened pią kwi 30 00:00:38 2004 00:01:43< sladen> CAP_NET_RAW 00:06:10>> monrad [~monrad@213083190232.sonofon.dk] has quit [Quit: Leaving] 00:06:58< broo> yeah that was just a typo, CAP_NET_RAW generates the error 00:12:55< broo> ah I see it now vattribute doesn't have --cap and the chcontext --cap is being converted to --bcap in the vattribute call 00:51:24>> Bertl_oO is now known as Bertl 00:51:35< Bertl> evening everyone! 00:51:59< Bertl> hi broo! seems like you've been busy today? 00:52:31< Apollo> Hi Bertl 00:52:42< Bertl> hi Apollo! 00:52:50< broo> hehe, yeah playing with 0.29.211 and the 1.9.0pre13 00:53:09< Bertl> and as far as I can see you solved almost all issues, right? 00:53:53< broo> yeah the only one that I'm not sure how to deal with is passiing capabilities to the vserver 211 seems to have a completely different setup 00:54:09< broo> it uses bcaps and ccaps instead of caps 00:54:09< Bertl> there are two kinds of caps now ... 00:54:25< Bertl> the bcaps are the bound for 'normal' linux caps 00:54:52< Bertl> and the ccaps are a brand new capability set for per context capabilities 00:55:17< Bertl> this was added together with the 'new' flagword ... 00:56:19< Bertl> have a look at include/linux/vserver/context.h to see what caps/flags are there (not all working, but most of them are) 00:56:46< broo> so the capability.h stuff no longer applies at all then? 00:56:56< Bertl> for bcaps it is still valid 00:57:16< broo> hmm for each of the ones I have tried to use I get unknown bcapability 00:57:30< Bertl> how do you try/use it? 00:57:51< broo> well first I tried putting them in capability 00:57:59< broo> then bcapaibility 00:58:13< broo> sorry capabilities 00:58:21< broo> and bcapabilities 00:58:52< broo> and they didn't get set and the bcap one generated an error, so then I tried doing a command line chcontext 00:59:28< broo> chcontext --secure --cap but it always came back as unknown bcap 00:59:53< Bertl> and that was with 0.29.211, right? 01:00:03< broo> so I put a bunch of echos in to the util-vserver scripts to see what was happening to the --cap line arg 01:00:08< broo> yepp 0.29.211 01:00:44< Bertl> chcontext --cap CAP_NET_RAW /bin/sh 01:00:49< Bertl> this gives you? 01:01:27< broo> unknown bcap 'CAP_NET_RAW' 01:01:45< Bertl> New security context is 49153 01:01:45< Bertl> Unknown bcap 'CAP_NET_RAW' 01:01:48< Bertl> like this, right? 01:01:54< broo> yes 01:02:32< Bertl> yeah, looks like a regression, but I'm not sure where ... 01:02:45< Bertl> let me do a quick check on that ... 01:04:51>> Netsplit uranium.oftc.net <-> quasar.oftc.net quits: dsanta, shuri, UFOczek 01:09:26>> UFOczek [ufoczek@hood.openbug.net] has joined #vserver 01:11:30< Bertl> broo: looks to me like enrico did forget to add the caps :( 01:11:38< Bertl> static struct Mapping_uint64 const VALUES[] = { 01:11:38< Bertl> #warning Add the 'bcap' values here 01:11:38< Bertl> }; 01:11:51< broo> hmm 209 looks like it does the same 01:12:04< Bertl> yep, actually 201 already did do this ;) 01:12:05< broo> ah that would be a problem :) 01:12:16< Bertl> but you can use the numeric values, I guess 01:12:30< Bertl> there is even an option to specify a bit number 01:14:49>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver 01:27:09< Apollo> Bertl could you give me a hand with another quota problem? 01:27:23< Bertl> sure, what's up? 01:27:39< Apollo> when I put in quotaon /dev/hdv2 it works great. 01:27:50< Apollo> however, when I put in quotaon /var it complains... 01:28:00< Apollo> quotaon: Mountpoint (or device) /var not found. 01:28:21< Apollo> mtab and fstab files are mapped /dev/hdv2 to /var 01:28:47< Bertl> this is inside a vserver? 01:28:55< Apollo> sorry, yes it is in the server. 01:29:07< Apollo> vserver 01:29:26< Bertl> okay, could you paste your mtab inside the vserver? 01:29:40< Apollo> /dev/hdv1 / ext3 rw,usrquota 0 0 01:29:40< Apollo> /dev/hdv2 /var ext3 rw,usrquota 0 0 01:30:03< Bertl> hmm, and this setup works? 01:30:37< Bertl> well, might be, the quota tools are strange in many ways ... 01:30:43< Apollo> it seems to. 01:31:04< Bertl> I'd suggest to change the ext3 to ufs, as otherwise the quotacheck tool will fail inside the vserver 01:31:12< Apollo> ok 01:31:30< Bertl> further, if you want group quotas too, you have to add that to the mtab 01:31:39< Apollo> no, I don't want groups. 01:31:44< Bertl> okay ... 01:32:08< Bertl> is /proc/mounts visible inside your vserver? 01:32:26< Bertl> and does it contain the system mounts? 01:32:31< Apollo> yes 01:32:38< Apollo> it does contain system mounts 01:33:02< Bertl> maybe quotaon has a peek at this info .. and therefore can't find /var 01:33:39< Bertl> try to strace the quotaon /var to see what the tool actually does ... 01:33:47< Apollo> ok, would it be safe to add the hdv1 and 2 partitions to this file? 01:34:17< Apollo> ok 01:34:42< Bertl> which file? /proc/mounts? 01:34:54< Apollo> yes, that is what I was referring to 01:35:12< Bertl> no chance, this is a virtual filesystem reflecting the in kernel status ... 01:35:17< Apollo> ok 01:35:41< Bertl> but you can hide this information by some means ... 01:35:49< Bertl> what ekrnel patches do you use? 01:36:58< Apollo> only 2.4.26-vs1.27 01:37:49< Bertl> well, there is a patch somewhere to hide the /proc/mounts info, so _if_ this is the cause for your issue, then it would be an option to use that patch ... 01:37:55< Bertl> (or might be ;) 01:38:11< Apollo> ok, worth a try. 01:38:22< Apollo> thx. I'll try those couple things. 01:39:13< Apollo> the only reason I need to quotaon the dir rather than the filesystem is because webmin want to do it that way 01:43:51>> Netsplit uranium.oftc.net <-> nucleon.oftc.net quits: nalfein, lilo 01:45:31>> Netsplit over, joins: lilo, nalfein 01:45:31>> unununium.oftc.net changed the topic of #vserver to: http://linux-vserver.org/ | latest stable 1.27, devel 1.3.9, exp 1.9.0pre13 01:45:56>> lilo [levin@lilo.usercloak.oftc.net] has quit [Read error: Connection reset by peer] 01:46:01>> lilo_ [levin@lilo.usercloak.oftc.net] has joined #vserver 01:51:01>> Netsplit uranium.oftc.net <-> nucleon.oftc.net quits: nalfein 01:51:13>> Netsplit over, joins: nalfein 02:27:15>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has joined #vserver 02:57:40< Bertl> night everyone! 02:57:47>> Bertl is now known as Bertl_zZ 02:59:49>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has quit [Ping timeout: 480 seconds] 03:47:46>> anonymouscoward [~nwalsh@shaggy.internode.com.au] has left #vserver [Kopete 0.8.1 : http://kopete.kde.org] 04:26:18>> Apollo [~throwaway@caracal.norcomcable.ca] has quit [Quit: ] 04:33:44>> anonymouscoward [~nwalsh@shaggy.internode.com.au] has joined #vserver 05:27:14>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has joined #vserver 06:16:07>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has quit [Ping timeout: 480 seconds] 08:12:34>> _id [~id@pD95E90D3.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 08:20:52>> broo [~broo@host30-5.btbx.net] has quit [Remote host closed the connection] 08:22:11>> _id [~id@217.94.144.126] has joined #vserver 08:24:08>> broo [~broo@host30-5.btbx.net] has joined #vserver 08:25:12< broo> Bertl_zZ: in addition to adding the caps to lib/bcap-v13.c you also need to change script/chcontext 08:27:04< broo> Bertl_zZ: in scripts/chcontext the $(OPT_SECURE:+--secure} in chain_cmd= ... needs to be moved up 2 lines so its before the ${OPT_CAPS ... }line otherwise the --secure appears after it on the command line and wipes out any --bcap options that had occurred 08:38:25< broo> and here is a quick little perl script that outputs the data for that structure: perl cap.pl < lib/vserver.h 08:38:34< broo> #!/usr/bin/perl 08:38:34< broo> # 08:38:34< broo> while(<>) { 08:38:34< broo> next if !/^#define/; 08:38:34< broo> next if !/VC_CAP/; 08:38:36< broo> ($def, $name, $num) = split(/ /, $_, 3); 08:38:38< broo> $name =~ s/VC_(.*)/$1/; 08:38:40< broo> print "{\"$name\", ".length($name).", (1< } 08:48:25>> broo [~broo@host30-5.btbx.net] has quit [Remote host closed the connection] 08:49:09>> broo [~broo@host30-5.btbx.net] has joined #vserver 08:50:04< broo> hmm now thats interesting, before I could run an X server in both the main server and a vserver at the same time, now when I fire one up in the vserver I can't get back to the one in main 08:51:26< broo> I'll have to try it the other way around sometime tomorrow 08:51:35 * broo is away: hey look over there -> 10:05:03>> rs [rs@ice.aspic.com] has joined #vserver 10:05:17< rs> hi dudes 10:17:03>> csm [~csm@82-32-130-79.cable.ubr05.hawk.blueyonder.co.uk] has joined #vserver 11:33:24>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has joined #vserver 11:46:01< csm> hmm 11:46:05< csm> cqdlim is not very intuitive 12:15:58>> serving [~serving@213.186.189.95] has quit [Read error: Connection reset by peer] 12:33:56>> RoadRunnR [~RoadRunnR@213.187.82.17] has joined #vserver 12:36:33>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has quit [Remote host closed the connection] 12:40:53>> pflanze [~chris@gate.wyona.com] has joined #vserver 12:41:18< pflanze> Bertl_zZ: vserver kernel 1.3.8 just crashed. 12:41:31< pflanze> I'll tell you later. 12:41:34>> pflanze is now known as pflunch 12:46:30>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has joined #vserver 12:54:33>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has quit [Ping timeout: 480 seconds] 14:05:31>> surriel [~riel@66.92.77.98] has joined #vserver 14:07:03>> Doener [~doener@217.88.142.104] has joined #vserver 14:08:59>> Apollo [~throwaway@caracal.norcomcable.ca] has joined #vserver 14:11:58>> serving [~serving@213.186.189.95] has joined #vserver 14:18:25>> surriel [~riel@66.92.77.98] has quit [Ping timeout: 480 seconds] 14:21:53>> surriel [~riel@66.92.77.98] has joined #vserver 14:30:09>> Netsplit over, joins: UFOczek, rs 14:30:09>> Netsplit jupiter.oftc.net <-> keid.oftc.net quits: dsanta, RoadRunnR 14:30:43>> dsanta [~santa@68.190.156.105] has joined #vserver 14:30:50>> Netsplit over, joins: RoadRunnR 14:43:44>> surriel [~riel@66.92.77.98] has quit [Ping timeout: 480 seconds] 15:14:47>> RoadRunnR [~RoadRunnR@213.187.82.17] has quit [Quit: Client exiting] 15:40:52>> CornerNote [~CornerNot@udsl-3-114.QLD.dft.com.au] has joined #vserver 15:41:46< CornerNote> hello 15:41:50< CornerNote> anyone home ? 15:43:24< broo> hi 15:50:37< CornerNote> hello 15:50:46< CornerNote> have you got your vserver running ? 15:51:41< broo> yep 15:52:01< CornerNote> i got mine up - but i could not find how to SSH directly to it 15:52:18< CornerNote> i had to ssh to the real server and then use vserver vps01 enter 15:52:40< CornerNote> can you give me a push in the right direction to get SSH working ? 15:52:43< broo> did you make sure your ssh in your real server isn't binding to your vservers ip 15:53:33< CornerNote> there is no eth0 file with the vservers IP in it 15:53:49< CornerNote> before i created the vserver the IP of the vserver would not ping 15:54:06< broo> in the real server set the ListenAddress to the real server ip specifically, if it binds to 0.0.0.0 it'll bind to all the ips on the machine 15:54:30< CornerNote> ahh - i see 15:54:34< CornerNote> where do i set that ? 15:54:45< broo> in /etc/ssh/sshd_config typically 15:55:10< broo> sometimes in /usr/local/etc/ssh/sshd_config 15:55:14< CornerNote> so i just change 0.0.0.0 to whatever the real IP is? 15:55:19< broo> and uncomment it 15:55:26< broo> yes 15:55:38< CornerNote> i dont have the test box here - but i will have a look when i go back into the office 15:55:41< CornerNote> thanks :) 15:55:44< broo> then restart your sshd 15:55:50< broo> np 15:56:50< CornerNote> i think thats about the last step and then i can run multiple gameservers as root 15:57:00< CornerNote> what do you use it for ? 15:58:06< broo> quite a few things, gameservers being one of them, mostly I use them to separate services when I don't have a multiple box situtation so that if one service is compromised the whole box doesn't tend to get compromised 15:58:19< broo> I'd still run the gameservers not as root if you can 15:59:47< broo> I also use them to provide failover services, cause its fairly easy to provide the vserver area to multiple machines and have a new machine take up the slack under failure condition 15:59:52< CornerNote> i basically want to split the server into seperate pieces so that each user can run a game but not see anyone elses game.. then they can do any command that requires root and not have full access to the server 16:00:41< broo> yep 16:00:46< CornerNote> can you tell me if the vserver can be set to limit CPU ? 16:00:56< CornerNote> or will it just use whatever is available 16:01:22< broo> not sure, it looked like in the 1.9.0pre13 stuff that I fired up yesterday that it had hard limits as an option 16:02:08< CornerNote> nice. that would stop one person from making a 64player BF1942 on a 1/2 a P4 16:02:15< broo> :) 16:02:45< CornerNote> i would like to make a cluster and then break it up using vservers 16:04:02< CornerNote> have you setup a cluster before ? 16:04:28>> pflunch is now known as pflanze 16:04:41< broo> another thing I like about vservers is you can have the main/real server doing a more secure IDS for the vservers, so things like aide can have a protected local database 16:05:12< broo> I made a beowulf cluster about 3 years ago, but haven't done anything like that since 16:06:16< broo> and I've never tried to do virtual servers in a cluster 16:06:28< CornerNote> i have never setup an IDS because i have never had anything that i consider important enough to protect 16:06:46< broo> I thought someone had vsever and openmosix working but that could just be a rumor 16:07:19< CornerNote> i'm more into php/mysql than linux - but i like to learn new things... just waiting for my big break when i can actually make something from it 16:09:04< CornerNote> is openmosix an OS or an application that runs on the os ? 16:10:09< broo> application that runs on top of the os, I'm pretty sure it doesn't have kernel drivers, been a while since I looked at that as well 16:10:32< CornerNote> something else i was wondering about vserver... can you have a real redhat server with a debian vserver under it? 16:11:02< CornerNote> doesnt have to be rd and deb - just an example 16:11:24< CornerNote> or does the vserver have to run the same os as the base server 16:11:37< csm> does anyone have a lot of experience with per context disk limits? 16:13:56< broo> the vserver doesn't have to run the same os as the base server (as long as the vserver os doesn't expect some funky kernelness that the base server doesn't have) 16:15:31< broo> so you couldn't run base of debian and a vserver of openbsd 16:16:16< broo> wonder if you had an abstraction layer between openbsd and the kernel if you could do it, hmm 16:16:40< broo> say like run distro light in the vserver with bochs or something 16:17:15< broo> csm: not I, haven't used the per context disk limits yet 16:17:30< csm> okie :) ta 16:18:48< CornerNote> so you can run whatever OS, as long as they both run on the same kernel 16:20:10< CornerNote> csm - i thought about limiting disk usage by installing the vserver onto a partition... i know it's not the most efficent way and difficult to change the size later... but that would be what i am looking at if the per contect disk quota doesnt work for me 16:21:32< broo> CornerNote: yep personally I run debian/debian, but I've done many combinations of unstable/stable between the vserver and the main servers 16:25:25< broo> another nice thing vservers are good for is setting up cross compiliing environments 16:34:24< CornerNote> well i am off to bed 16:34:32< CornerNote> thanks again for all your help broo 16:34:34< CornerNote> seeya 16:35:22< broo> cya 16:35:32>> CornerNote [~CornerNot@udsl-3-114.QLD.dft.com.au] has quit [Quit: ] 16:47:37>> surriel [~riel@imladris.surriel.com] has joined #vserver 16:55:14< pflanze> Bertl_zZ: are you there? 16:55:30< pflanze> surriel: are you vserver kernel developer? 16:58:24< albeiro> pflanze: Bertl_zZ is 16:59:15< pflanze> yes I know. Just wondering. 17:08:11< pflanze> How does one clean up zombies hanging around in a context? 17:08:22< pflanze> i.e. it's a vserver not running at all anymore. 17:08:35< pflanze> no init there, at least not shown by vps 17:08:41< pflanze> just zombies. 17:15:45>> Bertl_zZ is now known as Bertl 17:15:56< Bertl> hi everyone! 17:16:07< rs> hi Bertl 17:16:07< mcp> moin Bertl 17:16:28< Bertl> how is life and of course vserver? 17:16:40< mcp> life is shit 17:16:42< mcp> vserver is good 17:16:43< mcp> ;) 17:17:03< Bertl> hmm, well, okay .... ;) 17:17:06< mcp> ;) 17:17:54>> muisec [alanp@webssh.boredom.org] has left #vserver [] 17:18:17< Bertl> pflanze: hmm, you had a 1.3.8 crash? 17:18:50< pflanze> yes 17:19:02< Bertl> with stackdump (oops)? 17:19:03< pflanze> well it's strange: I can reproduce a machine reboot 17:19:11< pflanze> now it always just reboots 17:19:19< pflanze> but the first time I had to hit reset 17:19:23< Bertl> interesting, when? 17:19:28< Bertl> or better how? 17:19:35< pflanze> I did set up a gentoo guest 17:19:40< pflanze> then started it 17:19:42< pflanze> worked fine. 17:19:57< pflanze> Then my buddy changed a few things, rebooted, and since then it loops, 17:20:04< pflanze> it just reboots every 8 seconds (the vserver). 17:20:08< pflanze> Because of this, 17:20:16< pflanze> I'm trying to track it down using: 17:20:28< pflanze> chcontext --ctx 20000 chroot /vservers/scrat/gentoo/ /sbin/init --init 17:20:30< Bertl> hmm, wait, the vserver or the host reboots? 17:20:48< pflanze> the vserver reboots every 8 seconds, (until I stop it) 17:20:58< pflanze> because of this I did the above chcontext vodoo 17:21:05< pflanze> and the latter triggers a machine crash 17:21:07< pflanze> or machine reboot 17:21:23< pflanze> when I hit Ctl-C while waiting for it 17:21:45< Bertl> okay, the reboot makes sense ... 17:21:51< pflanze> I'm not completely sure anymore as to when it crashed the first time - I think it was too when I hit Ctl-c 17:22:03< pflanze> why? 17:22:09< rs> Bertl: I have 362Mb of logs for you 17:22:13< rs> do you want more ? 17:22:17< Bertl> you are starting init with basically all caps, including CAP_REBOOT 17:22:24< pflanze> AH urgh 17:22:40< Bertl> rs: yes, this is uncompressed, right? 17:23:13< rs> yep 17:23:16< Bertl> pflanze: looks like the init is unhappy inside the vserver, and initiates a reboot 17:23:28< Bertl> rs: could you bzip2 it and give me an url? 17:23:31< pflanze> yep that makes sense 17:24:02< Bertl> you could add --secure to your voodoo line ;) 17:24:26< pflanze> I just don't know ( a) why the machine froze the first time, but maybe I was really wrong, and ) how to track down the gentoo init problem. 17:24:28< pflanze> ah ok 17:24:47< pflanze> chbind --ip 10.0.6.1 --ip 192.168.6.1 chcontext --ctx 20000 --secure chroot /vservers/scrat/gentoo/ /sbin/init --init 17:24:53< pflanze> does this look ok? 17:26:26< pflanze> And the other question: how comes there are zombies that nobody's waiting for? (i guess because the fake init process has died?) How can I make them go away? 17:27:12< Bertl> pflanze: hmm, basically you can't ... (except for reboot) 17:27:40< Bertl> they want to deliver their return values to the parent, which is gone .... 17:27:48< pflanze> /proc/xx/status says ppid: 1 but I guess because of the different context that's nuts :) 17:28:06< pflanze> The problem is that "vserver foo stop/start" won't work anymore. 17:28:08< Bertl> this should not happen, but it might not be fixed in 1.3.x yet 17:29:41< rs> Bertl: what does the pre13 change ? 17:33:56< Bertl> some cleanup, the fixes we did for namespace, and a little /proc restructuring 17:34:14< Bertl> you have still unresolved issues with 2.6.6-rc3? 17:35:33< pflanze> What should I try to track down why gentoo's init fails? I can't seem to get strace to work over ctx boundaries :^) 17:35:56< pflanze> (Hm ah idea: start the strace from the vserver) 17:35:59< Bertl> well, then don't do it, start the strace _after_ the chcontext ;) 17:36:10< pflanze> yep 17:40:34< rs> Bertl: still not tested 17:41:10< Bertl> well, you should do the following, in our all interest: 17:41:18< Bertl> a) test if 2.6.6-rc3 does fix it 17:41:41< Bertl> b) check which patch introduced the 'regression' 17:42:01< Bertl> c) if it isn't fixed, write a bug report to trond 17:42:15< csm> ah 17:42:19< csm> Mr Bertl 17:42:22< rs> I will do that next week, I was very busy last days 17:42:23< csm> just the man ;) 17:42:33< Bertl> hi csm! 17:42:38< pflanze> (Is there already a script like "vserver-enter ctxnumber rootdir cmd"? that allows to "force enter" some non-running vserver.) 17:42:42< csm> hiya 17:42:52< csm> I'm trying to get to grips with per context disk limits 17:43:08< Bertl> pflanze: basically 'vserver enter' does this 17:43:24< Bertl> csm: hmm, stable or devel? 17:43:29< csm> am I right in thinking that cqdlim hasn't yet got a way of determining the amount of space in use? I literally want to say "you can't use more than 1.5Gb" 17:43:30< csm> stable 17:43:32< pflanze> the alpha tools don't allow to enter a nonrunning vserver 17:43:46< Bertl> pflanze: bug report! 17:45:29< pflanze> (Well, in fact "vserver foo enter" now 'works', but probably only because there are some zombies hanging around still in this case.) 17:46:08< Bertl> csm: hmm, okay, any specific questions? 17:46:43< csm> well, everytime the machine comes up I see I have to do cqdlim -x context -S inodes-used,inodes-allowed,blocks-used,blocks-allowed etc 17:47:00< csm> are all those values required? can cqdlim not determine the numbers in use already? 17:48:07< Bertl> well, yes it could, but the thing is the cqdlim tool is about 20 lines of code, for testing purpose only ... and nobody wrote a better solution yet ;) 17:48:27< csm> ah :) 17:48:58< csm> but do I need to provide the inodes used, for example? 17:49:12< csm> because for blocks I guess I can just do du -skx 17:49:27< Bertl> well, yes and no ... 17:49:51< Bertl> first, you have to provide all information, unless you want incorrect behaviour ... 17:50:18< Bertl> then, it depends on your setup if du -skx is correct or not ... probably it is not ... 17:50:34 * pflanze does have a disk ctx quota question: does it work on reiserfs? 17:50:43< csm> oh :) 17:50:49< Bertl> pflanze: does reiser support quota? 17:51:01< pflanze> I think so - but never tried it 17:51:33 * pflanze is googling around 17:51:38< Bertl> I#d say, unless you patch the patches mason did, you'll have no quota ;) 17:52:07< csm> how can I see if -skx is correct? 17:52:11< Bertl> okay, dinner time, I have to leave now, but I'm back in 20 minutes ... csm if you can wait, I'll explain ... 17:52:15< csm> compare an unloaded df with du -skx? 17:52:37>> Bertl is now known as Bertl_oO 17:58:46>> csm [~csm@82-32-130-79.cable.ubr05.hawk.blueyonder.co.uk] has quit [Quit: ..(cyp): [BX] Beefcake! BEEFCAKE!] 18:15:17< pflanze> Somehow upon machine reboot, the gentoo vserver is always started now and dies with zombies hanging around. 18:15:26< pflanze> So this is definitely not good. 18:15:46< sladen> pflanze: you may need to clear out /var/run/ ? 18:16:37< pflanze> why 18:16:40< pflanze> which file 18:19:15< pflanze> root@elvis root# vserver scrat enter 18:19:15< pflanze> 'vserver ... suexec' is support for running vservers only; aborting... 18:24:53< broo> its funny but I thought that was a nice feature cause I kept entering vservers that I didn't have running and this kept me from doing so :) 18:28:05< broo> Bertl_oO: quick question, any idea why starting an X server in a vserver would make the one in the main unavailable, can't ctrl-alt-f7 back to it, but its still running, back in the day (around ctx17) you could have all of them running just like running multiple X servers 18:29:11>> Bertl_oO is now known as Bertl 18:30:32< Bertl> okay, I'm back ... 18:31:29< Bertl> rs: do you have the unified diff of your changes to the kernel somewhere? 18:32:05< Bertl> broo: I don't see any reason for that ... actually ... 18:32:35< Bertl> what does CTRL-ALT-F1 do? 18:33:08< broo> takes me back to the main console (thats how I noticed the main Xserver is still running) 18:33:33< Bertl> and then CTRL-ALT-F7 ? 18:33:48< Bertl> or just ALT-F7 18:33:57< broo> takes me to a screen like a console (non-graphical) 18:34:08< broo> just like there wasn't an xserver running there 18:34:14< Bertl> hmm, and your main xserver was there? 18:34:21< broo> yep 18:34:28< Bertl> and it's still running? 18:34:50< broo> yeah in the main console if I do a ctrl-c it kills the xserver 18:35:12< Bertl> what does ps auxwww show? 18:35:17< broo> so I figure its still running just can't get to the graphical display 18:35:29< broo> didn't try that 18:36:35< rs> Bertl: yep, http://rs.rhapsodyk.net/vserver/linux-2.6.5-vs1.9.0pre12.2+namespacefix+memdebug.diff 18:36:50< broo> let me try it real quick, its on this machine so I'll probably get disconnected from irc 18:37:07< Bertl> rs: tx 18:43:24>> broo [~broo@host30-5.btbx.net] has quit [Remote host closed the connection] 18:43:32>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has joined #vserver 18:43:42< Bertl> hi Jon! 18:44:14< JonB> hey Bertl 19:01:14< pflanze> Bertl: what about the zombie problem? 19:01:26< pflanze> Should I write to the list? 19:01:34< pflanze> Somehow this has to be handled. 19:01:37< Bertl> well, basically it is known ... 19:02:01< pflanze> Do you have a patch already lying around somewhere? 19:02:03< Bertl> and the question is, how would a 'good' solution look like? 19:02:15< pflanze> hm 19:02:26< pflanze> I'm trying to sort my thoughts. 19:02:32< Bertl> because if the host's init dies, you know what you get, right? 19:02:33< pflanze> I had a bad day today with vserver 19:02:43< pflanze> a kernel panic 19:03:26< pflanze> But it's inacceptable to run into such a zombie situation with normal vserver usage that can basically only be solved by a machine reboot. 19:03:51< Bertl> hmm, let's say it's unfortunate and unwanted ... 19:04:08< pflanze> sure 19:04:42< Bertl> now what should the kernel do, when the init process (which is per definition not supposed to) quits, leaving it's children around? 19:04:51< pflanze> In any case, my attempts to solve the gentoo boot issue were very hairy. 19:05:24< pflanze> e.g.: the boot problem only arises when starting the gentoo vserver normally, not with my vodoo. 19:05:49< pflanze> My vodoo does let it run, but it cannot bind ip addresses for some strange reason 19:05:56< Bertl> is there nothing in the logs? 19:06:16< pflanze> I can include a strace when I do it with my vodoo, but that's not interesting, I want an strace with the normal startup. 19:06:30< pflanze> I dunno how to attach a strace with the normal startup. 19:06:52< pflanze> I tried replacing the vserver's /sbin/init but realized that strace was not installed inside gentoo 19:07:06< pflanze> that's what makes it really hairy..:) 19:07:28< Bertl> well, cp does work over distro boundaries? 19:07:30< pflanze> No, nothing in the logs 19:07:43< pflanze> well, I'd have to copy the libraries too, probably 19:07:52< Bertl> or compile strace statically? 19:07:55< pflanze> yes 19:08:05< pflanze> but that's much work for just a strace. 19:08:21< pflanze> imagine boot problems happening every other day.. 19:08:42>> hadge [~me@h64-5-199-35.gtcust.grouptelecom.net] has joined #vserver 19:08:48< pflanze> Which logs do you mean? 19:09:02< Bertl> the syslog inside the guest ... 19:09:06< pflanze> - stdout says nothing, - vshelperlog, 19:09:20< pflanze> - syslog inside does not work for some unknown reason 19:09:33< hadge> Hey there, quick question. When I do a df from inside a vserver, it lists the total hard drive usage by all the vservers. Is this going to change in the future? 19:09:37< pflanze> (the gentoo buddy disabled it then enabled it again, still does not log anything) 19:09:58< Bertl> pflanze: well, looks like gentoo isn't that suited for vserver after all? 19:10:12< pflanze> are you sure? 19:10:19< pflanze> [y/N] 19:10:23< Bertl> hadge: depends on what patches you use, and what options you configure ;) 19:11:01< Bertl> pflanze: probably it is another configuration issue ... what about infowolfe? 19:11:10< hadge> oh, using 1.9.0pre12 right now, with the latest util-vserver. What options would I play with? 19:11:15< pflanze> what's infowolfe? 19:11:59< Bertl> the guy who called himself a gentoo-vserver expert? 19:12:47< pflanze> I've looked at the gentoo page in the wiki, 19:13:13< pflanze> but there's nothing special. And upon first attempt with using init-style boot, it even worked fully. 19:13:31< pflanze> Either my buddy has destroyed it somehow, or I dunno. 19:13:58< pflanze> Problem is that there's no way to find out what's happening - that would be what vserver could be good for. 19:14:20< pflanze> ensc: is there a chance to attach strace to a init style boot process? 19:14:25< Bertl> hadge: this is going to change as soon as 2.6.x patches include the disk limits/quota stuff ... which isn't done yet ... 19:14:45< pflanze> ensc: where the strace binary is started from the host. 19:16:06< pflanze> Bertl and ensc: are you getting any money for your work, btw? 19:16:27>> broo [~broo@host30-5.btbx.net] has joined #vserver 19:16:49< Bertl> pflanze: unfortunately no ... 19:17:43< pflanze> Are you student? 19:17:44< broo> Bertl: okay this is bizarre, I can switch from main X server to vserver X server without problems, but I can't switch from vserver X server to main X server unless I switch to a non-graphical console first 19:18:05< broo> but other than that seems to work fine 19:18:10< Bertl> broo: this sounds better ... 19:18:31< Bertl> pflanze: I'm working on my doctoral thesis, but old student ;) 19:19:06< pflanze> k 19:19:37< pflanze> But your thesis is not vserver related? 19:19:48< Bertl> no ;) 19:20:26< pflanze> Fine. 19:20:33< pflanze> From you :) 19:20:43< pflanze> Not for you that much, of course :) 19:21:22< pflanze> I'm asking because I'm in a position now where everybody seems to thing "pay me please or I won't do anything" 19:21:31< pflanze> think 19:21:53< Bertl> ah, okay then, "pay me please or I won't do anything" ;) 19:22:08< pflanze> heh 19:22:19< pflanze> :) 19:22:21< pflanze> :/ 19:22:34< Bertl> dont worry, was just a joke ;) 19:22:55< Bertl> but if you feel like donating some money, there is a donations page .... 19:23:13< pflanze> If I'd earn any money with my attempt at vserver hosting, I'd donate something for sure. 19:23:23< pflanze> I'll see. 19:23:36< pflanze> Currently everything's a little unsure. 19:29:42< Bertl> pflanze: if you can provide a simple example for the zombie case (something which can be reproduced with chcontext, chbind and friends, but not vserver script and entire vserver) and a short description how it should act instead, I'm sure we can fix this ... 19:31:30< pflanze> You want a case that does *not* happen with entire vserver? 19:31:47< pflanze> The problem is that it happens with normal vserver boot only so far. 19:31:49< Bertl> yep, but I guess that is fairly simple ... 19:32:15< Bertl> think of chcontext --ctx 100 bash -c "sleep 100 &" 19:32:43< Bertl> (maybe that is already sufficient ;) 19:32:51 * pflanze trying 19:33:59< pflanze> that does not leave zombies 19:34:10< Bertl> did you wait 100 secs? 19:34:13< pflanze> yes 19:34:22< pflanze> well no, 19:34:33< pflanze> I (wie sagt man, schummeln) 19:34:39< Bertl> cheating 19:34:40< pflanze> I just used 3 seconds instead :) 19:35:15< Bertl> then try again with a deeper level, similar to init, maybe even with fakeinit, maybe that's the reason? 19:37:59< pflanze> Is there a doc of fakeinit? 19:38:26< Bertl> hmm, probably not, but IIRC, for stable/devel --fakeinit is sufficient ;) 19:38:26< pflanze> If you say "fakeinit" do you just mean the kernel init-pid hiding code? 19:39:16< pflanze> A --fakeinit option? to which command? 19:39:22< Bertl> chcontext? 19:39:28< pflanze> ah. 19:39:52< pflanze> --flag fakeinit 19:39:55< Bertl> have a look at the testme.sh (which should test this) 19:41:57< pflanze> chcontext --flag fakeinit --ctx 100 bash -c "( sleep 10 & sleep 11 & setsid sleep 12 & )&" 19:42:02< pflanze> does not leave any zombie 19:42:35< Bertl> what about ... 19:43:24< Bertl> chcontext --flag fakeinit --ctx 100 bash -c 'bash -c "sleep 10 &"; sleep 5 &' 19:44:11< pflanze> no zombie 19:45:13< Bertl> well, then maybe your zombies are not even caused by vserver stuff? 19:46:00< Bertl> for example, busybox used as init will leave zombies around in cetain situations (without any vserver code) 19:46:06< pflanze> Well, this vserver is configured to use "plain" ./apps/init/style 19:46:14< pflanze> and if I reboot the host, 19:46:31< pflanze> I see about 20 processes of this vserver in defunct state 19:46:38< Bertl> the host? 19:46:41< pflanze> and no init process of this vserver 19:46:54< pflanze> yes, it only happens if I reboot the host 19:47:03< pflanze> i.e. let the host start the vserver automatically 19:47:08< Bertl> the host is the 'real' machine? 19:47:10< pflanze> yes 19:47:27< Bertl> if you reboot it, there will be _no_ processes left, right? 19:47:40< pflanze> hm? 19:47:51< pflanze> when the machine is reset there will be no processes :) 19:47:58< pflanze> but after the boot there will be again 19:48:13< Bertl> so it happens _after_ the reboot? 19:48:24< pflanze> yes, after the host has auto-started the gentoo vserver 19:48:55< pflanze> it auto-starts also a bunch of debian based vservers fine (both "plain" init style and default init style) 19:49:03< Bertl> and if you start it from a shell, you do not get the zombies? 19:49:11< pflanze> No, then it loops 19:49:15< pflanze> i.e. restarts every 8 seconds 19:49:33< Bertl> well, I'd say your host is somewhat confused ... 19:49:57< Bertl> maybe you should consider installing it from scratch ... 19:50:14< pflanze> I guess that there's a special case for auto-start, if that fails, it won't try to start it again? 19:50:38< Bertl> well, it won't try on the shell again, afaik! 19:50:55< pflanze> I see in vshelper log that it gets a reboot command 19:51:13< pflanze> thus it looks like the init does a reboot kernel call. 19:51:25< Bertl> but if you get zombies from autostart, but no zombies from shell start, then it is something wrong with your host's init, right? 19:51:26< pflanze> Which the vshelper happily does. 19:52:06< pflanze> which init? 19:52:20< Bertl> /sbin/init on the host ;) 19:52:27< pflanze> what should be wrong with that one? 19:52:46< Bertl> it obviously leaves the zombies around, which the shell is able to reap ;) 19:52:48< pflanze> Is it involved in any way? 19:53:06< pflanze> for me host==real machine. 19:53:10< pflanze> not vserver 19:53:19< Bertl> host_init -> init_scripts -> vserver_script -> vserver_init -> process 19:53:29< pflanze> ah 19:53:31< pflanze> hm 19:53:37< Bertl> now the process dies ... and the zombie stays 19:53:40< Bertl> but: 19:53:44< pflanze> maybe 19:53:59< pflanze> that's a good idea 19:54:00< Bertl> host_init -> bash -> vserver_script -> vserver_init -> process 19:54:18< Bertl> does work, and doesn't leave zombies around, right? 19:54:30< Bertl> (aside from the looping reboot issue) 19:55:08< pflanze> Probably it only does not loop in the autostart case because the zombies are there. 19:55:20< Bertl> ight be ... 19:55:24< Bertl> even might! 19:55:48< pflanze> This hypothesis means two things: 19:56:13< pflanze> 1. if the parent is init (pid 1) on the host, sigchld or something does not work 19:56:23< pflanze> (for other pid's it works)= 19:56:50< Bertl> hmm, not really ... 19:57:08< pflanze> 2. the vserver init scripts do put the startup of the vservers into the background (they are not parent anymore), as opposed to "vserver foo start" which does not do this. 19:57:25< Bertl> but you can say that: under certain circumstances, the init on the host, refuses to reap some children ;) 19:57:50< pflanze> why should it do that apart from the ctx issue? 19:58:02< Bertl> if 2) is the issue, you could easily reproduce this by doing the same on the command line (&) 20:00:26< pflanze> PPid: 1 20:00:28< pflanze> s_context: 100 20:00:37< pflanze> but it is collected anyway 20:01:22< pflanze> (This was done using: 20:01:24< pflanze> ( chcontext --flag fakeinit --ctx 100 bash -c 'bash -c "sleep 40 &"; sleep 35 &' & )& 20:01:24< pflanze> ) 20:02:06< pflanze> (same thing without flag fakeinit) 20:02:17>> LeXo_ [~LeXo@lns-th2-4f-81-56-252-185.adsl.proxad.net] has joined #vserver 20:02:29< Bertl> hi LeXo_! 20:02:46< pflanze> so the hypothesis was wrong? 20:02:57< Bertl> which one? 20:03:30< pflanze> that the context difference in combination with my init is the reason for the failed reap 20:03:31>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has quit [Quit: Leaving] 20:04:02< Bertl> why? your init isn't doing the reaping here, it is the shell, right? 20:04:04< pflanze> (or are there really cases where init would ignore sigchld?) 20:04:12< pflanze> why the shell? 20:04:16< pflanze> if ppid is 1 20:04:41< pflanze> or is this faked? 20:04:50< pflanze> "ah" 20:04:50< Bertl> because the kernel code takes care of this case, and reparents the child ... and yes it is faked ;) 20:05:09< Bertl> that's why it is called fake init ;) 20:07:46< pflanze> Do you think that init is going to check /proc or use kill(0,pid) to see if the process is there? 20:08:29< pflanze> Or rather: 20:08:29< Bertl> no, because a) proc isn't mounted when init is started 20:08:51< Bertl> and b) why should init care about the processes? 20:09:08< pflanze> if ppid==faked 1, a process is not going to be reparented? 20:09:29>> franck [~LeXo@lns-th2-4f-81-56-252-185.adsl.proxad.net] has quit [Ping timeout: 481 seconds] 20:09:40< Bertl> well, that depends on the patch ... 20:09:49< pflanze> so if the vserver init process dies, it's childs still have ppid 1 but a nonexistent vppid 20:10:06< pflanze> 1.3.8 20:10:44< Bertl> we did a zombie fix in 1.9.0preX somewhere ... 20:10:59< pflanze> (combined with grsecurity) 20:11:12< Bertl> (which might also cause mayhem) 20:13:04< Bertl> hmm, should have been included in 1.3.8 20:13:28>> rs [rs@ice.aspic.com] has quit [Quit: leaving] 20:13:48< Bertl> you could do the following tests: 20:14:03< Bertl> compile a vanilla kernel with 1.3.7, 1.3.8 and 1.3.9 patches 20:14:24< Bertl> see if the behaviour changes somewhere and somehow ... 20:16:06< pflanze> found a message: 20:16:17< pflanze> (why didn't I check the host kernel log?..) 20:16:26< pflanze> (and glad did I include grsec :) 20:16:27< pflanze> Apr 30 18:08:56 elvis kernel: grsec: signal 11 sent to (vps:22832) UID(0) EUID(0), parent (vserver:23671) UID(0) EUID(0) 20:16:27< pflanze> Apr 30 18:08:56 elvis kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (vps:22832) UID(0) EUID(0), parent (vserver:23671) UID(0) EUID(0) 20:16:54< pflanze> looks like gentoo's init (?) tries to set the core limit 20:17:43< pflanze> eh 20:17:56< pflanze> it segfaults, and then it wants to generate a core 20:21:29< Bertl> well, that probably explains the bad startup, right? 20:22:02>> taxcollector [~taxcollec@192.16.167.161] has joined #vserver 20:22:18< Bertl> hi taxcollector! how much? 20:22:21< taxcollector> :) 20:23:18< taxcollector> If someone is in the know, I've come to ask a question regarding the alpha util-vserver tools. 20:23:44< Bertl> you read the excellent alpha util-vserver page? 20:23:45< taxcollector> I'm playing around with vunify and I'm noticing it is setting attributes on the source files that prevent it from being linked too 20:23:48< taxcollector> Yup. 20:26:28< taxcollector> Is the immutable attribute set by vunify supposed to be the same immutable bit one would normally set with chattr +i? 20:26:31< Bertl> well, it is supposed to set some flags ... 20:26:55< Bertl> but they should not prevent linking to the files ... 20:27:14< Bertl> could you give a short overview about kernel patch/tool version? 20:27:31< taxcollector> kernel 2.4.26 20:27:35< taxcollector> patch vs1.3.9 20:27:40< taxcollector> util-vserver 211 20:27:50< taxcollector> 0.29.211 20:28:08< Bertl> okay, and your filesystem is? 20:28:15< taxcollector> Sorry... ext3 20:28:39< Bertl> hmm, okay, basically the tools should set the immutable and the iunlink flag 20:28:56< Bertl> which in combination should allow you to link to the files ... 20:28:59< taxcollector> Right, in Unify_unify vunify does this: 20:29:00< taxcollector> if (vc_set_iattr(src, 20:29:00< taxcollector> 0, 20:29:00< taxcollector> VC_IATTR_IUNLINK|VC_IATTR_IMMUTABLE, 20:29:23< taxcollector> But doesn't that prevent me from creating a hard link to the src file? 20:29:40< Bertl> yep, so if those flags are not set, or linking to those files isn't possible, then it's a bug .. probably in the kernel ... 20:30:18< Bertl> give me a minute to verify that ... 20:30:38< taxcollector> Sure, there are lines in the patch like: 20:30:39< taxcollector> error = -EPERM; 20:30:39< taxcollector> - if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) { 20:30:39< taxcollector> + if (IS_APPEND(inode) || IS_IXUNLINK(inode)) { 20:30:39< taxcollector> EXIT; 20:30:52< taxcollector> * A link to an append-only or immutable file cannot be created. 20:30:53< taxcollector> */ 20:31:32< Bertl> IS_IXUNLINK() is the XOR of immutable and iunlink 20:31:40< taxcollector> right 20:32:21< taxcollector> Perhaps I am misunderstanding something then 20:32:35< taxcollector> It seems like the very first thing vunify does before it does the hard link 20:32:46< taxcollector> is set the very bits that shouldn't be set 20:33:07< Bertl> it's okay to set immutable and iunlink 20:33:24< Bertl> because both (0,0) and (1,1) with XOR give 0 20:33:40< taxcollector> doh 20:33:48< taxcollector> a sleep at the wheel 20:35:27< Bertl> # ln /tmp/x /tmp/a 20:35:27< Bertl> # chattr +i /tmp/x 20:35:27< Bertl> # ln /tmp/x /tmp/b 20:35:27< Bertl> ln: /tmp/b: Operation not permitted 20:35:27< Bertl> # setattr --iunlink /tmp/x 20:35:30< Bertl> # ln /tmp/x /tmp/c 20:35:32< Bertl> # showattr /tmp/c 20:35:35< Bertl> ---bU-X /tmp/c 20:35:37< Bertl> # lsattr /tmp/c 20:35:40< Bertl> ----i-------- /tmp/c 20:35:42< Bertl> this is the test I just did with 1.3.9 20:37:02< taxcollector> ok 20:37:57< taxcollector> The problem I was experiencing was vunifying setting the attributes as I pasted above but having the subsequent link fail. 20:38:52< Bertl> maybe for a start you could do the same test on your system? 20:39:00< taxcollector> I play around with it some more and see if I can get a better understanding of what is going on 20:39:01< taxcollector> Sure 20:39:25< taxcollector> Give me a minute or so 20:41:27< UFOczek> hello. 20:41:42< UFOczek> hi Bertl 20:41:58< taxcollector> My test succeeded, identical results 20:54:17< taxcollector> Here is the test that was failing for me: 20:54:18< taxcollector> [root@fft7 tmp]# mkdir ref ; touch ref/a 20:54:18< taxcollector> [root@fft7 tmp]# cp -Rp ref dst 20:54:18< taxcollector> [root@fft7 tmp]# cat > excludelist 20:54:18< taxcollector> [root@fft7 tmp]# /usr/lib/util-vserver/vunify -vv --manually /tmp/dst/ excludelist /tmp/ref/ excludelist 20:54:19< taxcollector> Initializing exclude-list for /tmp/dst/ 20:54:19< taxcollector> Initializing exclude-list for /tmp/ref/ 20:54:21< taxcollector> Starting to traverse directories... 20:54:21< taxcollector> unifying '/a' 20:54:24< taxcollector> link(): Operation not permitted 20:54:40>> Doener [~doener@217.88.142.104] has quit [Quit: Leaving] 20:59:40< Bertl> taxcollector: hmm, could you verify that both flags, the immutable and the iunlink is set? 20:59:45< Bertl> hi UFOczek! 21:00:21< UFOczek> at last! :) 21:01:45< Bertl> hmm ... means? 21:03:08< taxcollector> [root@fft7 tmp]# setattr --iunlink ref/a 21:03:08< taxcollector> [root@fft7 tmp]# showattr ref 21:03:08< taxcollector> ---bu-X ref 21:03:08< taxcollector> ---bU-X ref/a 21:03:08< taxcollector> [root@fft7 tmp]# lsattr ref 21:03:10< taxcollector> ------------- ref/a 21:03:35< Bertl> okay, so what happens here is that we are missing the immutable flag 21:03:47< Bertl> and I have a good idea why this is so ;) 21:03:54< taxcollector> Cool 21:04:35< Bertl> some time ago, enrico asked me if I could add the immutable flag to the vc_set_iattr function call .. 21:05:03< Bertl> and I agreed to do that for experimental ... 21:05:43< Bertl> now the tools seem to 'assume' that this is also in devel 1.3.x 21:05:59< Bertl> which isn't the case ... 21:06:31< Bertl> but as this is no big deal, I can provide a patch for you ... 21:06:37< taxcollector> Thanks 21:06:48< Bertl> just give me a few minutes to add and test this ... 21:34:21< Bertl> hmm, well, I have a patch, but this one has some problems ... 21:34:26< taxcollector> hmm? 21:35:00< Bertl> I guess I have to rework that part, as I can't reliably set/modify the immutable flag from inside that syscall ... 21:35:12< taxcollector> Oh, ok. 21:35:30< Bertl> (I'd need to know the filesystem type, which isn't a good thing to do ;) 21:35:56< taxcollector> you don't want to mess up your separation of logic 21:36:10< Bertl> but you can work around this by doing the +i separately ... 21:36:16< taxcollector> ok 21:36:27< Bertl> although I doubt that this will work as expected ... 21:36:42< taxcollector> Maybe we should just get Enrico to not use this flag? 21:36:57< taxcollector> And set it the "normal" way 21:37:04< Bertl> hmm, no, unfortunately the rabbithole goes much deeper here ... 21:37:36< Bertl> actually I'm not sure that IUNLINK and BARRIER works as expected, when the tools use this syscall ... 21:38:39< Bertl> I have to medidate on that for a little ... maybe I'll find a smart solution ... 21:38:56< taxcollector> OK. Thanks for looking into it. 21:39:05< Bertl> np, you're welcome 21:50:49>> UFOczek [ufoczek@hood.openbug.net] has quit [Ping timeout: 480 seconds] 21:55:54>> Khahan [~Filbert@D5774530.kabel.telenet.be] has quit [Ping timeout: 480 seconds] 21:56:56>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 21:57:04< Bertl> hi shuri! 21:57:10< shuri> hi Bertl! 22:58:21< Apollo> hi Bertl 22:58:40< Bertl> hey Apollo! 22:58:54< Apollo> got a couple minutes. 22:59:09< Bertl> if this is a question, yes ;) 22:59:18< Apollo> yup... hehe 22:59:25< Apollo> that quotaoff / problem I was having. 22:59:39< Apollo> I still haven't resolved it. 22:59:47< Apollo> vproc won't work, because the mounts file is a symbolic link 23:00:10< Apollo> I did the strace and it seems to be pulling the /dev/hdv2 out of the mtab file as it should 23:00:12< Bertl> that's correct 23:00:18< Apollo> any other ideas? 23:01:27< Bertl> well, do the strace (with strace >= 4.5.1) for both the succeeding quotaon/off and the failing one ... options (-fF -s 10000) and make the traces available, I'll have a look at them ... 23:01:45< Apollo> k, thanks, will do. 23:08:10< Apollo> ftp://ftp.norcomcable.ca/works 23:08:14< Apollo> ftp://ftp.norcomcable.ca/fails 23:08:38< Bertl> 421 too many anonymous users? 23:10:03< Apollo> should work now. 23:12:33< Bertl> hmm, could you do the following inside the vserver?: 23:12:41< Bertl> ls -la /dev/hdv? 23:13:01< Apollo> brw-r--r-- 1 root root 4, 0 Apr 29 07:44 /dev/hdv1 23:13:21< Bertl> hum, where is hdv2 ? 23:13:35< Apollo> brw-r--r-- 1 root root 4, 0 Apr 29 07:44 /dev/hdv1 23:13:35< Apollo> brw-r--r-- 1 root root 4, 1 Apr 29 07:44 /dev/hdv2 23:13:43< Bertl> okay ... 23:13:44< Apollo> sry, figured you only wanted one of them. 23:16:06< Bertl> that really looks like a quota tools bug, elt's try the following: 23:16:25< Bertl> exchange the two lines in mtab and try both quota commands ... 23:17:12< Apollo> not sure I fully understand. How do you mean exchange the two lines? 23:17:21< pflanze> ensc or Bertl: do you have an idea where I could hook in a server-based strace? where is the chroot call done on normal vserver startup? 23:17:36< pflanze> s/server-based/host-based/ 23:17:41< Bertl> Apollo: move the / one line down, so that /var is in the first row 23:18:08< Bertl> pflanze: use bash -x vserver .... 23:18:12< Apollo> oh, hehe. too easy to understand. 23:18:58< Apollo> same results... :( 23:19:11< Bertl> okay, what quota tools do you have? 23:19:35< Apollo> 3.09 23:20:24< Bertl> hmm, you could try with 3.11 23:20:33< Apollo> ok, will try that. 23:20:41< Bertl> but I'm not convinced that will help ... 23:20:55< Apollo> worth a shot... 23:21:00< Bertl> anyway, try it, and have a look at the source, where the error is reported 23:21:33< Bertl> the strace shows identical results for both devices/mountpoints 23:21:54< Apollo> ok, thx 23:22:00< Bertl> so I do not see why quotaoff decides that it likes one, but not the other ... 23:23:17>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 23:33:13>> netrose [netrose@24.207.228.55] has joined #vserver 23:33:19< Bertl> hi bobi! 23:55:30>> taxcollector [~taxcollec@192.16.167.161] has quit [Quit: Quit] --- Log closed sob maj 01 00:00:54 2004