[00:17] @enrico maybe we should talk about the userspace helper ... [00:17] for reboot and similar things ... [00:17] ok, I would prefer something like /proc/contexts//event [00:18] hmm, /proc/virtual//event ;) [00:18] this is similarly to /proc/acpi/event [00:18] hmm, and what exactly should this provide? [00:18] exactly one process can open on it and read() blocks until an event happens [00:18] and more important, what format? [00:19] such an event can be reboot within a ctx, or exiting all processes of a ctx (--> killing a ctx) [00:20] hmm, what if this isn't opened by a client? [00:20] are the events queued or simply thrown away? [00:20] it depends; reboot-signal is ignored. When a zombie-flag is set for the ctx, the kill-signal is pending and will dropped otherwise [00:21] hmm, and how to signal a context destruction, as this would also remove that event pipe? [00:22] don't forget /proc/acpi doesn't go away ;) [00:22] context metadata will be saved after killing a ctx. After reading /proc/virtual//status, the /proc entry will be removed also (similarly to wait()) [00:23] but this happens for special ctxs only (such with a zombie-flag) to remain backward compatbility [00:24] hmm, there is nothing to keep compatibility to ;) [00:24] okay so the zombie-flag would keep the context, until what? [00:24] or just the metadata/statistics? [00:24] currently, all tools are expecting that the ctx dissappears silently without leaving zombie kernel structures [00:25] statistics, exit-code of last process [00:26] hmm, that is non trivial with the current implementation, as init is always the child reaper for _all_ contexts ... [00:28] hmm, is there actually any reason for not having an event interface _and_ a userspace helper like usbhotplug? [00:29] userspacehelper is not general enough; e.g. for vserver-in-vserver, it would make no sense [00:30] and I do not like the automatic-kernel-process method [00:30] well, it could call a vserver specific userspace helper ... [00:30] with 2.6 there is better security, but with 2.4 it is very dangerous [00:31] hmm, okay is the acpi event interface a good one? [00:31] it is simple and works well. [00:32] okay, you would write some userspace tool to work with that? [00:32] the userspace-helper would have to rely on inter-vserver data when reacting on in-vserver events [00:32] this is very bad... [00:32] yes [00:33] do we have /proc/virtual/ already? [00:33] not yet, but that isn't the big problem (I want it anyway ;) [00:34] could you draft a proposal how the 'events' on this interface would look like ... for ctx start/stop and reboot/halt/etc ... [00:35] currently, I know only two events: kill and reboot [00:35] reboot/halt are userspace translations of special files like /vservers//.reboot [00:38] hmm, well the syscall (reboot) has 5 different commands/calls ... [00:38] LINUX_REBOOT_CMD_RESTART [00:38] LINUX_REBOOT_CMD_HALT [00:38] LINUX_REBOOT_CMD_POWER_OFF [00:38] LINUX_REBOOT_CMD_RESTART2 [00:39] and I obviously can't count ;) [00:40] and at least the RESTART2 has to be handled special, as it is issued either if RESTART fails or if a custom restart program should be executed ... [00:41] well I forgot LINUX_REBOOT_CMD_CAD_ON/LINUX_REBOOT_CMD_CAD_OFF ... [00:43] ok, it would not be a problem to honor these flags. But IMO, RESTART & HALT (==POWEROFF) are the only interesting cases for event interface [00:46] well, those are actually commands, but yes, I assume everything else could be reported but would be of dubious value ... [00:46] ctx-syscalls whcih are implementing these /proc interfaces would be good also (e.g. vc_ctx_wait(ctx, &status, flags), or vc_select(...)) [00:48] hmm, please elaborate ... (means I can't follow you ;) [00:51] vc_select(ctx, &mask) -> waits until an event specified in mask occurs (events are e.g. kill, reboot, halt), and sets the mask (similarly to select(2)) [00:51] this would be similarly to reading from /proc/virtual//event [00:51] (but more powerful) [00:52] hmm ... [00:52] vc_ctx_wait(ctx, &status, flags) -> waits until the ctx is kill or retrieves status/statistic information from an already killed one. flags can contain W_NOHANG so that ctx_wait() returns immediatily [00:55] hmm so you have a central event dispatcher in mind, right? [00:55] (kernel side) [00:55] dunno, I am not a kernel developer ;) I am just speaking about syscalls/interfaces which would be usefully for the userspace [00:57] okay, how should we handle the following situation ... [00:57] - ctx 1000 is started ... [00:57] - last process in ctx 1000 dies ... info isn't retrieved immediately ... but someone 'registered' to do so ... [00:58] - ctx 1000 is to be re-started before the information is consumed? [00:58] restart is not possible for zombie-flagged ctxs [00:58] so it simply fails, issuing an error, right? [00:59] yes, with something like -EBUSY [00:59] or -EPERM [00:59] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [00:59] hmm, but this will automatically lead to failing server restarts, if not handled with utmost care ... [01:00] that's why the zombie-flag should be turned off for backward compatbility [01:01] okay, and you would be able to restart the context after issuing some special syscall, or just after the ctx_wait() finished? [01:01] fleshcrawler (~fleshcraw@212.202.16.134) joined #vserver. [01:02] after the status was get. e.g. fork() does not create a PID which is used by a zombie-process [01:02] the ctx_wait() could be 'cat /proc/virutal//wait' also (or '.../status') [01:03] okay, so we block the context until the last hanging wait() is finished, and do not allow new waits to be attached ... [01:03] does the proc interface work for processes on a vanilla kernel? [01:03] only one wait() can succeed, the other one get -ECHILD [01:04] vanilla kernel does not have such an interface [01:04] hmm, so we just don't add it a t the moment, okay? [01:04] ok [01:05] but why shouln't it be allowed to ctx_wait() more than one time? [01:07] will be probably difficultly to implement (races when new ctx_wait() gets called while other ctx_waits() are returning) [01:08] I have to look how sys_wait() does this ... I would suggest we do it the same way ... [01:08] ok [01:10] hello there. [01:11] hi! [01:11] i was here yesterday with a dns-resolv problem. [01:11] I remember ... [01:11] It disappeared. I patched my kernel a few more times and then it was gone. [01:12] @ensc okay, I would suggest, the first step would be to do the event interface ... second step the wait/flag stuff ... okay? [01:13] @fleshcrawler well, you should always start with a clean tree ... [01:13] Bertl: yes, the event sounds more simple [01:13] @Bertl: I also had some issues by starting the server. it said that the specified IP was not alright. had todo with the kernel patch, too because that is gone, too. [01:14] @fleshcrawler what patches are you using now? [01:14] 17f [01:14] hmm, try the first vs1.00 release ... [01:15] c17f works fine for me now. [01:15] okay ... it's your decision ;) [01:16] what's wroing with 17f? [01:16] nothing ... was a test release before the final vs1.00 was released [01:16] ah okay. [01:17] I'm just trying to minimize the versions used by the community ;) [01:19] the 1.00 is not for the debian kernle isn't it? [01:20] not yet, right ... [01:20] fleshcrawler: i "Linus" default 2.4.21 kernel [01:21] fleshcrawler: used [01:21] @fleshcrawler do you use 2.4.22-3 with c17f ? [01:21] yes. I think so. [01:22] it's the debian kernel source package. [01:22] would you change to vs1.00 if there was a debian patch? [01:23] yes [01:24] http://vserver.13thfloor.at/Experimental/patch-2.4.22-3-vs1.00.diff.bz2 [01:24] http://vserver.13thfloor.at/Experimental/patch-2.4.22-3-vs1.1.0.diff.bz2 [01:24] ;) [01:24] thanx! [01:24] use both? [01:25] well the first is the stable release, the second the development release ... [01:25] ah! okay. [01:25] I personally don't test the debian stuff, so please report any issues to me ... [01:26] okay. I'll start baking. [01:26] and make sure that you do not use a 'bad' C compiler ... [01:26] Action: Bertl is still using 2.95 for the kernel ... [01:27] yeah. there were a lot going wrong lately. [01:38] Nick change: riel -> unriel [01:40] @enrico hmm, should we allow more than one process to connect to the event interface? [01:40] Bertl: when it is ok for the kernel implementation, I do not have problem with it [01:41] well, it complicates it ... [01:41] by the way, how should the events look like? ascii strings? [01:42] matta (matta@tektonic.net) joined #vserver. [01:42] hi matt! [01:43] hi! [01:43] so... [01:43] it's not rmap [01:43] it's really weird, it's behaving like it's out of memory [01:43] even though it's using over 1GB for cache [01:43] hmm, this time without rmap? [01:44] and peaks out at using 260MB of swap [01:44] yeah, with 2.4.22, 2.4.22+rmap, 2.4.23pre8+rmap+o(1) [01:44] Bertl: why not. But a single byte would be enough also [01:44] seems to not be a vserver problem but perhaps a yet to be found kernel problem? [01:44] kswapd just uses 100% system after a few hours [01:44] loads of a couple hundred.. [01:44] my solution is to move about 20 vservers off of it and see if that does it :) [01:45] hmm, well probably as good as any other ... ;) [01:45] also [01:45] i ran vmstat while it's doing this... [01:45] swapin/swapout is barely anything [01:46] mostly at 0 but sometimes spikes up to 300-1000 for one or the other which sems reasonable [01:46] hmm, interesting ... [01:46] really odd... [01:47] it just seems like it's not using the memory [01:47] Bertl: did you have any 2.6 patches ? [01:47] maybe a memory leak then ... which isn't swapped out ... [01:47] kswapd uses all cpu, has plenty of memory allocated to cache, it only uses 250MB out of 4GB of swap... but it looks like a OOM situation [01:48] Bertl: well, even if a process is trying to use all memory shouldn't it try to take away memory from the cache? [01:48] @jon yes, QHA and BME ... [01:49] Bertl: okay, because i got 2.6 running in my vmware, so we can get it tested [01:49] i found similiar problems like this for 2.4.2, 2.4.9, and 2.6-test4 [01:49] where people complain of kswapd under similiar circumstances [01:49] with google, I assume ... [01:49] i dunno... hard to debug [01:49] Bertl: yes [01:53] only thing I can think of is a longshit I think [01:53] none of the vservers are unified [01:53] so perhaps because of all the different programs it will not take the cache lower? [01:53] but that doesn't explain why it doesn't swap [01:53] er, longshot :) [01:54] freudian slip ;) [01:54] well, if it doesn't swap out, either the memory is locked, or the swapper can't decide what to swap out ... [01:55] I don't know much about the kswapd implementation ... maybe rik has some ideas ... [01:56] ahh no, his suggestion was to use 2.6 IIRC [01:56] we don't know what it is, but for sure, it's fixed in 2.6 8-) [01:56] i'm gonna try unifying and see if it does anything good, I unified 30 vservers on another server and no one mentioned a thing [01:59] @enrico .. okay I guess we have to do step 0 first ... [02:01] @ensc we have to change the current proc interface ... this means that a lot of tools will actually break, do you think you can handle that? [02:01] Bertl: yes; I think... [02:02] okay, let us talk about the 'new' proc interface then ... (and it's structure) [02:02] JonB (~jon@129.142.112.33) left irc: Quit: zzzzzzz [02:02] about /proc/virtual/ directory we do not need to debate, right? [02:03] yes, this is ok [02:05] should be the per context overview located beneath (e.g. /proc/virtual/.info) or below this path (e.g. /proc/virtual//info) ? [02:06] and how should it be named? what information should it contain? [02:06] @matt how is this handled on alex's patches? [02:07] @Bertl: Kernel backed. If I won't return something is wrong... ;-) [02:07] okay ;) [02:07] fleshcrawler (~fleshcraw@212.202.16.134) left irc: [02:10] Bertl: I prefer /proc/virtual//info [02:10] fleshcrawler (~fleshcraw@212.202.16.134) joined #vserver. [02:10] okay and /proc/virtual/info would then contain an overview of the vserver system itself, right? [02:11] @fleshcrawler heyja1 [02:11] @fleshcrawler heyja! (I mean) [02:11] @bertl hehe. okay it booted! [02:11] but I get an error :-((( [02:12] which one? [02:12] 1st: mount type devpts not supported by kernel [02:12] 2nd: Can't set the ipv4 root (Bad address). [02:12] hmm, you probably forgot to select that ... [02:12] Last one I had with a patch yesterday. [02:12] nono. I use the vserver I was running a few minutes ago. [02:12] with the old kernel it will work [02:13] I meant the devpts in the kernel config ... [02:13] I used the same config for the new kernel [02:13] Bertl: /proc/virtual/ I would think [02:13] that's how alex does it and it works out [02:13] @fleshcrawler hmm, that's interesting ... [02:14] @matt and /proc/virtual/ is a file then, right? [02:14] yeah [02:14] just open 1 file to parse [02:14] @ensc what is your opinion on that? [02:14] well, he is /proc/vservers/, but essentially yes [02:14] Bertl: info about general context environment; [02:14] but / should be a directory [02:15] are you planning on /proc/virtual//{info|mem|...} ? [02:15] w8... I think I haven't set the devpts [02:15] or just info? [02:16] I guess we have some options, and we should think about how to use them optimally ... [02:16] if multiple files then make a directory, but that's just more work i would think... especially for the scripts that parse them for data [02:16] but there is /proc/meminfo, not /proc/mem/info [02:16] ... [02:16] one thing I have in mind, would be linking every process/pid to it's / directory ... [02:17] ahh... [02:17] another could be linking the / info to the pid ;) [02:18] I guess we could also do a //limits with an overview about exactly that 8-) [02:19] true [02:19] that would be useful, info and limits [02:19] would limits have just limits or also usage? [02:19] enrico, any comments? [02:20] guess we should discuss this with alex too, maybe we can agree on a common interface for that too ... [02:20] yes, a ...//pids/42 -> /proc/42 directory similary to /proc//fd would be good also [02:22] okay, I assume /proc/virtual//status would then be a good one ... right? [02:22] yep [02:23] mcp (~hightower@81.17.110.148) left #vserver (bloss wech hier ... ;-)). [02:23] okay, guess this will need a night, to code and sleep over it ;) [02:24] we continue the discussion tomorrow, and try to get alex's opinion, and maybe an agreement ... [02:24] would 16:00 CET be okay? [02:36] for me: yes [02:36] @matt any chance for you to pay a visit? [02:37] possibly, other factors depend on when i'm around .. [02:37] fleshcrawler (~fleshcraw@212.202.16.134) left irc: [02:39] fleshcrawler (~fleshcraw@port-212-202-16-134.reverse.qsc.de) joined #vserver. [02:40] okay. I did another kernel. but still it can't bind to the ip. [02:41] also I have an error with the ulimit. it sais invalid argument but it works anyway. [02:41] hmm, maybe you did hit a real issue there ... but let's check ... what kernel did you use before? [02:42] it was kernel 2.4.22-3 from debian [02:42] with the c17f patch ... [02:42] and I patched it with ctx17a as I see now... [02:42] hmm, okay ... so this _is_ a version upgrade then ;) [02:42] what tools do you use? [02:43] for baking? [02:43] no vserver userspace I mean ... [02:43] u mean newvserver tool? [02:43] you probably have a debian package which contains chcontext and chbind ... [02:44] the so called 'vserver' tools ... [02:44] yes [02:44] chbind is there [02:44] which version/name has this package? [02:44] chbind has 0.26 [02:44] also chcontext [02:44] hmm, you updated that one, or is this the same you used before? [02:45] vserver package version is 0.26-1 [02:46] well, there are some things which aren't sound yet .. I'll list them, and you try to find a good explanation, okay? [02:46] ok [02:47] I already get confused by all this patching stuff... [02:48] the ulimit issue is something introduced with 2.4.22pre3 or so ... you need to specify -HS instead of the 'usual' -H to override the soft setting ... this should actually be the case for _both_ your kernel .. can you explain why you hit it now? [02:48] ulimit works now. [02:49] what do you mean? [02:50] well it boils down to: 2.4.21 doesn't complain about the ulimit, 2.4.22 does ... how comes that 2.4.22-3-ctx17a doesn't complain, while 2.4.22-3-vs1.00 does? [02:50] all complain! [02:50] that's not the problem! [02:51] the problem is with setting the ipv4 root. [02:51] okay .. so we solved that one, right ;) [02:51] yeah... sorry. my english is a bit lame. [02:51] now for the ipv4root ... what is the exact error message you get? [02:52] Can't set the ipv4 root (Bad address) [02:52] what does 'chbind --ip 192.168.0.1 false' return? [02:53] same [02:53] netrose (~john877@CC3-24.171.21.47.charter-stl.com) left irc: Ping timeout: 493 seconds [02:54] well, that is actually wrong (should not happen) ... could you grab the tools from enrico and compile them by hand .. you do not need to install them ... [02:54] url? [02:54] http://savannah.nongnu.org/projects/util-vserver [02:57] are u sure the page works? [02:58] well ... savannah should, but I see what u mean .. get them here http://www.13thfloor.at/vserver/d_release/v1.1.1/util-vserver-0.24.tar.bz2 [02:59] just to get sure this is not one of my security measures... ;-) [03:00] that one worked. [03:02] doesn't compile. I guess it's my gcc. [03:02] which one do you use? [03:03] 3.something... I'm installing 2.95 [03:03] and you compiled the kernel with it, right? [03:03] yes [03:03] 3.x should work; what are the errors? somewhere in a kernel-header? [03:03] well, I would suggest, _after_ you've installed 2.95, just recompile the kernel and try again ... [03:04] yes... [03:06] could it all depend on the new gcc? [03:06] could be .. I tried with 3.1.2 and 3.2.1 IIRC, and both failed to compile a 2.4 kernel reliable ... [03:06] no, you have some strange kernel-headers? In which header do you got the errors? [03:07] those header errors are fixed... i had one in route.h and one in net/ipv4/udp.c [03:07] but it was the wrong ctx patch for my kernel. debian-ctx patches and other versions compiled well. [03:10] those header errors were only debian specific. the ctx patches worked well for kernel.org kernels. [03:16] well. I think I go to bed now. Tomorrow I'll try some more patching and I'll compile the vserver utils with new kernel headers. maybe new chbind will work then. [03:17] okay, make it so, if you still have problems then, we go for a hunt ;) [03:19] alright. goodnight then and thanks for your ears! [03:19] you are welcome, and good night too ... [03:19] bye [03:19] fleshcrawler (~fleshcraw@port-212-202-16-134.reverse.qsc.de) left irc: [03:23] @ensc before I forget, I made a change in the vs1.1.1 release I didn't mention yet ... [03:23] Bertl: which one? [03:24] I moved the dynamic context id's to the upper end ... to be more precise MIN_D_CONTEXT ... [03:25] currently it's defined as 49152 so dynamic contexts should automatically be taken from 49152 to 65535 ... [03:31] should not affect me [03:31] okay, was hoping you would say that ... ;) [03:32] what happens when 65535 is reached? [03:33] goes back to 49152? [03:33] yes, but doesn't use existing, same implementation as jack did, only the start was moved from 2 to MIN_D_CONTEXT [04:47] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [06:20] Jimsan (~jradford@206.80.113.25) joined #vserver. [06:21] Jimsan (~jradford@206.80.113.25) left #vserver. [07:23] Nick change: Bertl -> Bertl_zZ [10:33] mcp (~hightower@81.17.110.148) joined #vserver. [10:33] #vserver: mode change '+o mcp' by ChanServ!services@services.oftc.net [11:03] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [12:45] loger joined #vserver. [12:58] say (~say@212.86.243.154) joined #vserver. [13:25] kestrel_ (~athomas@dialup28.optus.net.au) joined #vserver. [14:01] serving (~serving@213.186.190.146) left irc: Ping timeout: 493 seconds [14:44] fleshcrawler (~fleshcraw@212.202.14.168) joined #vserver. [14:44] fleshcrawler (~fleshcraw@212.202.14.168) left irc: Client Quit [15:25] kestrel_ (~athomas@dialup28.optus.net.au) left irc: Quit: Hey! Where'd my controlling terminal go? [15:43] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Ping timeout: 493 seconds [15:53] serving (~serving@213.186.189.198) joined #vserver. [16:41] Nick change: surriel -> riel [17:03] Nick change: Bertl_zZ -> Bertl [17:03] hi all! [17:14] kestrel_ (~athomas@192.65.90.92) joined #vserver. [17:18] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [17:19] hi mhepp! [17:48] Hi! [17:48] ;) [17:50] I want to test some new release of ctx patch! [17:50] good ... which one? [17:50] I am not sure... [17:50] some testing one? [17:51] fine, take a look at the newly release v1.1.1 ... [17:52] FINE, where can I find it? [17:52] http://www.13thfloor.at/vserver/d_release/v1.1.1/ [17:52] as usual also announced and linked on linux-vserver.org ;) [17:53] :) [18:14] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [18:16] fleshcrawler (~fleshcraw@port-212-202-14-168.reverse.qsc.de) joined #vserver. [18:16] hello [18:16] hi! [18:17] are you having a conservation or may I talk? [18:17] no nothing to be conserved ;) [18:17] sorry... I meant conversation [18:17] ;-) [18:17] well all letters are there, that must be sufficient ... [18:18] yes. I think so. there is a study that sais it doesn't matter how you write a word. it's just important that all letters are there and the beginning end ending letter is right. [18:19] anyway. I played arround with the kernel patches. vserver is working again and no errors are reported. [18:19] what was you change, the compiler? [18:19] i used the c17f (which is called ctx17a after compiling). that one worked for me before. [18:20] I haven't tried the vs1.1.0 patches yet. [18:20] hmm, okay ... [18:21] I'll do them right now because I'll be away for some hours and meanwhile I'll let it compile. [18:21] just one confusing thing is that patch c17f becomes ctx17a kernel image. [18:22] well probably a mistake on my side .. not changing the extension in the Makefile to c17f instead of ctx17a ... OTOH it was an experimental release ... [18:24] well. just wanted to say that this patch works fine with the debian kernel. [18:25] hmm, yes, but I hope v1.00 does too ... because this should be the version to use ... [18:52] okay. kernel compiled. I'll boot and try. have to hurry... [18:53] so no word on jack re virtual network? :) [18:58] not yet, or at least not that I know ... [19:01] fleshcrawler (~fleshcraw@port-212-202-14-168.reverse.qsc.de) left irc: Ping timeout: 493 seconds [19:21] loger joined #vserver. [19:55] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [20:38] say (~say@212.86.243.154) left irc: Ping timeout: 493 seconds [21:22] netrose (~john877@CC3-24.171.21.47.charter-stl.com) left irc: Ping timeout: 493 seconds [21:33] any clue what would cause this: [21:33] New security context is 25 [21:33] Can't execute /bin/bash (Permission denied) [21:33] running that bash from the server works fine... [21:33] wrong context tag? [21:34] [root@vps4 cli]# chcontext --ctx 23 /vservers/smallinfi/bin/bash [21:34] New security context is 23 [21:34] Can't exec /vservers/smallinfi/bin/bash (Permission denied) [21:34] i did that numerous timwes [21:34] lsctx /vservers/smallinfi/bin/bash shows? [21:34] [root@vps4 cli]# chctx -V 23 /vservers/smallinfi/bin/bash [21:34] chctx 1.34 (25-Jul-2003) [21:34] Context of /vservers/smallinfi/bin/bash set as #23 [21:34] [root@vps4 cli]# chcontext --ctx 23 /vservers/smallinfi/bin/bash [21:34] New security context is 23 [21:34] Can't exec /vservers/smallinfi/bin/bash (Permission denied) [21:34] [root@vps4 cli]# lsctx /vservers/smallinfi/bin/bash [21:34] #23 /vservers/smallinfi/bin/bash [21:34] hmmmm.. [21:35] had this problem before and chctx worked [21:36] any clues? [21:38] check the permissions _and_ the context of the directories above ... [21:39] i've noticed a bunch of context permission denied stuff [21:39] well, I always run chctx -R /vservers/ [21:39] well that is actually a bad idea, if you have unified servers ;) [21:51] why? [21:52] what should the top directory be? ctx 0? [21:52] because all the unified files must belong to ctx0 ... [21:52] otherwise they can be read only by one context ... [21:53] hrm... [21:54] best is to move everything into context 0 and just change the files you are absolutely sure they arent unified (link count =1 for example) into that context [21:56] hrm [21:57] i'm just going to reunify [21:57] that should reset everything [21:57] hmm, why should it? [21:58] it's relinking [21:58] hrm, it's not i guess.. [21:59] fleshcrawler (~fleshcraw@port-212-202-14-168.reverse.qsc.de) joined #vserver. [21:59] hello again... [21:59] hi! [22:00] sorry. I didn't come back. had to meet with my band for practice. but I finnished the vs1.1.0 kernel. [22:01] it's the same problem. the vserver can't bind to the IP. [22:01] you are playing in a band? or singing? [22:01]