1207008547 Q * _gh_ Ping timeout: 480 seconds
1207008714 Q * doener Quit: leaving
1207008896 J * doener ~doener@i577B8399.versanet.de
1207008975 J * Infinito ~argos@200-140-69-56.gnace701.dsl.brasiltelecom.net.br
1207010244 Q * bzed Remote host closed the connection
1207010252 J * bzed ~bzed@devel.recluse.de
1207010270 Q * Infinito Quit: Leaving
1207010273 Q * sladen Ping timeout: 480 seconds
1207010381 J * sladen ~paul@starsky.19inch.net
1207010802 J * dowdle_ ~dowdle@71-221-12-249.blng.qwest.net
1207011198 Q * dowdle Ping timeout: 480 seconds
1207012198 Q * sladen Ping timeout: 480 seconds
1207012325 J * Infinito ~argos@200-140-69-56.gnace701.dsl.brasiltelecom.net.br
1207012937 J * sladen paul@starsky.19inch.net
1207013349 P * dowdle_ Konversation terminated!
1207013676 Q * sladen Read error: Connection reset by peer
1207014655 Q * Infinito Quit: Leaving
1207015346 J * nauman ~nauman@pool-71-98-95-123.ipslin.dsl-w.verizon.net
1207015901 J * _gh_ ~gerrit@c-67-169-199-103.hsd1.or.comcast.net
1207017018 Q * comcardllc|com Ping timeout: 480 seconds
1207019506 Q * phedny Ping timeout: 480 seconds
1207020225 N * ensc Guest185
1207020235 J * ensc ~irc-ensc@77.235.182.26
1207020328 Q * Guest185 Remote host closed the connection
1207021608 Q * quasisane Remote host closed the connection
1207022933 Q * nauman Ping timeout: 480 seconds
1207023305 J * phedny ~mark@2001:610:656::115
1207023618 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1207024978 Q * xdr_ Read error: Connection reset by peer
1207027703 J * nauman ~nauman@pool-71-98-95-123.ipslin.dsl-w.verizon.net
1207027764 J * Slydder ~chuck@194.59.17.53
1207027950 M * Slydder morning all
1207028369 M * glen_ any news for today? like vserver merged to upstream for such special day as today? :)
1207028651 J * cryptronic ~oli@p54A3BB05.dip0.t-ipconnect.de
1207028677 J * quasisane ~sanep@c-76-118-191-64.hsd1.nh.comcast.net
1207028730 J * sharkjaw ~gab@64.28.12.166
1207031045 J * JonB ~NoSuchUse@77.75.164.169
1207031290 Q * larsivi Remote host closed the connection
1207031311 Q * tobifix Quit: ( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )
1207031433 J * ntrs__ ~ntrs@77.29.66.85
1207032353 Q * nauman Ping timeout: 480 seconds
1207032618 J * dna ~dna@36-234-dsl.kielnet.net
1207033005 J * tobifix ~tobifix@IVV7KNALLER.UNI-MUENSTER.DE
1207033100 J * xdr ~xdr@137-173-96-87.cust.blixtvik.se
1207033129 Q * JonB Quit: This computer has gone to sleep
1207033552 J * virtuoso_ ~s0t0na@ppp91-122-102-51.pppoe.avangarddsl.ru
1207033781 J * ftx ~ftx@dslb-084-060-206-206.pools.arcor-ip.net
1207033963 Q * virtuoso Ping timeout: 480 seconds
1207034432 J * ntrs_ ~ntrs@77.29.75.93
1207034867 Q * ntrs__ Ping timeout: 480 seconds
1207035544 N * DoberMann[ZZZzzz] DoberMann
1207035707 J * yarihm ~yarihm@vpn-global-dhcp3-255.ethz.ch
1207035807 Q * dna Quit: Verlassend
1207036341 M * Slydder have a strange problem with util-vserver not starting default clients on startup. anyone else expierencing this?
1207036381 M * daniel_hozac have you enabled the initscript?
1207036417 M * Slydder it's enabled. but it won't start the default guests
1207036492 M * Slydder i have to manually start even though /etc/vservers/guestname/apps/init/mark is there and default is the only value in it.
1207036511 M * daniel_hozac so you've got links to it in /etc/rc2.d?
1207036529 M * Slydder yes. it runs at startup
1207036531 M * Slydder S20
1207036560 J * arapaho ~arapaho@77.197.56.222
1207036583 M * daniel_hozac and od -tx1 /etc/vservers/<guest>/apps/init/mark shows that you have exactly "default\n"?
1207036635 M * daniel_hozac S20 sounds very early for vservers-default.
1207036661 M * Slydder no that's util-vserver
1207036729 M * daniel_hozac so either you're using the Debian package, or you don't have it enabled.
1207036747 M * Slydder and with od -tc /etc/vservers/guest/apps/init/mark it shows default\n
1207036772 M * Slydder vservers-default has to be linked in?
1207036785 M * Slydder I installed from source
1207036851 M * daniel_hozac yes.
1207036854 M * Slydder i have the vservers-default script in /etc/init.d/ but it's not set to run in rc2.d
1207036856 M * Slydder ok
1207036864 M * Slydder suggested level?
1207036887 M * daniel_hozac head /etc/init.d/vservers-default
1207036891 M * Slydder 98
1207036894 M * Slydder got it
1207036954 M * Slydder and util-vserver should still be left at S20 correct
1207036989 M * daniel_hozac it's fine, i suppose.
1207037000 M * daniel_hozac make sure you enable vprocunhide too.
1207037028 M * Slydder I have it at S19
1207037063 M * Slydder strange though. it worked fine before the upgrade. oh well.
1207037080 M * Slydder will find out if it works next time I take it down for maintainance
1207037277 Q * cryptronic Quit: Leaving.
1207037682 J * JonB ~NoSuchUse@130.227.63.19
1207037888 J * DavidS ~david@85.124.123.86
1207038335 Q * arapaho Remote host closed the connection
1207038435 J * friendly12345 ~friendly@ppp121-44-224-29.lns2.mel4.internode.on.net
1207038968 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1207039600 Q * balbir Read error: Operation timed out
1207040341 J * balbir ~balbir@122.167.210.43
1207040369 N * virtuoso_ virtuoso
1207041456 Q * xdr Ping timeout: 480 seconds
1207044200 J * jsambrook ~jsambrook@aelfric.plus.com
1207044653 Q * DavidS Quit: Leaving.
1207045351 J * xdr ~xdr@19-173-96-87.cust.blixtvik.se
1207045984 J * yarihm_ ~yarihm@vpn-global-dhcp3-255.ethz.ch
1207046013 Q * yarihm Ping timeout: 480 seconds
1207046098 J * ftx_ ~ftx@dslb-084-060-225-237.pools.arcor-ip.net
1207046420 J * dna ~dna@36-234-dsl.kielnet.net
1207046503 Q * ftx Ping timeout: 480 seconds
1207047586 Q * mrfree Quit: Leaving
1207049834 Q * balbir Read error: Operation timed out
1207050721 J * balbir ~balbir@122.167.201.89
1207051115 Q * friendly12345 Quit: Leaving.
1207051382 Q * ntrs_ Ping timeout: 480 seconds
1207051618 Q * balbir Ping timeout: 480 seconds
1207052062 Q * xdr Ping timeout: 480 seconds
1207052262 J * balbir ~balbir@122.167.206.245
1207052747 J * xdr ~xdr@19-173-96-87.cust.blixtvik.se
1207053431 Q * Aiken Quit: Leaving
1207053783 Q * glen_ Ping timeout: 480 seconds
1207054440 Q * opuk Remote host closed the connection
1207054655 J * ftx__ ~ftx@dslb-084-062-231-115.pools.arcor-ip.net
1207054967 Q * ftx_ Ping timeout: 480 seconds
1207055336 Q * sharkjaw Quit: Leaving
1207055391 Q * JonB Quit: This computer has gone to sleep
1207056285 J * hparker ~hparker@linux.homershut.net
1207056792 J * er ~sapan@pool-71-188-83-135.cmdnnj.east.verizon.net
1207057182 J * opuk ~kupo@2001:16d8:ffbd:100::10
1207058087 M * er hiya
1207058656 J * virtuoso_ ~s0t0na@ppp78-37-193-65.pppoe.avangarddsl.ru
1207059044 J * DavidS ~david@helios.uni-ak.ac.at
1207059067 Q * virtuoso Ping timeout: 480 seconds
1207059777 N * virtuoso_ virtuoso
1207059849 J * FireEgl Proteus@2001:5c0:84dc:1:4:ff:fe00:1
1207060238 Q * tobifix Quit: Leaving
1207060420 J * yarihm ~yarihm@hg-public-dock-67-dhcp.ethz.ch
1207060718 Q * yarihm_ Ping timeout: 480 seconds
1207060834 J * dowdle ~dowdle@71-221-12-249.blng.qwest.net
1207061256 Q * yarihm Ping timeout: 480 seconds
1207061630 Q * Slydder Quit: Leaving.
1207062563 J * dna_ ~dna@99-196-dsl.kielnet.net
1207062648 Q * DavidS Quit: Leaving.
1207062697 J * ftx_ ~ftx@dslb-084-062-248-244.pools.arcor-ip.net
1207062968 Q * dna Ping timeout: 480 seconds
1207063007 Q * ftx__ Ping timeout: 480 seconds
1207063867 P * Knorrie 
1207065106 J * onox ~onox@kalfjeslab.demon.nl
1207065658 J * JonB ~NoSuchUse@77.75.164.169
1207066469 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1207067782 J * virtuoso_ ~s0t0na@ppp91-122-186-75.pppoe.avangarddsl.ru
1207067890 N * DoberMann DoberMann[PullA]
1207068207 Q * virtuoso Ping timeout: 480 seconds
1207068297 Q * JonB Quit: This computer has gone to sleep
1207068611 J * nauman nauman@pal-179-051.itap.purdue.edu
1207068957 N * Bertl_zZ Bertl
1207068962 M * Bertl morning folks!
1207069032 M * daniel_hozac morning Bertl!
1207069038 M * hparker Morning Bertl!
1207069264 J * Slydder ~chuck@dslb-088-072-014-228.pools.arcor-ip.net
1207069406 J * JonB ~NoSuchUse@0405ds1-noe.0.fullrate.dk
1207070093 J * hijacker ~Lame@87-126-142-51.btc-net.bg
1207070233 M * er hi Bertl 
1207070451 M * er what happens if a process gets a SIGKILL while it's in Hs state? does it enter do_exit immediately? or when it starts getting tokens anew?
1207070500 J * Julius ~julius@p57B25ABF.dip.t-dialin.net
1207070534 M * Bertl er: it is halted until it gets more tokens
1207070617 M * er ok, and when it does get more tokens, I suppose the scheduler sends it into do_exit immediately 
1207070651 M * Bertl yes, normal scheduler actions should be taken (which includes signal delivery)
1207070961 M * er ok. there's this potential race that I'm looking into that might be happening on some nodes in PL.
1207070986 M * er what if a task is sleeping on a mutex, but enters into Hs state when it is woken up from the sleep
1207070986 M * daniel_hozac (it should be noted there's a scheduler patch in the kernel)
1207070995 M * er absolutely :)
1207071027 M * er so the bug is possibly something PL-related, but I'm just trying to diagnose the situation.
1207071049 M * Bertl sleeping on a kernel or userspace mutex?
1207071051 M * er and then it gets a SIGKILL so that the mutex value is never decremented
1207071057 M * er kernel mutex
1207071069 J * Slydde1 ~chuck@dslb-088-072-014-228.pools.arcor-ip.net
1207071078 M * er the mutex is never unlocked, that is.
1207071082 M * Bertl so the task is in kernel space, yes?
1207071087 M * er yes.
1207071097 M * Bertl then it should not be halted at all
1207071119 M * Bertl we never halt kernel space execution
1207071125 M * daniel_hozac preempt?
1207071142 M * er ok, but in this case PL is not using preempt
1207071230 M * er kernel-space execution is never halted even if there's a call to schedule() in a codepath?
1207071308 M * Bertl well, with preemption, it could get halted, but OTOH, that is probably what you want in this case
1207071317 Q * Slydde1 
1207071339 M * Bertl once the context gets tokens, the scheduler will reschedule and continue where it left (i.e. on the mutex)
1207071364 M * er right, but the case I'm looking at is if it were to get a SIGKILL in the meantime
1207071406 Q * Slydder Ping timeout: 480 seconds
1207071417 M * Bertl well, IMHO that is not different from the normal behaviour, just potentially delayed, no?
1207071443 M * er Bertl: exactly
1207071445 M * Bertl i.e. either we do not interrupt the mutex/signal cycle (no halt state) and it happens as 'normal'
1207071477 M * Bertl or we interrupt it (at a scheduling point) and continue, at the same point, once tokens are available
1207071492 M * Bertl (doing the same sequence as above)
1207071555 M * er right, it's the same sequence, but we had this bug (like daniel pointed out, possibly because of the PL scheduler patch) 
1207071601 M * er that made it so that tasks wouldn't get tokens anymore - and it was associated with really weird behaviour, like filesystem corruption
1207071640 M * Bertl without sync, I presume
1207071641 M * er i'm not totally sure that one causes the other, but eg. one of the things we observed were various processes getting stuck on inode->i_mutex
1207071736 M * er and it turned out that the mutex held by these tasks had its owner set to some process using pipe_write/pipe_wait
1207071742 J * yarihm ~yarihm@guest-docking-nat-1-084.ethz.ch
1207071839 Q * ruskie Remote host closed the connection
1207071839 M * er so my grand hypothesis, at this moment, is that this race I mentioned happened - some process using pipe() got KILLED while it was waiting on i_mutex
1207071839 M * Bertl hmm, yeah, question is, why did that context stop getting tokens in the first place?
1207071840 M * er so that when its pipes got cleaned up when it died, a bad inode got inserted into the slab, poisoning it so that on the next alloc_inode some poor fs routing got a bad mutex.
1207071852 M * er Bertl: yes, Andy is looking into that right now
1207071908 M * Bertl okay, send greetings to him! :)
1207071932 M * er www.cs.princeton.edu/~sapanb/blockers
1207071987 M * er also blockers2
1207072023 J * ruskie ruskie@ruskie.user.oftc.net
1207072035 M * er but I suppose that even though it may not be 'exposed' in the mainline kernel, it's still a race - if a process waiting on a mutex gets a SIGKILL
1207072099 M * er then the mutex becomes defective.
1207072121 M * er unless I'm mistaken, which daniel_hozac will confirm happens quite often :)
1207072176 J * tobifix ~tobifix@muedsl-82-207-250-104.citykom.de
1207072287 M * daniel_hozac hehe
1207072287 M * daniel_hozac not too often ;)
1207072287 M * tobifix good evening dudes :P
1207072530 Q * PowerKe Ping timeout: 480 seconds
1207072568 Q * bronson Quit: Ex-Chat
1207072601 J * mmouse_office ~mmouse@office.haefft.de
1207072689 M * mmouse_office hi! is there an uptodate vserver patch against adrian bunk's stable tree 2.6.16(.60)?
1207072700 N * mmouse_office mmouse
1207072730 M * daniel_hozac IIRC the latest is against 2.6.16.52.
1207072738 M * daniel_hozac and that's probably missing a number of fixes.
1207072760 Q * Bertl Ping timeout: 480 seconds
1207072842 M * mmouse umh, guessed something like that...
1207074143 M * mmouse thx
1207074145 Q * mmouse 
1207074653 Q * quasisane Ping timeout: 480 seconds
1207075627 J * doener_ ~doener@i577B991D.versanet.de
1207076038 Q * doener Ping timeout: 480 seconds
1207076311 J * bronson ~bronson@adsl-68-122-117-135.dsl.pltn13.pacbell.net
1207076484 Q * er Quit: er
1207077342 J * Bertl herbert@IRC.13thfloor.at
1207077814 J * mick_work_ ~clamwin@h-74-2-196-229.miatflad.covad.net
1207077853 Q * daniel_hozac Ping timeout: 480 seconds
1207077863 Q * opuk Ping timeout: 480 seconds
1207078148 Q * mick_work Ping timeout: 480 seconds
1207078156 N * mick_work_ mick_work
1207079212 J * daniel_hozac ~daniel@ssh.hozac.com
1207079221 J * opuk ~kupo@2001:16d8:ffbd:100::10
1207079893 Q * dowdle Quit: Konversation terminated!
1207080028 Q * JonB Quit: This computer has gone to sleep
1207080035 Q * yarihm Quit: This computer has gone to sleep
1207080161 J * dowdle ~dowdle@71-221-12-249.blng.qwest.net
1207080501 M * arachnist aaej
1207080962 J * erikthered ~erikthere@its-er.lrc.txstate.edu
1207081490 J * yarihm ~yarihm@84-75-103-252.dclient.hispeed.ch
1207081588 M * erikthered Hi all - I'm erikthered - I had a question relating to guest interfaces 
1207081609 M * Bertl hey erikthered! let's hear!
1207081743 J * JonB ~NoSuchUse@77.75.164.169
1207081755 M * Bertl a, had, so it got solved already?
1207081756 M * erikthered thanks - I have created a guest (vs2), duplicated from an existing vserver; there's no network device that's created when I bring up the original vserver (called vstest1) but when I bring up the duplicated vserver (vs2), I'm seeing an alias device come up
1207081799 M * Bertl how did you 'duplicate' it?
1207081913 M * erikthered using the util-vserver package script called dupvserver, with the patch found at http://wiki.yobi.be/wiki/Vserver_tools
1207081934 M * daniel_hozac there's no such thing.
1207081935 M * erikthered it basically updates the util-vserver script dupvserver to work with the new configuration style
1207081959 M * daniel_hozac again, not util-vserver.
1207081963 M * daniel_hozac that's vserver-debiantools.
1207081980 M * erikthered Ah.  okay.  apologies.  
1207081987 M * Bertl erikthered: so you want to check with the debian folks ..
1207081992 M * daniel_hozac well, Ola actually.
1207082011 M * daniel_hozac nobody else cares about it, AFAIK.
1207082019 M * erikthered okay.  
1207082176 M * erikthered I was reading through the flower page
1207082199 M * Bertl most likely, the tool created a config with an alias interface
1207082214 M * Bertl if you remove that, you should be (somewhat) fine
1207082236 M * erikthered where is that defined?  what i meant to say above was i couldn't find anything relating to it on the flower page
1207082242 M * Bertl in the future use the 'clone' method of util-vserver
1207082285 M * daniel_hozac erikthered: /etc/vservers/<guest>/interfaces/*/name
1207082360 M * erikthered I see;  the issue I'm seeing is that my original guest, vstest1, has the identical entry as the  clone, vs2;  when vstest1 comes up, there's no alias device created, only when vs2 is started
1207082423 Q * dna_ Ping timeout: 480 seconds
1207082483 M * Bertl well, I really doubt that they have the identical entries, but, to make sure, start both guests with --debug and upload the output
1207082498 M * Bertl (e.g. to paste.linux-vserver.org)
1207082588 Q * opuk Quit: leaving
1207082670 M * erikthered okay I'll have that up in a sec
1207082707 J * opuk ~kupo@2001:16d8:ffbd:100::10
1207083130 M * erikthered here's the first http://paste.linux-vserver.org/11897
1207083159 Q * hijacker Quit: Leaving
1207083160 M * erikthered and the second http://paste.linux-vserver.org/11898
1207083189 M * erikthered I possibly don't understand the exact semantics behind the private networking iptables tricks, but my model creates a private network using a dummy device and all the traffic is routed through my public interface;  i wanted to avoid creating network aliases (if possible) and earlier I had three guests running, all of which could see eachother, none of which had alias devices, and each were serving web pages (using reverse proxy called Pound)
1207083223 M * Bertl yes, that's the normal setup you get with util-vserver
1207083243 M * Bertl (ignoring the dummy part, but YMMV)
1207083300 M * Bertl daniel_hozac: /etc/vservers/vs2/interfaces/0/indirect what's that?
1207083330 M * Bertl seems to be part of the modifications
1207083335 Q * Julius Remote host closed the connection
1207083362 M * Bertl erikthered: I'd suggest to get an unpatched util-vserver (preferably 0.30.214+)
1207083428 M * erikthered that reference to ../indirect not in that patch; nor is it in my directory listing
1207083519 M * Bertl well, I see a lot of checks and information gathering which I'm not really familiar with, fact is, the tools decide to create the alias
1207083524 M * Bertl _addInterfaceCmd IP_ADDR 10.1.1.12/24 broadcast + label dummy0:10 dev dummy0  
1207083541 M * Bertl _addInterfaceCmd IP_ADDR 10.1.1.10/24 broadcast + label dummy0:10 dev dummy0
1207083560 M * Bertl note: the alias is created in both cases, i.e. for vs1 and vs2
1207083575 M * erikthered indeed I see that - I didn't realize one was overwriting the other.
1207083602 M * Bertl so, you want to assign an ip, but you don't want an alias, right?
1207083609 M * erikthered correct -
1207083621 M * Bertl in this case, you want to have the following in .../interfaces/
1207083631 M * Bertl 'dev' containing dummy0
1207083641 M * Bertl 'ip' the ip you want to get
1207083661 M * Bertl 'prefix' or 'netmask' with the netmask
1207083666 M * Bertl nothing else
1207083675 M * erikthered okay - no "name"
1207083680 M * Bertl precisely
1207083691 M * erikthered alright.  
1207083704 M * Bertl and you want to remove the existing aliases/addresses before starting
1207083728 A * ard feels the urge to really document the "why lo is enough" FAQ already, but really has to got sleep :-)
1207083742 M * daniel_hozac Bertl: indirect is some magic to setup a dummy interface per guest.
1207083769 M * erikthered i just stopped both of those guests, and just started up the single guest vs1 - no alias device is created;
1207083826 M * erikthered that's what I'm curious about most; I can't figure out what I've done (other than ifconfig dummy:10 down) for that host 
1207083843 M * erikthered * that doesn't allow it to create an alias
1207083882 M * Bertl well, you said you didn't want an alias, yes? :)
1207083912 M * erikthered that's correct - but i cannot find what is different between the two guests; one was cloned off the other; the clone creates the alias
1207083929 M * erikthered i don't want that clone creating aliases
1207083941 M * ard Hmmm
1207083947 M * erikthered I'll go ahead and  remove the 'name' from each device; 
1207083952 M * erikthered *each guest
1207083955 A * ard always explicitly put's the interface name in dev
1207083960 M * Bertl yes, because _both_ create the aliases
1207083961 M * ard in my case lo
1207083962 Q * bonbons Quit: Leaving
1207083986 M * Bertl erikthered: if you remove the IP assigned to the first guest, and restart it, it will also create the alias
1207084278 M * erikthered Bertl: do you mean remove the interfaces/0/ip file?
1207084308 M * erikthered only started up the first vserver and here's it's debug output http://paste.linux-vserver.org/11899
1207084342 M * Bertl nah, you host has that ip already assigned (guest)
1207084351 M * Bertl *your
1207084376 M * Bertl i.e. you want first to use 'ip addr del 10.1.1.10/24' on the host
1207084385 M * erikthered no it's not assigned through any device;  
1207084392 M * Bertl ip addr ls
1207084488 M * erikthered only ip address assigned to 10.1.1.* is 10.1.1.1 for the dummy0 interface
1207084528 Q * nauman Ping timeout: 480 seconds
1207084533 M * erikthered Bertl: would you be here in 20? I'm being summoned for a meeting
1207084533 Q * daniel_hozac Ping timeout: 480 seconds
1207084539 Q * opuk Ping timeout: 480 seconds
1207084546 M * Bertl erikthered: k, fine for me
1207084549 M * erikthered (if not, thanks for your help - I'll keep working at it)
1207084695 M * ard hmmm
1207084707 A * ard has bad experiences with 2.6.24.4+vs2.3.0.34
1207084715 M * ard (and the latest madwifi trunk)
1207084722 M * ard It just spontaneously reboots
1207084733 M * ard (when the wifi card associates...)
1207084778 M * Bertl did you verify without the vserver patches=
1207084781 M * Bertl s/=/?
1207084782 M * ard leave out the (...) to get a bad feeling about vs2.3.0.34 (which is running fine btw on another machine without madwifi ;-) )
1207084860 M * ard Bertl : it is 99.9% sure the madwifi driver... It never performed 100% stable, but usually stable enough to use it.
1207084880 M * ard madwifi+vtund+nfs and updatedb is a sure way to kill my macbook ;-)
1207084896 M * Bertl the madwifi-ng driver works quite fine here
1207084922 M * ard yes, but what if you do nfs over vtun over wifi?
1207084944 M * ard without the nfs over vtun over wifi I have no problems
1207084953 M * ard except for 11Mb...
1207085039 M * ard I will be glad when the ar5k drivers are stable enough :-).
1207085171 A * ard will upgrade his development server to 2.6.24.4-vs2.3.0.34 tommorow
1207085192 M * ard best way to test it is to add a little load to the server :-)
1207085199 M * ard O/~
1207085213 M * Bertl yep, load is always good
1207085405 J * daniel_hozac ~daniel@ssh.hozac.com
1207085406 J * opuk ~kupo@2001:16d8:ffbd:100::10
1207085422 M * Bertl seems the internet is a little bumpy today ...
1207085452 M * daniel_hozac or at least my tunnel broker.
1207086396 Q * ftx_ Remote host closed the connection
1207086487 M * erikthered Bertl: I made it back
1207086504 M * Hollow good that i'm not the only one with lame connection today ;)
1207086509 M * Hollow ISPs april fool ;)
1207086571 M * erikthered :) 
1207086803 J * Aiken ~james@ppp121-45-192-61.lns1.bne1.internode.on.net
1207086987 M * Bertl erikthered: wb!
1207087025 Q * tobifix Quit: ( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )
1207087291 Q * yarihm Quit: This computer has gone to sleep
1207087425 M * erikthered I'm here -  I removed the "name" from the second guest instance; that prevented the alias from being made
1207087453 M * Bertl as expected, 'name' means: create an alias
1207087487 M * erikthered alright good - that's a step in the direction I was looking
1207087508 Q * JonB Quit: This computer has gone to sleep
1207087649 M * erikthered there still exists a "name" in my vstest1 interface/0/ directory however; what could be preventing the creation of the alias device?
1207087680 M * Bertl if the ip already exists on a different interface/alias, then the alias will not be created
1207087923 M * erikthered i see - okay - it looks like it's creating the device, and because there's an entry in the host /etc/network/interfaces for dummy0, it's reading that config, which assigns it 10.1.1.1;
1207087988 M * erikthered (by the way I'm running a ubuntu 6.06lts if that helps any)
1207088019 M * Bertl that's fine, look util-vserver (unpatched) works like this:
1207088040 M * Bertl ip/prefix or ip/netmask -> create ip and assign to guest
1207088055 M * Bertl + name -> create alias and assign to guest
1207088067 M * Bertl + nodev -> do not create, just assign to guest
1207088084 M * Bertl that's it
1207088098 M * erikthered okay - is that in the vserver.start script?
1207088347 M * arachnist http://repo.or.cz/w/linux-2.6/zen-sources.git?a=commitdiff;h=58451232f4f2b3eb305499a494886c32c448d574 <| lol
1207088860 M * erikthered Bertl: well thanks for the help I appreciate it
1207089175 M * Bertl erikthered: you're welcome!
1207090394 Q * erikthered Quit: erikthered
1207091581 Q * onox Quit: zZzZ
1207092666 J * quasisane ~sanep@c-76-118-191-64.hsd1.nh.comcast.net