--- Log opened sob maj 08 00:00:48 2004 00:06:20< pflanze> Hm how can this be?: 00:06:22< pflanze> # strace -o o /opt/vserver/sbin/vps_ ax 00:06:22< pflanze> upeek: ptrace(PTRACE_PEEKUSER,7437,44,0): No such process 00:09:14< pflanze> this is in the middle of the strace, o already contains 4828 bytes 00:16:42>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has quit [Quit: leaving] 00:20:44< ensc> pflanze: strace can not follow context-changes 00:20:57< ensc> you to go into xid 1 before doing the strace 00:21:09< pflanze> aha 00:27:34< pflanze> How comes that init's children of a died guest have some completely different context id?: 00:27:42< taxcollector> ensc: Do you make modifications to alpha util-vserver with 1.3.x and 1.9.x in mind or just 1.9.x? 00:27:46< pflanze> root 22870 49202 scrat 0.0 0.0 1540 944 ? S 23:51 0:00 init [3] 00:27:46< pflanze> root 13878 4294967295 0.0 0.2 2656 2384 ? S 23:52 0:00 /bin/bash /sbin/rc default 00:27:59< pflanze> root 191 4294967295 0.0 0.2 2656 2388 ? S 23:52 0:00 /bin/bash /sbin/rc default 00:27:59< pflanze> root 8301 4294967295 0.0 0.2 2656 2388 ? R 23:52 0:00 /bin/bash /sbin/rc default 00:27:59< pflanze> root 14569 4294967295 0.0 0.0 0 0 ? Z 23:52 0:00 [stat] 00:28:11< ensc> taxcollector: it is tested with 2.4.x and 2.6.x patches only 00:28:11< pflanze> scrat is the vserver 00:29:00< taxcollector> Thanks 00:32:49>> monrad [~monrad@213083190250.sonofon.dk] has quit [Quit: Leaving] 00:34:15< pflanze> ensc: 00:34:26< pflanze> I've compiled a kernel without grsecurity, rebooted, 00:34:35< pflanze> and it still core dumps. 00:34:40< pflanze> And gdb still says: 00:34:43< pflanze> (gdb) bt 00:34:43< pflanze> #0 0x00000a09 in ?? () 00:34:43< pflanze> #1 0x4003ddc6 in __libc_start_main () from /lib/libc.so.6 00:34:56< pflanze> So it's not grsecurity's fault. 00:35:09< ensc> this address is really strange 00:37:22< ensc> pflanze: the 4294967295 means an error; probably a race occured while 'ps' returned the pid, and vps tried to determine the xid 00:37:32< pflanze> ah 00:39:27< pflanze> (well a race sounds strange, those processes stay forever iirc) 00:39:51< pflanze> (rather that the vserver does "not exist anymore" in some sense) 00:39:59< ensc> there is really no way to reproduce the coredump when strace'ing it? 00:40:27< pflanze> never seen a segfault when using strace in the wrapper 00:43:17< ensc> the backtrace above is from a glibc version, right? 00:43:42< pflanze> yes 00:44:21< pflanze> so it's not dietlibc's fault either :)) 00:47:01< ensc> no, else the backtrace would be a little bit strange 00:47:18< pflanze> yep 00:48:17< pflanze> (..and my gentoo client still refuses to boot..) 00:51:12< pflanze> hmm! 00:51:46< pflanze> I did remove the exec < /dev/null from my vshelper wrapper at some time 00:51:57< pflanze> maybe it segfaults if fd's were closed? 00:54:29< pflanze> no, same thing 00:56:09>> Bertl_oO is now known as Bertl 00:56:14< Bertl> back for a moment ... 00:56:29< Bertl> have you tried running the vps with gdb? 00:56:48< Bertl> (just an idea) 00:56:49< pflanze> hm, how would I interact with it? 00:56:58< Bertl> gdb vps_ 00:57:01< pflanze> I mean, when it 's started by vshelper 00:57:26< Bertl> you can automate gdb ... so you could start it with the wrapper ... 00:59:24< pflanze> hey, guess what? 00:59:28< pflanze> the segfaults have gone, 00:59:35< pflanze> and my gentoo client keeps running. 01:00:19< pflanze> now you want to know how? 01:00:40< Bertl> after a day of searching? you must be kidding? 01:01:25< pflanze> you're right, I'll let you fry a bit 01:01:52< pflanze> I won't tell you so easily 01:02:04< pflanze> :) 01:02:16< pflanze> It *was* the wrapper script. 01:02:19< pflanze> and fd's 01:03:05< pflanze> or ? 01:05:12>> gilbert [~gilbert@208-186-222-203.nrp4.brv.mn.frontiernet.net] has quit [Ping timeout: 480 seconds] 01:06:38>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has joined #vserver 01:08:29>> mode/#vserver [+o Bertl] by ChanServ 01:08:37>> taxcollector [~taxcollec@192.16.167.161] has quit [Quit: ] 01:08:44< pflanze> no it was not it 01:08:50<@Bertl> pflanze: speak up! or you will be removed! 8-) 01:08:58< pflanze> sorrry 01:09:03< pflanze> no need to be removed 01:09:19<@Bertl> was a joke ... would never do that ... 01:09:22< pflanze> I did change my wrapper script some time 01:09:33< pflanze> just added new stuff at the top. 01:09:41< pflanze> so the old stuff was still there. 01:09:59<@Bertl> which means? 01:10:05< pflanze> the old stuff did the fd 0/1/2 redirect (0 to dev null, 1,2 to /tmp/somelog) 01:10:29<@Bertl> hmm, then you changed contexts? 01:10:35< pflanze> and now today I did comment out the new stuff (which was just an exec chroot ..) above, 01:10:55< pflanze> which made the old fd redirect stuff active again. 01:11:07< pflanze> "And it didn't segfault anymore" "and the client kept running". 01:11:11< pflanze> BUT: 01:11:29< pflanze> I did comment out one line too much, the one that built the command to be executed. 01:11:35< pflanze> So the chroot just failed. 01:11:42< pflanze> And vshelper essentially did nothing. 01:11:46< pflanze> Which prevented the segfault. 01:11:51< pflanze> And "left the client running" 01:12:07< pflanze> Which it always did when vshelper was disabled. 01:12:38< pflanze> I enabled the correct exec chroot command again, and segfault is back and client reboots again forever. 01:12:39< pflanze> So it was all just a fata morgana. 01:12:41<@Bertl> hmm, okay ... your system is probably broken somehow ... we just don't know how yet, maybe the compiler? maybe some libs? ... who knows ... 01:13:18< pflanze> Well, I'm not sure if the vps segfaults are important at all 01:13:28<@Bertl> what about the strace? did stracinf the vps with -fF -o x.log fail= 01:13:33<@Bertl> ? 01:14:02>> mode/#vserver [-o Bertl] by Bertl 01:14:10< pflanze> No, works, *if* the ctx is 1 (else it won't follow), 01:14:22< pflanze> but also prevents the segfault from happening 01:14:38< Bertl> hmm, but chcontext --ctx 1 vps segfaults? 01:14:56< pflanze> no 01:15:02< pflanze> runs through cleanly 01:15:10< pflanze> when run on the cmdline 01:15:15< Bertl> within the script of course ... 01:15:20< pflanze> should I put the chcontext into the wrapper 01:15:23< pflanze> moment 01:15:31< shuri> Bertl 01:15:36< Bertl> hi shuri! 01:15:41< shuri> 19:30:16 up 2 days, 1:23, 1 user, load average: 0.16, 0.04, 0.01 01:15:45< shuri> with exp14 01:15:52< shuri> but got strange msg en dmsg 01:15:57< shuri> !!! dentry:c53d4080 »virtual« 01:15:58< shuri> !!! dentry:c53d4080 »virtual« 01:15:58< shuri> !!! dentry:c53d4080 »virtual« 01:16:01< Bertl> great! ... means I have to upload a new release ;) 01:16:02< shuri> a lot of this. 01:16:12< Bertl> yeah, that is fine ... 01:16:15< shuri> ok 01:16:22< shuri> so is work fine 01:16:27< Bertl> it actually means that something is accessing /proc/virtual 01:16:32< shuri> no more crash 01:16:34< shuri> good 01:16:45< shuri> i run it on production 01:16:49< Bertl> great! 01:17:04< shuri> it wil lbe your fault 01:17:09< shuri> if the server crash!! 01:17:10< shuri> :P 01:17:12< Bertl> I'll upload pre15 soon, and after that I plan to release 1.9.0 01:17:27< shuri> good 01:17:41< Bertl> pflanze: if the segfault happens with chcontext --ctx 1 too, then try with 01:17:58< Bertl> chcontext --ctx 1 strace -fF -o x.log vps 01:18:27>> rs [~rs@rs.admin.rhapsodyk.net] has joined #vserver 01:18:31< rs> re 01:18:38< Bertl> if this doesn't fail, something really weird is going on, if it fails, enrico might be able to draw some conclusions from the output 01:18:52< Bertl> aloha rs! 01:18:59< rs> yo Bertl :) 01:19:09< Bertl> will be back later ... 01:19:09< rs> wazap ? 01:19:15>> Bertl is now known as Bertl_oO 01:19:38< rs> ok cu 01:20:22< pflanze> Ok, with this in the wrapper: 01:20:24< pflanze> chcontext --ctx 1 strace -o `tempfile --prefix=myvps_` /opt/vserver/sbin/vps_ "$@" 01:20:34< pflanze> I get: 01:20:39< pflanze> - no segfaults 01:20:57< pflanze> - vps runs through cleanly, I see ~80kb strace files 01:21:25< pflanze> - but gentoo client still reboots 01:21:56< pflanze> (going to try with -fF ) 01:24:51< pflanze> (well same thing, bigger straces containing ps trace of course) 01:27:02< pflanze> One note: the vshelper.log output is different with the nonsegfaulting vps (with the strace in the wrapper): 01:27:17< pflanze> it prints: 01:27:21< pflanze> No responsible vserver found for resonsible xid '49178' (49178); aborting... 01:27:32< pflanze> during the restart. 01:28:00< pflanze> ooooh 01:28:01< pflanze> /opt/vserver/sbin/vps: line 14: chcontext: command not found 01:28:06< pflanze> hrm 01:40:19< pflanze> Ok, 01:40:38< pflanze> finally got straces from vps_ when called from vshelper: 01:40:42< pflanze> write(1, "? Z 0:00 [ls] write(1, "\n", 1) = 1 01:40:42< pflanze> SYS_273(0x2e010000, 0x5012, 0, 0x5012, 0x40001cff) = -1 ESRCH (No such process) 01:40:42< pflanze> write(1, "20498 ", 6) = 6 01:40:42< pflanze> write(1, "4294967295", 10) = 10 01:40:43< pflanze> write(1, " ", 1) = 1 01:40:44< pflanze> write(1, " ", 14) = 14 01:40:46< pflanze> write(1, "? R 0:00 ps ax", 26) = 26 01:40:52< pflanze> write(1, "\n", 1) = 1 01:40:54< pflanze> wait4(20498, 0xbffff5e4, 0, NULL) = -1 ECHILD (No child processes) 01:40:56< pflanze> SYS_273(0x2e010000, 0, 0, 0, 0x804a9a6) = 1 01:40:58< pflanze> --- SIGSEGV (Segmentation fault) @ 0 (0) --- 01:41:00< pflanze> +++ killed by SIGSEGV (core dumped) +++ 01:43:38< pflanze> ensc: hope that helps a bit. 01:44:25< pflanze> If you can tell me how to automatically run a program under gdb and get a backtrace and store it, I'll do it. 01:44:45< pflanze> (that's what Bertl_oO suggested) 01:50:04>> Napalm [~napalm@host81-7-22-112.adsl.v21.co.uk] has joined #vserver 01:50:18< Napalm> lo everyone 02:00:23< Napalm> no one arounmd? 02:01:27< ensc> ok, I can reproduce it 02:01:33< ensc> ... and it hangs my machine 02:04:12>> Bertl_oO is now known as Bertl 02:04:21< Bertl> hmm, what hangs you machine? 02:04:33< Bertl> s/you/your/ 02:05:16< ensc> it is dead; no mouse, no net, no keyboard 02:05:29< ensc> and no logmessage 02:05:38< Bertl> hmm, after what exactly? 02:05:47< ensc> reproduced twice when starting a gentoo vserver 02:05:59< ensc> (and this vshelper calls) 02:06:01< Bertl> spinlock debugging enabled? 02:06:19< ensc> no 02:06:23< ensc> it's a 2.4.26 kernel 02:06:37< ensc> it is my usual workstation 02:06:54< Bertl> hmm, okay ... I'll investigate it tomorrow ... 02:07:04< Bertl> try to get a stackdump of the processes ... 02:07:08< Bertl> with the sysreq-T 02:07:20< rs> ensc: I got some problem with plain init option and redhat, do you know that issue ? 02:07:25< Bertl> I'm off to bed now ... 02:07:31>> Bertl is now known as Bertl_zZ 02:07:38< rs> good night Bertl_zZ 02:07:42< ensc> Bertl_zZ: sysreq is not working 02:08:04< ensc> rs: which issue? 02:08:14< rs> hmm 02:08:39< rs> redhat doesn't start correctly 02:08:52< rs> but some process are still there 02:09:22< rs> so the vserver-stat command show the context but not the name 02:09:38< ensc> I know, I would not recommend 'plain' for rh style vservers 02:09:42< rs> and you can stop the vserver because the vserver command tell you that it's not running 02:09:59< ensc> vkill will help 02:10:00< rs> but when you are trying to start it, it tell you that it's already running :) 02:10:13< ensc> or are the processes in Z state? 02:10:19< rs> what kind of init is recommanded ? 02:10:29< rs> some process are in D stat :) 02:10:34< rs> getty and init for instance 02:11:05< rs> and init seems to not be the faster of other process if I remember correctly 02:11:29< rs> so I disabled the plain init option 02:11:35< Napalm> brb 02:11:52< ensc> for rh, I would use the ordinary 'sysv' style. Else, for my vserver I am using minit 02:11:53>> Napalm is now known as Napalm_oO 02:11:56< rs> but it was for testing vshelper stuff, and I can understand how it's working BTW :) 02:12:15< rs> if I try to restart within a vserver, it just shutdown 02:12:33< rs> fakeinit will work with rh ? 02:13:18< ensc> rs: enable logging to see what happens 02:13:40< rs> how ? 02:13:47< rs> I tried to make a symlink 02:13:55< rs> but no file was created 02:14:30< ensc> the file must be created manually 02:14:36< rs> ok 02:16:31< rs> btw sysv will work well with other distrib ? 02:16:44< rs> what are drawbacks ? 02:17:24< ensc> it works with debian 02:17:35< ensc> pflanze: segfault seems to happen in fork() 02:18:04< pflanze> do you fork after wait? 02:18:26< ensc> pflanze: no, fork() is one of the first actions 02:18:46< ensc> (after I switched to xid 1) 02:18:47< pflanze> But the strace shows that it's parsing ps output? 02:19:00< pflanze> or am I wrong? looking again.. 02:20:03< ensc> mmh... true. 02:20:27< rs> ensc: I created the file, but it remain empty :) 02:22:15< ensc> rs: is /sbin/vshelper pointing to the vshelper? 02:22:38< rs> no but I changed the proc setup 02:23:21< rs> ~# cat /proc/sys/kernel/vshelper 02:23:21< rs> /usr/lib/util-vserver/vshelper 02:23:54< ensc> and /etc/vservers/.defaults/apps/vshelper/logfile is pointing to an existing file? 02:24:12< rs> default ? 02:24:25< rs> I only did it in the vserver conf 02:24:49< rs> as the flower page says :) 02:25:04< rs> I try the .default way 02:26:38< rs> almost the same 02:26:52< ensc> oh... flowerpage is wrong. vshelper logfile can not be configured on a per-vserver base 02:27:38< rs> oups sorry 02:27:48< rs> it's ok with .default 02:28:07< rs> ok so the configuration.xml should be fixed 02:28:26< rs> do you want me to co-maintain this file ? 02:29:03< rs> ok so now it log when I do a vserver ... restart 02:29:27< rs> but a reboot inside a vserver don't send nothing to this file 02:29:43< rs> s/don't// 02:30:36< ensc> rs: I would like to get fixes and enhancements for this file 02:31:20< rs> you prefere that I send you patches ? 02:31:50< pflanze> (I don't understand: echo -n > /etc/vserver/scrat/fstab; added all mounts to /etc/fstab; mount -a; vserver scrat start -> does not work anymore) 02:32:12< pflanze> (And I've checked with ls and df from the host a hundred times that all mounts worked) 02:32:21< ensc> yes, patches are easier to apply since I make changes also 02:32:53< rs> so no ideas for vshelper ? 02:33:04>> gilbert [~gilbert@208-186-222-203.nrp4.brv.mn.frontiernet.net] has joined #vserver 02:33:15< ensc> rs: you are using the paths suggested by the rpm? 02:33:23< rs> rpm ? 02:33:28< ensc> the spec-file 02:33:30< rs> it's a debian 02:33:45< ensc> when you build it with 'rpm-build -ta ...tar.bz2' 02:33:55< ensc> e.g. cfg under /etc/vservers 02:34:21< rs> I didn't use any build utils for building this vserver 02:34:43< rs> I used jvds images and a by hand config 02:35:16< rs> is there something I missed ? 02:36:20< ensc> rs: try to execute 'vshelper restart' manually 02:36:33< ensc> where xid is the xid of an existing vserver 02:38:05< rs> bvdsn01:~# /usr/lib/util-vserver/vshelper 15 restart 02:38:05< rs> Sat May 8 00:36:33 UTC 2004: vshelper 15 restart 02:38:05< rs> No responsible vserver found for resonsible xid 'restart' (restart); aborting... 02:38:21< kestrel> ensc: is there some doco on getting minit and vshelper working? 02:41:30< rs> what is the main advantage using minit ? 02:42:38< kestrel> from what i can glean, you don't need to use minit anymore... 02:43:15< ensc> kestrel: it's similarly to the 'plain' initstyle; either use it directly and create /etc/vservers/.../apps/init/cmd.start with '/sbin/minit'. Or use the 'minit' style which expects /sbin/minit-start in the vserver 02:43:46< rs> the cmd.start file is mandatory ? 02:44:05< kestrel> aah, okay 02:44:10< ensc> rs: I love the automatic restarting of services, there is not bloat which tries to initialzie hardware and it is fast and small 02:44:36< ensc> rs: you could rename /sbin/minit to /sbin/init also 02:45:05< rs> I will try it 02:45:13< rs> whould work with rh and debian ? 02:45:56< kestrel> when i change my cmd.start to "/sbin/init" i get this: Usage: init 0123456SsQqAaBbCcUu 02:46:25< rs> I don't know what to put in cmd.start, the doc isn't really clear about that 02:46:43< pflanze> kestrel: the normal /sbin/init needs an "--init" argument to act as such. Or be pid 1. 02:46:47< rs> if this file doesn't exist, the vshelper stuff wont work ? 02:46:52< kestrel> aah, thanks pflanze 02:47:00< kestrel> rs: i have this: 02:47:03< kestrel> /sbin/init 02:47:05< kestrel> --init 02:47:27< pflanze> kestrel: being pid 1 is said to be better -> fakeinit stuff which has been implemented in the vserver kernel. 02:47:27< rs> shouldn't be the default value if the file is missing ? 02:47:35< kestrel> wow, it worked! 02:47:47< kestrel> pflanze: okay, how do i enable that? 02:47:55< kestrel> or is that not actually implemented yet 02:47:57< pflanze> kestrel: "plain" init style. 02:48:09< ensc> kestrel: when using 'plain' as initstyle, the 'fakeinit' flag should be set automatically 02:48:39< kestrel> ah, hmm...i ended up with two init processes: 02:48:39< kestrel> [root@build:/]ps -ef 02:48:39< kestrel> UID PID PPID C STIME TTY TIME CMD 02:48:39< kestrel> root 1 0 10 10:47 ? 00:00:05 init [4] 02:48:39< kestrel> root 27264 27219 0 22:41 ? 00:00:00 init [3] 02:48:40< pflanze> But be aware that it can fail miserably.. 02:48:40< kestrel> root 27329 1 0 22:41 ? 00:00:00 /usr/sbin/syslogd 02:48:53< kestrel> okay 02:49:13< pflanze> at least in my gentoo case. 02:49:21< kestrel> how so? 02:49:29< kestrel> i had pain getting gentoo working 02:49:36< kestrel> it has infinite loops in its init scripts 02:49:40< kestrel> and halt.sh as well 02:49:41< pflanze> Somehow gentoo immediately restarts just after startup. 02:49:49< kestrel> hmm, odd 02:49:56< rs> doesn't work better with the cmd.start file :) 02:49:57< pflanze> So it loops once every 8 seconds. 02:50:21< pflanze> And I still have no clue as to why. 02:50:28< rs> kestrel: which kernel patch version are you using ? 02:51:26< kestrel> wow! 02:51:31< kestrel> it all just worked! :) 02:51:40< kestrel> Linux cavern 2.4.26-vs1.3.9 #18 Fri May 7 22:30:16 EST 2004 i686 unknown unknown GNU/Linux 02:51:54< rs> ok 02:51:54< kestrel> util-vserver-0.29.211 02:52:03< kestrel> rs: i did this: 02:52:12< kestrel> put /sbin/init 02:52:13< kestrel> --init 02:52:18< kestrel> (two seperate lines) 02:52:49< kestrel> in ./apps/init/cmd.start 02:52:57< rs> me too 02:53:03< rs> but I use the exp patch 02:53:04< kestrel> echo plain > apps/init/style 02:53:07< kestrel> ah 02:53:14< rs> maybe it's related 02:53:19< ensc> pflanze: I have an idea... can you remove the 'NORETURN' from lib_internal/util-exitlikeprocess.h? 02:54:24< pflanze> ensc: hm currently I can't test it anymore because it won't start up at all anymore. 02:54:32< pflanze> Because of this mount issue. 02:54:45< pflanze> "whatever I did, it's wrong now.." 02:55:38 * pflanze changing again for vserver fstab 02:55:44< kestrel> mmm, after i did a shutdown inside the vserver, i can no longer start the vserver. it dies with this: chcontext: vc_new_s_context(): Operation not permitted 02:57:13< pflanze> kestrel: if you use plain init style, the cmd.start is not needed 02:57:22< kestrel> ah 02:57:31< kestrel> nor cmd.stop i assume? 02:57:38< pflanze> right 02:57:49< pflanze> at least I have neither 02:57:54< kestrel> so am i going to have to reboot to clear this out? 02:57:59< kestrel> clear that error, rather 02:58:16< pflanze> probably not 02:58:20< kestrel> i quite like the new vserver-utils, thanks ensc :) 02:58:37< kestrel> it is still giving me that error even after removal of cmd.* 02:59:02< pflanze> no idea - are you root and on the host? 02:59:19< kestrel> yep 02:59:33>> gilbert [~gilbert@208-186-222-203.nrp4.brv.mn.frontiernet.net] has quit [Quit: ] 02:59:38< pflanze> maybe vps aux|less to see if something's hanging around? 02:59:59< kestrel> nope, nothing 03:00:05< kestrel> vserver-stat only shows ctx 0 03:00:06< kestrel> odd 03:01:03< pflanze> something like chcontext --ctx 1234 sh -c 'cat /proc/self/status' does not work anymore? 03:01:26< pflanze> well maybe you are on 2.6? 03:02:18< kestrel> hmm, no, that does actually work 03:02:20< kestrel> i am on 2.4.26 03:02:26 * pflanze too 03:03:30< kestrel> /usr/sbin/chbind --silent --ip 10.1.1.18/21 /usr/lib/util-vserver/exec-ulimit /etc/vservers/build/ulimits /usr/lib/util-vserver/chcontext-compat --silent --cap CAP_SYS_BOOT --secure --ctx 2 --hostname build.swapoff.org --domainname swapoff.org --disconnect --flag fakeinit /usr/lib/util-vserver/save_ctxinfo /etc/vservers/build /usr/lib/util-vserver/clearenv /usr/lib/util-vserver/chain-echo /tmp/vserver-start.abTlQN '' /usr/lib/util-vserver/capc 03:03:34< kestrel> that is the command that is failing 03:04:30< pflanze> no idea 03:06:22< Napalm_oO> sorry dudes 03:06:39< Napalm_oO> im off, ive smoked a joint and had a drink 03:06:52< Napalm_oO> my head is going round, so im ogg ti watch a film 03:07:14< Napalm_oO> byeee 03:07:26>> Napalm_oO [~napalm@host81-7-22-112.adsl.v21.co.uk] has quit [Quit: ] 03:09:05< kestrel> looks like it is exec-ulimit doing it 03:10:22< kestrel> reboot, i think 03:10:23>> kestrel [athomas@38.6.233.220.exetel.com.au] has quit [Quit: brb] 03:20:10< pflanze> ensc: looks like that was it! 03:20:27< pflanze> no NORETURN no segfault 03:21:41< pflanze> you played a bit too much with that shiny noreturn, did you? :) 03:24:31< rs> good night dudes 03:24:36>> rs [~rs@rs.admin.rhapsodyk.net] has quit [Quit: leaving] 03:26:55>> kestrel [athomas@38.6.233.220.exetel.com.au] has joined #vserver 03:27:04< kestrel> well 03:27:17< kestrel> it turns out that if i do a 'vserver build stop', i get that error from then on 03:27:33< kestrel> and i can't seem to shake it without a reboot 03:29:01< pflanze> strange 03:29:25< pflanze> also using 0.29.211 here, and I did many vserver foo stop for sure 03:29:41< kestrel> hmmm 03:29:56< kestrel> when i do a shutdown inside the vserver, init keeps running 03:30:08< kestrel> you using the stock kernel? 03:30:35< kestrel> hey, can i get a copy of one of your vserver config "tree's"? 03:32:32< ensc> kestrel: are there 'Z' processes? 03:32:42< ensc> or does 'vkill --xid ... -s 9' work? 03:33:18< kestrel> i'll just start it again 03:34:04< kestrel> strangely, when i do this: 03:34:28< kestrel> vserver build enter 03:34:29< kestrel> # shutdown -h now 03:34:29< kestrel> it drops me out, but then actually kills my current shell too, dropping me back from my su - 03:35:09< kestrel> after the shutdown, this is what i have: 03:35:10< kestrel> 4 S root 890 2 build 1 0 68 0 - 122 do_sel 11:33 ? 00:00:00 init [0] 03:36:03< kestrel> aftare a -s 9, it disappears 03:36:34< kestrel> but vserver-stat still shows the vserver as active 03:37:35< ensc> it would be interesting to know, with which parameters the 'vshelper' was invoked 03:38:34< kestrel> how can i determine that? 03:39:32< kestrel> so now i have done a 'vserver build stop' 03:39:33< ensc> ln -s /var/log/vshelper /etc/vservers/.defaults/apps/vshelper/logfile 03:39:36< ensc> touch /etc/vservers/.defaults/apps/vshelper/logfile 03:39:43< kestrel> which responds with this: vkill: vc_ctx_kill(): No such process 03:39:54< kestrel> okay, i will do that 03:40:37< kestrel> unfortunately, i will have to reboot to accomplish try again :\ 03:40:54< kestrel> s/accomplish// 03:41:00< ensc> why? just use another xid and remove /var/run/vservers/build 03:41:18< kestrel> hmm, good thinking! :) 03:41:57< kestrel> Sat May 8 11:41:44 EST 2004: vshelper restart2 3 03:42:01< kestrel> that was on boot 03:42:33< ensc> ok, restart2 is uninteresting 03:42:37< kestrel> nothing when i do a shutdown from within the vserver 03:42:57< kestrel> should there not be something when i issue a shutdown? 03:43:41< kestrel> and nothing when i do a vserver stop 03:43:44< kestrel> odd 03:43:45< ensc> yes; but I do not know, if 'shutdown' is the right tool 03:43:56< ensc> 'reboot -f' might be better 03:43:56< kestrel> oh 03:44:00< kestrel> okay 03:44:10< ensc> (or 'halt -f') 03:44:21< pflanze> Well, reboot without -f does work with "plain" init style, right? 03:44:35< ensc> it should 03:44:48< kestrel> ah, this is a bit more interesting 03:44:50< kestrel> Sat May 8 11:44:15 EST 2004: vshelper restart2 4 03:44:51< kestrel> Sat May 8 11:44:30 EST 2004: vshelper restart 4 03:44:51< kestrel> Restarting vserver '/etc/vservers/build' 03:44:51< kestrel> Sat May 8 11:44:30 EST 2004: vshelper restart2 4 03:44:51< kestrel> -d option is not supported under Linux. 03:44:53< pflanze> It also does iirc (not trie for long) 03:45:00< ensc> but it calls all the hardware related initscripts 03:45:05< kestrel> and it seems to have actually killed the vserver correctly 03:45:29< kestrel> so i shouldn't be using shutdown then? 03:45:48< ensc> you have to figure out, what this program is doing... 03:45:54< kestrel> indeed 03:45:57< kestrel> very odd 03:46:01< ensc> in any case, it has to call reboot(2) finally 03:46:48< kestrel> yeah 03:47:21< kestrel> well, it's good that it's working now 03:47:31< kestrel> aaagh 03:47:34< ensc> pflanze: the NORETURN seems to be it; but I can not test it further, since I get hard lockups 03:47:43< kestrel> except i still can't start a vserver with the same xid 03:47:46< ensc> will release .213 soon 03:48:01< ensc> kestrel: there are hanging processes 03:48:31< ensc> with gentoo I see lot of 'Z' processes which do not disappear 03:48:34< kestrel> okay 03:49:05< kestrel> i don't have any processes in Z state though 03:49:08 * kestrel shrugs 03:49:34< pflanze> I do strace of /sbin/init in the gentoo client. writes a nice log, but just stops in the middle. Ah: and yes it triggered a reboot?? 03:49:36< pflanze> reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0 03:51:17< pflanze> why the hell would an init program call reboot right at the beginning, and then go on starting services for ages until it is interrupted by the vserver tools? 03:51:32< pflanze> s/call reboot/call reboot(2)/ 03:52:42< ensc> pflanze: this reboot is doing LINUX_REBOOT_CMD_CAD_OFF which is for setting up the keyboard 03:53:01< ensc> LINUX_REBOOT_CMD_CAD_OFF 03:53:01< ensc> (RB_DISABLE_CAD, 0). CAD is disabled. This means that the CAD 03:53:01< ensc> keystroke will cause a SIGINT signal to be sent to init (process 03:53:01< ensc> 1), whereupon this process may decide upon a proper action 03:53:01< ensc> (maybe: kill all processes, sync, reboot). 03:53:22< pflanze> ah 03:53:47< pflanze> ok but why is it then ripped off, by vserver as it seems? 03:53:58< pflanze> there's only one reboot() call in the strace 03:54:14< ensc> this command is translated to the 'restart2', which is ignored by vshelper 03:57:08< pflanze> This is the vshelper log: 03:57:09< pflanze> Sat May 8 03:56:05 CEST 2004: vshelper restart2 49187 03:57:09< pflanze> Sat May 8 03:56:07 CEST 2004: vshelper restart 49187 03:57:09< pflanze> Restarting vserver '/opt/vserver/etc/vservers/scrat' 03:57:09< pflanze> Sat May 8 03:56:07 CEST 2004: vshelper restart2 49187 03:57:09< pflanze> exitLikeProcess(): No child processes 03:57:10< pflanze> Can't ignore signal CHLD, forcing to default. 03:57:13< pflanze> Sat May 8 03:56:12 CEST 2004: vshelper restart2 49188 03:57:47< pflanze> (hey btw note the exitLikeProcess :)) 03:59:32< pflanze> Somehow vshelper got triggered (03:56:07 CEST 2004: vshelper restart) 04:00:12< pflanze> (Maybe it's so quick that my strace command is terminated before it can write down the rest of the strace?) 04:00:32< ensc> pflanze: yes, there is something wrong... I can not see, why 'wait()' fails there 04:02:31< pflanze> (Well I don't mind if vps is wrong in this point, if gentoo doesn't trigger the vshelper for unknown reason :) ) 04:05:01< ensc> I guess it will be triggered because 'init' fails 04:06:28< ensc> the bad thing are the hard lockups with the 1.27 patch 04:16:10>> sladen [paul@80.1.73.116] has quit [Ping timeout: 480 seconds] 04:21:41< kestrel> it is /usr/lib/util-vserver/exec-ulimit returning 'chcontext: vc_new_s_context(): Operation not permitted' 04:22:28< ensc> kestrel: no, this message is coming from 'chcontext' 04:22:41< ensc> (or better chcontext-compat) 04:22:46< kestrel> chcontext works though... 04:22:58< kestrel> ah, okay 04:23:01< kestrel> i understand 04:24:04< kestrel> chcontext-compat works, except when i have the fakeinit flag 04:24:13< kestrel> [root@cavern:~]/usr/lib/util-vserver/chcontext-compat --silent --cap CAP_SYS_BOOT --secure --ctx 4 --hostname build --domainname swapoff.org --disconnect uptime 04:24:13< kestrel> 12:23:39 up 39 min, 2 users, load average: 0.06, 0.06, 0.01 04:24:17< kestrel> [root@cavern:~]/usr/lib/util-vserver/chcontext-compat --silent --cap CAP_SYS_BOOT --secure --ctx 4 --hostname build --domainname swapoff.org --disconnect --flag fakeinit uptime 04:24:18< kestrel> chcontext: vc_new_s_context(): Operation not permitted 04:24:42< kestrel> should i just give up and wait for a new release? :) 04:24:46< kestrel> or is there hope? 04:26:15< pflanze> good night 04:26:23>> pflanze is now known as pflasleep 04:27:08< ensc> # /usr/lib/util-vserver/chcontext-compat --silent --cap CAP_SYS_BOOT --secure --ctx 4 --hostname build --domainname swapoff.org --disconnect --flag fakeinit uptime 04:27:11< ensc> 04:26:50 up 1:07, 14 users, load average: 0.20, 0.82, 0.86 04:28:38< ensc> what gives: /usr/lib/util-vserver/chcontext-compat --silent --cap CAP_SYS_BOOT --secure --ctx 4 --hostname build --domainname swapoff.org --disconnect cat /proc/self/status | grep Cap 04:29:58< kestrel> CapInh: 0000000000000000 04:29:58< kestrel> CapPrm: 00000000d44c04ff 04:29:58< kestrel> CapEff: 00000000d44c04ff 04:29:58< kestrel> CapBset: 00000000d44c04ff 04:30:06< ensc> is ok 04:30:08< kestrel> see you later pflanze 04:30:46< kestrel> weird...? 04:31:16< ensc> and '... | grep ctxflags' ? 04:31:40< kestrel> ctxflags: 16 04:32:21< ensc> this is it. somehow, the 'PRIVATE' flag is set which prohibits entering a context 04:32:36< ensc> no.. wrong 04:32:50< ensc> private is 8. the 16 is fakeinit which is correct 04:33:19< ensc> probably you try to enter a context with '--fakeinit' which has already a fakeinit process 04:33:20< kestrel> so even though i don't specify fakeinit on the command line, it is already set? 04:33:44< ensc> there are probably processes in this context, right? 04:33:52< kestrel> vserver-stat does not show any other contexts other than 0 04:33:59< kestrel> i can't see any 04:34:15< kestrel> [root@cavern:~]vserver-stat 04:34:16< kestrel> CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 04:34:16< kestrel> 0 144 2.1G 183.7K 1m27s26 0m17s45 1h10m56 root server 04:34:16< kestrel> [root@cavern:~] 04:34:50< kestrel> vps -ef | grep build shows no processes 04:49:34< Medivh> hi ;) 04:51:29< Medivh> been wondering about one thing - what is the maximum number of ips one vserver can have? 05:07:40>> click [click@gonnamakeyou.com] has quit [Remote host closed the connection] 05:40:00>> ensc [~ircensc@ultra.csn.tu-chemnitz.de] has quit [Ping timeout: 480 seconds] 08:14:30>> lexo_ is now known as franck 08:39:15>> mhepp [~mhepp@213.211.38.107] has joined #vserver 08:51:24>> id_ill is now known as _id_bessa 09:01:10>> serving [~serving@213.186.191.61] has quit [Read error: Connection reset by peer] 09:20:06>> _id_bessa [~id@pD9E614D3.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 09:31:40>> _id_bessa [~id@217.81.158.198] has joined #vserver 10:32:09>> mids [mids@mids.student.utwente.nl] has quit [Quit: Lost terminal] 10:57:11>> serving [~serving@213.186.191.61] has joined #vserver 11:11:31>> Doener` [~doener@pD9E12B5C.dip.t-dialin.net] has joined #vserver 11:18:20>> Doener [~doener@p5082D993.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 11:21:19>> _id_bessa is now known as _id 11:21:28< _id> re 12:05:15>> click [click@gonnamakeyou.com] has joined #vserver 12:11:59>> hiaslboy_oO is now known as hiaslboy_weekEND 12:53:21>> UFOczek [ufoczek@hood.openbug.net] has quit [Remote host closed the connection] 12:53:27>> grzegbor [grzegbor@orion.black.pl] has quit [Remote host closed the connection] 12:54:08>> mhepp [~mhepp@213.211.38.107] has quit [Remote host closed the connection] 13:45:02>> UFOczek [ufoczek@hood.openbug.net] has joined #vserver 13:57:21>> Napalm [~napalm@81.7.22.112] has joined #vserver 13:57:35< Napalm> anyone around? 13:57:52< albeiro> not really ;) 14:02:08< Napalm> hmm 14:02:23< Napalm> ive got webmin working on a vserver 14:02:24< Napalm> :) 14:15:38>> Napalm [~napalm@81.7.22.112] has quit [Quit: ] 14:15:39>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has joined #vserver 14:38:16>> monrad [~monrad@213.83.190.226] has joined #vserver 14:45:45>> UFOczek [ufoczek@hood.openbug.net] has quit [Ping timeout: 480 seconds] 15:06:42>> UFOczek [ufoczek@hood.openbug.net] has joined #vserver 15:22:45>> Bertl_zZ is now known as Bertl 15:22:49< Bertl> morning everyone! 15:23:09< UFOczek> morning Bertl ! 15:23:25< Bertl> hi UFOczek, how is life? 15:23:41< UFOczek> Bertl: not good, i'm waiting for 2.6.6 ;-) 15:24:06< Bertl> ah yes, and wolk and vserver ;) 15:24:12< UFOczek> yup;-) 15:25:20< Bertl> you could test the current rc3 version of vserver ... 15:25:34< UFOczek> i cant because i have a lot of production servers 15:25:35< Bertl> just to make sure vserver on 2.6.6 doesn't give any issues ;) 15:25:52< UFOczek> so i don't have any free boxes. 15:26:00>> monrad [~monrad@213.83.190.226] has quit [Remote host closed the connection] 15:26:11< Bertl> hmm, and you are going to 'test' wolk+vserver on a production machine? 15:26:17< UFOczek> yes. 15:26:21< UFOczek> just like I said :) 15:26:25< Bertl> customers will love you ;) 15:26:35< UFOczek> they do, already 15:27:02< Bertl> well, it's okay for me, I have no problems with that ... 15:28:11< UFOczek> now i'm using only 2.6.5 with wolk (without vserver).. 15:28:26< UFOczek> and that's why i'm not happy :-) 15:32:28< Bertl> Medivh: 15 or 16 depending on the tool version ... 15:33:23>> mlgd [~mlgd@194.149.164.113] has joined #vserver 15:33:31< Bertl> hi mlgd! 15:33:31< mlgd> Bertl : hello 15:34:05< mlgd> i don't find ctx patch for kernel 2.4.25 15:34:58< Bertl> stable? 15:35:10< Bertl> http://www.13thfloor.at/vserver/s_release/v1.27/ 15:35:36< Bertl> devel: 15:35:37< Bertl> http://www.13thfloor.at/vserver/d_release/v1.3.9/ 15:36:59< mlgd> ok, i'm testing it 15:37:16< mlgd> but i need 1 hour to compile my kernel for AMD K7 15:37:54< Bertl> hmm, sounds weird ... 15:38:15< mlgd> i have errors on patching 15:38:20< mlgd> 1 out of 1 hunk FAILED -- saving rejects to file include/net/ip.h.rej 15:38:27< mlgd> 1 out of 2 hunks FAILED -- saving rejects to file include/net/route.h.rej 15:38:29< Bertl> patching what? 15:38:36< UFOczek> looks like kernel source 15:38:40< mlgd> 1 out of 7 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej 15:38:52< Bertl> which kernel source do you patch? debian patched kernels? 15:39:09< mlgd> bertl : yes 15:39:23< Bertl> then I would not suggest to use the vanilla patches for that ;) 15:39:33< Doener`> mlgd: then go with the kernel-patch-ctx package ;) 15:39:58< Bertl> http://vserver.13thfloor.at/Stuff/Debian/ 15:40:16< mlgd> doener : it don't included patch for kernel 2.4.25 15:40:24< Bertl> here are the debain patches so far, but it seems that debian packages are up to date ... 15:40:50< Bertl> you can apply the http://vserver.13thfloor.at/Stuff/Debian/patch-2.4.25-1-vs1.26.diff for example plus the incremental to vs1.27 15:41:10< mlgd> ok i'm testing 15:41:11< Doener`> mlgd: any problems with 2.4.26? you could as well upgrade your kernel if you're doing a build anyway... 15:41:40< Bertl> would suggest that for security reasons anyway ;) 15:42:04< Bertl> oh I forgot, debian kernels do not have any security issues ;) 15:42:16< mlgd> also can i upgrade to kernel 2.6.x ? 15:42:22< Doener`> patch-2.4.25-vs1.27.diff.gz 15:42:31< Doener`> that's from the kernel-patch-ctx package... 15:43:04< mlgd> doener : i don't have patch-2.4.25-vs1.27.diff.gz in kernel-patch-ctx 15:43:18< Doener`> which branch? 15:43:47< Doener`> i've got kernel-patch-ctx 1:1.27-1 from sid... 15:43:50< mlgd> patch-2.4.23-vs1.21.diff.gz 15:44:09< mlgd> it's for 2.4.23 max 15:44:26< Doener`> you're on sarge, right? 15:44:53< mlgd> yes all right 15:45:09< mlgd> the patch on http://vserver.13thfloor.at/Stuff/Debian/ works fine 15:45:21< mlgd> no error when i apply it 15:45:42< mlgd> i launch compilation 15:46:10>> UFOczek [ufoczek@hood.openbug.net] has quit [Quit: brb.] 15:46:34< mlgd> thank's for the link 15:47:25 * Doener` hopes that 1.27 will make it into sarge before it's completly frozen... 15:47:46< mlgd> what's 'Virtual Root device support' ? 15:47:52>> pflasleep is now known as pflanze 15:48:15< pflanze> Good day 15:48:18< Bertl> morning chris! 15:48:31< Doener`> mlgd: a secure device to allow quota for a vserver on a separate partition 15:48:49< Bertl> couldn't explain it better ;) 15:48:53< Doener`> IIRC it 'tunnels' quota command to the real device 15:49:35< mlgd> if i use only 1 parition, i don't need that ? 15:50:01< Bertl> if you do not use quota inside a vserver, you do not need it ;) 15:50:15< mlgd> ok 15:50:32< Doener`> but if you want quota in the vservers on a shared partition you'll need extra patches 15:50:54< mlgd> let's go for 45 minutes of compilation 15:52:06< mlgd> it's done 15:52:09< Bertl> that's the debian kernel build time? 15:52:21< mlgd> it's strange 15:52:26< mlgd> only 3 minutes 15:52:43< Bertl> probably something went wrong ;) 15:53:55>> franck [~LeXo@lns-th2-4f-81-56-252-185.adsl.proxad.net] has quit [Ping timeout: 480 seconds] 15:58:10< pflanze> Question: does XFS or JFS support quotas that work with the ctx quota patch? 15:58:50< pflanze> Or are fast-directories-and-tailmerging now integrated into ext3? 15:59:31< pflanze> I've always used reiserfs for it's speed and efficiency with small files (read: maildir). 15:59:43< Bertl> xfs has a very confusing quota syste, and jfs doesn't have any idea of quota at all 16:00:00>> franck [~LeXo@81.56.252.185] has joined #vserver 16:00:02< Bertl> reiserfs has no quota support in the mainline ... 16:00:06< pflanze> yep 16:00:13< Bertl> which leaves vserver with quota for ext2/ext3 atm 16:00:14< pflanze> though patches are public 16:00:28< Bertl> any patches for 2.6.6-rc3? 16:00:38< pflanze> reiserfs quota you mean? dunno 16:00:48< pflanze> I've not used them yet 16:00:53< Bertl> I'd love to adapt the reiser quota system when I do the 2.6 quota stuff ... 16:01:16< Bertl> (haven't found any patches for 2.6 yet) 16:08:20>> lexo_ [~LeXo@lns-th2-4f-81-56-252-185.adsl.proxad.net] has joined #vserver 16:08:32< Bertl> hi lexo_? 16:14:55>> franck [~LeXo@81.56.252.185] has quit [Ping timeout: 480 seconds] 16:15:06< _id> re 16:15:13< Bertl> hi _id! 16:15:39< Bertl> I assume you followed the c-radio broadcast, right? 16:16:19< _id> nope - ? url 16:18:21< _id> Bertl, i was in the hosptial for 4 days 16:18:34< Bertl> hmm, why's that? 16:18:54< _id> magen-darm infekt :( 16:19:02< _id> stomach-something infect 16:19:04< Bertl> btw, they haven't added it to the archives yet ... 16:20:00< Bertl> stomach flu / abdominal influenza 16:20:22< _id> yes 16:21:00< Bertl> well, you can probably listen to that when they update their archives ... 16:21:12< _id> c-radio.com ? 16:21:21< Bertl> http://c-radar.ccc.de/ 16:21:35< _id> ccc chaos computer club -- hehe nice 16:22:51< _id> they have a huge archive - stuff for weeks 16:23:00< _id> thanx 4 the tip 16:23:10< Bertl> you're welcome 16:23:39< _id> all in german ? 16:23:45< Bertl> yep 16:24:49< _id> http://swpat.ffii.org/news/04/cons0507/ 16:34:20>> dionv [~dionv@masq-van7ant.skynet.ca] has joined #vserver 16:35:20< Bertl> hi dionv! 16:37:14< dionv> hi Bertl 16:38:59< JonB> Bertl: how was it i created an extra "netcard" the alias thing 16:39:27< Bertl> huh? please elaborate! 16:39:28>> lexo_ is now known as franck 16:39:55< JonB> Bertl: eth0:jon 16:40:13< JonB> Bertl: is it just ifconfig eth0:jon ? 16:40:17< JonB> no special stuff ? 16:40:39< Bertl> or with ip (from iptools 2) but yes, that simple ... 16:40:42< pflanze> Does using ctx quota allow to quickly determine the space taken by each vserver? 16:40:57< JonB> Bertl: tak 16:41:06< Bertl> pflanze: no, that is Context Diks Limits ... 16:41:16< pflanze> Ah? 16:41:39< pflanze> Is there a context disk limits patch for 1.3.8? 16:41:42< pflanze> 1.3.9 16:42:23< Bertl> http://www.13thfloor.at/vserver/d_addons/quota/ 16:42:36< Bertl> q0.14 should work ... if not let me know ... 16:42:54< pflanze> But what is ctx quota then ? 16:43:32< Bertl> simple, if you want user/group quota inside a vserver on a shared partition, then you are speaking of Per Context Quota 16:44:05< Bertl> if you want to account/limit a vserver's disk usage we speak of Context Disk Limits 16:44:27< pflanze> I *do* want to use a shared partition and vunify. And limit each vserver's total un-shared space. 16:44:54< Bertl> this is called Context Disk Limit ;) 16:44:58< pflanze> But I thought the extension of user quotas to user+ctx quotas would do just this? 16:45:23< pflanze> Well, the *sum* of ctx+{all users} would be what i need of course. 16:45:26>> mlgd [~mlgd@194.149.164.113] has quit [Ping timeout: 480 seconds] 16:45:37< Bertl> well, this was about .. hmm .. a year ago this way ... today it is somewhat improved ;) 16:47:03< pflanze> I'm still rather confused. Is there any (wiki) page I should read? 16:47:45< Bertl> unfortunately no, talon started to write a detailed howto, but it seems it was lost on the way somehow ... :( 16:48:02< Bertl> there is a basic setup explanation (outdated) in the 2.6 devel section ... 16:48:16< pflanze> Ok may I ask enough to write a wiki page? 16:48:25< Bertl> sure ... 16:48:31< pflanze> Ok: 16:48:44< Bertl> http://vserver.13thfloor.at/Linux2.6/index.php?page=Per+Context+Quota 16:48:48< pflanze> - does Context Disk Limit only work on ext2/3 as well? 16:48:55< Bertl> http://vserver.13thfloor.at/Linux2.6/index.php?page=Per+Context+Disk+Limits 16:49:40< Bertl> the disk limit _will_ work on all filesystems capable of (and prepared to) storing xid info per file 16:50:15< Bertl> the current (stable/devel) implementation requires the quota hashes to store the disk limits, so it is bound to ext2/ext3 16:51:20< Bertl> I have to reimplement the disk limit stuff for 2.6 anyway, so if there is somebody interested in testing it on other filesystems, I see no big problems there ... 16:51:49< pflanze> I'll try to summarize what "user disk quotas" tradiditionally do: 16:52:01< pflanze> and then how that extends to vservers 16:52:31< Bertl> okay ... 16:52:34< pflanze> user disk quota means, the total space of all files belonging to one user may not exceed some predefined value. 16:52:52< pflanze> (well, weak and hard limits, but leave that for later) 16:53:04< Bertl> roughly speaking, yes ... 16:53:05< pflanze> This is per filesystem. 16:53:12< Bertl> correct 16:53:21< pflanze> now for vservers: 16:53:30< pflanze> different vservers use the same user id's. 16:53:50< pflanze> So normal quotas of multiple vservers on same fs would not make sense. 16:54:06< pflanze> This is why the uid needs to be extended with ctxid. 16:54:28< pflanze> Which makes the "per-context quota" patch. 16:54:30< Bertl> that was the old idea ... it is obsoleted now for several reasons 16:54:38< pflanze> ah? 16:54:57< Bertl> mainly because of the way user quota 'actually' work ... 16:55:14< Bertl> the quota information and the accounting information is stored in some quota files 16:55:28< Bertl> actually one for each quota type (user/group) 16:56:07< pflanze> yep 16:56:08< Bertl> now those quota files are accessed not only by the kernel (unfortunately) but also by the much-too-smart quota tools 16:56:16< pflanze> yep 16:56:21< pflanze> (strange thing that) 16:56:32< Bertl> which meanst that they have to be available _inside_ a vserver too 16:56:45< pflanze> ah 16:56:46< Bertl> (if you do not want to have the Host admin to change the user quota ;) 16:57:05< pflanze> ic 16:57:12< Bertl> so I had to find a workaround ... and actually I found one 16:57:23< Bertl> the basic idea behind this is: 16:57:35< Bertl> - quota files are per superblock atm 16:58:17>> UFOczek [ufoczek@hood.openbug.net] has joined #vserver 16:58:18< Bertl> - the first step was to add something called quota hashes, which allowed to have an arbitrary number of quota hashes per superblock 16:58:30< UFOczek> re! :) 16:58:44< Bertl> - the next step was to allow for different quota files for each quota hash 16:59:17< Bertl> - and final, something to allow to send quota ioctls to the appropriate hash/kernel (the vroot device) 16:59:47< pflanze> ah that's the vroot device 16:59:56< Bertl> so todays quota solution requires one hash for each context _and_ filesystem 17:00:19< Bertl> (which has to be created with the cqhadd command 17:00:33< pflanze> one quota hash contains a set of uid=>sum_of_space mappings? 17:00:49< Bertl> the hash is identified by (fs,xid) 17:01:07< pflanze> yep, and contains?.. 17:01:16< pflanze> uid=>space and gid=> space? 17:01:17< Bertl> and it contains (uid,current,soft,hard) and (gid,current,soft,hard) tuples 17:01:23< pflanze> k 17:01:52< Bertl> in addition to that, each quota hash allows for storing 5 disk limit values 17:02:30< Bertl> current inode count/blocks, maximum inodes/blocks and reserved % 17:03:02< Bertl> this hasn't to be tied to the quota hash, but it was some kind of simplification 17:03:16< pflanze> (btw xid = context id, right? (why not vid?)) 17:04:15< Bertl> because a vserver actually consists of (xid,nid) 17:04:40< pflanze> what is the nid? 17:04:46< pflanze> network? 17:04:48< Bertl> the network context 17:04:52< pflanze> k 17:05:30< pflanze> does chbind store settings in a table which is referenced by nid's? 17:05:39< pflanze> instead of per-process storage? 17:06:11< Bertl> yes, all information is stored in a structure similar to the context (xid) which can also be looked up and joined ;) 17:06:39< Bertl> this will in future allow to manipulate the current network setup on the fly ... 17:06:56< pflanze> ah cool 17:07:20< pflanze> (hm, soon I'll write a book) 17:07:35< pflanze> :) 17:08:05< Bertl> you can extend that one: http://vserver.13thfloor.at/Stuff/PAPER-05.4.txt 17:08:10< pflanze> So the ctx quota patch implements the per xid hashes? 17:08:37< pflanze> and hooks for userspace tools to create quota files? 17:09:01< Bertl> the so called q0.14 patch consists of 4 patches 17:09:28< pflanze> k 17:09:50< Bertl> the first, actually splitting up the quota structures into quota hashes (allowing for more than one per superblock) without changing anything for the user 17:10:19< Bertl> the second, implementing the xid file tagging, which is required to tell the xid from a given file 17:10:40< pflanze> which needs ext2/3 17:10:45< pflanze> currently 17:10:47< Bertl> the third, which uses the quota hashes to implement per context quota (by looking at the xid) 17:11:00< Bertl> no, the second patch actually is almost fs agnostic ... 17:11:07< pflanze> ah k 17:11:24< Bertl> the first and the third one require ext2/ext3 atm 17:11:51< pflanze> k 17:11:52< Bertl> and the last one, which adds the context disk limits to the existing hash structure 17:12:09< Bertl> (could be done fs agnostic) 17:13:30< pflanze> (hm is q0.14 q version 0.14 or something like qu0ta one->four? prolly not right?) 17:13:58< Bertl> hehe, no it's just quota-version 0.14 ;) 17:14:03< pflanze> k 17:14:24< Bertl> http://www.13thfloor.at/vserver/d_addons/quota/ 17:14:39< Bertl> actually has q0.12-q0.14 17:15:15< pflanze> yep 17:16:11< pflanze> Now with the quota patch, it *would* be possible to know the total storage of each vserver, by adding all "current" entries in one hash, right? 17:17:06< Bertl> hmm, yes, given that the quota info is correct ... 17:17:35< Bertl> (requires quotacheck to be run first ;) 17:17:39< pflanze> yep 17:17:47< pflanze> of course 17:18:07< pflanze> So far that's it for quota. 17:18:17< pflanze> (right?) 17:18:24< pflanze> So where does the other patch come in? 17:18:31< Bertl> the disk limit one? 17:18:40< pflanze> yep. it will not need a check run first? 17:19:01< Bertl> well, it doesn't use the quota information at all ... 17:19:17< pflanze> yep 17:19:30< Bertl> it relies on what you tell it is the 'current' value, and note any changes ... 17:19:58< pflanze> ok, so you'd basically use "du" for a "check run" first 17:20:00< Bertl> further the values are used to 'virtualize' the values for df and friends 17:20:20< pflanze> ah cool 17:20:22< Bertl> du might not be the best choice, but basically yes 17:21:06< pflanze> How does it work? still needs to store the xid to each inode, right? 17:21:14< Bertl> to have the system working correctly, you need to account only files belonging to the given xid ... 17:21:50< pflanze> basically "one hash per filesystem"? 17:22:27< Bertl> it currently uses the xid stored with a file, but could also work without the xid tagging, as long as no other context (not even the host context) manipulates files belonging to a specific context 17:24:11< pflanze> ah, does each write operation use the current->xid information to know which total has to changed? 17:24:32< Bertl> as I said, it could, but currently it uses the xid of the file 17:24:42< pflanze> ok 17:25:09< pflanze> which patch adds the xid to files? 17:25:15< Bertl> that's why du isn't that smart to use, especially in a unified case ... 17:25:23< pflanze> yrp 17:25:24< pflanze> yep 17:25:29< Bertl> the second one ... called xid file tagging 17:25:53< pflanze> (of course :) 17:26:01< Bertl> this is already included in current 2.6 exp (1.9.0preX) 17:26:09< pflanze> So the disk limit patch needs the quota patch as well? 17:26:13< pflanze> ah 17:26:39< Bertl> currently yes, because it 'reuses' the quota hash to store it's 5 values ... but generally speaking no 17:29:43< pflanze> Hm, context disk limits are only experimental? 17:30:00< Bertl> no, they are in stable too ... 17:30:13< pflanze> already included in the main vserver patch? 17:30:22< Bertl> no, as Addon: http://www.13thfloor.at/vserver/s_addons/overview/ 17:33:10< pflanze> btw if you allow, some small criticism: I find the navigation on 13thfloor a bit confusing, maybe it's because of this 3 level mechanism 17:33:30< pflanze> and since links are not underlined they are not visible immediately 17:33:49< pflanze> well, some links are 17:35:17< Bertl> hmm ... you mean the 'tab' structure is to complicated? 17:35:32< pflanze> I always felt a little confused because of it 17:35:46< pflanze> because I lost the feeling to "how deep" the site is. 17:35:52< pflanze> maybe it's just subjective 17:36:09< Bertl> hmm, interesting, what alternative approach would you suggest? 17:36:38< pflanze> I think I would just have put the 3rd level into the navigatio at the left 17:37:07< pflanze> well I realize that the nav bar at the left is only one level 17:38:15< pflanze> I'm not sure yet. But especially the addon page is confusing since you don't know where to go next, until you realize the tabs on the right 17:38:42< pflanze> (combination of the tab approach and missing links over the list in the text) 17:39:55< Bertl> well, actually there are 3-4 levels, and putting them into the left menu would make it 10 pages long (probably) 17:40:26< Medivh> hi! 17:40:33< Bertl> and to be honest, I'm not a fan of auto expanding entries in a menu ... 17:40:42< Bertl> hi Medivh! 17:41:13< pflanze> Javascript no, but otherwise I like expanding menues (one particular expansion for each page) 17:41:28< Medivh> Bertl, I asked one question here this morning, but seemed as noone was around, maybe you can answer it? been wondering what the max number of IP addresses a vserver can have is? 17:41:33< _id> Bertl, can you give me please some instructions to bake a sane ctx+grsec kernel - is there a howto or something similar ? 17:41:34< pflanze> (I'll think a bit more in the future) 17:44:43< _id> i tried wolk4.14s but there are too many patches i dont need - like preemt scheduler and other strange stuff 17:44:58< pflanze> _id: it's relatively easy 17:45:04< pflanze> I did it myself 17:45:17< _id> vanilla or wolk ? 17:45:39< pflanze> needs some cleaning up of about 6-8 conflicting hunks though, so needs some C knowledge 17:45:49< pflanze> vanilla + grsec + vserver 17:45:56< pflanze> 2.4.XX that is 17:46:04< _id> 2.4.26 ? 17:46:08< pflanze> yep 17:46:33< _id> did you uploaded ther patched source somewhere ? 17:46:48< pflanze> no, but I could provide them now 17:47:05< pflanze> I've even made conflict resolution patches :) 17:47:14< Medivh> isn't there people providing grsec patches that work with vserver too? 17:47:23< _id> would be great if it is not too much work 4 you 17:47:46< pflanze> yep, there are links on the wiki iirc 17:48:12< Medivh> yep there are 17:48:18< pflanze> (but I generally don't trust patches from unknown source and do it myself :~) 17:48:27< Medivh> heheh ;) 17:48:53< _id> pflanze, i am no senior kernel hacker 17:49:10< _id> still in the process of learning 17:49:23< _id> how to do things proper 17:49:40< Bertl> Medivh: I answered you question when I came this morning ... 17:50:01< Medivh> Bertl, oh, you did? let me scroll back :) 17:50:04< Bertl> _id: no tips no howto, I don't use grsec ... 17:50:31< Medivh> ah, there ;) Bertl, thanks 17:51:49< Medivh> [15:32:06] Medivh: 15 or 16 depending on the tool version ... <--- "morning" ... finally someone who got the same understanding of morning as I do :P 17:53:49< _id> http://www.13thfloor.at/vserver/s_release/v1.27/patch-2.4.26-vs1.27.diff ? 17:54:41< Bertl> Medivh: it's always morning, when I get up ;) 17:54:52< Medivh> exactly! :) 17:55:25< Bertl> _id: hmm, is this a question? 17:55:52< pflanze> _id: http://pflanze.mine.nu/~chris/linux/patches/grsec+vserver/ 17:56:02< _id> ah thanx =) 17:56:35< pflanze> _id: these are not final patches, but to clean up the mess afterwards 17:56:50< pflanze> you first patch with grsec, then with vsXXX. 17:58:11< pflanze> Then you patch with grsec+vserver-cleanup_nur-rej-abergegendevnull.diff, then with grsec+vserver-cleanup_ohne-rej-extinction.diff 17:58:52< pflanze> This is my current "best" approach to not have to merge again manually upon each kernel/vs release 17:59:12< Bertl> hmm, so you 'accept' rejects on the vserver patch? 17:59:41< pflanze> I first just patch vs on top of grsec, which gives rejects. 17:59:52< pflanze> Then I remove the rejects with my first patch. 18:00:03< Bertl> I think this has a high inherent error potential ... 18:00:10< pflanze> Which cleans out those that are still identical, leaving those that are now different. 18:00:28< pflanze> The latter of which I check manually that they are still about the same. 18:00:46< pflanze> Then I apply my second patch which does the right stuff at the places of the vs rejects. 18:01:29< Bertl> consider that either the kernel or the grsec patch changes, and this results in another yet unhandled reject of the vserver patch, will you notice it? 18:01:53< pflanze> yep, my first patch will give rejects. 18:02:04< Bertl> why? 18:02:11< pflanze> Admittedly this step is a bit messy, since there are already rejects if the line numbering changes :(( 18:02:37< pflanze> Well, the vs rejects must match the rejects in my diff to be removed. 18:02:42< Bertl> hum, patching at a different line number doesn't give a reject (usually) 18:02:58< pflanze> yep, but patching away rejects is a different story: 18:03:09< pflanze> the rejects contain the line numbers as *text* and thus get different. 18:03:34< Bertl> okay, so your 'verification' is based on 'removing' the reject files, right? 18:03:38< pflanze> yes. 18:03:54< pflanze> Not just removing them, but "patching them away" 18:04:13< Bertl> I see, you should explain that, and include a special 'search for left over rejects' phase after the patching ... 18:04:26< pflanze> yep. 18:04:34< Bertl> (which will clearly indicate a change in one of the patches) 18:04:56< pflanze> _id: have you read the above? 18:05:34< _id> ok - i did 18:07:15< _id> but is the patch not for 2.4.25 ? 18:07:22< _id> instad of .26 18:09:16< pflanze> _id: yep it is -- that's just what they are for, they also work for 2.4.26 and future kernels :) 18:09:45< pflanze> " This is my current "best" approach to not have to merge again manually upon each kernel/vs release" 18:11:08< _id> d/l the .26 source of kernel.org 18:11:28< _id> ok 18:12:17< pflanze> ok there is now a "Readme!" file at my url, with excerpts of the above conversation. It includes statements from Bertl, Medivh, _id, and myself. 18:12:31< Bertl> ;) 18:13:00< Bertl> .o( with proper creadit to each of us? ) 18:13:06< Bertl> just joking! 18:13:17< pflanze> hope you agree with me publishing such irc log parts. 18:13:34< _id> fine thanx 18:14:06< Bertl> the entire channel is logged, and published, so no problem with that ... 18:14:13< pflanze> ah didn't know 18:14:27< _id> i guess the whole server gots logged 18:15:27< _id> - btw - is there a way to use ispell in irc sessions ;) ? 18:15:27< mcp> pflanze: you also fixed the problem that when grsec and vserver are patched together you can't disable grsec acl subsystem once it's enabeld? 18:15:47< pflanze> mcp: no, didn't know about that 18:15:52< mcp> I knew that 18:15:52< mcp> :p 18:15:56< Bertl> mcp: hehe ;) 18:16:19< mcp> moin Bertl 18:16:28< pflanze> Yes, be aware that I'm not using the ACL system. I do use most of the other stuff though. 18:16:34< Bertl> morning to you too, mcp! 18:16:35< _id> mcp, any chance to try wolk4.15s / i saw ur .config on wolk.sf.net/people 18:16:57< mcp> _id: I ripped vservers out from 4.15 because no one maintains it and it was the evil old ctx17 version 18:17:10< Bertl> mcp: is 2.6.6 in sight? 18:17:22< mcp> Bertl: dunno when linus is going to release it 18:17:22< _id> ok then i will surly try pflanze?s way 18:18:36< _id> mcp, I guess the 2.6 branch is not suitable for production ? 18:19:06< mcp> well, depends 18:19:49< mcp> but I won't use it for anything public yet (i.e. apache, mailserver or whatever has remote access) 18:20:01< mcp> you know that even 2.6.6-rc3 has one local remote root possiblity? ;) 18:20:05< mcp> oh shit 18:20:12 * mcp should just shut up ;) 18:20:13< Bertl> for security reasons, or for stability ones? 18:20:20< mcp> sec reasons 18:20:36< Medivh> mcp, I hope it's not in 2.4.26 too, then :P 18:20:38< mcp> its damn stable 18:20:39< eyck> oh shit.. 18:20:45< mcp> Medivh: nono, thats safe 18:20:50< Medivh> mcp, phew ;) 18:20:50< Bertl> hmm, 'local remote root possiblity' interesting term 18:20:56< mcp> errr 18:21:02< mcp> remove that remote 18:21:04< mcp> ;) 18:21:10 * mcp is not yet full awake 18:21:11< mcp> :) 18:21:18< Bertl> no coffee yet? 18:21:40 * pflanze thinks remote possibility for local root 18:21:44< mcp> I had coffee but it won'T help 18:21:57< Doener`> hmm... coffee... good idea! 18:22:03< mcp> brb, reboot 18:22:27< Medivh> find someone running a phpnuke vulnerable to remote command execution and running a vulnerable kernel and there goes the remote vulnerability ;) 18:23:22< Bertl> yep, find someone with strong passwords (like admin/admin) and you do not even require phpnuke ... 18:24:06< eyck> hmm, find a crowbar and you don't even need passwords.. 18:24:20< Bertl> right, you are! 18:24:24< eyck> oh my, we are SO elite blackhat crackers.. 18:24:55< Bertl> .oO( hmm, crackers ... good idea ;) 18:25:00< Medivh> yeah let's go hack some wikis :P~ 18:25:21< Bertl> was more thinking about something to eat ... but ... 18:25:33< eyck> .oO ( pizza ).. 18:25:49< eyck> oh man, talking on LUGs is so exhausting... 18:26:14< Medivh> eat ... good idea 18:26:19< Bertl> .oO( eyck: "linux is so damn cool! any questions?" ) 18:26:41< eyck> I knew there was some reason I didn't like the idea of staying at university 18:27:07< eyck> Bertl: hmm, this is not a very safe line here... we've got a very strong *BSD camp around here... 18:27:08< JonB> eyck: dropping out ? 18:27:28< eyck> JonB: nope, staying as in - stay and teach.. 18:27:36< JonB> eyck: ahh 18:27:48< JonB> eyck: why not stay and research ? 18:27:49< eyck> Bertl: with some 2 or 3 world-class hackers, ... 18:28:11< eyck> JonB: no such possibility, you stay == you teach. 18:28:16< JonB> eyck: what do you mean, bertl is not there, is he? 18:28:35< JonB> eyck: in denmark, at the university, it is 50% teach and 50% research 18:28:43< eyck> nope, Bertl is from Austria, I'm not. 18:28:55< eyck> JonB: exactly. you can't stay and not teach. 18:29:08>> _shuri_ [~shushushu@207.236.226.187] has joined #vserver 18:29:14< JonB> eyck: and you can be A VERY VERY lousy teacher, if you just produce some research, you can stay 18:29:45< eyck> JonB: besides, they don't pay very well ( ie good enough too feed you and your SO ), and I'm rather poor so I can't actually afford staying at the uni.. 18:29:59< JonB> eyck: okay 18:30:01< eyck> JonB: hmm, well, but still, ,you have to teach. You can't avoid it. 18:30:13< JonB> eyck: they dont research at all at your university? 18:31:15< eyck> JonB: of course they do. But you can't do research and avoid teaching. Besides, we've got strong reaserch only in few mathematical analysis fields, 18:31:32< pflanze> _id: if you go my route, read the Readme! file again, it's explained a bit better (at the end of it) now. 18:31:37< JonB> eyck: both are importent 18:31:59>> _shuri_ [~shushushu@207.236.226.187] has quit [Quit: ] 18:32:15< eyck> JonB: yup, but if I'm allergic to public speaking then it's not a very wise decision career=-wise ;) 18:32:55< JonB> eyck: irc is a public forum 18:33:18< JonB> FSCK! some switch managers are not too bright 18:33:32< eyck> JonB: yup, but I've got a very extensive training in speaking on irc ;) 18:33:41< _id> pflanze, oki 18:34:17< eyck> JonB: besides, irc is many-to-many chat, or one-on-one, university is on-to-many, this is whole different beast 18:35:05< Bertl> now that _we_ _all_ have listened to eycks talk, shouldn't we agree, and applaude? ;) 18:35:09< JonB> eyck: some of my classes are many to many 18:35:21< JonB> Bertl: hahaha, dont tease him 18:35:52< eyck> JonB: hmm, then you're very lucky and you've got great students. 18:36:04< JonB> eyck: heh, i'm still a student 18:36:06>> mlgd [~mlgd@194.149.164.113] has joined #vserver 18:36:12< mlgd> hello 18:36:15< JonB> eyck: it just depends on the kind of class 18:36:19< Bertl> greetings mlgd! 18:36:24< mlgd> Bertl : Kernel panic 18:36:40< mlgd> on Kernel with patch 18:36:40< Bertl> fine! which kernel, what panic? 18:36:41< eyck> JonB: hmm, then you're a very lucky student. 18:36:48< mlgd> ext3 18:37:09< JonB> eyck: well, the first many classes was one teacher speaking to many 18:37:21< mlgd> bertl : how include ext3 into 18:37:39< JonB> eyck: but later as i choose some course, some of them the teacher spoke the first time, and the next time some student had to speak 18:39:00< eyck> JonB: well... there are seminars and semi-seminars, that's where mostly students talk, 18:39:08< Bertl> mlgd: okay, let me subsume that: you have an ext3 related panic with a patched kernel, right? ;) 18:39:16< mlgd> yes 18:39:28< Bertl> care to share the details? 18:39:37< eyck> ah, Bertl is excercising his god-like communication skills... 18:39:50< JonB> now there are so many bright people here... if i wanted to script logging in to a website, choosing the right link, entering a mac address, parse the output, ... when the switch uses javascript at the website ? 18:39:55< mlgd> bertl ??? 18:39:56< eyck> let's all sit back, relax, and watch the marvels... 18:40:10< eyck> unwind. 18:40:16< eyck> let's all sit back, relax, and watch the marvels unwind. 18:40:19< JonB> mlgd: uname -a 18:40:27< Bertl> mlgd: maybe you could elaborate on what patch, which kernel, and what the panic actually said? 18:40:54< mlgd> uname -r : 2.4.25-1-k7 18:41:01< mlgd> i have reboot my server 18:41:13< JonB> mlgd: NOT YET 18:41:14< mlgd> with a good kernel 18:41:26< JonB> mlgd: does the server say the panic at the screen ? 18:41:30< JonB> mlgd: write that down 18:41:58< mlgd> Kernel panic : no device /dev/console 18:41:58< Bertl> I'd suspect it's something like 'can't mount root fs' .... 18:42:14< mlgd> bertl : my partition is EXT3 18:42:30< Bertl> which isn't that bad, per se ;) 18:43:05< Bertl> no device /dev/console, isn't a typical kernel message ... 18:43:32< Bertl> but the question remains, why is the '/dev/console' missing? 18:43:50< pflanze> [Hm, I've sent a mail with subject "alpha tools: /sbin/init style boot debugging" to the vserver@list.linux-vserver.org list, looks like it has been lost?] 18:43:53< Bertl> could be, because the rootfs couldn't be mounted 18:44:02< mlgd> because the server don't mount partition / 18:44:07< Bertl> could be, because you use devfs and it isn't compiled in ... 18:44:22< Doener`> pflanze: i got that one, so it's not lost 18:44:23< Bertl> so it's the rootfs which can't be mounted ... 18:44:31< mlgd> yes 18:44:40< pflanze> Ah, so it's my receiving end that's f*cke 18:44:41< Bertl> well, did you compile ext3 into the kernel or as module? 18:44:41< pflanze> d 18:44:51< mlgd> i don't know 18:45:07< JonB> Bertl: doesnt it just mount it as a ext2 if ext3 isnt supported? 18:45:08< mlgd> i compile with the default kernel.conf for 2.4.25-1-k7 18:45:29< Bertl> hmm, then just do a grep EXT3 kernel.conf 18:45:39< Bertl> JonB: no, not by default ... 18:45:47< JonB> hmm 18:45:53< mlgd> (sorry for my poor english, i'm french) 18:46:01< Bertl> (btw, I'm almost certain ext2 is compiled as module too) 18:46:31< Bertl> mlgd: we will not use it against you ;) 18:46:37< mlgd> CONFIG_EXT3_FS=m 18:46:42< mlgd> CONFIG_EXT3_FS_XATTR=y 18:46:45< mlgd> CONFIG_EXT3_FS_XATTR_SHARING=y 18:46:48< mlgd> CONFIG_EXT3_FS_XATTR_USER=y 18:46:51< mlgd> CONFIG_EXT3_FS_XATTR_TRUSTED=y 18:46:55< mlgd> CONFIG_EXT3_FS_POSIX_ACL=y 18:47:02< mlgd> that's all 18:47:10< Bertl> so, you are using a module for ext3, which requires to use an initial ramdisk too 18:47:18< JonB> mlgd: make the top one compiled in 18:47:34< mlgd> i dont't understand 18:47:53< Bertl> I have no idea how to build an initial ramdisk on debian, but debian folks will know ... usually it's mkinitrd 18:48:27< Bertl> you have to specify path of the initrd image and kernel version to that 18:49:02< Bertl> (just to make this clear, this is neither vserve related, nor an unusual requirement) 18:49:12>> monrad [~monrad@213083190226.sonofon.dk] has joined #vserver 18:49:39< Bertl> hi monrad? 18:50:04< monrad> hey 18:50:18< mlgd> hello monrad 18:51:09< Medivh> Bertl, speaking of not vserver related ... you wouldn't happen to know what to patch so that using LABEL=/ for the root partition in grub works? 18:51:39< Bertl> hmm, probably an RH specific grub patch? 18:51:50< Medivh> must be about the kernel, not grub 18:52:08< Bertl> you said in grub ... 18:52:30< Medivh> s/grub/grub.conf/ ;) 18:52:50< Bertl> of course there is an RH specific LABEL patch for the kernel too ... as the whole LABEL stuff is RH specific 18:54:33< Medivh> hm, need to browse the contents of kernel source rpm then ;) 18:58:11< mlgd> bertl : i have include ext3 in kernel via make menuconfig 18:58:14< mlgd> i recompile 18:58:41< Bertl> you will probably be missing other modules in the boot process .. why not doing the initrd? 18:59:23< mlgd> what's initrd ? 18:59:53< Bertl> the initial ram disk, which usually contains all the modules required to boot your linux kernel ... 19:00:34< Bertl> typically it is located in the /boot directory beside the kernel and named initrd-xy.img or somilar 19:00:43< Bertl> s/somilar/similar/ 19:01:18< Bertl> it is created with the mkinitrd command, and referenced by your bootloader (grub or lilo) 19:02:13< mlgd> yes, i have it for the kernel that i have compiled with ctx patch 19:02:43< Bertl> great, so you 'just' need to use it with the bootloader ... 19:03:49< mlgd> it's very crazy to compile a kernel with vserver on Debian 19:04:55< Bertl> well, actually it's a matter of 10 minutes with no complication at all (even on debian ;) 19:05:07< Doener`> mlgd: what makes you think that? 19:05:42< mlgd> 1 day to compile kernel that doesn't worked 19:07:03< Bertl> mlgd: well, you could also have payed me for one hour, and it would have worked ;) 19:07:16< Doener`> maybe you lack a little rtfm ;) (no offense intended) 19:07:41< mlgd> bertl : not for free ? 19:08:01 * Doener` .oO( is offense spelled like that? ) 19:08:12< Bertl> mlgd: it isn't vserver related at all, so why should I do that? 19:08:33< mlgd> for help me 19:08:56< mlgd> :) 19:08:56< Doener`> hmm.. i guess Bertl would be a pretty busy man then :) 19:09:37< Bertl> mlgd: sure, no problem, just that I have about 2mio kernel installations to do first ;) 19:10:13< Bertl> and I'm sorry that I can't continue to work on vserver for that time ;) 19:13:21< eyck> 2mio ? 19:13:29< eyck> what is 2mio? 19:14:05< Bertl> two millions 19:14:39< mlgd> bertl :) 19:15:28< mlgd> i'm going to #debianfr 19:15:31< mlgd> bye 19:15:34>> mlgd [~mlgd@194.149.164.113] has left #vserver [] 19:16:06< Bertl> .oO( maybe someone should warn them ... *sigh* ) 19:18:12< eyck> hehe, that's what you get for trying to be nice 19:18:27< Bertl> yeah, well, I can live with it ... 19:18:49< pflanze> Can I strace a process over context boundaries if it needs to chcontext again? 19:19:18< Bertl> you could try removing the process isolation and ptrace blockers from the patch ... 19:20:02< pflanze> (maybe strace should be a capability independent from ctx?) 19:20:11< pflanze> (ehr-- 19:20:22< pflanze> strace-over-ctx-boundary should be a cap. well.) 19:20:34< Bertl> I thought about a special cap, but it's not that easy ... 19:21:02< pflanze> ok np 19:21:28< Bertl> thing is, strace uses the /proc and sysfs info for identifying the processes ... so it would basically require to make the 'Spectator' stuff a cap ... but this might be a solution for 1.9.x development ... 19:26:52< pflanze> What do you think of a cross-vserver-action system? 19:27:04< pflanze> Like, one vserver may, if so configured, restart another vserver 19:27:14< pflanze> I guess over the vshelper. 19:27:44< Bertl> well, sounds interesting, but why not do this in userspace? 19:28:03< pflanze> How could a vserver leave it's boundaries for restarting another? 19:28:18< Bertl> how does the rebootmgr work? 19:28:22< pflanze> ah, dunno. 19:28:26< pflanze> of course, sockets? 19:28:42< Bertl> well fifo, but yes ... 19:28:44< pflanze> makes sense. 19:37:10< pflanze> somehow this gentoo client not even starts with echo gentoo > init/style 19:37:38< pflanze> strace shows several starts of services, but none of them keeps running. 19:37:50< pflanze> no single process is left up after vserver start 19:38:17 * pflanze writes mailing list 19:38:32< Bertl> are you sure that you didn't mess up with libraries and such? 19:39:18< pflanze> in gentoo? 19:39:32< pflanze> on the host everything works so far, with debian clients 19:40:42< Bertl> is gento init started? so is there a script executed on startup, which drags in all the services? 19:41:02< pflanze> there is /sbin/init, yes. 19:41:20< pflanze> But plain init style didn't work, default init style didn't work either of course since the host is debian, 19:41:39< pflanze> now with "gentoo" init style it correctly runs /etc/rc, but that's where I am now. 19:41:54< Bertl> if there is /etc/rc or /etc/rc.sysinit, you could try with a chroot /vserver/root and 'just' calling those from the host context ... 19:41:59< pflanze> i.e. strace shows activity, I even see ssh startup line on terminal, but nothing else. 19:42:35< pflanze> I need a secure chroot command. 19:42:46< pflanze> i.e. "vserver foo newenter" 19:42:57< pflanze> even when server is not running. 19:43:09< Bertl> why? 19:43:10< pflanze> you told me that's a bug of the tools that they don't allow it? 19:43:26< pflanze> 'cause then I can chroot into it without danger 19:43:48< pflanze> aka it's not my gentoo installation. but my host. 19:43:58< Bertl> sorry, chris are you converned about security, or do you want to debug the gentoo stuff? 19:45:41< Bertl> I know that gentoo seems to be a slightly weird distro (which is not the only one, btw) but have you tried putting you Guest onto some disk, and simply booting it the old way (no vserver studff at all?) 19:46:47< pflanze> nah 19:47:18< Bertl> okay, enough for me for now ... will be back later ... 19:47:24>> Bertl is now known as Bertl_oO 20:00:53< infowolfe> hey pflanze, how ya doin? 20:00:53>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has quit [Quit: Leaving] 20:01:25< pflanze> thanks, how do you mean? :) 20:01:34< pflanze> s/thanks/well thanks/ 20:03:27< infowolfe> i'm reading that you're having some gentoo issues? 20:03:36< pflanze> yes 20:03:50< infowolfe> anything i can offer assistance with? 20:05:26< pflanze> well, I have basically three ways to go, a) tell buddy that his gentoo is fucked up, b) tell buddy that gentoo doesn't work with vserver, c) repartition disk so that gentoo w/o lvm can work and try to reboot into gentoo. 20:05:46< pflanze> And e), what I'm doing right now, write a "venter" script. 20:06:07< pflanze> That does chbind/chcontext setup itself. 20:06:57< infowolfe> umm 20:07:05< infowolfe> gentoo DOES work with vserver though 20:08:01< pflanze> which leaves me with options a,b, and e 20:08:20< pflanze> ehr, a, c and e 20:08:34< pflanze> (and maybe there's d which I have missed heh) 20:09:35< infowolfe> well, would you like me to take a look for you? 20:10:41< pflanze> hm, thanks for the offer, but I can't ask the buddy right now if it's ok for him to let you in. 20:11:14< pflanze> I think I'll first finish the venter script 20:11:40< infowolfe> well, let's see what we can do from here then, if that's ok 20:11:47< infowolfe> so you don't waste energy on it? 20:12:29< pflanze> what do you propose? 20:12:37< pflanze> to do 20:13:04< pflanze> did you write the wiki page? 20:13:06< pflanze> about gentoo 20:13:07< infowolfe> chroot /vservers/ 20:13:10< infowolfe> no, i didn't 20:13:16< infowolfe> i haven't had a chance to do any real documentation work 20:13:23< infowolfe> i'm just a gentoo freak :-p 20:13:29< pflanze> k moment 20:13:49< infowolfe> i don't want you to enter, i just want you to chroot to it 20:14:07< infowolfe> then source /etc/profile && env-update && /sbin/rc shutdown 20:14:27< infowolfe> that should clear up any leftovers (if you've had a powerloss or something along those lines) 20:15:37< infowolfe> gentoo does it's service checking via a filesystem (/var/lib/init.d/) 20:15:45< infowolfe> so the filetree looks like this 20:15:52< infowolfe> -> /var/lib/init.d/ 20:16:11< infowolfe> -> /var/lib/init.d/softlevel (should read "default" unless you've hacked the runlevels) 20:16:36< infowolfe> -> /var/lib/init.d/deptree,depcache,envcache should be ignored 20:17:27< infowolfe> -> /var/lib/init.d/options/ holds /etc/rc.conf options (ex. /var/lib/init.d/options/xdm for me has content "/usr/bin/gdm") 20:17:28< pflanze> k 20:17:52< infowolfe> -> /var/lib/init.d/snapshot should be empty 20:18:15< pflanze> well, rc shutdown did stop my shell 20:18:19< infowolfe> -> /var/lib/init.d/softscripts are links to /etc/init.d/ 20:18:21< infowolfe> it was supposed to 20:18:34< infowolfe> -> /var/lib/init.d/started (is what you really needed to worry about) 20:18:50< infowolfe> started has a link to each service that is shown by gentoo as being started 20:19:04< infowolfe> whether they're running or not isn't check (hence the /etc/init.d/service "zap" command 20:19:27< infowolfe> attempt to start it with vserver start and pastebin me any/all errors and we can fix them, cool? 20:20:07< infowolfe> i need to create some documentation so that people know this kinda stuff 20:20:08< infowolfe> lol 20:20:54< infowolfe> the big thing is this: if you're stracing, and you attempt to start services that are shown as already started, gentoo ignores the start request 20:21:29< infowolfe> if you /sbin/rc default without doing /sbin/rc shutdown first, gentoo says "hrm, my softlevel is already default, so i'm not gonna do anything" 20:21:42< infowolfe> which MAY have had an effect on your particular situation 20:22:01< pflanze> I C 20:22:10< pflanze> that's really confusing coming from other distros 20:22:14< pflanze> it helped: 20:22:25< pflanze> now it prints more stuff on startup 20:22:27< pflanze> root@elvis init# vserver scrat start 20:22:27< pflanze> * Caching service dependencies... 20:22:27< pflanze> * Starting syslog-ng... 20:22:27< pflanze> Error opening file /proc/kmsg for reading (Operation not permitted) 20:22:27< pflanze> Error initializing configuration, exiting. 20:22:28< pflanze> * Failed to start syslog-ng [ !! ] 20:22:30< pflanze> * Starting sshd... [ !! ] 20:22:33< infowolfe> wee!!!! 20:22:33< pflanze> * ERROR: Problem starting needed services. 20:22:35< infowolfe> wonderful 20:22:39< pflanze> * "vixie-cron" was not started. 20:22:41< pflanze> * Starting local... [ ok ] 20:22:42< infowolfe> hey plfanze, hold on for a second 20:23:22< infowolfe> http://pastebin.de/ 20:23:31< infowolfe> paste the entirety of the gentoo startup there please 20:23:41< infowolfe> and then give me the link 20:23:50< infowolfe> and we can start getting your gentoov server running 20:23:50< pflanze> that was all 20:23:56< infowolfe> that's it? 20:23:58< infowolfe> ok, enter it 20:24:36< pflanze> http://pastebin.de/pastebin.py?id=641 20:24:55< infowolfe> use your favorite editor to edit /etc/init.d/vixie-cron 20:25:25< pflanze> yep? 20:25:38< infowolfe> does it show "need logger" ? 20:25:51< pflanze> depend { ..logger } yes 20:25:55< infowolfe> good 20:25:59< infowolfe> leave that alone then 20:26:06< infowolfe> syslog-ng is why everything else is borked 20:26:31< infowolfe> edit /etc/syslog-ng/syslog-ng.conf 20:26:44< pflanze> yep? 20:26:59< infowolfe> comment out the line starting with destination console_all 20:27:10< pflanze> k 20:27:34< infowolfe> on the line that starts with source src { unix-stream edit it and remove the last entry (/proc/kmsg) 20:28:22< pflanze> k 20:28:24< infowolfe> then leave the context 20:28:28< infowolfe> vserver stop 20:28:33< infowolfe> then attempt to start it again 20:28:45< infowolfe> if it doesn't start correctly, chroot into it and issue /sbin/rc shutdown 20:29:08< infowolfe> if it doesn't start correctly, i'm going to have to yell at enrico for borking the gentoo patch that i gave him like 6 months ago :-p 20:30:16< pflanze> hm 20:30:23< pflanze> still Failed to start syslog-ng and so on 20:30:32< infowolfe> new pastebin please? 20:31:12< pflanze> http://pastebin.de/pastebin.py?id=642 20:31:34< infowolfe> oh poo 20:31:58< pflanze> did i misedit the conf as it seems 20:32:01< infowolfe> the last line in the /etc/syslog-ng/syslog-ng.conf has console_all in it somewhere 20:32:04< infowolfe> it was my mistake 20:32:04< infowolfe> lol 20:32:05< infowolfe> sorry 20:32:20< infowolfe> i didn't have an unedited version of syslog-ng.conf 20:32:26< infowolfe> i'll pastebin the version that works for me, ok? 20:32:31< pflanze> sure 20:32:54< infowolfe> http://pastebin.de/pastebin.py?id=643 20:33:18< infowolfe> if your config and mine look exactly the same, you're set 20:33:23< infowolfe> and it WILL start correctly 20:33:52< pflanze> cool it does 20:34:33< pflanze> Thanks very much! 20:34:38< infowolfe> actually, is console_all in destination messages still? 20:34:42< pflanze> no, 20:34:49< infowolfe> coolness 20:34:53< pflanze> there was a line still in the config that referred to it 20:34:56< infowolfe> cool 20:35:00< infowolfe> so that's fixed now? 20:35:01< pflanze> #log { source(src); destination(console_all); }; 20:35:04< infowolfe> let's see if you can ssh into it 20:35:08< pflanze> well, sshd still does not start 20:35:13< pflanze> but I guess that will be in the logs now 20:35:25< infowolfe> hrm, does it give anything on the commandline why it won't? 20:35:31< pflanze> no, just [!!] 20:35:51< infowolfe> netstat -l from the host 20:36:12< infowolfe> the *only* ip ssh should be listening on is the main ip for the host machine 20:36:25< infowolfe> if it's bound to more than one ip, the gentoo sshd will fail without any errors 20:36:30< infowolfe> (it can't bind to port 22) 20:37:20< pflanze> well, sshd in the host has 20:37:22< pflanze> ipv4root: 4706e2c3/f0ffffff 0100007f/000000ff 20:37:31< pflanze> should be ok 20:37:39< pflanze> and other vservers can start ssh 20:37:52< pflanze> even debian in the same config as the gentoo client 20:38:01< infowolfe> hrm... 20:38:21< infowolfe> what do the logs hint at? 20:38:23< pflanze> Apr 30 16:53:50 elvis sshd[7940]: Received signal 15; terminating. 20:38:44< pflanze> moment, going to look at kernel logs 20:39:04< pflanze> nothing there 20:39:16< infowolfe> are those the logs inside the scrat vserver? 20:39:23< pflanze> the above line yes 20:39:31< pflanze> ah hey, April 30 20:39:32< infowolfe> why does it say elvis then? :-p 20:39:33< pflanze> that's old 20:39:50< infowolfe> the signal 15 is "shutdown" afaik 20:40:15< pflanze> there are only 2 lines in var/log/messages: 20:40:17< pflanze> May 8 20:33:39 scrat syslog-ng[8980]: syslog-ng version 1.6.0rc3 starting 20:40:17< pflanze> May 8 20:33:40 scrat cron[22283]: (CRON) STARTUP (fork ok) 20:40:29< infowolfe> ok 20:40:33< infowolfe> are you inside scrat right now? 20:40:41< infowolfe> cat /var/log/everything/current 20:40:54< pflanze> no such file 20:41:00< infowolfe> hold 1 20:41:15< infowolfe> lol 20:41:18< infowolfe> nevermind, i'm dumb... 20:41:28 * infowolfe is used to metalog 20:41:55< infowolfe> edit your /etc/ssh/sshd_config 20:42:11< infowolfe> lines 30 and 31 uncomment 20:42:17< infowolfe> (syslogfacility auth) 20:42:23< infowolfe> and loglevel info 20:42:26< pflanze> k 20:42:31< infowolfe> oooh 20:42:32< infowolfe> crap 20:42:46< infowolfe> check /etc/init.d/sshd 20:42:55< infowolfe> under depend, use logger dns 20:43:15< infowolfe> remove the "need net" line 20:43:27< infowolfe> (should be line 9 of that file) 20:43:30< pflanze> yep 20:43:41< infowolfe> now issue /etc/init.d/sshd start 20:44:14< pflanze> still [!!] 20:44:16 * infowolfe huggles his 3 monitors (they allow all kinds of information to be present) 20:44:20< infowolfe> do we have any log info? 20:44:45< pflanze> no 20:44:58< infowolfe> and it doesn't give any other information? 20:45:06< pflanze> no 20:45:11< pflanze> the funny thing is: ssh -d works 20:45:14< pflanze> sshd -d 20:45:58< infowolfe> try /usr/sbin/sshd -e 20:46:17< pflanze> works 20:47:03< infowolfe> /usr/sbin/sshd -eD 20:47:39< pflanze> yes works 20:48:28< infowolfe> do ps aux | grep ssh 20:48:41< pflanze> now it's off again since I did killall sshd 20:49:03< pflanze> It must be the ssh startup config 20:49:20< infowolfe> hrm... 20:50:07< infowolfe> what part do you think is borked? 20:50:22< pflanze> dunno, init.d/ssh maybe 20:50:44< infowolfe> do you have start-stop-daemon present? 20:50:46< pflanze> where does /sbin/runscript log to? 20:50:57< pflanze> yes 20:51:02< pflanze> /sbin/start-stop-daemon 20:51:32< infowolfe> runscript doesn't log 20:51:58< pflanze> wondering why I don't see more output to the terminal 20:52:57< infowolfe> remove the --quiet option from start-stop-daemon under the start() { portion of /etc/init.d/sshd 20:53:15< infowolfe> and also check for /var/run/sshd.pid 20:53:35< infowolfe> (after starting) 20:53:57< pflanze> (null) already running. [ !! ] 20:54:05< infowolfe> hrm 20:54:09< pflanze> but stop says not yet been started 20:54:11< infowolfe> ls /var/lib/init.d/started 20:54:56< pflanze> heh 20:54:59< pflanze> rm /var/run/sshd.pid 20:55:03< pflanze> was all it took 20:55:05< infowolfe> lol 20:55:14< infowolfe> normally it'll overwrite that for you :- 20:55:18< infowolfe> :-\ 20:55:18< pflanze> strange 20:55:23< infowolfe> ok 20:55:30< pflanze> is this start-stop-daemon really the same as debian's? 20:55:36< infowolfe> attempt vserver scrat stop && vserver scrat start 20:55:46< pflanze> I never seen such problems on debian. 20:55:48< infowolfe> try emerge search start-stop-daemon :-p 20:56:32< infowolfe> it's very possible that it's not the same version 20:56:39< infowolfe> although, i highly doubt it's not the same tools 20:56:41< infowolfe> tool* 20:56:56< infowolfe> it's part of gentoo's baselayout package 20:58:27< pflanze> hm, I switched to "plain" init style, didn' work, 20:58:37< pflanze> switched back, gentoo still won't boot anymore 20:58:43< pflanze> guess I'll have to rc shutdown again 20:59:32>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has joined #vserver 21:00:10< infowolfe> hrm 21:00:39< infowolfe> do an /sbin/rc shutdown 21:00:50< infowolfe> THEN i want you to ls /var/lib/init.d and paste the results for me 21:01:32< infowolfe> if [ -f /var/lib/init.d/softlevel ] 21:01:58< infowolfe> if [`cat /var/lib/init.d/softlevel` = "default"] 21:02:04< pflanze> hrrrrm, starts up now but again requires me to rm the pid file 21:02:11< infowolfe> /sbin/rc shutdown or something 21:02:32< infowolfe> i wnat you to stop it and test to see if anything in /var/lib/init.d is there 21:02:35< infowolfe> want* 21:03:17< pflanze> sorry I haven't read fast enough 21:03:31< pflanze> I've running it again now, with "gentoo" init style though 21:03:55< pflanze> I'll add an rm /var/run/sshd.pid to /etc/init.d/ssh 21:04:05< infowolfe> no 21:04:06< infowolfe> don't 21:04:11< pflanze> ok? 21:04:15< infowolfe> edit /etc/conf.d/local.stop 21:04:28< pflanze> yes? 21:04:48< infowolfe> i need to figure out where/when it's called :-\ 21:05:04< infowolfe> i want to add a quick bash script to it that will kill all *.pid in /var/run 21:05:49< pflanze> you think I should add rm /var/run/*.pid here? 21:05:57< infowolfe> yah 21:05:59< infowolfe> that'll do the trick 21:06:14< infowolfe> and MAKE SURE that local is in your default runlevel 21:06:18< infowolfe> rc-update add local default 21:06:22< pflanze> but that will only work if gentoo is shut down cleanly 21:06:34< infowolfe> you're right... 21:06:38< infowolfe> but hold on :-p 21:06:40< pflanze> and in this case it'll shut down sshd anyway which will remove the pid file 21:06:41< infowolfe> <~~ is on top of it already 21:07:37< infowolfe> i'll have a cute little tarball for you shortly 21:10:03< pflanze> would be cool if plain style init would work 21:11:53< infowolfe> oh, shit, do you have /sbin/depscan.sh in your /sbin/rc? 21:12:02< pflanze> yes 21:12:05< infowolfe> should be like the 5th or 6th line 21:12:06< infowolfe> cool 21:12:10< infowolfe> was that in the wiki? 21:12:22< pflanze> my buddy did comment it out, 21:12:30< infowolfe> what an ass 21:12:33< pflanze> but on my search for boot problems I put it in again 21:12:34< infowolfe> it needs to be re-added 21:12:36< infowolfe> lol 21:12:37< infowolfe> ok 21:12:48< infowolfe> that's one of my fixes :-D 21:13:15< pflanze> So it should be *active*? 21:13:33< infowolfe> yes1 21:13:34< infowolfe> ! 21:13:45< pflanze> (that's what it is, so fine.) 21:14:21< infowolfe> lol 21:14:37< infowolfe> good... the env-update *creates* your /var/lib/init.d on startup inside vserver 21:14:52< infowolfe> and if you don't have it, you get all KINDS of weird errors 21:15:10< infowolfe> in fact, i think i'm the first person to run gentoo inside vserver with success :-p 21:17:36< infowolfe> btw, i'm reading the /sbin/rc file so i can figure out how it's all created/etc so i can test and do hard-cleaning if it wasn't clean to begin with 21:19:04< pflanze> That's my new trick to make that thing boot without my intervention: 21:19:10< infowolfe> what is? 21:19:14< pflanze> put this into prepre-start 21:19:15< pflanze> chbind --ip "`cat interfaces/loc/ip`" chcontext --secure chroot /vservers/scrat/gentoo/ /sbin/rc shutdown 21:19:25< infowolfe> lmfao 21:19:41< infowolfe> wiki it then! 21:19:42< infowolfe> lol 21:20:08< infowolfe> so i don't have to hack up some scripts to do it userspace 21:20:27< infowolfe> wait a minute 21:20:33< infowolfe> hrm.. 21:21:36< infowolfe> make a quick bash script 21:21:46< infowolfe> hide it in /etc/conf.d/vserver 21:21:52< infowolfe> #!/bin/bash 21:22:36< infowolfe> source /sbin/functions.sh 21:23:06< infowolfe> if [ -e ${svcdir} ] 21:23:13< infowolfe> then 21:23:15< infowolfe> /sbin/rc shutdown 21:23:16< infowolfe> fi 21:23:19< infowolfe> there ya go! 21:23:31< pflanze> inside the vserver that is? 21:23:37< infowolfe> yah, inside the vserver 21:23:39< infowolfe> chmod 700 it 21:23:48< infowolfe> and call THAT instead of /sbin/rc shutdown directly 21:23:52< pflanze> ah you mean and execute that through prepre-start? 21:23:55< infowolfe> yah... 21:23:58< pflanze> ok nice idea 21:24:05< infowolfe> this way we're not shutting down if we've already shut down, y'know? 21:24:54< pflanze> I find it a bit ugly to have to change distributions to make them work in vserver 21:25:08< infowolfe> umm, well, you have to do it no matter what distro you have 21:25:13< pflanze> it's easier to just let people come with their images and start it up. 21:25:26< pflanze> I didn't change debian in any way 21:25:57< pflanze> Not a single change! or I must have a hole in my memory. 21:26:04< infowolfe> lol 21:26:09< infowolfe> you didn't have to mess with mounts? 21:26:28< infowolfe> in my free time i'm working on better gentoo vserver client support 21:26:29< pflanze> no, I just left most of the vservers as is 21:26:42< pflanze> with stable tools they emitted mount errors but that's cosmetics 21:26:43< infowolfe> meaning, you don't have mount failures on boot? 21:26:48< infowolfe> lol 21:27:03< infowolfe> well, i have hack to fix that too :-p 21:27:12< pflanze> with the alpha tools, an fstab is written automagically so that's no issue anymore anyway 21:29:21< infowolfe> tell me if you like this one (for cosmetics) 21:29:23< infowolfe> #!/bin/bash 21:29:23< infowolfe> if [ -f /dev/initctl ];then 21:29:23< infowolfe> rm /dev/initctl 21:29:23< infowolfe> fi 21:29:23< infowolfe> touch /dev/initctl 21:29:25< infowolfe> for i in {/bin/{mount,umount},/sbin/{swapon,swapoff,hwclock}}; do cp /bin/true $i;done 21:29:51< infowolfe> that takes care of mount errors 21:32:11< infowolfe> like it? 21:32:15< pflanze> hm 21:32:22< infowolfe> that's to be executed INSIDE the vserver 21:32:25< pflanze> yes 21:32:33< pflanze> but I don't like it that much 21:32:41< infowolfe> all of your mounts and unmounts will be successful :-p 21:32:42< infowolfe> lol 21:32:45< pflanze> as I said, It's basically better to not change much 21:32:55< infowolfe> why 21:33:30< pflanze> So your vserver guests could just tar up their system and boot on another machine. 21:33:43< pflanze> With nothing changed except fstab and the kernel. 21:33:48< infowolfe> eh... 21:33:52< pflanze> And network settings of course. 21:34:18< pflanze> Or even not this: 21:34:30< infowolfe> if they want to tar and boot on another machine, they can buy a dedicated server to begin with :-p 21:34:45< pflanze> take an installation from a real machine with network settings, fstab etc, run it inside vserver for some time, take it back to the machine and it'll work :) 21:34:53< infowolfe> lol 21:34:58< infowolfe> that won't work with gentoo anyway 21:35:05< infowolfe> let's say i've got a p4 optimized system... 21:35:14< pflanze> hm good point. 21:35:23< infowolfe> unless i'm taking it to either another p4 or an opteron, it won't work... 21:35:28< infowolfe> period 21:35:47< pflanze> That's why I don't think the gentoo optimization idea is worth so much. 21:35:49< infowolfe> it's quaint that everything for debian is compiled for i386... 21:36:33< infowolfe> same hardware, gentoo tuned by me on one side and debian tuned by my ex-employer's debian guru on the other... guess which machine performed better in a stress test that we came up with together? 21:36:34< pflanze> ok let's stop being idealistic :) 21:37:22< eyck> infowolfe: debian? 21:37:40< infowolfe> we hit the boxes hard with php/mysql/apache in test 1 and sendmail/mj2 (majordomo 2) in test2... 21:37:45< infowolfe> gentoo won hands down on both 21:38:04< eyck> interesting, i wonder why 21:38:32< infowolfe> eyck, umm, smp machines with hardware raid 1 21:38:41< infowolfe> 2GB ram and dual 40G 7200rpm IDE 21:39:10< infowolfe> php/mysql/apache tends to really like smp 21:39:11< eyck> although, I must admit this is all very exotic software... php, mysql, sendmail, majordomo... who uses that stuff?? 21:39:17< infowolfe> lol 21:39:20< infowolfe> everybody 21:39:41< infowolfe> in fact... they send an average of 750,000 emails a day via mj2 21:39:44< eyck> oh, right. just like microsoft IIS 21:40:03< infowolfe> (they've got one or 2 mailing lists... and a global whitelist from spamhaus, aol and a couple others) 21:40:44< infowolfe> the thing is... athlon mp 2000+ processors... the debian i386 packages weren't very well tuned for the processors 21:41:11< infowolfe> whereas the gentoo box was compiled from scratch with all processor flags enabled and a "non-stock" CFLAGS 21:41:52< infowolfe> not only that, but my kernel was lighter weight, i booted faster, and could handle a lot more load 21:42:19< infowolfe> i topped gentoo out at a load average of about 1500 whereas the debian box was completely unresponsive at 1000 21:42:24< infowolfe> and i have pix of the debian box :-p 21:43:08< infowolfe> http://infowolfe.yafro.com/photo/19053 21:45:04< infowolfe> eyck, were you being serious about "everybody" using microsoft IIS? 21:47:40< infowolfe> http://news.netcraft.com/archives/web_server_survey.html 21:47:54< infowolfe> it seems to me that microsoft is a distant 2nd in webservers :-p 21:48:05< infowolfe> .. and always has been :-p 22:07:14>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has joined #vserver 22:15:44< pflanze> for whatever reason, gentoo shuts down again now even with gentoo init style 22:16:02< pflanze> prolly my prepre-start script doesn't work 22:18:09< JonB> or maybe it got sasser, doesnt that reboot the computer ;-P 22:19:18< pflanze> yep thats the point 22:19:52< pflanze> it does not just because I was so sly to use chcontext around the chroot 22:20:09< pflanze> but it still triggers the vshelper 22:20:28< pflanze> which means, my prepre-start script triggers another start on top 22:20:33< pflanze> stop first 22:20:39< pflanze> holy mess 22:21:22< pflanze> infowolfe: how can I get the effect of /sbin/rc shutdown without triggering a reboot? 22:27:24< pflanze> anyway I've removed that stuff from my script again 22:27:32< pflanze> manually ran the rc shutdown 22:28:24< pflanze> but why the h* will vserver start now not issue any output to the terminal and the gentoo client do a restart 22:29:49>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has quit [Remote host closed the connection] 22:32:24< pflanze> *sigh*, looks like prepre-start is called too late. 22:32:40< pflanze> after the vserver tools looked at the init style 22:32:45< pflanze> instead of before. 22:34:57>> JonB [~NoSuchUse@129.142.112.33.ip.tele2adsl.dk] has quit [Quit: Leaving] 22:36:38< pflanze> that's baaaad 22:47:38< pflanze> _id: ah btw I'm using grsecurity 1.9.x, not 2.0.x 22:48:00< pflanze> 2.0.x will very probably not work with my patches 22:50:12< pflanze> And I'm using vserver 1.3.{8,9} 23:06:17>> monrad [~monrad@213083190226.sonofon.dk] has quit [Quit: Leaving] 23:08:09< infowolfe> sorry pflanze, i wasn't paying a lot of attention 23:08:11< infowolfe> i'm back now 23:08:39< pflanze> well, so far so good now. 23:08:47< infowolfe> you fixed it? 23:09:01< pflanze> There's no /sbin/rc shutdown cleanup attempt anymore of my part. 23:09:16< infowolfe> i might end up having to do it in userspace :( 23:09:21< pflanze> I offer the buddy a debian guest from which he has access to the gentoo vserver. 23:09:26< infowolfe> but let me know if you want me to, i'm window shopping for my new car stereo 23:09:36< pflanze> So he can clean it up manually should it ever be necessary. 23:09:46< infowolfe> that's cool 23:10:15< pflanze> Well not that cool, but state of affairs now. 23:10:44< pflanze> I'll send enrico a bug report about the prepre-start issue --- Log closed nie maj 09 00:00:56 2004