1139443219 M * Skram something in /etc got messed up
1139443230 M * Skram fixed and trying the greular vserver name stop..
1139443253 M * Skram A timeout occured while waiting for the vserver to finish and it will
1139443254 M * Skram be killed by sending a SIGKILL signal. The following process list
1139443254 M * Skram might be useful for finding out the reason of this behavior:
1139443268 M * Skram 27521 17620 <<<name>>> ?        Ss     0:00 init [6]  
1139443268 M * Skram ----------------------------------------------------------------------
1139443269 M * Skram ?
1139443271 M * Skram Any ideas.
1139443289 M * Skram ill try it again, see if no errors.
1139443363 M * Skram it /sbin/runscript.sh: line 32: /var/lib/init.d/softlevel: No such file or directory
1139443366 M * Skram hrmmm
1139443369 P * meandtheshell 
1139443460 M * arnaud Bertl, it seems that on a "physical" server, the bind() call doesn't appear in strace, is it possible?
1139443500 M * Bertl with equivalent config, no
1139444490 J * ScoobyD00 ~foo@80-195-186-201.cable.ubr08.newm.blueyonder.co.uk
1139444542 M * ScoobyD00 hi - can i ask - does a guest access a USB port in the same way as if it were a host?
1139444600 M * ScoobyD00 (am having trouble running CUPSD in a vserver guest)
1139444777 M * Bertl well, given the device is available inside the guest, yes
1139444790 M * ScoobyD00 hi bertl :o) was hoping you would be here
1139444844 M * ScoobyD00 do i have to do something specific to make the device available?
1139444854 M * ScoobyD00 or is it more a problem with the guest OS?
1139444892 M * Bertl you have to copy the device nodes inside ... don't know what that would be for usb printers though
1139444922 Q * ag- Read error: Connection reset by peer
1139444928 M * ScoobyD00 when running on the host (gradually moving services into guests) it used "/dev/usblp0"
1139444937 M * ScoobyD00 so if i make that node in the guest, all should be ok?
1139444942 J * ag- ag@caladan.roxor.cx
1139444971 M * Bertl if it doesn't require special capabilities, then yes
1139445178 M * ScoobyD00 thanks - all working
1139445226 Q * Doener Quit: Leaving
1139445238 M * Bertl ScoobyD00: you're weclome!
1139445545 J * grant_ mep@p50919AC5.dip0.t-ipconnect.de
1139445561 M * Bertl welcome grant_!
1139445917 Q * ScoobyD00 Quit: 
1139445964 Q * grant Ping timeout: 480 seconds
1139446197 M * derjohn Bertl, are you in contact with openvps people?
1139446299 M * derjohn I mean, the website does not tell much about what they do (Missing screenshots ...)
1139446309 M * Bertl not really ... but they used to visit here
1139446320 M * derjohn Bertl, Austria?
1139446374 M * derjohn Bertl, where are they from? 
1139446383 M * Bertl ahem, no, on the channel I meant
1139446404 M * derjohn Bertl, *lol* ... "visit" ... errrh, yes :)
1139446482 M * derjohn Bertl, besides that: Is there a skiing region in your area? If yes, I may try to go there for a long weekend and use the change to invite you for a pizza or other foo,
1139446633 M * Bertl there are some of them in the area .. will dig out something
1139446688 M * derjohn sounds like wintersports is not one of your hobbies ;) .. yes, would be great!
1139446708 A * derjohn checks umts availability in .at ....
1139447242 A * [PUPPETS]Gonzo notes: derjohn hasn't enough sleep.
1139447264 M * ebiederm Bertl: Can I have a sanity check?  Do you see the email I wrote about OpenVz containers/contexts?
1139447283 M * derjohn [PUPPETS]Gonzo changed his clan !
1139447290 M * Bertl ebiederm: sec
1139447318 M * Bertl Subject: Re: [PATCH 1/4] Virtualization/containers: introduction
1139447322 M * Bertl that one?
1139447325 M * ebiederm Yes.
1139448079 M * ebiederm Bertl: I think I asked the question wrong.  I was wondering if the contents of that email were sane.
1139448193 M * Bertl ah, k, will check too
1139448949 M * ebiederm Thanks.....
1139450426 N * ebiederm ebiederm_oO
1139452386 M * hallyn ebiederm: so you think a struct container only makes sense if we don't use clone?
1139452709 N * ebiederm_oO ebiederm
1139452722 M * ebiederm hallyn: Not precisely.  
1139452757 M * ebiederm I think a struct container only make sense if it gives us the opportunity to optimize out the cost of all
1139452760 M * ebiederm of the extra pointers.
1139452789 M * ebiederm At that point I think something very link clone is desired but for the namespaces that we put in struct container.
1139453007 J * mef ~mef@c-68-39-177-97.hsd1.nj.comcast.net
1139453133 M * Bertl wb mef!
1139453147 M * Bertl ebiederm: okay, should have some more time now
1139453168 M * Bertl daniel_hozac: could you reproduce roadrunner's issues in any way?
1139453180 M * Bertl roadrunner: could it be that this issue is drbd related?
1139453190 M * daniel_hozac the unmountable thing after building?
1139453199 M * Bertl yep
1139453217 Q * gerrit Ping timeout: 480 seconds
1139453221 M * daniel_hozac yeah, the hung mount is still here.
1139453221 M * Bertl I tried with various kernel versions, and all worked quite well so far
1139453236 M * Bertl okay, so you are unable to unmount?
1139453240 M * daniel_hozac right.
1139453242 M * daniel_hozac EBUSY.
1139453258 M * daniel_hozac loop mounted ext2.
1139453260 M * Bertl okay, now what kernel version did you test with?
1139453272 M * daniel_hozac 2.6.15.3-based with 2.0.1.2.
1139453300 M * Bertl okay, I'll upload a 2.6.16-rc2 version, could you give that a try?
1139453312 M * Bertl will try with a similar 2.6.15 version here
1139453348 M * daniel_hozac sure.
1139453390 M * hallyn ebiederm:  ok.  well if we are perceived as overloading clone too much, i liked your suggestion of perhaps using unshare
1139453511 M * Bertl daniel_hozac: http://vserver.13thfloor.at/Experimental/patch-2.6.16-rc2-vs2.1.0.10.diff
1139453605 M * Bertl hallyn: btw, how is your feeling about the kernel virtualization in general (mainline)
1139453739 M * Bertl ebiederm: we (read Linux-VServer) will need a container struct anyway, to deal with the limits and capabilities
1139454401 J * stefani ~stefani@c-24-19-46-211.hsd1.wa.comcast.net
1139454414 M * Bertl welcome stefani!
1139454646 M * hallyn Bertl: well enough ppl are interested that something should have a chance of going in.
1139454680 M * stefani hola
1139454696 M * Bertl yes, agreed ... what would that something need to be to make you happy? :)
1139454700 M * ebiederm Bertl: Sorry my landlord is busy investigating a leak.
1139454714 M * Bertl memory?
1139454723 M * Bertl just kidding!
1139454760 M * hallyn i'm fine either way  :)  But i always am fond of plan 9-ish feeling solutions
1139454859 M * hallyn to make me happy, i just want full vserver, app migration, and vserver migration.  "that's a;;"
1139454869 M * hallyn "that's all"
1139455007 M * Bertl well, sound good to me :)
1139455095 M * ebiederm Anyway right now is a good time to investigate different techniques.  So the up and down sides are well understood.
1139455155 M * hallyn agreed
1139455180 M * ebiederm Once we can say we didn't do it your way not because we didn't understand it but because of problems with the idea.
1139455228 M * ebiederm We should be able to make forward progress.
1139455261 M * ebiederm Unfortunately it is taking a lot of study for me to figure out what the OpenVz guys are talking about.
1139455316 M * hallyn the global pidspace seems a  hard req for them.  thoughtsnon how to do that w/ your approach?
1139455363 M * Bertl well, the problem IMHO is that the OVZ folks have a product
1139455393 M * Bertl and they can not easily change into a completely different direction, not even if it is obviously a better one
1139455426 M * Bertl I 'assume' that certain tools and management systems require certain interfaces
1139455453 M * Bertl what I do not understand is why they try to find other reasons ...
1139455462 M * hallyn ?
1139455487 M * Bertl let me give an example for the 'namespace'
1139455513 M * Bertl VZ uses a simfs (virtual filesystem), which seems to be absed
1139455528 M * Bertl on symlinks with special meanings
1139455551 M * Bertl they have a bunch of different templates arranged for that
1139455568 M * Bertl and all the available management software is written around that
1139455594 M * Bertl now what would happen if suddenly a namespace would replace that?
1139455671 M * Bertl similar (probably even more concerns) apply to the networking
1139455685 M * Bertl but hey, that's just MHO :)
1139455701 M * hallyn makes sense.
1139455750 M * Bertl daniel_hozac: OMG 0.30.210 is using colors?
1139455774 M * hallyn but then 1. are they lazy 2. must products be cross-platform or 3. do customers not want change.  oh well,end result is same
1139455790 M * daniel_hozac Bertl: 0.30.209 did too, but the coloring function was broken so it didn't show ;)
1139455806 M * Bertl ah, is there a patch to break it *G* :)
1139455880 M * ebiederm Bertl: That is what is really good and really painful about the current kernel development model.  If people are doing it the code will go it (to prevent forks like this).  Unfortunately people have already standardized on strange things.
1139456012 M * ebiederm If it comes down to OpenVZ just not being able to change to a sane kernel implementation because of history my sympathies.  But whatever goes into the kernel is going to be clean and maintainable.  The only more important thing than preventing forks.
1139456076 M * Bertl well, you know by now that I totally agree here, that was partially a reason for me not pushing for inclusion ...
1139456124 Q * hue Ping timeout: 480 seconds
1139456146 M * Bertl but, we should try to figure what the true reasons are, because although my reasoning makes good sense, we could just miss something they stumbled about and burried somewhere ...
1139456192 M * Bertl ebiederm: btw, did you look at the namespaces approach?
1139456209 M * Bertl (I mean the in kernel filesystem namespace approach)
1139456268 M * Bertl daniel_hozac: I can now (somewhat) reproduce it with 2.6.15 ...
1139456405 M * Bertl daniel_hozac: actually it's 2.6.14.6-vs2.0x
1139456434 M * Bertl funny thing is, it seems not to happen in my test setup
1139456488 M * daniel_hozac interesting.
1139456530 M * Bertl going to check the code now, let me know if 2.6.16-rc2 misbehaves for you too
1139456778 M * daniel_hozac i'll have to check it tomorrow, i'm going to get some sleep now. good night everyone!
1139456789 M * Bertl okay, tx, good night!
1139456843 J * Smutje_ ~Smutje@xdsl-87-78-4-72.netcologne.de
1139456856 J * hue ~hue@218.20.51.109
1139456858 M * ebiederm Bertl: I haven't looked closely at the in kernel filesystem namespaces. 
1139456868 M * ebiederm I have read a lot of code that uses them but that is about it.
1139456884 M * Bertl okay, nevermind then :)
1139456892 Q * weasel Remote host closed the connection
1139456897 J * weasel weasel@asteria.debian.or.at
1139456935 M * ebiederm Bertl: What question could I answer looking at the kernel filesystem namespaces?
1139456954 Q * Smutje Ping timeout: 480 seconds
1139456954 N * Smutje_ Smutje
1139456960 M * Bertl there seem to be issues (lately?) with 'hanging' mounts
1139456971 M * hallyn oh - 
1139456983 M * ebiederm Bertl: Things that you can't unmount?
1139456985 M * Bertl i.e. name spaces which are not visible/accessible
1139456988 M * hallyn that's due to the shared subtree code, fixed in git
1139456995 M * Bertl ah?
1139457002 M * Bertl hallyn: url?
1139457006 M * hallyn one sec
1139457015 M * ebiederm I know Al Viro just posted a couple of patches for something like that.
1139457023 M * Bertl excellent
1139457038 M * Bertl so they were playing around there again ...
1139457073 M * Bertl ebiederm: see, that's a good example why attaching this to tasks is not perfect
1139457095 M * Bertl ebiederm: if I could get a list of all namespaces, I could easily identify what happened where
1139457128 M * ebiederm Bertl: I agree.  
1139457151 M * Bertl does not mean that the interface has to be used very often
1139457153 M * hallyn http://lkml.org/lkml/2006/2/7/425
1139457157 M * Bertl tx
1139457181 M * ebiederm Part of that is why I am so paranoid about lifetime issues.
1139457213 M * Bertl what about putting 'info' messages into the first few releases?
1139457214 M * ebiederm The interesting approach is in the netdev code.
1139457229 M * anonc ah - i wonder if thats why my drbd was able to be unmounted but drbdadm still insisted the block device was in use...
1139457244 M * Bertl anonc: could be, could be
1139457267 M * anonc i'll just patch it manually and see what happens...
1139457273 M * ebiederm When you bring down a device if there are stray references it keeps running the notifier attempting to bring the device down.
1139457283 M * Bertl anonc: will do so here too
1139457315 Q * mef Remote host closed the connection
1139457386 M * Bertl mugwump: still around?
1139457474 M * ebiederm And then the netdev code prints a warning every second or so.
1139457489 M * ebiederm And all of that while blocking bringing the device down.
1139457519 M * ebiederm Something like that we always kill a namespace when the processes using it go away could be very interesting.
1139457532 Q * SuperLag Quit: reboot
1139457533 M * ebiederm I think my network namespace is currenty structured very much like that.
1139457724 M * hallyn ebiederm: btw, waiting on hubertus to fix an s390 compile error in your git tree...  then will be testing
1139457767 M * Bertl compile error, interesting ...
1139458011 M * hallyn know nothing about z myself...
1139458174 Q * rene- Read error: Connection reset by peer
1139458410 M * ebiederm hallyn: What is the compile error?
1139458420 M * ebiederm Bertl: I like compile errors.
1139458435 M * ebiederm Which branch of my git tree?  pspace or proof-of-concept?
1139458440 M * Bertl I prefer them over compiler errors :)
1139458466 M * ebiederm Bertl: compiler are some of the worse.
1139458487 M * ebiederm Although I prefer even compiler errors over subtle hardware errors.
1139458579 M * ebiederm When you look at your code, and you look at your assembly and all is good but you get the wrong answer...
1139458616 M * hallyn CC      arch/s390/kernel/asm-offsets.s
1139458616 M * hallyn arch/s390/kernel/asm-offsets.c: In function `main':
1139458616 M * hallyn arch/s390/kernel/asm-offsets.c:25: error: structure has no member named `pid'
1139458616 M * hallyn make[1]: *** [arch/s390/kernel/asm-offsets.s] Error 1
1139458634 M * ebiederm Ok.  Definitely my proof-of-concept branch!
1139458655 M * Bertl ebiederm: now I got you a way to get nice cross compilers, and what do you do? :)
1139458692 M * mugwump Bertl: for <1hr I'll be around
1139458696 M * ebiederm Bertl: I avoid the issue and fix the code so it doesn't do that.
1139458706 M * hallyn yeah, the pspace patches haven't applied cleanly on anything i've got lying around :(
1139458727 M * Bertl mugwump: you talked about a dup_namespace or so?
1139458733 M * ebiederm hallyn: Sorry.  The pspace-8-Feb branch should have everything you need.
1139458743 M * hallyn git?
1139458749 M * mugwump Bertl: yes, I managed to merge that... sec
1139458757 M * ebiederm The problem was it requires paches that Andrew has accepted since 2.6.16-rc1-mm5 was released.
1139458779 M * hallyn where do i get the patches?
1139458818 M * ebiederm hallyn: The easy was it to get the other pspace-8-Feb-2006 branch of my git tree....
1139458834 M * ebiederm I posted it this morning so all of the mirror should be updated.
1139458838 M * hallyn school me  :)
1139458877 M * hallyn i'm git/cg challenged...
1139458920 M * Bertl apropos apropos, mugwump, could you schedule a short git intro for interested folks here on the cahnnel sometime in the near future?
1139458943 M * mugwump yes, by all means
1139458946 M * ebiederm git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-ns.git pspace-8-Feb-2006:pspace-8-Feb-2006 
1139458978 M * ebiederm then git-checkout pspace-8-Feb-2006
1139458999 M * hallyn neat, thanks
1139459005 M * ebiederm Bertl: The commits on that branch all correspond to sane patches.
1139459011 M * mugwump your first fetch you'll want to use rsync:// or http://
1139459023 M * mugwump then edit .git/remotes/origin to change to git://
1139459051 M * mugwump but if you don't mind waiting then just use git:// all the time :)
1139459062 M * Bertl hmm .. not so near future :)
1139459083 M * Bertl was more thinking about next week or so :)
1139459112 M * ebiederm Once you have any kernel tree getting another branch from anywhere is much faster.  Especially if you use the git protocol.
1139459143 M * Bertl i.e just get 2.0 kernel, and start from there *G*
1139459143 M * hallyn yeah, ie how can i locally create a branch against a remote tree, then back it out, ...  i thought i had it last night, then couldn't delete the branch
1139459170 M * mugwump yes, you just add another "remote" which corresponds to a local branch (which you branched from the latest common commit you share with the branch)
1139459210 M * hallyn uh...
1139459216 M * Bertl that sounds like you simply have to do the right thing and all pieces will fall into place automatically :)
1139459218 M * mugwump eg, I just go "stg branch ebiederm-pspace; stg pull ebiederm" to get your updates, or "stg branch master; stg pull" to get from linus
1139459246 M * hallyn oh you branch before you pull...
1139459255 M * mugwump then "stg branch vs2.1.0.9-head; stg pull" to rebase Herbert's patches against the day's changes from Linus
1139459259 M * hallyn then checkout?
1139459308 M * hallyn ebiederm:  i did a 'cg-update' first, it gave me merge conflicts  :(
1139459326 M * mugwump well, "stg branch" is changing branches (that is, checking out the one I want)
1139459350 M * mugwump you just need to be careful about what you're trying to pull into what branch
1139459362 M * mugwump of course "pull" means "merge"
1139459432 M * mugwump so, if you're on a branch, and you just pull from the origin, you're merging changes from upstream into your patched codebase
1139459530 M * mugwump whereas with stgit, it "pops" (unapplies) the patches on your stack (which look like the last N commits to a raw git tool), merges in changes from head that should not require any actual merging, then re-applies your patches
1139459574 M * hallyn ebiederm and then on a fresh  tree on the checkout: error: Could not read 3ac4c6bdccabc07491e0d6f11104f34f87c8877f
1139459669 M * mugwump anyway, next week.  Who's interested, and what TZs are we in?  I'm UTC+13 right now, and work hours 9am-6pm would be best
1139459705 M * Bertl mugwump: you set the time, and maybe announce it on the ML
1139459730 M * Bertl wed/thu should be fine
1139459776 M * hallyn I'm interested, I'm in UTC-600, but whatever...
1139459792 M * anonc Bertl: using the patch from http://lkml.org/lkml/2006/2/7/425 doesn't seem to make a difference - still getting busy responses from the drbd takedown script.
1139459807 M * Bertl yup, didn't make a difference here either
1139459820 M * hallyn hmm
1139459835 A * hallyn ducks
1139459845 M * Bertl nobody blames you
1139459854 A * Bertl points at hallyn behind the desk
1139459923 A * ebiederm back
1139459943 M * Bertl ebiederm: how is your (memory?) leak going?
1139459966 A * ebiederm grin
1139460031 M * ebiederm hallyn: Weird.  error what protocol was that.
1139460052 M * hallyn used rsync to clone new tree, git for fetch
1139460077 M * Bertl mugwump: btw, is Mark Lord drinking or did I miss something important?
1139460081 M * hallyn hmm, and i'd gotten "git-checkout-index: unable to read sha1 file of..." for a bunch of files during clone
1139460095 M * Bertl mugwump: +	default 0x78000000 if VMSPLIT_2G
1139460095 M * Bertl +	default 0x40000000 if VMSPLIT_1G
1139460095 M * Bertl +	default 0xC0000000
1139460133 M * Bertl is now 0x78 the ugly half of 0x100 ?
1139460244 M * ebiederm I'm amazed this is all still floating around when people can run 64bit kernels.
1139460286 M * Bertl ebiederm: 64bit kernels are not that effective when run (in QEMU) on x86 machines :)
1139460297 M * Bertl s/effective/efficient/
1139460355 M * ebiederm Bertl: But you don't need to give your kernel under QEMU more than 768Megs either.
1139460381 M * Bertl yeah, but you _can_ run 32bit kernels natively on those machines *G*
1139460536 M * ebiederm hallyn: Problems could be from the fact my tree on kernel.org is sparse.  So plain rsync will not grab everything.
1139460587 M * ebiederm All I know is you don't want me teach a course on how to do that kind of thing.  It all comes too easily to me.
1139460639 M * ebiederm I used to use tla and everyone else screamed that it was all to hard and clutsy, and I had no problems.
1139460651 M * ebiederm git is much better than that but the princple applies.
1139460729 M * ebiederm You know what irc is almost as bad as meeting people in real life the names are all different!
1139460807 M * Bertl huh?
1139460846 M * ebiederm Well in real life you have to map names to faces.
1139460885 M * Bertl and?
1139460915 M * ebiederm But I ebiederm == Eric Biederman am talking to Bertl == Herbert Potzl and keeping the mapping from one form of communication to another is interesting.
1139460936 M * Bertl well, friends call me Bertl, so it's pretty easy :)
1139461034 M * ebiederm My challenge is whenever I start talking to someone I keep wondering is this someone I should already be familiar with.
1139461066 M * ebiederm It took me a little while to put mugwump and Sam Viain together.
1139461077 M * Bertl ah, k
1139461109 M * ebiederm And hallyn must be Serge E Hallyn.  
1139461133 M * Bertl *shht* now you spoiled his disguise :)
1139461177 M * ebiederm Sorry....
1139461179 M * hallyn bastard!
1139461204 M * Bertl hallyn: sorry serge, nobody would have found out ...
1139461207 M * hallyn ok - so i should start with linus' tree again, put yours on top, then put the other branch on top...
1139461224 M * ebiederm ok start with linus's tree.
1139461226 M * hallyn will try that tomorrow :)
1139461229 M * ebiederm Fetch the branch of my tree you want.
1139461242 M * ebiederm If you are using raw git use fetch and not pull.
1139461264 M * ebiederm Fetch just down loads and stores the code, pull also merges it into your current branch.
1139461268 M * hallyn ok - i havne't decided whether git or cg is easier (for me) to understand
1139461274 M * hallyn ah
1139461304 M * hallyn downloads the code into filenames specified by sha1sum, right?
1139461317 M * hallyn merge then recreates the real paths...?
1139461323 M * ebiederm hallyn: Yes or into an equivalent pack file.
1139461338 M * ebiederm hallyn: Checkout and merge are two separate operations.
1139461338 M * hallyn pack file?
1139461373 M * ebiederm hallyn: A pack file is an archive of sha1 files that are compressed with deltas between each other.
1139461382 M * ebiederm The kernel git repostiory as a pack file is about 100M.
1139461391 M * ebiederm As a bunch of sha1 files it is about 500M.
1139461404 M * mugwump yes, as each sha1 file is the complete contents.
1139461405 M * ebiederm Mostly it is under the covers so you don't care.
1139461448 M * ebiederm So a fetch will download everything and store the head into into .git/refs/heads
1139461460 M * ebiederm The git checkout can be told to put that code into your current working directory.
1139461527 M * ebiederm If you ever loose the head of a branch you can always find it again by running git-fsck. :)
1139461574 M * ebiederm For tracking what linus has merged git is very nice.
1139461584 M * hallyn and the head points to a file which contains what exactly?
1139461596 M * hallyn not the pack file?
1139461609 M * Bertl educated guess: hashes?
1139461616 M * hallyn hah
1139461619 M * ebiederm HEAD is a symlink to a file in refs/heads.
1139461632 M * ebiederm The file in refs heads holds the sha1 of the root directory of your tree.
1139461639 M * ebiederm And that file is updated whenever you do a commit.
1139461671 Q * hue Ping timeout: 480 seconds
1139461679 M * ebiederm That should be the only thing in git that needs to be rewritten.
1139461725 M * ebiederm git directory files are an interesting idea.
1139461734 M * hallyn but?
1139461744 M * ebiederm They are filename + permissions + sha1 :)
1139461780 M * ebiederm Practically a normal unix directory with inodes replaced by hashes.
1139461915 M * hallyn Ok, just one more q then - exactly what is a 'remote' and a 'branch'?  i.e. a local remote, would look like what?  A full .git tree?
1139461943 M * ebiederm So two related concepts.
1139461979 M * ebiederm A remote is a short cut so you don't have to type in long urls when ever you want to do something remotely.
1139461993 M * ebiederm Something like a symlink to a remote repository.
1139462024 M * ebiederm A branch is just a file in .git/refs/heads that has the sha1 hash of a tree.
1139462031 M * ebiederm But a branch is local.
1139462065 M * ebiederm You switch branches with git-checkout.
1139462092 M * hallyn does git-checkout remove all the files in the last branch and not in the current branch?
1139462101 M * ebiederm When you fetch you fetch into some branch, but it doesn't need to be your current branch.
1139462136 M * ebiederm hallyn: git-checkout has enough information to compute a diff between the two branches.
1139462190 M * ebiederm Oh that was does not how does.  Yes git-checkout will remove all files in the last branch and not in the current-branch iff those files were checked int.
1139462207 M * ebiederm If you have a dirty tree that causes problems git-checkout will complain.
1139462218 M * hallyn i've noticed :)
1139462221 M * hallyn what defines 'dirty'?
1139462230 M * ebiederm If you just have random files lying around that were never checking in git doesn't care.
1139462241 M * ebiederm Another good command to is git-reset
1139462259 M * ebiederm Dirty is when you have modified a file but not checked it in.
1139462273 M * ebiederm In raw git there are 3 levels.
1139462279 M * ebiederm The archive (checked in code).
1139462284 M * Bertl a file _known_ to git, yes?
1139462304 M * ebiederm Bertl: yes only a file _known_ to git will be considered dirty.
1139462335 M * ebiederm The index (basic a staging area for checkin files)
1139462343 M * ebiederm The files in your working directory.
1139462373 M * ebiederm git-checkout is the polite and usually sane way of doing things.
1139462385 M * ebiederm git-reset is it's cousin that says this is what I want do it!
1139462418 M * ebiederm So hallyn in those situations where you have weird stuff going on git-reset can usually be used to hammer things back into shape.
1139462476 M * ebiederm I don't know what state things are in but a git-clone of my repository should fetch both branches.
1139462503 M * hallyn i usually reset by doing rm -rf; git clone  :)
1139462505 M * ebiederm And of course there is always git-format-patch to dump patches out of git.
1139462527 M * ebiederm hallyn: That works if you have enough bandwidth.
1139462540 M * ebiederm git-reset usually takes a split second so if you know where you are...
1139462556 M * hallyn i didn't trust git-reset to not muck tings up....
1139462566 M * ebiederm Makes some sense.
1139462572 M * Bertl well, I guess you can trust the hashes
1139462593 M * hallyn but how does it reset - rm -rf the tree then extract from the branchfile?
1139462604 M * ebiederm The other interesting trick is git-clone -l -n -s which is for creating a local clone with nothing checked out that looks to the old repository for all of it's objects.
1139462611 M * hallyn Or does it try to optimize based on what it thinks should be in the tree now?
1139462650 M * ebiederm hallyn:  Not quite either.  git-reset --hard seems to figure out what should be checkout and put those files there.
1139462674 M * ebiederm So with git-reset you can leave files that should be checkout laying around.
1139462690 M * ebiederm s/should/should not/
1139462712 M * hallyn well this should be enough to let me play...
1139462716 M * ebiederm git-ls-files -o will report them as things git does not know about.
1139462760 M * hallyn Hmm, yup.  lots of .o files :)
1139462776 M * hallyn Thanks, ebiederm.
1139462781 M * hallyn Now I'm off to bed.
1139462781 M * ebiederm Welcome.
1139462786 M * ebiederm Sleep well.
1139462796 M * Bertl hallyn: good night!
1139462825 M * ebiederm May the farce be with you!
1139462838 M * hallyn night
1139462844 N * hallyn hallyn_zzzz
1139462900 M * ebiederm Getting started with git reminds me of learning to drive a stick shift.
1139462916 M * ebiederm How do I get this fool thing in the right gear!
1139463003 M * Bertl ebiederm: have you read the u/gid virtualization mail yet?
1139463030 M * ebiederm Bertl: The one requesting this be the time the kernel gets more capable of doing things.
1139463084 M * Bertl well, hmm, probably yes ...
1139463217 M * ebiederm Under the issues for agreeing on a virutalization/namespace implementation by Kyle Moffet or something else?
1139463220 M * mugwump ok, I have a git:// URL for my branch now
1139463229 M * Bertl yep the one from Kyle
1139463251 M * mugwump git://vserver.utsl.gen.nz/vserver.git
1139463268 M * mugwump the "vserver-inclusion" is the magic branch
1139463336 M * ebiederm fetching.
1139463355 Q * shedi Read error: Connection reset by peer
1139463418 M * ebiederm Got it.
1139463428 M * mugwump great!  :)
1139463604 M * ebiederm Now I don't have an excuse not to read the vserver code!
1139463763 M * ebiederm Well I have now replied.  Compare pointers to struct user.
1139463768 M * mugwump there really is very little there so far
1139463781 M * mugwump ie, it's just the umbrella, the syscall switch, and some menial /proc visibility
1139463792 M * mugwump the existing tools fail to work for some reason I have yet to ascertain
1139463810 M * ebiederm Yes just 5 patches.
1139463958 M * Bertl ebiederm: if you want to look at the full patch set:
1139463961 M * Bertl http://www.13thfloor.at/vserver/d_rel26/v2.1.0/split-2.6.14.4-vs2.1.0/
1139464011 M * Bertl (or for stable)
1139464012 M * Bertl http://www.13thfloor.at/vserver/s_rel26/v2.01/split-2.6.14.3-vs2.01/
1139464076 M * ebiederm mugwump: Could you not just import Bertls patches against 2.6.14.4?
1139464102 M * mugwump ebiederm: I have, they are on another branch
1139464107 M * ebiederm Ok.
1139464125 M * ebiederm This is your update to the latest kernels then.
1139464129 M * mugwump yes
1139464194 M * mugwump http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=shortlog;h=edfec509d9611a7962ed535242e44a4f25a2e1f2 # vs2.01
1139464195 M * Bertl ebiederm: if you like you can have a full version for 2.6.16-rc2 (devel)
1139464226 M * ebiederm Bertl that would probably be interesting.
1139464229 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.16-rc2-vs2.1.0.10.diff
1139464244 M * Bertl if you give me 10min or so, I can break it down for you
1139464252 M * Bertl (well, my tools will do that)
1139464271 M * ebiederm Bertl:  no problem.   In the next day or two is fine.
1139464287 M * Bertl okay, will break it down anyway ...
1139464317 M * Bertl mugwump: for your 'sync' you know the devel dirs, right?
1139464341 M * ebiederm I need to get to bed soon, and then tommorrow see how efficient I can make access a context type structure. 
1139464346 M * Bertl mugwump: http://vserver.13thfloor.at/Devel/
1139464402 M * ebiederm Hmm.  I have changed the name in my head from container to context!
1139464414 M * mugwump Bertl: interesting, perhaps those are better to import than the split patches?
1139464415 M * ebiederm Most be the vserver influence :)
1139464426 M * Bertl ebiederm: IMHO a good step :)
1139464451 M * Bertl no, seriously, I don't mind container
1139464468 M * Bertl I really love 'space' for the various spaces
1139464476 M * ebiederm If what I am doing is optimizing for used to be global variables I think context fits what is in my head better.
1139464496 M * Bertl and it's fine as long as we have 'guest' for the full featured thing 
1139464498 M * ebiederm Bertl: Actually space is nice because it is uniq and short and far out there!
1139464521 A * Bertl always thought is was wide (not short :)
1139464540 M * Bertl ah no, that was *deep* :)
1139464551 M * ebiederm lolo
1139464562 A * ebiederm typo lol!!!!
1139464575 J * shedi ~siggi@inferno.lhi.is
1139464597 M * ebiederm I have been typing unix commands to long I can't remember how to properly spell unique!
1139464626 M * mugwump ok, just fixed my gitweb at http://vserver.utsl.gen.nz/gitweb/, now it should work browsing around the repo
1139464650 M * Bertl tats fin wit me ... hav a good parsa :)
1139464694 M * Bertl mesa is used to talk to all kind of people, speaking (writing?) all kind of languages they call english :)
1139464702 M * mugwump I have to run, I'm running very late indeed for Taichi :)
1139464711 M * mugwump later folks!
1139464712 A * mugwump &
1139464713 M * Bertl mugwump: run then, and tx!
1139464719 M * ebiederm bye.
1139464890 M * ebiederm I just found another case I did not get quite right.  The instances where you can have one instance of something dealing with another are truly painful.
1139464962 M * ebiederm Anyway, after having said something totally naive about permissions, I am going to retire.
1139464971 M * ebiederm I don't think there is anything more I can do today.
1139464982 M * Bertl okay, have a good night too, then ...
1139464986 M * ebiederm Have a good night Bertl.
1139464988 M * Bertl will be off to bed shortly ...
1139465001 N * ebiederm ebiederm_zZzZ
1139465500 Q * shedi Read error: Connection reset by peer
1139466276 J * shedi ~siggi@inferno.lhi.is
1139467306 M * sladen mugwump: when did you move to NZ?!
1139467361 M * Bertl a few years ago, IIRC?
1139467979 P * stefani parting (is such sweet sorrow)
1139468641 Q * mnemoc Ping timeout: 480 seconds
1139471124 Q * shedi Read error: Connection reset by peer
1139471973 J * shedi ~siggi@inferno.lhi.is
1139473031 Q * shedi Read error: Connection reset by peer
1139473139 J * meandtheshell ~markus@85-125-225-123.dynamic.xdsl-line.inode.at
1139473461 M * RoadRunnR morning everybody
1139473468 M * Bertl morning!
1139473490 M * RoadRunnR Bertl: any news on the mount issue, or should is starting digging through the vserver stuff myself ;-)
1139473502 M * Bertl nope, still working on it
1139473531 M * Bertl I know 2.6.14.x-vs2.0.1 already has the issue
1139473543 M * Bertl I know it is a vserver issue not a mainline one
1139473551 M * RoadRunnR to bad, but thanx anyway, i'm going to play with 2.6.16-rc2 then for a while
1139473558 M * Bertl I know it is not caused by any vserver call
1139473827 M * RoadRunnR Bertl: how do you know that?
1139473840 A * RoadRunnR is trying to learn how to debug vserver stuff
1139473842 M * Bertl because I disabled the switch for a test :)
1139473884 J * shedi ~siggi@inferno.lhi.is
1139473957 Q * shedi Quit: 
1139474062 M * Aiken this problem? http://pastebin.com/546325
1139474083 M * Aiken after a vserver slate stop
1139474107 M * RoadRunnR Aiken: yes, it also prevents the device from beeing umounted
1139474133 M * Bertl yep
1139475674 Q * Aiken Read error: Connection reset by peer
1139475698 J * Aiken ~james@tooax6-181.dialup.optusnet.com.au
1139476063 M * Bertl we now also know that it is not in the networking code :)
1139477131 J * prae ~prae@ezoffice.mandriva.com
1139477562 M * prae Bertl: !
1139477799 M * Bertl prae: !
1139477868 M * prae Bertl: so, I can't send you an email from mandriva   :-\
1139477887 M * Bertl hmm, did you get a reply?
1139477921 M * prae yes, your smtp-server refused this email because, ipaddr from mandriva smtp server haven't resolv
1139477935 M * prae « .... @13thfloor.at>: host mail.13thfloor.at[212.16.62.50] said: 450 Client
1139477935 M * prae     host rejected: cannot find your hostname, [212.85.150.163] (in reply to
1139477935 M * prae     RCPT TO command) »
1139477939 M * Bertl hmm, well, I can add an exception ...
1139477991 M * prae I contact the hostmaster to add resolv to this ipaddr, it's bizarre :-\
1139478020 M * Bertl that would be better indeed
1139478024 M * prae yes
1139478067 M * prae so, I say in this mail: your patch has been commited into dev branch here by core-dev-team
1139478079 M * prae a preview-release package is available here : http://people.mandriva.com/~blino/uc/initscripts-7.61.1-50.1.20060mdk.i586.rpm
1139478082 M * Bertl ah, cool!
1139478129 M * prae Blino - mdv developper - say you a "thanks"  :)
1139478160 M * Bertl (s)he is welcome!
1139478164 M * prae he :)
1139478293 Q * phreak``_ Quit: Reconnecting
1139478294 J * phreak`` ~phreak``@styx.xnull.de
1139478348 M * prae M. Phreak  :)
1139478363 M * phreak`` yah, morning prae 
1139478409 M * prae ;)
1139478751 J * mire_ ~mire@mail.sfb.bg.ac.yu
1139478765 M * mire_ hey, anyone got vserver working with grsec?
1139478832 M * Bertl guess it works/worked for those guys who did the grsec patches
1139478854 M * mire_ one more q, is there any way to search the mailing list?
1139478862 M * phreak`` Bertl: yeah, it "works" :) but it need pretty heavy patching :)
1139478896 M * mire_ since I can't find a way to search the list, I only get thread or date index
1139478987 M * mire_ oh found it :)
1139479386 J * shedi ~siggi@tolvudeild-204.lhi.is
1139480664 M * SiD3WiNDR the grsec guy is funny
1139480676 M * SiD3WiNDR "I don't understand. What are these "small" Linux versions? the .x.y style (ie 2.6.14.6)?"
1139480680 M * SiD3WiNDR = spender, on the grsec forums.
1139480987 M * Bertl well, maybe somebody should explain it to him
1139481529 J * lilalinux ~plasma@h1-gw.of.net-lab.net
1139481657 M * SiD3WiNDR well I only got that c/p'd, I don't know where the actual thread is, but I hope someone already did
1139481667 M * SiD3WiNDR although I think a kernel patch developer should have known that by now
1139481693 A * Bertl goes now reading up on that ... nah, just kidding :)
1139481763 A * mire_ really likes vserver :-D
1139481813 M * Bertl and that makes my day :)
1139481924 M * Bertl any folks eager to use jfs around?
1139482599 M * Hollow Bertl: how can different devices share the same major number? i just wondered for vroot and noticed it's common all over the place..
1139482612 M * Bertl hmm?
1139482624 M * Hollow well, vroot and tty both have major=4
1139482637 M * Bertl character and block device
1139482655 M * Hollow ah, ic..
1139482659 M * Hollow thx ;)
1139482663 M * Bertl that's not unusual if you look at the numbers
1139482667 M * Hollow yeah..
1139482760 M * Bertl btw, still narrowing down the unmount issues
1139482780 M * Bertl but I must be there any minute ... as I almost removed all stuff from the kernel :)
1139482840 M * Hollow heh.. must have missed it.. which umount problem?
1139482864 M * Bertl http://vserver.13thfloor.at/Stuff/BUGHUNT/RoadRunnR-0001/issue.txt
1139482915 M * Hollow ah.. mhm.. never noticed such an issue..
1139483013 M * Bertl me neither ...
1139483036 M * Hollow but it is reproducable for you?
1139483041 M * Bertl yep
1139483054 A * Hollow shrugs
1139483054 M * Bertl but not in my test environment
1139483057 M * Hollow but good luck anyway ;)
1139483066 M * Bertl yeah, thanks!
1139483103 M * Hollow i have reorganized the vserver-utils code meanwhile, and started work on vcc now
1139483127 M * Hollow and i implemented the new dx, ix, nx, and vx tools
1139483199 M * Bertl cool
1139483257 M * Hollow i think the decision to replace the vserver command with a C version was quite good
1139483284 M * Hollow bash is not that much fun :)
1139483564 M * cehteh mhm
1139483606 M * cehteh Hollow: i am working on a small embedded macro language for such things ... 
1139483707 M * Hollow cehteh: hm, interesting.. any code or examples?
1139483750 M * cehteh bit forth, bit lisp, centered around optarg processing, so it has a bit strange syntax :)
1139483763 M * cehteh --PRINT --ADD 1 2    would yield 3
1139483799 M * cehteh in base syntax (its not really a syntax, a program is just a sequnce of words and each word can be bound to actions)
1139483869 M * cehteh there are some simple transformations and preprocessing things to make it more useable and define a syntax which can be used interactively or for configfiles
1139483879 M * Hollow hm.. maybe usable some day.. atm i'd need something like a simple functional command interpreter, which can be used in interactive mode (with prompt) or just on command line /stdin
1139483902 M * cehteh yeah .. i am for a april fools joke for the first official release :)
1139483909 M * Hollow heh
1139483943 M * cehteh that would be useable but not a 100%stable interface then
1139484014 M * cehteh http://www.pipapo.org/pipawiki/MaLa
1139484170 M * Hollow off for a bit, have to pick up some vinyl at the post office.. cu later
1139484190 Q * marl_ Ping timeout: 480 seconds
1139484449 M * Bertl cehteh: why not do MaLa/C/diet?
1139485274 M * cehteh Bertl: the name 'glibc' is historic, the first implementation was with Tom Lords hackerlab clib
1139485290 M * cehteh it should compile with any ansi c like clib
1139485621 Q * andrew_ Ping timeout: 480 seconds
1139486253 M * Bertl cehteh: ah, good :)
1139486271 M * Wonka might be interesting for the problem we have had here some time ago: http://gnumonks.org/~laforge/weblog/2005/10/27#20051027-modularity-sysrq
1139486488 M * Bertl hmm, object not found here :/
1139486549 M * Wonka funny
1139486608 M * Wonka it's on http://gnumonks.org/~laforge/weblog/linux/netfilter/index.html
1139486608 M * Wonka Thu, 27 Oct 2005
1139486609 M * Wonka The modularity of iptables - or "ipt_SYSRQ" 
1139486627 M * Wonka »a target module that allows you to issue the "magic sysreq" command via a network packet. This way you can sync, unmount and reboot a otherwise stuck machine that still responds to interrupts.«
1139486683 M * Bertl ah, IIRC something was also provided for netconsole
1139486696 M * Bertl thing is, it somehow opens a can of worms
1139486706 M * Bertl s/somehow/somewhat/
1139487007 M * Wonka cryptographic signature...
1139487026 M * Bertl yeah, but if somebody sniffes it
1139487026 M * Wonka should at least be possible to get it secure
1139487038 M * Wonka there's also a timestamp, the article says
1139487047 M * Wonka so, not really well replayable
1139487049 M * Bertl hmm, that might work
1139487305 J * xlock ~xlock@tor-irc.dnsbl.oftc.net
1139487322 M * Bertl welcome xlock!
1139487333 M * xlock ty bertl
1139487505 P * xlock 
1139488119 Q * mire_ iridium.oftc.net arion.oftc.net
1139488119 Q * jkl iridium.oftc.net arion.oftc.net
1139488119 Q * click iridium.oftc.net arion.oftc.net
1139488119 Q * Psy0rz_ iridium.oftc.net arion.oftc.net
1139488119 Q * blizz iridium.oftc.net arion.oftc.net
1139488119 Q * Adrinael iridium.oftc.net arion.oftc.net
1139488119 Q * monrad iridium.oftc.net arion.oftc.net
1139488119 Q * cohan iridium.oftc.net arion.oftc.net
1139488119 Q * harry iridium.oftc.net arion.oftc.net
1139488119 Q * kilian iridium.oftc.net arion.oftc.net
1139488119 Q * Snow-Man iridium.oftc.net arion.oftc.net
1139488119 Q * phreak`` iridium.oftc.net arion.oftc.net
1139488119 Q * prae iridium.oftc.net arion.oftc.net
1139488119 Q * grant_ iridium.oftc.net arion.oftc.net
1139488119 Q * Bertl iridium.oftc.net arion.oftc.net
1139488119 Q * Pazzo iridium.oftc.net arion.oftc.net
1139488119 Q * Wonka iridium.oftc.net arion.oftc.net
1139488119 Q * SNy iridium.oftc.net arion.oftc.net
1139488122 Q * entroposcope iridium.oftc.net arion.oftc.net
1139488122 Q * wibble_ iridium.oftc.net arion.oftc.net
1139488122 Q * ComplexMind iridium.oftc.net arion.oftc.net
1139488122 Q * sladen iridium.oftc.net arion.oftc.net
1139488122 Q * mountie iridium.oftc.net arion.oftc.net
1139488122 Q * cehteh iridium.oftc.net arion.oftc.net
1139488122 Q * Vudumen iridium.oftc.net arion.oftc.net
1139488122 Q * Cru iridium.oftc.net arion.oftc.net
1139488122 Q * eyck iridium.oftc.net arion.oftc.net
1139488122 Q * nox iridium.oftc.net arion.oftc.net
1139488122 Q * zobel iridium.oftc.net arion.oftc.net
1139488122 Q * Hunger iridium.oftc.net arion.oftc.net
1139488122 Q * meandtheshell iridium.oftc.net arion.oftc.net
1139488122 Q * hallyn_zzzz iridium.oftc.net arion.oftc.net
1139488122 Q * ntrs iridium.oftc.net arion.oftc.net
1139488122 Q * Dr4g_ iridium.oftc.net arion.oftc.net
1139488122 Q * brc_ iridium.oftc.net arion.oftc.net
1139488122 Q * mire iridium.oftc.net arion.oftc.net
1139488122 Q * micah iridium.oftc.net arion.oftc.net
1139488122 Q * cemil iridium.oftc.net arion.oftc.net
1139488282 J * mire_ ~mire@mail.sfb.bg.ac.yu
1139488282 J * phreak`` ~phreak``@styx.xnull.de
1139488282 J * prae ~prae@ezoffice.mandriva.com
1139488282 J * meandtheshell ~markus@85-125-225-123.dynamic.xdsl-line.inode.at
1139488282 J * grant_ mep@p50919AC5.dip0.t-ipconnect.de
1139488282 J * hallyn_zzzz ~xa@c-24-11-243-196.hsd1.in.comcast.net
1139488282 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com
1139488282 J * Bertl herbert@212.16.62.52
1139488282 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it
1139488282 J * Dr4g_ Dr4g@82-40-43-86.cable.ubr06.uddi.blueyonder.co.uk
1139488282 J * jkl eric@c-67-172-156-116.hsd1.co.comcast.net
1139488282 J * Wonka produziert@chaos.in-kiel.de
1139488282 J * SNy 9a2cb72906@bmx-chemnitz.de
1139488282 J * zobel zobel@zobel.irc.ftbfs.de
1139488282 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com
1139488282 J * brc_ bruce@20151215029.user.veloxzone.com.br
1139488282 J * mire ~mire@183-166-222-85.COOL.ADSL.VLine.Verat.NET
1139488282 J * click click@ti511110a080-4978.bb.online.no
1139488282 J * Psy0rz_ ~psy0rz@lounge.datux.nl
1139488282 J * kilian kk@projects.verfaction.de
1139488282 J * Snow-Man ~sfrost@kenobi.snowman.net
1139488282 J * blizz ~blizz@evilhackerdu.de
1139488282 J * Adrinael adrinael@hoasb-ff09dd00-79.dhcp.inet.fi
1139488282 J * monrad ~mikkel@213083190131.sonofon.dk
1139488282 J * cohan ~cohan@koniczek.de
1139488282 J * harry ~harry@d515321D1.access.telenet.be
1139488282 J * micah ~micah@69.90.134.205
1139488282 J * cemil ~cemil@defiant.wavecon.de
1139488282 J * Hunger Hunger.hu@Hunger.hu
1139488282 J * nox ~nox@nox.user.oftc.net
1139488282 J * eyck eyck@81.219.64.71
1139488282 J * Cru ~mindwarp@turbodiesel.e.de.wahlich.com
1139488282 J * Vudumen vudumen@217.20.138.8
1139488282 J * cehteh foobar@cehteh.homeunix.org
1139488282 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1139488282 J * sladen ~paul@193.28.45.41
1139488283 J * ComplexMind ~ComplexHo@cpc1-brig3-6-0-cust194.brig.cable.ntl.com
1139488283 J * wibble_ wibble@vortex.ukshells.co.uk
1139488916 J * andrew_ ~andrew@tnlug.linux.org.tw
1139489301 J * Loki|muh loki@satanix.de
1139489419 Q * Loki_muh Read error: Connection reset by peer
1139489476 Q * weasel Remote host closed the connection
1139489482 J * weasel weasel@asteria.debian.or.at
1139489909 Q * Aiken Read error: Connection reset by peer
1139490611 P * lchvdlch :)
1139491335 P * roadrunner 
1139491471 M * arnaud ok, so it's postfix's fault
1139491535 M * arnaud grmpf
1139491610 M * Bertl arnaud: ah, solved it?
1139491626 M * arnaud Bertl, by upgrading postfix yes
1139491650 M * Bertl good to know, you might add a note on our problematic programs page
1139491663 M * arnaud postfix 2.1.5:
1139491665 M * arnaud     if (!IN_CLASSA(inaddr)
1139491665 M * arnaud         || !(((inaddr & IN_CLASSA_NET) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)) {
1139491665 M * arnaud         if (bind(sock, (struct sockaddr *) & sin, sizeof(sin)) < 0)
1139491676 M * arnaud this if() should not be executed
1139491706 M * Bertl ah, cool
1139491707 M * arnaud the loopback address is in class A and the second condition is false too
1139491719 M * arnaud but it is...
1139491740 M * arnaud so postfix binds to the local interface and can't connect to the mx
1139491802 M * Bertl i.c.
1139493426 J * mnemoc ~amery@200.75.27.68
1139493479 M * Bertl morning mnemoc!
1139493559 M * mnemoc hi Bertl 
1139493662 J * sod` ~soda@yoko.gunnm.org
1139493664 M * sod` hi
1139493695 M * Bertl welcome sod`!
1139493728 J * Doener doener@i5387E8DE.versanet.de
1139493737 M * Bertl morning Doener!
1139493749 M * Doener morning Bertl!
1139493749 M * sod` I have some problems with vserver, I installed the lastest versions of util-vservers, the last kernel patch and when I run : vserver myserver start, it does'nt work, saying that : "/proc/uptime can not be accessed"
1139493763 M * sod` Do you have any idea please ?
1139493770 M * Bertl yep, run the vprocunhide script
1139493789 M * Bertl it is usually installed with the 'make distribution-install'
1139493796 M * Doener hm, doesn't the error message even state that?
1139493797 M * sod`  \o/
1139493824 M * sod` it works :)
1139493830 M * Bertl :)
1139493871 M * Bertl sod`: that script should be added to your sysv (or whatever) init, so that it is auomagically run when your system boots
1139493915 M * sod` ok, now, the network doesn't work too
1139493925 M * Bertl ah, no, you just think so :)
1139493940 M * sod` SIOCSIFADDR: Permission denied
1139493944 M * sod` :/
1139493954 M * Bertl what are you 'trying' to do?
1139493968 M * Doener you're not supposed to setup the networking from the inside
1139493995 M * sod` In fact, I have myserver/interfaces/0/{ip,prefix,dev} files
1139494010 M * sod` but the interface does'nt seem to work
1139494010 M * Bertl ah, and you have that ip already set?
1139494016 M * sod` no
1139494026 M * arnaud Bertl, the postfix directive smtp_bind_address also solves the problem
1139494028 M * Bertl check with 'ip addr ls'
1139494038 M * arnaud Bertl, i added that on the problematic programs page
1139494043 M * Bertl arnaud: ah, good to know! thanks!
1139494052 M * Bertl sod`: check with 'ip addr ls'
1139494077 M * Doener Bertl: maybe we should have named addresses by default and add a 'noname' config? *tired of folks trusting ifconfig instead of ping or sth.*
1139494103 M * Bertl nah, folks have to do the step into the 21st century :)
1139494103 M * sod` Bertl: I don't have ip program :)
1139494113 M * Doener install iproute
1139494118 M * sod` Bertl: but, can I set up the gateway for the vserver instance
1139494131 M * Bertl sod`: yes, on the host
1139494141 M * sod` Bertl: ok, it works !
1139494151 M * sod` I see the ip on eth0
1139494153 M * Bertl \o/
1139494158 M * sod` ok, and now, for the gateway ?
1139494185 M * Bertl depends on your setup
1139494201 M * Bertl do you have several public ips in different networks?
1139494226 M * sod` yeah
1139494238 M * Bertl with several default gateways?
1139494246 J * weaselTM weasel@asteria.debian.or.at
1139494252 M * sod` no, one gateway
1139494268 M * Bertl okay, then the current setup should be already fine
1139494268 N * weaselTM Guest2063
1139494268 Q * weasel Killed (Guest2063 (go away))
1139494269 N * Guest2063 weasel
1139494292 M * Bertl sod`: if you have more than one gateway, you will need this:
1139494295 M * Bertl http://archives.linux-vserver.org/200311/0470.html
1139494364 M * sod` thanks !
1139494398 M * Bertl you're welcome! have fun! feel free to hang around, and don't forget to add yourself to out Happy Users page once you are :)
1139494417 M * sod` I am very Happy with vserver !
1139494437 M * sod` We use it for our french free-hosting service tuxfamily (http://tuxfamily.org)
1139494451 M * Doener http://www.frsirt.com/english/advisories/2006/0464 *LOL* (compare affected products and solution)
1139494458 M * Bertl sod`: ah, then please put a link there (if not done so already)
1139494476 M * sod` a link ? 
1139494481 M * Bertl (and here the user page http://linux-vserver.org/VServer+Users)
1139494482 M * daniel_hozac Doener: lol
1139494512 M * Bertl sod`: well, maybe something stating that you use <A href=...>Linux-VServer</A>
1139494518 M * sod` Bertl: ok
1139494542 M * Bertl and of course, add a link to the Users page pointing to your site
1139494577 M * sod` :)))
1139494581 M * sod` no problem 
1139494718 M * Doener Bertl: hm, vserver.13thfloor.at seems to be dead
1139494746 M * Bertl Doener: works here
1139494759 M * daniel_hozac here too.
1139494760 M * Doener :(
1139494789 M * Bertl ah, well, first wikipedia, now linux-vserver :)
1139494822 M * Doener 209.135.140.107, that's the right ip address?
1139494837 M * daniel_hozac that's the one i'm connecting to.
1139494840 M * Bertl yup
1139494866 M * daniel_hozac Bertl: after adding that missing hunk, the accounting works fine again.
1139494868 M * Doener ok, so it's not a dns problem... going to bug my isp then
1139494878 M * Bertl daniel_hozac: excellent!
1139494892 M * Bertl daniel_hozac: currently building guest #19
1139494911 M * daniel_hozac eexit
1139494938 M * daniel_hozac argh, dumb KVM is messing with me.
1139494960 M * Bertl making you look like an idiot! stupid KVM!
1139494984 Q * Doener Quit: Leaving
1139494991 A * Bertl is in sleep deprevation-funny mode ... we apologize for the inconvenience ...
1139495005 M * daniel_hozac haha.
1139495036 J * Doener doener@i5387CFC8.versanet.de
1139495041 M * daniel_hozac this is rather OT, but how would you go about debugging a shutdown failure?
1139495053 M * Bertl depends on the shutdown failure
1139495066 M * daniel_hozac as in, the box will be ready to shutdown, but it won't power off or reboot.
1139495068 M * Bertl what does _not_ work? the power off?
1139495188 M * daniel_hozac (that is what hangs the KVM too, i think)
1139495294 M * Bertl daniel_hozac: that's a wrong/broken call to the bios
1139495294 M * sod` Bertl: MEGA THANKS, it works ery good !
1139495294 M * Bertl sod`: excellent! you're welcome again!
1139495294 M * daniel_hozac great :/ that sounds like something i'll never be able to fix or even debug.
1139495294 M * sod` thanks !
1139495294 M * Bertl daniel_hozac: I would not be suprised if changing a few kernel options would make it work
1139495294 M * Bertl daniel_hozac: try with APM and look for experimental/embedded options
1139495294 M * Bertl daniel_hozac: something like use bios for power of ...
1139495306 M * daniel_hozac CONFIG_X86_BIOS_REBOOT=y
1139495324 M * Bertl what about APIC/ACPI?
1139495357 M * Doener *lol* ticket written, and when i prepared a traceroute to attach it, the connection was fine again
1139495546 M * daniel_hozac hmm.
1139495572 M * daniel_hozac ACPI: Interpreter disabled.
1139495580 M * daniel_hozac apm: BIOS not found.
1139495594 M * daniel_hozac i guess that might be the problem.
1139495638 M * Bertl yep, could be, check for the time/date limit
1139495659 M * daniel_hozac for ACPI? 2001.
1139495674 M * sod` Bertl: just one question
1139495692 M * sod` Bertl: I have an public ip on the machine which host the vserver with an ssh server
1139495704 M * sod` and I have an public ip on the vserver with a ssh server
1139495716 M * Bertl Listen directive on the host
1139495728 M * sod` aaaahhhhh
1139495734 M * Bertl :)
1139495745 M * Bertl the guest won't need that, as they are restricted anyway
1139495780 M * daniel_hozac ah, i missed: ACPI: Unable to locate RSDP
1139496043 J * gerrit ~gerrit@c-67-160-130-59.hsd1.or.comcast.net
1139496068 M * Bertl welcome gerrit!
1139496084 M * gerrit Hi Bertl!
1139496276 M * sod` thanks for all !
1139496277 Q * sod` Quit: leaving
1139496355 M * daniel_hozac is it possible to reboot a box that doesn't have APM or ACPI?
1139496432 M * daniel_hozac well, working APM or ACPI, at least.
1139496487 M * Bertl yes, should be possible, but not for recent laptops
1139496500 M * daniel_hozac it's a really old server ;)
1139496525 M * daniel_hozac (Proliant 1600, most recent BIOS is from 2000)
1139496595 M * Bertl well, I'd suggest to try two things
1139496626 M * Bertl a) search for a fixed ACPI table for it and/or fix it yourself
1139496649 M * Bertl b) try various APM/ACPI combos, with LAPIC and so
1139496653 J * mef ~mef@targe.CS.Princeton.EDU
1139496662 M * Bertl (do not hesitate to enable ACPI and APM)
1139496667 M * Bertl morning mef!
1139496671 M * daniel_hozac i already have both enabled.
1139496678 M * mef good morning bertl
1139496696 M * daniel_hozac (i have almost everything enabled. it is a Fedora kernel ;))
1139496720 M * Bertl ah, in this case try option c)
1139496747 M * Bertl test with kernel which is still alive :)
1139496774 M * daniel_hozac hmm?
1139496783 M * Bertl (not patched to death :)
1139496805 M * SiD3WiNDR why wouldn't you be able to reboot a box without apm/acpi?
1139496812 M * daniel_hozac ah.
1139496812 M * SiD3WiNDR those are for power management, not for reboot management ;)
1139496819 M * Bertl SiD3WiNDR: not reboot, power off
1139496825 M * SiD3WiNDR ah
1139496832 M * SiD3WiNDR all I see is "< daniel_hozac> is it possible to reboot a box that doesn't have APM or ACPI?" ;)
1139496832 M * daniel_hozac neither works though ;)
1139496846 M * Bertl hmm, reboot should work
1139496892 M * Bertl daniel_hozac: try 'reboot -f' or echo "r" >/proc/sysrq-trigger
1139496908 M * Bertl (but make sure to sync fielsystems first)
1139497152 M * daniel_hozac well, ok, reboot does get past the rebooting stage, but the box won't come back up afterwards. i guess the BIOS is really rather broken.
1139497215 M * Bertl whcih bios version do you have?
1139497223 M * daniel_hozac the latest, P08.
1139497292 M * Bertl is it the right one?
1139497302 M * daniel_hozac would the SCSI card's BIOS be able to interfer with this sort of thing?
1139497314 M * Bertl hp page lists E34 for the slower PII
1139497329 M * daniel_hozac i've got the PIII 500 MHz model.
1139497340 M * Bertl okay, what OS is configured in the bios?
1139497945 J * yodahome ~yoda@pD9514B38.dip0.t-ipconnect.de
1139498031 M * yodahome Hi! @ all
1139498120 J * SuperLag ~aaron@38.99.66.175
1139498161 M * Bertl welcome yodahome! SuperLag!
1139498162 M * SuperLag Gentlemen, I am stumped, once again. :)
1139498181 M * yodahome @ Bertl: Hi! Any new ideas about the problem with the debian vservers that will not boot?
1139498231 M * SuperLag I have 5 guests configured.  the first one all of a sudden refuses inbound ssh connections.  ssh is started, I have tried setting the listen address both to 0.0.0.0 and to the ip of that guest, yet all inbound ssh connections get refused.  I'm stumped. :/
1139498245 M * SuperLag btw, ssh works on all the other guests, just fine :)
1139498254 M * Bertl refused means?
1139498291 M * Bertl yodahome: hmm, no, not really, last time we concluded that they _are_ started IIRC, just the script doesn't do what it's supposed to do ...
1139498323 M * SuperLag akulbe@linux % ssh 38.99.66.176 -l root                                                                                                 ~
1139498326 M * SuperLag ssh: connect to host 38.99.66.176 port 22: Connection refused
1139498356 M * Bertl okay, do you get any log message on the host or in one of your guests?
1139498489 M * yodahome Yeah, that's how far we came... and I really don't know enough about how the script works to get an idea what may be the cause... so I'll probably just play around a bit... Any chance that updating to newer utils might improve the situation (magically)??
1139498514 M * SuperLag Bertl: strangely... no. I don't.
1139498583 M * Bertl SuperLag: okay, let's use tcpdump -vvnei eth0 port 22
1139498590 M * Bertl (or whatever interface you have)
1139498611 M * SuperLag Bertl: should I do that from inside the guest?
1139498619 M * SuperLag or on the host?
1139498620 M * daniel_hozac Bertl: umm, i'd like to check, but i have no idea how to enter the BIOS :/
1139498626 M * Bertl yodahome: I don't think so, but you can try, definitely I'd try to comment out the lines we traced last time?
1139498635 M * Bertl daniel_hozac: IIRC F8 or F12
1139498648 M * Bertl SuperLag: host
1139498666 M * Bertl bingo!
1139498712 M * SuperLag huh?
1139498720 M * SuperLag or was that one intended for someone else? :)
1139498729 M * Bertl yeah, basically for myself :)
1139498760 M * Bertl searching for an issue for 16 hours now (nor more)
1139498764 M * Bertl *or
1139498770 M * SuperLag :)
1139498772 M * Bertl yeah, actually it's 20 hours
1139498775 M * daniel_hozac RoadRunnR's?
1139498779 M * Bertl yup
1139498791 M * Bertl I have a working and a non working version, now diffing
1139498791 M * daniel_hozac cool, what was the problem?
1139498796 M * daniel_hozac ah.
1139498798 M * SuperLag Bertl: I ran the tcpdump command with the options you specified.  Should it be printing to stdout?
1139498805 M * Bertl not so fast young grashopper! :)
1139498816 M * Bertl SuperLag: yes
1139498822 M * SuperLag nothing.
1139498833 M * Bertl SuperLag: if you do not see anything, then your isp does not route the ip to you (yet)
1139498848 M * Bertl SuperLag: i.e. it stops somewhere before
1139498849 M * SuperLag hehe
1139498862 M * Bertl try with tracepath (from a different site)
1139498882 M * Bertl and verify with an address you know that it is working
1139498947 M * SuperLag it makes no sense
1139498952 M * SuperLag none
1139498955 M * SuperLag Bertl: get this.
1139498980 J * martin ~martin@84-245-81-250-broadband.iol.sk
1139498981 M * SuperLag I have other IPs on that same physical interface, and I can ssh through them, to the *other* guests, just fine.
1139498992 M * martin hello
1139498997 M * Bertl welcome martin!
1139499000 M * SuperLag and when I say "other IPs", I mean other *public* IP addresses
1139499013 M * martin i'm here again with a problem
1139499017 M * Bertl SuperLag: those will also log with the tcpdump, yes?
1139499030 N * martin Guest2064
1139499067 M * SuperLag Bertl: no sir.
1139499075 N * Guest2064 MartinZd2
1139499095 M * Bertl SuperLag: then you are doing something wrong
1139499098 M * SuperLag but I can run tcpdump on the other interface (eth0) and it starts logging like crazy
1139499116 M * Bertl well, you are probably logged on via ssh too
1139499129 M * SuperLag eth0 is the same interface that this ssh and IRC connection are going over
1139499145 M * Bertl pick a host that is outside your network (somewhere on the internet)
1139499156 M * SuperLag already tried that
1139499176 M * SuperLag I can get to guests 2,3,4,5 that way
1139499179 M * SuperLag but not guest 1
1139499187 M * Bertl use something like:  tcpdump -vvnei host <outside-ip>
1139499200 M * SuperLag oh
1139499204 M * Bertl ops
1139499212 M * Bertl tcpdump -vvnei  eth0 host <outside-ip>
1139499234 M * MartinZd2 i have one application running on real server. it listens on 0.0.0.0:12345. i need to run the same application on vserver, but i can't of course. therefore i run that application using "chbind --ip 127.0.0.1 -- application". now i can run this app on both server and vserver. my problem is the application running on server can't bind to other addresses than local. how could i solve that?
1139499251 M * SuperLag Bertl: nothing
1139499265 M * Bertl MartinZd2: add further IPs to the chbind?
1139499285 M * Bertl SuperLag: now try with one of your other guests as destination
1139499306 M * Bertl SuperLag: if you still get nothing you are doing something wrong
1139499313 M * MartinZd2 Bertl: is it possible to add more addresses? i'll try
1139499349 M * Bertl MartinZd2: sure, 127.0.0.1 is probably the worst choice anyway :)
1139499399 M * SuperLag Bertl: I get logging when I use guest2's IP ad the destination, and connect back to the host
1139499438 M * Bertl SuperLag: you should not connect in all directions ...
1139499450 M * Bertl SuperLag: let me ask a few questions:
1139499460 Q * shedi Quit: Leaving
1139499472 M * Bertl - are you working _on_ that machine right now?
1139499488 M * Bertl - how do you access the host (physical server)?
1139499494 M * SuperLag ssh
1139499504 M * Bertl from where? somewhere outside, yes?
1139499512 M * SuperLag I am in Kansas City, MO.  The box is in San Jose, CA in a colocation facility.
1139499536 M * Bertl okay, good, your host has ip 'A'
1139499537 M * SuperLag and I have 6 public IP addresses
1139499543 M * SuperLag host - 38.99.66.175 (eth0), guest1 - 38.99.66.176 (eth1)   
1139499565 M * Bertl hmm, you sure about that?
1139499571 M * SuperLag guests 2,3,4,5 38.99.66.236|237|238|239
1139499585 M * SuperLag am I sure about what?
1139499585 M * Bertl I mean it's unusual that you get two interfaces but the same network
1139499593 M * SuperLag yes, I'm sure
1139499609 M * Bertl so 38.99.66.175 is on eth0, but 38.99.66.176 on eth1?
1139499613 M * MartinZd2 Bertl: doesn't seem to work. i ran "chbind --ip 127.0.0.1 --ip 192.168.0.10/eth1 -- app", but that app can't connect to 192.168.0.10
1139499615 M * SuperLag corrent
1139499619 M * SuperLag correct, that is
1139499634 M * Bertl MartinZd2: what's 192.168.0.10/eth1 supposed to be?
1139499654 M * Bertl MartinZd2: try chbind --ip 192.168.0.10 -- app
1139499658 M * SuperLag Bertl: can I paste you some output in /query?
1139499671 M * SuperLag or would you prefer I pastebin it?
1139499678 M * Bertl yep, definitely
1139499718 M * SuperLag http://rafb.net/paste/results/VMf9Jy56.html <-- note the MAC address are one digit apart
1139499739 M * SuperLag sorry, you answered as I was away pasting :)
1139499771 M * Bertl no, that doesn't look right to me :)
1139499781 M * SuperLag what doesn't look right?
1139499788 M * Bertl first, check the broadcast addresses
1139499806 M * Bertl the eth1 one is in a different network
1139499853 M * Bertl the eth0 one should be 38.99.67.255 too or
1139499857 M * Bertl the netmask is wrong
1139499895 M * Bertl also, I doubt that you have a router there which gives you two IPs in the _same_ network but on _different_ interfaces
1139499908 M * SuperLag that doesn't make sense.
1139499919 M * Bertl also eth1 shows _zero_ packets
1139499928 M * SuperLag my config file defines the same broadcast and netmask
1139499934 M * Bertl so nothing was ever received or transmitted there
1139499962 M * SuperLag then what in the hell am I using???
1139499974 M * Bertl I'd opt for eth0 for all of them
1139499999 M * Bertl probably with wrong masks 
1139500001 M * SuperLag are you thinking eth1 on the same broadcast domain would cause a routing loop?
1139500028 M * Bertl well, it would definitely lead to undetermined behaviour
1139500053 M * Bertl but now let's check if your ip for your guest 5 is there
1139500063 M * Bertl use 'ip addr ls' and upload the output again
1139500152 M * SuperLag it's not there
1139500156 M * SuperLag but I can get out
1139500196 M * SuperLag I can start guest 5, the ifconfig info shows the interface, but it has no IP configuration, and still allows me to ping out to an external site, by domain name
1139500259 M * Bertl use 'ip addr ls' (on the host) and upload the output :)
1139500271 M * MartinZd2 Bertl: doesn't work. that weird application is hardcoded to bind to "localhost:3456" and moreover it needs to bind to "192.168.0.10:1234"
1139500284 M * SuperLag Bertl: huh?
1139500294 M * SuperLag you mean the same thing I did before?
1139500296 M * SuperLag that's ifconfig
1139500313 M * Bertl SuperLag: 'ip addr ls'
1139500333 M * Bertl MartinZd2: well, if it is hardcoded to localhost, then change localhost
1139500359 M * Bertl MartinZd2: if it is hardcoded to something else, use S/DNAT to fix that for that specific port
1139500367 M * MartinZd2 Bertl: :-/ but there are other apps runing on that server that needs localhost as 127.0.0.1
1139500401 M * Bertl MartinZd2: so what do you expect me to do? change the hardcoded app?
1139500428 M * MartinZd2 Bertl: :) no ... if that app ran on vserver there would be no problem
1139500442 M * Bertl why not put it there then?
1139500461 M * MartinZd2 Bertl: well, i guess i will have to :-/
1139500512 Q * Loki|muh Read error: Connection reset by peer
1139500514 J * Loki|muh loki@satanix.de
1139500556 M * MartinZd2 i am angry with that app! that weird app is Openexchange and it is very ugly hardcoded ..
1139500591 M * Bertl openexchange sounds like open source ...
1139500591 M * MartinZd2 Bertl: thanks for the tips ;)
1139500631 M * MartinZd2 Bertl: this is commercial version and i don't know why i we can't get the source ...
1139500646 M * Bertl ah, open but closed :)
1139500695 M * Bertl well, you might still have luck using some S/DNAT tricks on it
1139500702 M * Bertl especially if it uses specific ports
1139500703 M * MartinZd2 one more question: if i run java on vserver1 and vserver2 will it share the memory?
1139500720 M * MartinZd2 ok, i'll try NAT then :)
1139500728 M * Bertl if it is the same executable/libs then it will share some memory
1139500740 M * Bertl (that something you can get with unification)
1139500747 M * SuperLag Bertl: ip is not a valid command
1139500758 M * Bertl SuperLag: on the host?
1139500759 M * MartinZd2 SuperLag: install iproute2 :)
1139500768 M * Bertl SuperLag: what tools have you installed?
1139500786 M * Bertl MartinZd2: iproute is a requirement for util-vserver
1139500839 M * MartinZd2 Bertl: same executable/libs ? on each vserver is one copy. does it mean they're same?
1139500842 M * harry :(
1139500852 M * harry we've decided not to use vserver, but vmware server :s
1139500858 M * Bertl MartinZd2: no, probably not, see unification ...
1139500876 M * Bertl harry: well, the hardware industry will be happy :)
1139500878 M * MartinZd2 Bertl: in manual? i'll check it
1139500900 M * harry Bertl: i couldn't give any numbers on performance difference
1139500909 M * harry and: you know the hardware it runs on... ;)
1139500916 M * Bertl MartinZd2: http://linux-vserver.org/alpha+util-vserver
1139500925 M * MartinZd2 BTW anyway, what is the advantage of vserver against vmware?
1139500957 M * Bertl well, for example, lycos tested up to 150 guests on a dual PIII
1139500981 M * Bertl I doubt that vmware will do that on any machine :)
1139501003 M * harry the main disadvantage (that my boss mentioned): if the kernel gets owned, all your vm's are worthless
1139501019 M * Bertl same as on vmware, no?
1139501038 M * harry in vmware you have different/independent kernels for all hosts
1139501058 M * Bertl IIRC, they even had an exploit for the root kernel (from inside), via the network modules :)
1139501082 M * harry hmm... url on that? ;)
1139501167 M * Bertl http://www.gentoo.org/security/en/glsa/glsa-200601-04.xml
1139501191 M * Bertl https://www.juniper.net/security/auto/vulnerabilities/vuln2836.html
1139501219 M * yodahome I just booted the debian vserver using this really large command (by hand). When trying a ps from inside i get: "Error, do this: mount -t proc none /proc" Obviously /proc is not mounted and can't be. Is that a problem that occurs because of not using the script to boot? Or is it more serious?
1139501252 M * Bertl probably just not mounted
1139501417 M * yodahome yeah, but i can't do that from inside the vserver, right?
1139501429 Q * MartinZd2 Ping timeout: 480 seconds
1139501432 M * Bertl yodahome: not once the guest is started
1139501935 M * yodahome yeah, I thought so... Ok, no more playing today. Cu!
1139501937 J * MartinZd2 ~martin@84-245-81-250-broadband.iol.sk
1139501945 M * hallyn_zzzz ebiederm: in your pspace patchset, you miss a few uses of 'kill_proc'
1139501976 M * Bertl good morning hallyn_zzzz!
1139502009 P * yodahome 
1139502070 N * hallyn_zzzz hallyn
1139502070 M * hallyn good morning
1139502962 J * Smutje_ ~Smutje@xdsl-84-44-144-61.netcologne.de
1139503064 Q * Smutje Ping timeout: 480 seconds
1139503064 N * Smutje_ Smutje
1139503480 J * stefani ~stefani@superquan.apl.washington.edu
1139503503 M * Bertl stefani: hola!
1139503816 M * stefani salut ! 
1139504470 M * SuperLag Bertl: here it comes
1139504528 M * SuperLag Bertl: that was bad.  this is better --> http://rafb.net/paste/results/faQeFZ89.html
1139504678 M * Bertl well, kinda looks like I'd expected
1139504716 M * Bertl so, first you want to get them to eth0
1139504733 M * Bertl (at least that's where the traffic seems to happen)
1139504961 M * SuperLag that doesn't make sense though
1139504969 M * SuperLag I'm trying to save some traffic for myself!! :)
1139504987 M * SuperLag that's why I wanted to use one interface for me, and one for the guests
1139504999 M * Bertl well, look, it might work if your ips would split those networks
1139505004 M * Bertl *isp
1139505070 M * Bertl e.g. give you 38.99.66.175,176 on one network (/28 e.g.)
1139505070 M * Bertl and the 236.237.238.239 on the other
1139505070 M * Bertl currently they seem to be only connected to eth0
1139505084 M * Bertl I'm not sure that eth1 has even link
1139505113 M * Bertl and of course, the broadcast for eth0 is wrong
1139505171 M * SuperLag why is that wrong?
1139505189 M * Bertl sec
1139505212 M * Bertl http://jodies.de/ipcalc
1139505237 M * Bertl now enter: 38.99.66.175 and 22
1139505265 M * Bertl and check the broadcast
1139505309 M * SuperLag I was wondering.
1139505333 M * SuperLag because when I did ifconfig eth1 38.99.66.176/22 it automatically set it at .67.255
1139505463 M * Bertl so the question is now, why do you use that wrong address?
1139505521 M * Bertl once you fixed that, we can investigate the other issue, regarding the guest IP
1139505603 M * SuperLag Bertl: that's what I was given.
1139505614 M * SuperLag I'm talking to one of the guys at the colo about it right now
1139505624 M * Bertl well, then I'd say your isp has no clue whatsoever :)
1139505642 M * Bertl that's something a network admin has to get right :)
1139505837 M * Hollow Bertl: the vcc comand line is working :) http://phpfi.com/101206
1139505857 M * Bertl coll!
1139505861 M * Bertl *cool! even
1139505942 M * Hollow next step is to implement the commands.. so, seems like i'll bother you with a bunch of questions the next few days ;)
1139505952 M * Bertl I'm still going in circles here, but I know now that there are three bears on the island :)
1139505968 J * FireEgl Atlantica@2001:5c0:84dc::
1139505978 M * Bertl welcome FireEgl!
1139505998 M * FireEgl =D
1139508254 J * fwl ~fwl@83.215.237.1
1139508275 M * Bertl welcome fwl!
1139508302 M * fwl hello Bertl !
1139508339 M * fwl al last I found the way in here
1139508350 M * Bertl yeah, great! new irc client?
1139508366 J * shedi ~siggi@inferno.lhi.is
1139508445 M * fwl yes, client is fine. but I had to disable default setting for SSL. yesterday I was too tired to think of a reason for my connection problem.
1139508447 N * ebiederm_zZzZ ebiederm
1139508525 M * Bertl fwl: ah, well, I'm still searching for the issue we discovered
1139508571 M * fwl yes, I thought so. we should not hurry now, but go another little steps to reach goals.
1139508620 M * fwl to me it does not matter to wait until next week. quality is more important than speed.
1139508651 M * Bertl good to hear, well we should be able to nail it today or tomorrow
1139508676 M * Bertl I'm at my 45th kernel compile and 28th guest buidl today :/
1139508691 M * fwl ;-)
1139508711 M * ebiederm hallyn:  I know I missed a few places.  I think I said that in my introduction.
1139508724 M * Bertl ah, morning ebiederm!
1139508734 M * ebiederm Good morning.
1139509194 M * SuperLag Hollow: how goes it?
1139509310 M * ebiederm hallyn: But I should have gotten enough instances of kill_proc that by turnning off a few things the code was useable.
1139509610 M * Roey hey all!
1139509616 M * Roey hey Bertl, ebiederm, SuperLag, fwl 
1139509771 M * Hollow SuperLag: fine thanks, you?
1139509948 M * Bertl hey Roey!
1139509966 Q * gdm Quit: leaving
1139509985 Q * prae Quit: Execute Order 69 !
1139510631 M * hallyn ebiederm: yup, except some drivers i need for s390 :)  which clearly you couldn't know
1139510675 M * SuperLag Hollow: a little frustrated, but otherwise good
1139510725 M * Bertl SuperLag: because of the colo issues?
1139510812 M * SuperLag yep
1139510846 M * Bertl ah, well, better you find out now than in a few month, when you have real issues
1139510868 M * ebiederm hallyn: Right.  I am in the process of digesting your patch now.
1139511018 M * ebiederm hallyn: I took 2 of your 3 patches fs3270.c needs some more work to be correct.
1139511198 M * hallyn so what's your thought on pspace to use in device driver modules?  Should init_pspace be exported and used in all drivers?
1139511241 M * ebiederm hallyn: No.
1139511278 M * ebiederm Although there may be sense in exporting init_pspace.
1139511303 M * ebiederm For fs3270 you need to save the pspace when you save the pid.
1139511306 M * Bertl why would device driver want to do that?
1139511330 M * ebiederm Bertl: Good question.
1139511348 M * ebiederm drivers/s390/char/fs3270.c seems to be what we are discussing.
1139511389 M * Bertl okay, that's a screen driver, yes?
1139511410 M * Bertl something similar to a console/termina
1139511414 M * Bertl +l
1139511446 M * ebiederm Bertl: That is what it looks like yes.
1139511453 M * ebiederm Appearently it has a controlling process.
1139511458 M * Bertl what is the 'pid' supposed to do there?
1139511510 M * Bertl          * If the rdbuf command failed or the idal buffer is
1139511510 M * Bertl          * to small for the amount of data returned by the
1139511510 M * Bertl          * rdbuf command, then we have no choice but to send
1139511510 M * Bertl          * a SIGHUP to the application.
1139511521 M * Bertl that looks very hackish to me
1139511554 M * Bertl and it's the _only_ use of that strange pid
1139511558 M * ebiederm Agreed. 
1139511569 M * hallyn Candidate for proper fixing perhaps...
1139511578 M * Bertl I'd say so ...
1139511599 M * Bertl if it wants to inform an application of whatever
1139511603 M * dhansen Bertl: hallyn: probably worth a mail to the s390 guys.  They usually fix these kinds of things in a hurry.
1139511621 M * dhansen plus, with s390, there are always 1000 things going on under the covers that us mere mortals will never know :)
1139511626 M * Bertl then it should do it via a 'proper' interface :)
1139511676 M * Bertl dhansen: hmm, well, unfortunately I do not own such a thing, but I already booted and tested linux-vserver on hercules (from virtual punch cards  :)
1139511680 M * ebiederm All of this feels like it is a synchronous interface so they might simply be able to send a signal to current.
1139511724 M * hallyn Bertl: whoa
1139511771 M * Bertl http://list.linux-vserver.org/archive/vserver/msg09704.html
1139511773 M * ebiederm hallyn: Is the s390 your main test machine?  Or do you mess with a bunch of different architectures?
1139511949 M * hallyn ebiederm: depends on the time...  right now that's my main one.  sometimes it's a power5.  usually it's both.
1139511983 M * ebiederm Ok.
1139512046 M * hallyn I can test on x86 if i must, but it requires a bit of setup right now...
1139512048 J * dearaujo ~dearaujo@pixpat.austin.ibm.com
1139512057 M * Bertl welcome dearaujo!
1139512066 M * ebiederm hallyn: No problem.
1139512067 M * dearaujo hello
1139512074 M * Bertl hallyn: no, hercules is easy to install
1139512084 M * hallyn long as you have a card punch?
1139512093 M * Bertl a virtual one! :)
1139512100 J * frankeh ~frankeh@129.33.1.37
1139512110 M * Bertl welcome frankeh!
1139512123 M * dearaujo i was wondering if someone could explain to me vprocunhide
1139512136 Q * fwl Quit: This computer has gone to sleep
1139512136 M * Bertl dearaujo: sure, it's a script ...
1139512199 M * dearaujo i understand that it "protects entries in the proc filesystem from being seen in every context"
1139512206 M * dearaujo but why do you need that?
1139512227 M * Bertl do you have a machine at hand?
1139512231 M * dearaujo yes
1139512262 M * Bertl does your /proc contain something like /proc/sysrq-trigger ?
1139512279 M * dearaujo yes
1139512332 M * Bertl well, if you write an 'r' there, you machine will reboot instantly
1139512332 M * Bertl now, we actually don't want that to happen from inside a guest :)
1139512505 M * dearaujo heh no :)
1139512505 M * Bertl in theory, the procfs should be clean of such stuff
1139512505 M * Bertl it is supposed to contain processes. period.
1139512505 M * Bertl unfortunately all kind of crap piled up there
1139512505 M * Bertl and we just didn't want to fix every single instance
1139512505 M * Bertl so we decided to simply apply some policy, and
1139512505 M * Bertl categorize them in good and evil!
1139512505 M * Bertl as policy in the kernel is bad per se, we moved that policy into userspace
1139512533 M * Bertl and here we are, vprocunhide :)
1139512565 M * frankeh Hey, without interrupting the current thought.. (just catching up) on the fs3270 issues.... there is no reason why the underlying hypervisor on VM should have to know pids !  There is probably some extra code in there for the reattachment of the 3270 console after one detached.  
1139512591 M * frankeh You can run the same kernel natively on the 390
1139512648 M * Roey Bertl:  you're always so positive
1139512649 M * Roey thanks :)
1139512667 M * frankeh 6-pack aftermath :-)
1139512668 M * dearaujo so
1139512684 M * Bertl Roey: the pleasure is mine ...
1139512688 M * dearaujo it seems this script keeps the vservers from messing up the host procfs then
1139512713 M * Bertl as there is only _one_ procfs, yes :)
1139512721 M * dearaujo well yes :)
1139512724 M * dearaujo heh
1139512733 M * dearaujo great - thank you for the clarification
1139512743 M * Bertl you're welcome!
1139512747 M * ebiederm frankeh: It doesn't look like the pid gets all of the way to the hypervisor.  Just into the fs3270 driver for playing odd tricks.
1139512994 M * Bertl frankeh: IMHO it is an ugly hack to kill/signal the 'client' (user app) when something goes wrong
1139513054 M * frankeh I just looked at this code .. (first time) ... the raw3270_request is what is getting submitted. the fs_pid is higher up and hence simply a linux issue.
1139513064 M * frankeh I don't see where the pid is issued against the hypervisor.
1139513065 M * ebiederm And it is equally bad to assume that the process that opened the file descriptor is always the process that has it open.
1139513123 M * ebiederm frankeh: I don't think anyone every asserted the pid was issued against the hypervisor.
1139513171 M * frankeh Here is a theory .. I presume this allows a single application to take over the single console !
1139513181 M * frankeh And that I think can not be shared.
1139513195 M * Bertl like X11, yes
1139513259 M * frankeh It seems like they are simply making sure of this constraint..  Don't get hung up on it ..if it becomes a problem we have the channels to fix it in 390x
1139513267 M * frankeh what do you see the problem to be ?
1139513320 M * ebiederm frankeh:  At a minimum the dirver now needs to save/restore the pspace as well as the pid with all of the appropriate reference counting.
1139513339 J * fwl ~fwl@83.215.237.1
1139513351 M * Bertl ebiederm: why not just add another constraint that the process has to reside in the initial pspace?
1139513385 M * ebiederm frankeh: But when looking into that it simply appears that the driver was doing something quite silly so we suggested it shouldn't use pids at all.
1139513395 M * frankeh if that's all then I see no problem ...  just would like first to understand how this is really used .. I am just guessing based on using s390 linux
1139513399 M * ebiederm Bertl:  That could work as well.  I don''t know the situation for the s390.
1139513412 M * Bertl and that's still my preference (i.e. remove the pid stuff there)
1139513478 M * Bertl frankeh: there are two calls (callbacks), save and restore
1139513494 M * ebiederm The pid stuff is wrong in the general case so it certainly need to be looked at.
1139513515 M * frankeh OK .. send email to schwidefsky@us.ibm.com 
1139513517 M * Bertl both can get into trouble and if so, they test if there is a process pid, and sends a HUP
1139513527 M * Bertl *send
1139513549 M * Bertl IMHO just leaving the pid field empty should expose any issues
1139513576 M * frankeh There is only one place in _open where we assign fs_pid   and before it checks there is no other fullmode user. So we know single client only (regardless of container or not).
1139513584 M * ebiederm Bertl: The problem is very cute if you send the fd to another process with unix domain sockets.
1139513613 M * Bertl yeah, well, or if the process dies and gets replaced :)
1139513650 M * ebiederm Bertl: The pid is saved in the file descriptor so dying and getting replaced only kicks in if you invoke unix domain sockets.
1139513685 M * Bertl ebiederm: don't let fs_pid fool you
1139513700 M * Bertl ebiederm: it's store in an fs3270 struct
1139513727 M * frankeh Yes and look at open ... first there is a check and if already in full mode then -EBUSY !
1139513757 M * frankeh anyway .. I can't critizise this without further knowledge... so put it on the stack for Martin..
1139513766 M * ebiederm I guess I let the: filp->private_data = fp; fool me.
1139513821 M * ebiederm Anyway this appears to be a classic case of we changed the kernel and look at the bugs we flushed out.
1139513879 M * frankeh yes .. shows again that there are (in)finite problems spots that are not necessarily easily spotted unless "->pid" is examined one by one !
1139513894 P * dearaujo 
1139513944 M * Bertl we should have taken the well tested VZ implementation :)
1139513958 M * ebiederm frankeh: If it was just ->(pid, tgid, pgrp, session) it would be easy.  But there are a few places in the kernel that use pids but don't reference struct task_struct.
1139513998 M * frankeh VZ still on the table !!  and the (pid..session) issue is what your TASK_REF ultimately would solve.
1139514001 M * ebiederm Bertl: VZ only tests on a narrow subset of the entire kernel.  s390 is not one of those pieces.
1139514038 M * ebiederm frankeh: I think so.  I temporarily took TASK_REF off the table because I had a bad feeling of what would happen during a file close.
1139514048 M * ebiederm Because of fowner.
1139514055 M * ebiederm But the overhead appears to be identical.
1139514056 M * frankeh And Eric already seemed to have pointed out some spots in VZ that were missed.
1139514061 M * Bertl ebiederm: you must be mistaken, it runs with thousands of guests on all kind of architectures (according to the PR department ;)
1139514092 M * ebiederm Bertl: To the marketing department ia64, x86 and x86_64 is all kinds of architectures!
1139514095 M * frankeh Ask the PR department what GCC is ?  Do you think they will know:-)
1139514117 M * frankeh anyway .. what other issues to discuss today ?
1139514143 M * ebiederm frankeh: VZ stuff is on the table to see if they have any good ideas behind recent silence.
1139514224 M * ebiederm They have some backwards compatibility business issues that may leave them out of the game.
1139514232 M * frankeh Well.. you saw our stuff from December, which is PID wise, similar to VZ.. I recoded for pidspace (using my code from there), but it was almost identical to your pspace solution, so I don't want to through in another wrench into the game for now apparent purpose.
1139514271 M * frankeh I went on record .. I like the consistent namespace approach. I am getting more and more convinced of it.
1139514279 M * ebiederm frankeh: Agreed.  I don't there is a way the VZ VPID stuff can get back on the table.
1139514289 M * ebiederm Cool.
1139514311 M * Bertl frankeh: yes, the dual pid idea is the first one you get when faced with the task to allow migration
1139514345 M * Bertl it was what came to my mind when folks asked about guest migration too
1139514346 M * frankeh What needs to be decided is are we ditching (at this point) the "struct container" object and going with separated namespaces for subsystems.
1139514371 M * frankeh Only concern with that is space in task_t... 
1139514382 M * Bertl already said yesterday, I love the idea of 'spaces'
1139514399 M * ebiederm frankeh: task_t is huge a couple extra pointers are not a problem.  
1139514418 M * Bertl we currently add the following elements
1139514424 M * ebiederm frankeh: The only possible issue is that we slow down fork() and other pieces of the kernel.
1139514435 M * Bertl - two pointers to vx/nx structs (context/networ)
1139514441 M * frankeh But then people say, we might not have enough bits in clone ????  each bit a pointer .. so it can't be just a couple of pointers then or the other concern is mute
1139514450 M * Bertl - two id fields (for faster/simpler) checks
1139514469 M * Bertl and we would/will add two more fields there
1139514471 M * hallyn so we use unshare but not clone?
1139514477 M * hallyn a. don't slow down clone
1139514482 M * hallyn b. get around the flag shortage
1139514495 M * hallyn but we make unshare even less symetrical with clone...
1139514497 M * ebiederm frankeh: Bits in clone are not a fundamental problem.  An implementation only.  We still have enough bits to get all of the major things anyway.
1139514517 M * ebiederm hallyn: The clone slowdown is atomic_inc for every namespace.
1139514527 M * ebiederm Unshare hasn't been merged yet has it.
1139514532 M * ebiederm ?
1139514534 M * Bertl nope
1139514537 M * ebiederm Except for in the mm tree.
1139514538 M * frankeh agreed, but that statement on mailing list has never been reputed.
1139514555 M * ebiederm frankeh: Which statement?
1139514555 M * hallyn ebiederm: i believe it's in current git
1139514588 M * Bertl ebiederm: I guess he means the overhead of clone
1139514605 M * frankeh hence a container object can server as a umbrella object which takes a ref on creation and then we don't have to do per task/clone refcouting etc.
1139514637 M * Bertl which is basically correct .. we could even optimize that and
1139514642 M * hallyn yup, it's there
1139514645 M * ebiederm Yes.  That and a few other optimization opportunities are the value I see for containers iff it is interesting.
1139514669 M * ebiederm hallyn: Crap then I need to get that fixed before it hits a stable release.
1139514670 M * frankeh And for the subsystems that require fast access you cache  task->container->subs  into task->cont .
1139514684 M * hallyn get what fixed?
1139514711 M * ebiederm unshare last I looked has borked the meaning of the clone bits, so it can't share common code with sys_clone.
1139514734 M * ebiederm I mentioned it and apparently I didn't scream loudly enough.
1139514742 M * hallyn yes, don't think janak addressed that
1139514747 M * Bertl btw, what about the lower clone bits?
1139514760 M * Bertl do they have any meaning?
1139514787 M * ebiederm Bertl: unshare can use them.  sys_clone can't right now because the encode the exit signal.  But that is almost always left at the default of zero.
1139514795 M * mugwump  you guys *still* here?  :)
1139514806 M * ebiederm mugwump: No we are over there!
1139514806 M * Bertl ebiederm: let me rephrase that ...
1139514828 M * Bertl what would be the effect over hijacking the signal mask bits for clone purposes?
1139514859 M * ebiederm Bertl: We would need a bit saying we were hijacking the other bits I believe.
1139514876 M * Bertl imho the only affected parts would be libc and some special admin tools, no?
1139514876 M * ebiederm Doable but awkward.
1139514902 M * ebiederm We are not allowed to break the uer space ABI only extend it. 
1139514923 M * Bertl hmm, k
1139514924 M * ebiederm So only container creating admin tools would be affected.
1139514984 M * ebiederm Let me go off on a tangent for a second.
1139514986 M * ebiederm Task refs.
1139514994 M * Bertl so we have 9 clone flags left
1139515010 M * Bertl ah, okay, task refs it is ...
1139515022 Q * fwl Quit: This computer has gone to sleep
1139515086 M * frankeh got to run now ... 
1139515094 M * Bertl k, cya!
1139515095 M * ebiederm By frankeh.
1139515105 M * frankeh ttyl
1139515117 M * ebiederm Bertl: For clone my count is 6 or 7 bits are free in the stable kernel.
1139515138 M * ebiederm With task refs my concern is two fold.
1139515148 M * ebiederm 1 The overhead may be more than (container pid)
1139515175 M * ebiederm 2) We have to actively change the logic of the code to make the work.
1139515276 M * ebiederm Adding overhead to open and closing a file descriptor is scarier than adding it for process creation.
1139515297 M * Bertl 0x00001000, 0x00400000, 0x04000000, 0x08000000 and the complete upper nibble, plus the NEWNS, makes nine, no?
1139515302 M * ebiederm But the overhead in the common case where we have nothing to signal does not seem to count.
1139515329 Q * SuperLag Ping timeout: 480 seconds
1139515352 M * ebiederm Bertl: I wasn't counting NEWNS.  And I think I missed 0x1000.  So by that count nine.
1139515353 M * Bertl task refs from where to where ...
1139515376 M * ebiederm The hot path to be concerned about is the fcntl signals.
1139515421 M * ebiederm ttys are cool I don't have to do any additional reference counting to support them.
1139515473 M * Bertl just look at f_setown(), that's what you are referring to, no?
1139515491 M * ebiederm Bertl:  yese f_setown().
1139515497 M * Bertl         f_modown(filp, arg, current->uid, current->euid, force);
1139515508 M * Bertl it's not very efficient
1139515540 M * Bertl it takes an irq lock
1139515561 M * ebiederm The ugly part is that we need a deref in __fput.
1139515583 M * ebiederm There is a bug in my patch in respect to that.
1139515587 M * Bertl yes, but we have an advantage there (at least I think so)
1139515596 M * ebiederm ?
1139515615 M * Bertl the task should not go away before the filehandles, no?
1139515657 M * ebiederm unix domain sockets.    I can copy the file descriptor to a different task if I want to.
1139515699 M * ebiederm Or I can dup the file descriptor and only send one reference into a different context.
1139515700 M * Bertl okay, but in the common case it will not happen that often
1139515713 M * ebiederm Yes.
1139515715 M * Bertl so the typical case would be a dec
1139515726 M * Bertl dec+test
1139515750 J * SuperLag ~aaron@38.99.66.175
1139515827 M * ebiederm Bertl: Yes.
1139515864 M * ebiederm Actually the typical case is even better a pointer test and only if that success a dec+test.
1139515876 M * Bertl yup
1139515890 M * Bertl so I would not worry about that too much
1139515893 M * ebiederm But both (container,pid) and task refs share the same property.
1139515906 M * ebiederm Agreed.  Somehow got confused.
1139515927 J * fwl ~fwl@83.215.237.1
1139515929 M * ebiederm With a task_ref do we keep enough information to do permission checks?
1139515954 M * Bertl yes, definitely, although I'd prefer some 'magic' values for the init spaces
1139515972 M * Bertl would drastically simplify the flat admin model
1139516000 M * Bertl i.e. not checking ref->task->space->perm but
1139516019 M * Bertl simply doing ref->task->space == init
1139516050 M * Bertl (or in the more usual case just current->space == init_space)
1139516078 M * Bertl that would work for 99% of all use cases (IMHO)
1139516079 M * ebiederm Ok.
1139516128 M * ebiederm I almost follow that.
1139516159 M * Bertl we currently have context ids (out of tradition)
1139516171 M * Bertl and there are two special ids, 0 and 1
1139516191 M * Bertl the former is the 'admin' context, the latter the 'spectator' context
1139516211 M * Bertl i.e. 0 can administrate everything, and 1 can see everything
1139516247 M * Bertl now this would work with some permission space too, but would become much slower
1139516266 M * ebiederm Ok.  Noted.
1139516278 M * Bertl if we have a specific init_space magic, this could be used to have one for 0 and 1
1139516284 M * ebiederm I have a destination here so beare with me a moment longer.
1139516297 M * Bertl k
1139516343 M * ebiederm The big question of the day are containers. 
1139516354 M * Bertl guests :)
1139516404 M * ebiederm Repeat.  The question to resolve is:  Do we gain anything by having a struct contanier that holds pointers to the different namespaces.
1139516425 M * ebiederm I want to see if I can break the OpenVZ use model.
1139516426 M * Bertl we need something like that, to allow moving between them
1139516445 M * Bertl but we do not need them for indirection
1139516462 M * Bertl on the contrary, they would reduce the usefullness 
1139516463 M * ebiederm Bertl: Movement is the slow path...  We can do that a million ways.
1139516477 M * Bertl let me give an example:
1139516501 M * Bertl you create a 'container' with init process and such
1139516506 M * ebiederm My goal is to break tne OpenVZ model so we can put up that argument and go forward.
1139516549 M * Bertl now inside that container a simple ssh process decides to use clone_NS
1139516566 M * Bertl it is not forbidden, because it's part of the ABI
1139516586 Q * fwl Quit: This computer has gone to sleep
1139516589 M * Bertl we also do not want to block that, why should we?
1139516597 M * ebiederm correct.
1139516622 M * Bertl but, we now have a process inside the container, which does not share a single space with the other processes
1139516636 M * Bertl if we would use that umbrella concecp
1139516650 M * Bertl then the task would have to get his own, no?
1139516675 M * Bertl and if that actually happens, we are screwed ...
1139516731 M * ebiederm Depending we may have to make exceptions for CLONE_NEWNS, and the fs namespace.
1139516738 M * Bertl (because of restrictions and permissions and whatnot which would not apply to the new task)
1139516781 M * Bertl what we need, IMHO, is a 'permission' space structure, which stands for the 'guest'
1139516781 M * ebiederm For all new namespaces we can clearly require the creation of a new umbrella.
1139516798 M * ebiederm Bertl: Yes....
1139516799 M * Bertl that would also fit the OVZ purpose
1139516817 M * Bertl they could even make it 'persistent' without processes
1139516841 M * ebiederm All in esssence yes.
1139516844 M * Bertl now, what would that 'permission' struct hold?
1139516861 M * ebiederm Bertl: permission is the easy bit.
1139516862 M * Bertl a bunch of 'templates' for the spaces
1139516877 M * Bertl a bunch of flags to allow/deny stuff
1139516884 M * Bertl and a mask for clone flags
1139516894 M * ebiederm Sounds about right.
1139516933 M * Bertl the processes inside the guest can then do whatever they like, as long as it conforms to the permission struct, which cannot be cloned
1139516949 M * Bertl s/cloned/renewd/changed/
1139516951 M * ebiederm We need that and we need to think that through.  But that does not kill the umbrella idea as something to do for optimization.
1139517007 M * Bertl how would you move between spaces (single ones) with the umbrella without creating more and more of them?
1139517023 M * ebiederm Ok.  Now let's take your permission struct.  And place it in the umbrella with all of the other namespaces.
1139517054 M * ebiederm Can we show from a code standpoint that there is a place where the umbrella will fall down.
1139517064 M * ebiederm I think fcntl siginfo is one of those places.
1139517090 M * ebiederm err. The fcntl f_owner stuff is one of those places.
1139517124 M * ebiederm If I can look at the implementations and show that even with the best possible implementation umbrellas are not
1139517129 M * ebiederm a win I can kill the concept.
1139517145 M * Bertl I'm probably too tired atm .. roughly 24 hours awake now ..
1139517160 M * ebiederm Bertl: Ok.  Then take some rest and I will think it through myself.
1139517209 M * ebiederm I think I am going to talk out loud though in case someone else is following this.
1139517221 M * Bertl np, channel is logged ...
1139517265 M * ebiederm So assumption one we have an pointer umbrella that is in the thread_info struct and is completely as fast
1139517266 M * ebiederm as current.
1139517300 M * ebiederm We have an operation set_umbrella() to allow us to change to temporarily switch to a stored context.
1139517333 M * Bertl what if we just want to enter the namespace of that context?
1139517343 M * Bertl and not the pid space for example
1139517352 M * Bertl (choose any other pair)
1139517418 M * ebiederm Bertl: My gut agrees with you the tying is a problem.  But my head says I can't say for certain it is a problem.
1139517434 M * ebiederm The implementation is different.
1139517440 M * Bertl just how would you do it?
1139517454 M * Bertl - create a new umbrella?
1139517493 M * Bertl - assume it does not happen?
1139517511 M * Bertl - declare it as evil?
1139517515 M * ebiederm So in f_owner I place a struct umbrella * and replace the uid, and euid.
1139517563 M * ebiederm No. I guess I can't because uid, and euid are not umbrella properties.
1139517591 M * Bertl that's right
1139517603 M * ebiederm So in f_owner I would have to place an umbrella * and the pid.
1139517613 M * Bertl you have to store the uid/euid in addition
1139517639 M * ebiederm Bertl:  Yes storing uid/euid remains the same.
1139517742 M * ebiederm So the difference is that instead of passing the pspace to all of the pid sending functions, I just wrap the pid sending functions with set_umbrella.
1139517830 M * ebiederm So that instances is a wash.
1139517860 M * ebiederm So set_umbrella will only come in useful if there are places where I do a lot of work in a different context.
1139517873 M * ebiederm Or if umbrellay derfereences are much much cheaper.
1139517973 M * ebiederm And of course you loose the compiler errors.
1139518046 M * ebiederm With f_owner there could be something there as to implement CLONE_UID I also need to capture
1139518063 M * ebiederm the uidspace.
1139518069 M * ebiederm Or at least a struct user.
1139518209 M * ebiederm So in find_task_by_pid I save one entry on the stack.
1139518237 M * ebiederm No real savings, and problem a reduction in cache line hits.
1139518245 M * ebiederm Plus everything is explicit.
1139518274 M * ebiederm In the networking either I have a socket that I can derive it from or the packet is flying around too much.
1139518295 M * ebiederm The netchannel optimizations should clean up that problem for me.
1139518313 M * ebiederm By doing everything in user space socket context.
1139518388 M * ebiederm Ok.  And I guess my final argument.  iff struct container is only for performance optimization it is something we can easily go back though the code an introduce.
1139518419 M * ebiederm Basically a ref count batching thing.
1139518433 M * ebiederm So we can design the interface as individuals.
1139518451 M * Bertl which IMHO requires a special 'clone' if you want to move between spaces
1139518475 M * Bertl (not between 'contexts')
1139518480 M * ebiederm Bertl: There is something like that.
1139518510 M * ebiederm But if we never every make contexts/umbrellas explicit in the API we can use the simply as a batching technique if we need them.
1139518566 M * ebiederm Iff that is all they are then we can design the kernel interfaces without them.
1139518579 M * ebiederm Then refactor to get more performance if we need to.
1139518601 M * ebiederm That actually allows us to not special case CLONE_NEWNS.
1139518626 Q * ntrs Quit: Leaving
1139518626 M * Bertl let me put it this way, we started with a 'single' context struct, but it was to inflexible, we now have one for contexts, one for networking and a special one for disk space
1139518636 M * Bertl *too
1139518637 M * ebiederm The tricks about variables that I want for the network stack can still potentially be applied on a per namespace basies.
1139518653 J * fwl ~fwl@83.215.237.1
1139518663 M * ebiederm Bertl:  I actually agree with you.
1139518709 M * ebiederm But from a design perspective we can easily make on internal kernel API issue only.
1139518721 M * ebiederm At which point it is an optimization we can look at later.
1139518744 M * ebiederm That is all I need to end the discussion on this point.
1139518757 M * Bertl ok :)
1139518820 M * ebiederm Plus that is the unix way code it simple and brute force initiall and then optimize it!
1139518835 M * ebiederm The flexibility is clearly important.
1139518870 M * ebiederm Now are task_refs interesting enough for me to merge them...
1139518892 M * ebiederm Well time to wrap up that piece of the discussion.
1139518961 M * ebiederm A little back and forth and we will have consensus.
1139519358 N * ebiederm ebiederm_oO
1139519380 J * RicardoGuillen ~admin@dsl-200-67-20-123.prod-empresarial.com.mx
1139519392 M * Bertl welcome RicardoGuillen!
1139519393 P * RicardoGuillen 
1139519499 Q * fwl Quit: This computer has gone to sleep
1139519626 J * fwl ~fwl@83.215.237.1
1139519934 J * lafeuil ~lafeuil@4be54-2-82-225-0-42.fbx.proxad.net
1139519951 M * Bertl welcome lafeuil!
1139519966 M * lafeuil Bertl: thanks
1139520300 Q * fwl Quit: This computer has gone to sleep
1139520606 M * Bertl okay, off to bed now .. will have to continue tomorrow ...
1139520614 M * Bertl have a good whatever everyone, cya!
1139520620 N * Bertl Bertl_zZ
1139520674 J * Viper0482 ~Viper0482@p549767B2.dip.t-dialin.net
1139520733 J * fwl ~fwl@83.215.237.1
1139521622 Q * fwl Quit: This computer has gone to sleep
1139521724 J * fwl ~fwl@83.215.237.1
1139522134 M * ebiederm_oO Sleep well Bertl_zZ 
1139522139 N * ebiederm_oO ebiederm
1139522339 M * dhansen ebiederm: so, what is the next thing you're going to do with your "namespace" patches?
1139522374 M * ebiederm dhansen:  Well first I am going to finish wrapping up the conversation on the list.
1139522399 M * ebiederm dhansen:  Then I am going to see what the best way to get namespaces into the kernel.
1139522422 M * ebiederm dhansen: In parallel with that I will go back through and code review and fix as many bugs as possible.
1139522444 M * dhansen ebiederm: I've been looking at your patches, and I have a few ideas to make them a bit more reviewable
1139522452 M * ebiederm All of the issues have been resolved to my satisfaction.
1139522460 M * ebiederm dhansen:  Ok. shoot.
1139522482 M * dhansen first of all, I'd kill the #if 0/1 stuff
1139522495 M * dhansen It makes sense when developing, but just makes reviewing harder
1139522504 M * dhansen In patches like 0007-Add-a-mnt-paramenter-to-follow_link.diff
1139522530 M * dhansen it makes a little more sense to separate out the "add parameter" part and the "use the parameter in proc" part into different patches
1139522531 M * ebiederm Hmm..
1139522555 M * ebiederm I think you are looking at my devel/proof-of-concept branch.
1139522562 M * dhansen oh, there are newer ones? :)
1139522573 M * dhansen I grabbed the kernel.org ones
1139522596 M * ebiederm So my tree should have 2 branches.  The one with the code I posted for review was pspace-8-Feb-2006.
1139522610 Q * FireEgl arion.oftc.net venus.oftc.net
1139522610 Q * zobel arion.oftc.net venus.oftc.net
1139522638 M * ebiederm There is still code in my old branch but it was really development.
1139522657 M * ebiederm Posted so people could see the whole scope of what I have looked at.
1139522699 M * ebiederm dhansen: Do you see my other branch?
1139522735 M * dhansen ebiederm: I only see one on kernel.org.  To which one are you referring?
1139522750 M * ebiederm dhansen: I have one git tree with 2 branches on kernel.org.
1139522751 Q * fwl Quit: This computer has gone to sleep
1139522761 Q * Viper0482 iridium.oftc.net unununium.oftc.net
1139522761 Q * SuperLag iridium.oftc.net unununium.oftc.net
1139522761 Q * shedi iridium.oftc.net unununium.oftc.net
1139522761 Q * stefani iridium.oftc.net unununium.oftc.net
1139522761 Q * MartinZd2 iridium.oftc.net unununium.oftc.net
1139522761 Q * wibble_ iridium.oftc.net unununium.oftc.net
1139522761 Q * ComplexMind iridium.oftc.net unununium.oftc.net
1139522761 Q * sladen iridium.oftc.net unununium.oftc.net
1139522761 Q * mountie iridium.oftc.net unununium.oftc.net
1139522761 Q * cehteh iridium.oftc.net unununium.oftc.net
1139522761 Q * Vudumen iridium.oftc.net unununium.oftc.net
1139522761 Q * Cru iridium.oftc.net unununium.oftc.net
1139522761 Q * eyck iridium.oftc.net unununium.oftc.net
1139522761 Q * nox iridium.oftc.net unununium.oftc.net
1139522761 Q * entroposcope iridium.oftc.net unununium.oftc.net
1139522761 Q * Wonka iridium.oftc.net unununium.oftc.net
1139522761 Q * Pazzo iridium.oftc.net unununium.oftc.net
1139522761 Q * grant_ iridium.oftc.net unununium.oftc.net
1139522761 Q * phreak`` iridium.oftc.net unununium.oftc.net
1139522761 Q * Bertl_zZ iridium.oftc.net unununium.oftc.net
1139522761 Q * SNy iridium.oftc.net unununium.oftc.net
1139522761 Q * lafeuil iridium.oftc.net unununium.oftc.net
1139522761 Q * weasel iridium.oftc.net unununium.oftc.net
1139522761 Q * andrew_ iridium.oftc.net unununium.oftc.net
1139522763 Q * harry iridium.oftc.net unununium.oftc.net
1139522763 Q * cohan iridium.oftc.net unununium.oftc.net
1139522763 Q * monrad iridium.oftc.net unununium.oftc.net
1139522763 Q * Adrinael iridium.oftc.net unununium.oftc.net
1139522763 Q * blizz iridium.oftc.net unununium.oftc.net
1139522763 Q * Psy0rz_ iridium.oftc.net unununium.oftc.net
1139522763 Q * click iridium.oftc.net unununium.oftc.net
1139522763 Q * jkl iridium.oftc.net unununium.oftc.net
1139522763 Q * mire_ iridium.oftc.net unununium.oftc.net
1139522763 Q * kilian iridium.oftc.net unununium.oftc.net
1139522763 Q * Snow-Man iridium.oftc.net unununium.oftc.net
1139522763 Q * Hunger iridium.oftc.net unununium.oftc.net
1139522763 Q * Doener iridium.oftc.net unununium.oftc.net
1139522763 Q * cemil iridium.oftc.net unununium.oftc.net
1139522763 Q * mire iridium.oftc.net unununium.oftc.net
1139522763 Q * brc_ iridium.oftc.net unununium.oftc.net
1139522763 Q * Dr4g_ iridium.oftc.net unununium.oftc.net
1139522763 Q * hallyn iridium.oftc.net unununium.oftc.net
1139522763 Q * meandtheshell iridium.oftc.net unununium.oftc.net
1139522763 Q * micah iridium.oftc.net unununium.oftc.net
1139522763 M * ebiederm Look in refs/heads/
1139522768 J * Viper0482 ~Viper0482@p549767B2.dip.t-dialin.net
1139522768 J * SuperLag ~aaron@38.99.66.175
1139522768 J * shedi ~siggi@inferno.lhi.is
1139522768 J * stefani ~stefani@superquan.apl.washington.edu
1139522768 J * MartinZd2 ~martin@84-245-81-250-broadband.iol.sk
1139522768 J * phreak`` ~phreak``@styx.xnull.de
1139522768 J * grant_ mep@p50919AC5.dip0.t-ipconnect.de
1139522768 J * Bertl_zZ herbert@212.16.62.52
1139522768 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it
1139522768 J * Wonka produziert@chaos.in-kiel.de
1139522768 J * SNy 9a2cb72906@bmx-chemnitz.de
1139522768 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com
1139522768 J * nox ~nox@nox.user.oftc.net
1139522768 J * eyck eyck@81.219.64.71
1139522768 J * Cru ~mindwarp@turbodiesel.e.de.wahlich.com
1139522768 J * Vudumen vudumen@217.20.138.8
1139522768 J * cehteh foobar@cehteh.homeunix.org
1139522768 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1139522768 J * sladen ~paul@193.28.45.41
1139522768 J * ComplexMind ~ComplexHo@cpc1-brig3-6-0-cust194.brig.cable.ntl.com
1139522768 J * wibble_ wibble@vortex.ukshells.co.uk
1139522793 M * ebiederm hicup.
1139522809 J * zobel zobel@zobel.irc.ftbfs.de
1139522809 J * FireEgl Atlantica@2001:5c0:84dc::
1139522809 J * lafeuil ~lafeuil@4be54-2-82-225-0-42.fbx.proxad.net
1139522809 J * Doener doener@i5387CFC8.versanet.de
1139522809 J * weasel weasel@weasel.noc.oftc.net
1139522809 J * andrew_ ~andrew@tnlug.linux.org.tw
1139522809 J * mire_ ~mire@mail.sfb.bg.ac.yu
1139522809 J * meandtheshell ~markus@85-125-225-123.dynamic.xdsl-line.inode.at
1139522809 J * hallyn ~xa@c-24-11-243-196.hsd1.in.comcast.net
1139522809 J * Dr4g_ Dr4g@82-40-43-86.cable.ubr06.uddi.blueyonder.co.uk
1139522809 J * jkl eric@c-67-172-156-116.hsd1.co.comcast.net
1139522809 J * brc_ bruce@20151215029.user.veloxzone.com.br
1139522809 J * mire ~mire@183-166-222-85.COOL.ADSL.VLine.Verat.NET
1139522809 J * click click@ti511110a080-4978.bb.online.no
1139522809 J * Psy0rz_ ~psy0rz@lounge.datux.nl
1139522809 J * kilian kk@projects.verfaction.de
1139522809 J * Snow-Man ~sfrost@kenobi.snowman.net
1139522809 J * blizz ~blizz@evilhackerdu.de
1139522809 J * Adrinael adrinael@hoasb-ff09dd00-79.dhcp.inet.fi
1139522809 J * monrad ~mikkel@213083190131.sonofon.dk
1139522809 J * cohan ~cohan@koniczek.de
1139522809 J * harry ~harry@d515321D1.access.telenet.be
1139522809 J * micah ~micah@69.90.134.205
1139522809 J * Hunger Hunger.hu@Hunger.hu
1139522809 J * cemil ~cemil@defiant.wavecon.de
1139523013 M * ebiederm dhansen: You still there?
1139523386 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com
1139523461 M * dhansen ebiederm: yeah, 
1139523474 M * ebiederm Ok.  Everything bounced around and I wasn't sure.
1139523483 M * ebiederm Did you find my new branch?
1139523535 M * dhansen nope, can you point me to the URL again.  it may have been lost in the split
1139523550 M * ebiederm So the git tree is:
1139523627 M * ebiederm git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-ns.git
1139523645 M * ebiederm The branch is pspace-8-Feb-2006
1139523660 M * ebiederm Same repository as before different branch.
1139523700 M * dhansen do you have any plans to turn it back into a patch series?
1139523718 M * dhansen (I doubt we'll get akpm or Linus to suck up a single tree for this stuff)
1139523726 M * ebiederm dhansen: Sure.
1139523736 M * ebiederm I am maintaining it that way.
1139523762 M * ebiederm But for maintenance and for ensuring everyone has all of the patches when the casually test I am just holding it in git.
1139523797 M * ebiederm Basically git-format-patch turns it into a patch series :)
1139523817 M * ebiederm At the moment there are a few commits that probably should be merged but otherwise all looks good.
1139523904 Q * lafeuil Quit: lafeuil
1139524007 M * ebiederm dhansen: serge and hubertus can almost get my latest set to boot on the s390.
1139524043 M * ebiederm Short of a fresh pronouncement form on high I think we are on the right general track though.
1139524101 M * hallyn ebiederm: so when you want to have 5 patches on top of each other to implement a new feature/send to lkml, do you just create new branches on top of each other for each such patch?
1139524102 M * dhansen ebiederm: I care less about running it and more about understanding it :)
1139524145 M * ebiederm dhansen:  Yes.
1139524179 M * ebiederm dhansen: definitely get the latest branch as it should be comprehensible and moderately well targeted (although still buggy)
1139524192 M * ebiederm hallyn: Usually.
1139524238 M * dhansen ebiederm: could you dump another patch series out of your git tree so it can be analyzed a bit more easily?
1139524259 M * ebiederm Sure what are you looking for?
1139524356 M * ebiederm To be precise what do you want that is different from the patches I posted to lkml?
1139524359 M * hallyn ok - i was actually feeling comfy with git this morning.  Hoping to make a lsm-stacker git tree this weekend
1139524406 Q * frankeh Ping timeout: 480 seconds
1139524411 M * dhansen ebiederm: maybe nothing different from what you posted.  I can go dig them back out, I guess.  I also figured there would be something later than tnose :)
1139524545 M * ebiederm dhansen: There are a few bug fixes.  But nothing fundamental has changed.
1139524576 M * Skram TCP: Treason uncloaked! Peer 212.38.139.219:12855/6890 shrinks window 4219757519:4219758933. Repaired.
1139524579 M * Skram woops
1139524614 M * ebiederm Mostly I have been looking very hard to see if there was anything in the discussion that would cause a fundamental shift in direction.
1139524639 M * ebiederm ebiederm:   The result no.  But it took understanding a lot of code to get there.
1139524669 M * Skram how can i make it so applications run in swap after a user's RSS/RAM limit has been reached?
1139524903 M * daniel_hozac you can't run in swap.
1139524957 M * daniel_hozac but what you're after is implemented as soft limits in the devel series.
1139525344 M * ebiederm dhansen: I guess a lot of what I will do next is to see which little pieces I can break out of my tree (bug fixes and enhancements) and get those merged first.
1139525402 N * ebiederm ebiederm_oO
1139525741 P * meandtheshell 
1139525919 P * stefani I'm Parting (the water)
1139526168 J * lafeuil ~lafeuil@4be54-2-82-225-0-42.fbx.proxad.net
1139526345 M * Skram daniel_hozac: hrmm... so if they run out of rss, they process is blocked
1139526353 M * Skram and they have no idea unless they look in free -m?
1139526373 M * daniel_hozac Skram: no, the OOM killer will do its thing.
1139526378 M * Skram OOM?
1139526389 M * daniel_hozac out of memory.
1139526397 M * Skram is there a way to config it?
1139526417 M * Skram is it per VPS or on the HOST?
1139526575 M * SuperLag too bad Bertl is sleeping :)
1139526621 J * fwl ~fwl@83.215.237.1
1139526626 M * SuperLag "You're right.  That isn't the right default route.  We need to move you to another cabinet, since you're on port 24 of the switch and your other NIC isn't plugged in."
1139526635 M * SuperLag That's what my colo said :)
1139526808 M * Skram hrmm
1139527373 Q * fwl Quit: This computer has gone to sleep
1139527848 Q * lafeuil Quit: lafeuil
1139527957 Q * Viper0482 Quit: bin raus, 
1139527989 J * Viper0482 ~Viper0482@p549767B2.dip.t-dialin.net
1139528006 Q * Viper0482 Quit: 
1139528089 J * Viper0482 ~Viper0482@p549767B2.dip.t-dialin.net
1139528106 Q * Viper0482 Quit: 
1139528451 Q * Doener Quit: Leaving
1139528516 J * fwl ~fwl@83.215.237.1
1139529083 J * Aiken ~james@tooax6-136.dialup.optusnet.com.au
1139529143 Q * fwl Quit: This computer has gone to sleep