[01:05] SG1 (~sgarner@apollo.quattro.net.nz) joined #vserver. [01:05] Simon (~sgarner@apollo.quattro.net.nz) left irc: Read error: Connection reset by peer [01:06] Nick change: riel -> unriel [02:10] serving (~serving@213.186.190.211) left irc: Ping timeout: 485 seconds [02:17] SG1 (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [03:39] Nick change: Bertl -> Bertl_zZ [04:04] serving (~serving@213.186.190.6) joined #vserver. [07:03] iceberg_ (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [07:03] Bertl_zZ awake? [07:03] or am i too late [07:03] Nick change: iceberg_ -> infowolfe [07:03] :-\ [07:04] i'm wondering when vnet.c will be added :-p [07:06] omg! 2.6 is now the stable version! [07:10] Bertl_zZ are there any 2.6 patches? [07:58] mdaur_ (mdaur@pD9E053D3.dip.t-dialin.net) joined #vserver. [08:05] mdaur (mdaur@p509167A4.dip.t-dialin.net) left irc: Ping timeout: 485 seconds [08:22] Topic changed on #vserver by serving!~serving@213.186.190.6: http://linux-vserver.org/ || latest stable 1.22, devel 1.3.0 "Revolutions". [08:33] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [11:04] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [11:30] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [11:52] loger joined #vserver. [13:40] Last message repeated 1 time(s). [13:40] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) left irc: Read error: Connection reset by peer [13:42] Simon (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [14:11] Doener`` (~doener@p5082D4C3.dip.t-dialin.net) joined #vserver. [14:18] Doener` (~doener@pD9E12083.dip.t-dialin.net) left irc: Ping timeout: 485 seconds [14:24] say (~say@212.86.243.154) left irc: Ping timeout: 499 seconds [15:12] TamaPanda (~a@193.173.84.237) joined #vserver. [15:12] morn [18:08] loger joined #vserver. [18:16] Nick change: Bertl_zZ -> Bertl [18:16] hi everyone! [18:21] @ccoke there should be no difference regarding hardware between vs1.20 and vs1.22 (you can use the incremental patches) [18:22] @kungfuftr hi, how is sam, haven't heard from him for a while now ... [18:22] bertl: cheers [18:22] @kungfuftr what are the errors, do you have an strace? [18:23] @Tamama if you have results (regarding stability) please post them to the mailing list ... [18:23] heh [18:24] will do [18:25] are there any pre-made programs that stress-test a vserver? [18:26] there are some tools in alexey's branch, like the fork bomb and similar ... [18:26] we didn#t find the time/resources to add stress testing yet ... [18:26] hm [18:26] and the tools from Jonathan of course ... [18:27] is there documentation on the places that are changed by the patches needed to vserver? [18:27] I would appreciate a 'good' set of stress tests ... (we could even have them run on STP/OSDL) [18:27] the best documentation currently available is the source, in the split-* form ... [18:28] ugh [18:28] i'm not well versed in patches or the kernel [18:28] it's not soo bad anymore, because a) I did a lot of cleaning and b) it's separated [18:30] if you want to get a feeling # grep '^@@' ../split-2.4.23-vs1.22/05_2.4.23_sched.diff [18:30] @@ -165,7 +165,12 @@ static inline int goodness(struct task_s [18:30] @@ -618,8 +623,19 @@ repeat_schedule: [18:30] @@ -599,6 +599,8 @@ void update_process_times(int user_tick) [18:31] lsdiff ../split-2.4.23-vs1.22/05_2.4.23_sched.diff [18:31] linux-2.4.23/kernel/sched.c [18:31] linux-2.4.23/kernel/timer.c [18:31] so its quite easy to extract the relevant information, for the changes themselves you have to read the patches ... [18:31] right [18:32] i'll prolly write something to fork off processes that crash on purpose and see where that leads [18:32] just trying different stuff [18:33] good, make sure to 'explain' and 'discuss' your approaches on the mailing list, this usually gives good feedback ... [18:53] okay, brb ... [18:53] sorry... was afk just there [18:53] sam's okay, he's back in NZ for a while [18:53] doh! just noticed the brb [18:53] I'm back in about 10 minutes ... can we talk then ... [18:53] k [18:53] Nick change: Bertl -> Bertl_oO [19:15] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [19:15] 2.6 stable [19:15] where is the patch :P [19:15] lol [19:16] joke [19:26] serving (~serving@213.186.190.6) left irc: Read error: Connection reset by peer [19:28] Nick change: Bertl_oO -> Bertl [19:29] okay, I'm back ... kungfuftr? [19:29] lo [19:29] :P [19:29] hi shuri! [19:29] hi [19:29] 2 secs, i'll get the error message [19:29] @shuri hmm, I was not sure how to interpret the mail, if you are laughing about that ... [19:29] hehe [19:30] Unable to register (YPBINDPROG, YPBINDVERS, udp). [19:30] happens only with the vservers [19:31] hmm, this sounds like the service is contacting the rpc, could you verify that portmap is running and responsive? [19:31] it is [19:32] but the service fails to register via portmap? (be carefl, portmap is often accessed via 127.0.0.1, which will not work in vservers) [19:32] hm [19:32] why is that? (127.0.0.1) [19:32] sam went through this and we're very certain portmap is working as it should... [19:33] okay, can you provide an strace (>= 4.5) of the 'failing' connect/register? [19:33] socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7 [19:33] bind(7, {sin_family=AF_INET, sin_port=htons(770), sin_addr=inet_addr("0.0.0.0")}}, 16) = 0 [19:33] ioctl(7, 0x5421, [1]) = 0 [19:33] setsockopt(7, SOL_IP, IP_RECVERR, [1], 4) = 0 [19:34] sendto(7, "d\241\243\275\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0"..., 56, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("192.168.4.11")}}, 16) = 56 [19:34] @Tamama virtualization of local loopback is not here yet, jack is working on it ... [19:34] poll([{fd=7, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 [19:34] recvfrom(7, "d\241\243\275\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 400, 0, {sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("192.168.4.11")}}, [16]) = 28 [19:34] close(7) = 0 [19:34] write(2, "Unable to register (YPBINDPROG, "..., 49Unable to register (YPBINDPROG, YPBINDVERS, udp).) = 49 [19:34] pleas on a web page!!!!! [19:34] like that? [19:34] lol [19:34] =0) [19:34] http://paste.msunix.org [19:34] use that :) [19:34] ta [19:35] Doener`` (~doener@p5082D4C3.dip.t-dialin.net) left irc: Quit: Leaving [19:35] http://paste.msunix.org/index.php?view=3831 [19:35] tada! [19:37] hmm, this trace shows, that a bind, send and receive to the portmap works, but the reply is interpreted as a failure, so portmap just says "sorry dude, can't register" ... (my interpretation, YMMV) [19:38] maybe debug or verbose mode on portmap could shed some light on that? [19:38] hhhmmm... yeah... will peek and slap sam about it... ta! [19:38] also rpcinfo could provide some insight ... [19:41] what is the problem with 127.0.0.1.. its 'special' in some way? [19:42] well, the problem is, that using 127.0.0.1, currently would give you a shared ip among all vservers, which probably isn't what you are looking for ... [19:42] well as 127.0.0.1 is an ip... wouldnt you need to assign it first? [19:42] just like you assign other ip's to vservers [19:43] yup, if you do not assigne, you cannot use it ... [19:43] say (~say@212.86.243.154) left irc: Ping timeout: 485 seconds [19:43] so i do not see the problem? [19:43] just that the ports are shared [19:43] which could potentially be a nousance [19:44] `rpcinfo -b ypbind 1` ?? [19:45] @Tamama well, if you 'use' 127.0.0.1 in vserver A to attach port 80 and allow 127.0.0.1 in B, this vserver can make 'local' connections to A/80 [19:46] yes i can understand, but it is the same with all other ip's as well [19:46] @kungfuftr if you use ypbind version 1 ... [19:46] need to force the vserver to use only the IP assigned to it? [19:48] hm what software even uses 127.0.0.1 ? [19:48] portmapper for example ;) [19:48] never used it, never plan to :) [19:49] i dont assign 127.0.0.1 to allowed ip's so no prob for me :D [19:50] Bertl-> http://paste.msunix.org/index.php?view=3832 - that's what rpcinfo gives back [19:50] rpetre (~rpetre@82.76.7.19) joined #vserver. [19:50] hm if i assign an ip to a server.. and i send to another local port.. what ip does it use to send from? [19:50] Shuriz (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [19:51] hello [19:51] hi [19:52] @Tamama default kernel behaviour uses 0.0.0.0 and maps it to an arbitrary address available on the host ... [19:52] does anyone around here has any experience regarding vservers on debian woody with a recent kernel? [19:52] rpetre-> yeah? [19:52] sorta... [19:52] i kinda got stuck [19:52] hmm, define recent ... [19:53] 2.4.23 [19:53] yeah, were' running woody on a 2.4.23 vserver kernel [19:53] okay, lets hear ... [19:53] i compiled the kernel just fine [19:54] pppsssttt... any more idea bertl? [19:54] hm time for home [19:54] Tamama (~a@193.173.84.237) left irc: [19:54] and i installed the 'backport'-ed version of vserver-tools [19:54] but it seems they don't get along [19:55] @kungfuftr it seems yp is already running on that machine ... [19:55] @rpetre what is the 'backported' version? [19:55] *blink* very odd... cos it's defenitely not... same happens in every vserver [19:55] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Ping timeout: 499 seconds [19:56] 0.23 [19:56] rpetre-> build your own debian package from source, is an easy enough process [19:56] ah [19:56] ok [19:56] what version of vserver? [19:56] what patches did you use? [19:56] the patch says "patch-2.4.23-vs1.22.diff" [19:57] so 1.22 then [19:57] ok [19:57] and you probably got it from the release site, right? [19:57] yes... [19:57] did you see any notes regarding the tools? [19:57] none that i remember [19:58] i'll go check [19:58] hmm, maybe we should setup a matrix, tools vs version ... [19:58] yx [19:59] Shuriz (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Ping timeout: 499 seconds [20:00] should i use "vserver" or "util-vserver" ? [20:01] would you like coffe or tea? ;) [20:02] sorry, i don't get it [20:02] what's the difference (s) [20:02] ? [20:02] well, basically they are equally powerful ... [20:02] one set is written in C++ the other in plain C ... [20:02] they are maintained by different people and vary slightly in usage ... [20:03] I would suggest you try both, (one after the other) and decide for yourself ... [20:03] oh, ok, tx a lot [20:03] np [20:03] good bye [20:03] cu [20:03] rpetre (~rpetre@82.76.7.19) left irc: Quit: find / -name real.life -exec '{}' \; [20:10] @kungfuftr try running portmap with -d -v ... [20:10] hhhmmm... on 'real'(tm) server? [20:10] well wherever it runs now?! [20:11] you'll have to pardon me, new to vservers... more from a BSD jail background meself [20:11] I pardon you, using BSD jails ;) [20:11] *slap* [20:11] linux-- [20:11] *cough* [20:12] ^_^ [20:12] basically the vserver idea emerged from bsd jails ... so I guess we have no problem with that ... [20:13] where's portmap shove it's debug info? STDERR? [20:14] I assume so, but I don't know ... [20:14] maybe starting it in a shell would be a goot thing(tm) [20:15] hhhmmm... looks like i'll have to play with it at another point... the vservers are currently in use... a well [20:16] okay, np .. just let me know ... [20:17] pflanze (~chris@cc-linux4.ethz.ch) joined #vserver. [20:17] hello [20:17] hi chris! [20:17] what could be the reason for ssh inside a vserver suddenly hanging on one of my vserver-enabled machines? [20:18] which vserver patch version? [20:18] I do 'ssh myhost -p port' and it hangs forever, [20:18] starting ssh inside vserver as 'ssh -d' gives nice debugging output that ends with: [20:18] ... [20:18] debug1: PAM establishing creds [20:18] debug1: fd 10 setting O_NONBLOCK [20:18] debug1: fd 12 setting O_NONBLOCK [20:18] vs1.22 [20:18] on 2.4.23 [20:19] what does ssh -v myhost -p port give? [20:20] hmm, just to clarify, where is the sshd, and where the ssh? [20:20] client/server which one is running inside a vserver/on this host? [20:20] sshd is inside vserver (2.4.23-vs1.22), ssh is on my laptop. [20:20] (laptop w/o vserver) [20:20] ssh -v gives: [20:20] any ssh connections to the host server? [20:20] ... [20:20] debug1: fd 3 setting TCP_NODELAY [20:20] debug1: channel 0: open confirm rwindow 0 rmax 32768 [20:20] Environment: [20:20] [20:21] (then the environment, same as without -v but sshd -d) [20:21] and hangs here. [20:21] what user you trying to log in as? [20:21] ssh to the host works. [20:21] are there any messages in /var/log/messages? [20:21] (regarding this issue of course ;) [20:21] normal user and root both hang. [20:22] hmm, is this a 'new' behaviour, or just the first try? [20:23] This is new. [20:24] no messages in the logs except this in auth.log: [20:24] Dec 18 18:24:33 ethlife-b-kontro ssh(pam_unix)[1043]: session opened for user root by (uid=0) [20:24] Dec 18 18:24:40 ethlife-b-kontro ssh(pam_unix)[1043]: session closed for user root [20:24] which looks normal [20:24] okay, let me make an educated guess: take the ip your laptop has, and add it to /etc/hosts inside the vserver ... [20:24] the closed only there if I force kill the ssh client. [20:25] something like ... [20:25] 192.168.0.2 laptop [20:25] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [20:25] still hangs [20:27] btw I *do* have a reverse lookup name, and it even works with the "host" command from inside vserver. [20:27] so dns works. [20:27] do any other services work on the vserver, ie: apache, smtp, pop, etc. [20:27] yes apache works fine. [20:28] iptables is flushed? [20:28] hmm, is /dev/pts mounted correctly on the vserver? [20:28] (check on the host, or via /proc/mounts) [20:29] also try to connect more than once (3-4 conenctions), leaving the 'hanging' sshs around for some while ... [20:30] I think it's pts [20:30] none /mnt/md13/vserver/kontro/dev/pts devfs rw 0 0 [20:30] none /mnt/md13/vserver/kontro/dev/pts devpts rw 0 0 [20:30] none /mnt/md13/vserver/kontro/dev/pts devfs rw 0 0 [20:30] I do one too many devfs mount [20:30] yup, devfs doesn't work on vserver /dev/pts ... [20:31] yeah, I still had 'mount -t devfs none "$ROOTDIR"/dev/pts/' in my startup script [20:31] you have to use /dev/pts for now ... [20:31] sorry devpts ... [20:31] maybe you remember - I had this problem already once, about a month ago, when I did first set up this vserver (my first one). [20:31] shame on me, I already forgot. [20:32] Well, does this already deserve an FAQ entry? [20:32] go ahead ... it won't hurt ;) [20:33] working fine now. [20:34] I had a look at devfs, but it's not simple to add the required modifications, and it's depreciated anyway, although I use it without issues (on the host) [20:35] Bertl-> been playing with 2.6.0 then? [20:35] Yes, I'm using devfs on all (real) machines as well, like it. Hope they come up with something better before devfs is removed. [20:35] sure, otherwise we would not have 2.6 vserver hacks ... [20:36] any huge benefit to using it as of yet? [20:36] @pflanze well, udev might replace it in 2-3 years ;) [20:37] @kungfuftr 2.6, devfs or the hack? [20:38] 2.6 [20:39] well, some stuff isn't supported on 2.4 (and probably never will) the kernel seems faster, and scales better .. but it's far from perfect yet ... [20:40] hhhmmm... all the more reason to use 4.9 [20:53] @ALL any opinions regarding preemption, O(1) sheduler, etc? [20:53] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Quit: ipv6 [20:55] ask sam... =0) [20:55] well, I did, but got no reply yet ... [21:20] pflanze (~chris@cc-linux4.ethz.ch) left irc: Ping timeout: 499 seconds [21:20] okay, have to leave now, cu all l8er ... [21:20] Nick change: Bertl -> Bertl_oO [21:23] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [23:36] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Quit: ipv6 [23:36] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [00:00] --- Fri Dec 19 2003