1141949196 J * lilalinux_ ~plasma@dslb-084-058-203-075.pools.arcor-ip.net
1141949634 Q * lilalinux Ping timeout: 480 seconds
1141950181 Q * rs Quit: rs
1141950191 Q * lilalinux_ Remote host closed the connection
1141950560 J * phycho ~phycho@ext-gw.darktech.org.uk
1141951913 J * matta ~matta@71.224.125.126
1141953761 Q * phycho Ping timeout: 480 seconds
1141955003 J * matt1 ~matta@71.224.125.126
1141955459 Q * matta Ping timeout: 480 seconds
1141955873 J * matta ~matta@71.224.125.126
1141956150 Q * gerrit Ping timeout: 480 seconds
1141956329 Q * matt1 Ping timeout: 480 seconds
1141956355 M * mugwump Bertl: you planning on going to that virtualisation expo thingy?
1141956362 M * mugwump in Germany?
1141956371 M * Bertl the linuxhotel? yep
1141956476 A * mugwump considers getting Catalyst to send him over
1141956485 M * Bertl would be nice :)
1141956758 M * mugwump Wo sind das Virtualisierungstechnologien?  Welche ... city?  :)  Ich kann das web page nicht verstehen
1141956784 M * Bertl hmm, well, it's probably german biased, it happens in Essen
1141956805 M * mugwump Essen ... is there a lot of food there?
1141956814 M * Bertl I hope so :)
1141956857 M * mugwump Oh, I just thought, the name of the city... :)
1141956879 M * Bertl yeah, I figured :)
1141958040 J * matt1 ~matta@71.224.125.126
1141958308 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net
1141958459 Q * matta Ping timeout: 480 seconds
1141959148 A * mugwump decides to wait until Beer O'Clock to ask $Director
1141959224 M * Bertl guess that is always a good time to ask :)
1141959754 M * Bertl okay, I'm off to bed now ... back tomorrow!
1141959761 M * Bertl have a good one everyone and cya!
1141959765 N * Bertl Bertl_zZ
1141960094 Q * harry Ping timeout: 480 seconds
1141960167 Q * lost_eps Quit: Leaving
1141960540 J * phycho ~phycho@ext-gw.darktech.org.uk
1141960739 J * harry ~harry@d515321D1.access.telenet.be
1141962476 J * Loki_muh loki@satanix.de
1141962476 Q * Loki|muh Read error: Connection reset by peer
1141962596 J * Smutje_ ~Smutje@xdsl-87-78-0-115.netcologne.de
1141962729 Q * Smutje Ping timeout: 480 seconds
1141962729 N * Smutje_ Smutje
1141964341 Q * Dr4g_ Read error: Connection reset by peer
1141964348 J * Dr4g ~Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk
1141966587 J * lost_eps ~lost_eps@216.235.146.165
1141966664 Q * rs Quit: rs
1141967590 M * lost_eps is anyone still up?
1141969595 Q * lost_eps Quit: Leaving
1141970627 Q * Dr4g Read error: Connection reset by peer
1141970631 J * Dr4g ~Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk
1141970686 Q * Dr4g Quit: 
1141970688 J * Dr4g ~Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk
1141971048 J * coocoon ~coocoon@p54A0696D.dip.t-dialin.net
1141971053 M * coocoon morning
1141971130 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1141977404 J * tokkee tokkee@casella.verplant.org
1141977407 M * tokkee Hi...
1141977559 M * daniel_hozac hello
1141977716 J * Dr4g_ ~Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk
1141977883 Q * Dr4g helium.oftc.net oxygen.oftc.net
1141977883 Q * Loki_muh helium.oftc.net oxygen.oftc.net
1141977883 Q * phycho helium.oftc.net oxygen.oftc.net
1141977883 Q * michal` helium.oftc.net oxygen.oftc.net
1141977883 Q * meebey_ helium.oftc.net oxygen.oftc.net
1141977883 Q * samuel_ helium.oftc.net oxygen.oftc.net
1141977883 Q * teukka helium.oftc.net oxygen.oftc.net
1141977883 Q * Geert helium.oftc.net oxygen.oftc.net
1141977883 Q * wibble helium.oftc.net oxygen.oftc.net
1141977883 Q * phedny helium.oftc.net oxygen.oftc.net
1141978010 J * wibble wibble@vortex.ukshells.co.uk
1141978248 J * teukka ~tmatilai@backport.ri.fi
1141978266 J * Loki|muh loki@satanix.de
1141978276 J * michal` ~michal@81.169.139.228
1141978324 J * Geert geert@geert.irssi.be
1141978497 J * meebey meebey@booster.qnetp.net
1141978507 J * phedny ~mark@volcano.p-bierman.nl
1141979548 Q * Dr4g_ Quit: Leaving
1141979577 J * djudko ~davej@bi01p1.nc.us.ibm.com
1141979807 Q * gerrit Ping timeout: 480 seconds
1141979901 J * GeDaST ~proxy@85.108.45.81
1141979921 M * tokkee Is there any way I can bind a vserver to a virtual (e.g. tap) network device?
1141979979 M * daniel_hozac is the host setting it up?
1141980017 Q * djudko_ Ping timeout: 480 seconds
1141980028 M * Loki|muh greetings tokkee 
1141980218 Q * shedi Quit: Leaving
1141980226 M * tokkee Heyho Loki|muh 
1141980231 M * tokkee daniel_hozac: nope
1141980239 M * tokkee daniel_hozac: Not yet ;-)
1141980599 J * pagano ~pagano@lappagano.cnaf.infn.it
1141980877 J * dev_ ~dev@swsoft-mipt-nat.sw.ru
1141981101 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net
1141981938 P * phedny 
1141981997 J * djudko_ ~davej@129.33.1.37
1141982283 J * shedi ~siggi@tolvudeild-200.lhi.is
1141982422 Q * djudko Ping timeout: 480 seconds
1141982718 J * `DoM` ~dom@195.32.84.44
1141982737 N * Bertl_zZ Bertl
1141982741 M * Bertl morning folks!
1141982805 M * doener_ morning Bertl! pong!
1141983138 J * djudko ~davej@bi01p1.nc.us.ibm.com
1141983218 Q * LCamel_ Remote host closed the connection
1141983283 M * Bertl doener_: ah, yeah, the ping was regarding the sendfile fix, wanted to know if it applies to 2.6.15.5 too, but I already figured that :)
1141983303 M * phreak`` morning Bertl & doener_ 
1141983334 M * Bertl hey phreak``! seems like a good day to get stuff done, eh? :)
1141983336 M * phreak`` Bertl: it doesn't (well at least I wasn't able to apply it onto 2.6.15)
1141983342 M * phreak`` Bertl: yah :)
1141983357 M * Bertl phreak``: really? it worked fine here :)
1141983367 M * phreak`` Its Friday, and I'm almost done with my work (the payed one at least)
1141983458 M * phreak`` Bertl: yeah, against 2.6.15-vs2.1.1 its applying fine, thats right .. :) but not against 2.0.2 it ain't applying (well I've no idea if 2.0.2 is even affected)
1141983475 M * doener_ well, 2.6.15.5 isn't affected at all
1141983511 M * doener_ the patch shouldn't break anything, but it is not needed
1141983562 Q * djudko_ Ping timeout: 480 seconds
1141983585 M * doener_ and vs2.0.x doesn't have the sendfile changes, so it's likely to refuse the patch ;)
1141983622 J * meandtheshell ~markus@85-125-229-187.dynamic.xdsl-line.inode.at
1141983659 M * Bertl doener_: okay, that's what I wanted to hear, so as I thought, it should be fine for 2.6.15.5-vs2.1.x
1141983709 M * Bertl btw, had a longer discussion with one of the (o)vz guys yesterday
1141983714 M * Bertl we tried to figure some of the code :)
1141983768 M * phreak`` the ovz one ? or the vserver ? or the joined effort code ? :)
1141983776 M * Bertl the ovz one *G*
1141983785 M * phreak`` heh, thought so :)
1141983805 M * doener_ did it quick confirmation, 2.6.15.x's rw_verify_area only returns values <= 0, so the patch is fine
1141983812 M * Bertl well, they call the sof limits 'limit' and the hard limits 'barrier'
1141983812 M * dev_ which code did you want, Bertl?
1141983813 M * doener_ s/did it/did a/
1141983829 M * Bertl ah, the expert, excellent!
1141983834 M * dev_ :)
1141983856 M * Bertl I was wondering about a few details regarding memory accounting
1141983914 M * Bertl you have *_locked and * functions, the locked one apply to changing the beancounters when they are 'locked down' or so, yes?
1141983920 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl
1141983929 M * Bertl welcome ||Cobra||!
1141983962 M * ||Cobra|| hi Bertl 
1141983997 M * dev_ _locked means that ub_lock is held
1141984004 M * dev_ already...
1141984015 M * Bertl yeah, okay, so you can change the values
1141984019 M * dev_ yup
1141984024 M * Bertl (without caring about SMP issues)
1141984039 M * dev_ why are you wondering about it?
1141984062 M * dev_ it looks quite straightforward...
1141984065 M * Bertl no it just confused us when reading fragments of the code
1141984074 M * dev_ mmm
1141984131 M * Bertl thing is, friend aistis came up with the manpage
1141984131 M * Bertl http://openvz.org/documentation/mans/vzctl.8
1141984144 M * Bertl and we tried to figure the part saying that: Maximum IPC SHM segment size. Setting the barrier and the limit to different values does not make practical sense.
1141984200 M * Bertl and we figured that the code does not care about the (soft) limit at all, just logs the usual message when over, but only the (hard) barrier
1141984228 M * dev_ yup. not all the resources have both limits (soft/hard). Some of them have only hard limits
1141984279 M * dev_ numgile for example, doesnt have softlimit :)
1141984290 M * Bertl yeah, understandable ... just the docu was confusing in this regard
1141984307 M * dev_ oh, I see...
1141984316 M * dev_ numgile = numfile
1141984323 M * Bertl yeah, figured that :)
1141984340 M * Bertl the warning, is it issued inside or outside the container?
1141984372 M * Bertl I mean, it's a printk, so I suspect outside, but maybe I'm missing something
1141984463 M * dev_ They are printed to host system with a ratelimit, so that Admin could detect when shortage of resources happens in some VPS
1141984512 M * Bertl yeah, saw that, my question to that is, could/shouldn't that be userspace stuff?
1141984517 J * phycho ~phycho@ext-gw.darktech.org.uk
1141984557 M * Bertl welcome phycho!
1141984595 M * dev_ why you think so? we print messages, increases failcnt and user space can monitor failcnt'ers to detect shortages
1141984598 M * Bertl shouldn't be too hard to compare current with the soft limit and print a message every now and then (from userspace). IMHO no need to have a kernel mechanism for that?
1141984629 M * Bertl dev_: the failcnt doesn't apply to the soft limits, or am I wrong?
1141984699 M * Bertl well, it seems to apply if they are there ...
1141984720 M * dev_ Oh, got you. We don't report usage over "softlimit". Only hardlimit hits
1141984725 J * djudko_ ~davej@129.33.1.37
1141984744 M * Bertl hmm, code says slightly different
1141984761 M * dev_ let me check. which piece of code?
1141984764 M * Bertl IMHO you count soft and hard limit hits
1141984774 J * samuel_ ~samuel@levinux.UQAR.UQUEBEC.CA
1141984776 M * Bertl but you only report over soft limit cases
1141984783 A * samuel_ is away: (Auto-Away after 10 mins) [BX-MsgLog On]
1141984793 M * Bertl http://download.openvz.org/kernel/broken-out/2.6.15-025stab014.1/diff-ubc-20060120
1141984804 M * Bertl __charge_beancounter_locked()
1141984959 M * dev_ 1. as you can see failcnt is incremented in both cases. yeah? but kernel messages are printed only when it fails to allocate resources even in unstrict places.
1141985058 M * Bertl hmm, not even, only
1141985070 M * Bertl not 'even', 'only' in UB_SOFT cases
1141985102 M * Bertl so AFAICT for the shmem for example, never
1141985130 M * Bertl but the failcnt is incremented every time, that's right
1141985157 Q * djudko Ping timeout: 480 seconds
1141985182 M * Bertl anyway, what I thought was, wouldn't it be better to have that 'over soft limit' check and warning in userspace?
1141985549 Q * matt1 Ping timeout: 480 seconds
1141985763 M * dev_ Bertl: I suppose it is quite easy to implement user space daemon monitoring current usages and checking them against softlimits. we have sys_ubstat syscall for such purposes
1141985839 M * Bertl okay, so you agree that this would be a good way to do that
1141985902 M * Bertl dev_: do you consider a syscall to be the best choice for relaying such data to userspace, or would you prefer a different interface?
1141985925 M * Bertl e.g. the 'unfortunate' procfs or netlink?
1141986848 M * dev_ I don't like /proc for this, as it is inatomic, and we had lot's of problems with. e.g. /proc/user_beancounters can't be read atomically and applications really notice it sometimes... :(
1141986874 M * dev_ this can be netlink maybe... But I see no reason why it can't be simple binary interface via syscall...
1141986887 M * dev_ i.e. we have to interfaces - proc for human readable info and syscall for apps
1141986891 M * dev_ to = 2
1141986927 M * Bertl yeah, just asking for a professional option here
1141986931 M * Bertl *opinion
1141986950 M * dev_ :)
1141986988 M * Bertl would it be interesting for OVZ folks to find a common interface (e.g. via syscall) to report such stuff?
1141987003 M * Bertl (common with linux-vserver and FreeVPS for example)
1141987049 M * dev_ sure.
1141987069 M * dev_ though I see no easy way as we have too different resource management system :/
1141987095 M * Bertl well, as far as I can see it basically maps 1:1
1141987133 M * Bertl just names (and sometimes the accounting) differ
1141987174 M * Bertl a generic interface could easily cope with that
1141987246 M * dev_ hmm... then it is will be fine
1141987270 M * Bertl let's double check it, shall we?
1141987284 M * dev_ I'm just not very familiar with your interfaces, so it's a bit hard for me to tell immedeately...
1141987290 M * dev_ let's do it
1141987312 M * Bertl okay, so we basically have  the following values per limit
1141987347 M * Bertl current, min, max,   soft, hard, hit
1141987368 M * Bertl where min/max is the observed minimum/maximum and
1141987376 M * Bertl hit is the number of hard limit hits
1141987433 M * Bertl we planned something like a 'guarantee' but decided that this is userspace, but no problem to have a field reported back there
1141987566 M * doener_ yep
1141987569 M * doener_ oops
1141987579 M * Bertl upload it somewhere :)
1141987611 M * dev_ how is calculated min/max? for what time period?
1141987646 M * dev_ we have a complicated logic in sys_ubstat to report maxhelp to userspace. do you want to implement it the same way?
1141987712 M * dev_ Bertl: this looks exactly as in OpenVZ, with min only :) did we get you to this idea? :) ok. Do you think min is that valuable?
1141987741 M * Bertl well, the min is something which actually came from OVZ
1141987749 P * pagano Leaving
1141987752 M * Bertl the max was there since the beginning
1141987780 M * Bertl the main difference is that we do not reset them after a time, actually atm we do not reset them at all
1141987826 M * Bertl but, IMHO if we have some userspace daemon watching over that, it would make more sense to put that 'complicated' logic in userspace too
1141987851 M * Bertl i.e. I'd make the min/max resetable from userspace (or autoreset on read)
1141987916 Q * Aiken Quit: Leaving
1141987917 J * lilalinux ~plasma@dslb-084-058-203-075.pools.arcor-ip.net
1141987936 M * Bertl but, regardless of the implementation, we could have some jiffie counter or interval stating the span for min/max
1141988090 M * dev_ we have no min :))))
1141988110 M * Bertl really? well, where did I get that from then?
1141988143 M * Bertl probably it came naturally, so I added it ...
1141988145 M * dev_ Bertl: it is always bad to have "reset" functionality. bacause in this case only one app will be able to monitor it
1141988157 M * dev_ :(
1141988175 M * dev_ iptables counters, routers etc. all are avoiding "reset" functionality
1141988191 M * dev_ we declined a lot of request for "reset" functionality for failcnt
1141988236 M * Bertl hmm, is the failcnt also based on some interval logic?
1141988289 Q * teukka Read error: Connection reset by peer
1141988330 J * teukka ~tmatilai@backport.ri.fi
1141988350 M * Bertl wb teukka!
1141988432 M * dev_ no, failcnt is simply an increasing counter. But people don't like to take delta to see whether something failed during the time interval, instead they suggest to implement "reset" functionality, which is wrong.
1141988485 M * Bertl okay, so except for the interval logic, I do not see that many differences, what fields does OVZ have that we do not?
1141989179 J * Wenix ~wenix@81.7.189.11
1141989281 M * eyck hmm, company behind it?
1141989557 M * dev_ no any other fields, Bertl.
1141989584 M * dev_ held(current), maxheld over some period, soft/hard limit and fail counter (hits)
1141989595 M * dev_ eyck: are you about OpenVZ?
1141989621 M * eyck what do you mean?
1141989623 M * Bertl dev_: what about the guarantees?
1141989796 M * dev_ have you implemented it or think only about it?
1141989806 M * dev_ or you mean our guarantees?
1141989867 M * Bertl yep
1141989879 M * Bertl (as in, yep, I mean 'your' guarantees :)
1141990526 M * dev_ guarantees are essentially the same. oomguarpages for example has failcnt also
1141990551 M * Bertl how does the failcount apply there?
1141990602 M * Bertl I mean, the oom 'guarantee' is just a check to avoid oom kill on containers which are below the limit, right?
1141990653 M * dev_ right. but if you are higher the limit and OOM selects a task in VPS, oomguarpages.failcnt++
1141990717 M * Bertl okay, is that true for any other guarantee?
1141990789 M * Bertl (i.e. vm guarantee, or are there more?)
1141990861 J * terrorgrl ~terrorgrl@jaim.at
1141990874 P * terrorgrl 
1141991286 M * dev_ vmguarantee doesn't increase failcnt, but this can be fixed :) may be helpfull
1141991309 M * Bertl what does the vm guarantee do?
1141991648 M * dev_ security_vm_enough_memory(). it keeps mainstream logic for enough_memory and overcommit, but per VPS. see *vm_enough_memory().
1141991674 M * Bertl ah, ic.
1141991712 M * Bertl now one 'funny' limit/value is the privvmpages
1141991746 M * Bertl what does it mean when the manpage states: Allows controlling the amount of memory allocated by the applications. For shared (mapped as MAP_SHARED) pages, each VPS really using a memory page is charged for the fraction of the page (depending on the number of others using it). For "potentially private" pages (mapped as MAP_PRIVATE), VPS is charged either for a fraction of the size or for the full size if the allocated address space.
1141991933 M * dev_ it means, that privvmpages accounts fraction of page if it is shared between VPSs (page is really maped with PTEs in VPS, not vma mapped) - MAP_SHARED case.
1141991984 M * Bertl so if three VPS share a page, you account what? 0.3333 pages? or 1365 bytes?
1141991995 M * dev_ similar to this.
1141992012 M * dev_ actually we account 1024,1024 and 2048. if 4 VPSs, 4x1024
1141992016 M * Bertl and if another one joins the group, the value gets smaller?
1141992020 M * dev_ we charge power of 2 bytes
1141992027 M * dev_ this helps to avoid O(n) algos
1141992034 M * dev_ yes. gets smaller
1141992063 M * Bertl so you fixup the values when this happens, or calculate them every time anew?
1141992071 M * dev_ it distributes as 2048:2048 if 2 users, 1024, 1024, 2048 if 3, 1024x4 if 4, and so on
1141992080 M * dev_ fix when page is mapped/unmapped
1141992120 M * Bertl i.c. is that worth the efford? I mean why do you need those values?
1141992160 M * dev_ you mean, why we don't charge the whole value to all VPSs?
1141992167 M * Bertl for example
1141992210 M * dev_ if you have sharing and charge the same value to all (w/o accounting shares) you get the wrong information about consumed memory, overcommitment of the whole node etc.
1141992224 M * dev_ you can sum the memory and get more than you have etc.
1141992245 M * Bertl ah, so it is cosmetic?
1141992267 M * dev_ you can't provide good tools for analyzing... etc.
1141992287 M * dev_ I can't say it is cosmetic...
1141992315 M * Bertl well, the current method will paint a wrong picture too
1141992334 M * Bertl but it will be correct in regard of the sum over _all_
1141992404 M * Bertl so basically I see two extremes, one is to account it for every vps, the other to divide it evenly, yours is somewhere inbetween
1141992519 M * dev_ yep. But due to random distribution of this fraction it is quite accurate
1141992619 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1141993488 M * Bertl dev_: so assumed that we assign 'unique' identifiers (numbers?) for the various limits, we should be able to get a common structure reported back to userspace, no?
1141993549 M * dev_ hmm, looks like yes
1141993633 M * Bertl I also assume that we can agree on 64bit values here
1141993956 J * matt1 ~matta@71.224.125.126
1141994140 M * dev_ mmm, I can't see why you need 64bit values on 32bit archs.
1141994168 M * Bertl well, you probably don't want to have different structs for each arch
1141994194 M * Bertl and two different structs on x86_64 for example :)
1141994200 M * dev_ the struct can be the same. with long fields inside. or do you mean it will require compat after that?
1141994229 M * dev_ the problem is that it is arch dependant anyway. on 32bit archs limits/counters should 32bit, on 64 - 64, on 128-128
1141994246 M * Bertl what 128bit archs do you know?
1141994327 Q * GeDaST Quit:  -»«- Kaçak v4 -»«- www.Kacak.net -»«-
1141994332 M * dev_ no for this moment, I'm just trying to tell you that this is arch-dependant :)
1141994354 M * dev_ u64 will suite me... though I doubt it is good solution in _VERY_ long term :)
1141994356 M * Bertl that's what I said, so I'd make the struct arch independant to avoid issues
1141994390 M * Bertl well, I doubt that any resource (in very long term) will require more than 64 bit to be accounted
1141994465 M * dev_ Bill Gates also thought so :))) well, ok
1141994502 M * Bertl yeah, but IIRC the number of atoms in the universe, including dark and exotic matter :) is roughly 10^69
1141994552 M * Bertl no, sorry, 10^79 actually ...
1141994634 M * Bertl so that would roughly be 2^230
1141994682 M * Roey 2^230 >> 10^69?
1141994701 M * Roey 2^230 >> 10^79, rather?
1141994717 M * Bertl no, 2^240 >> 10^79 :)
1141994759 M * Bertl nah, 10^79 ~ 2^262
1141994814 M * dev_ Yeah, but you also should remember that though there are many atoms, there are much more their combinations and atom states.
1141994819 M * dev_ nice math :)
1141994856 M * Bertl yeah, well, but unless the context should account for the atoms involved in calculation, 64bit would suffice :)
1141994870 M * dev_ :))))))))))))))))
1141994895 M * Loki|muh lol
1141994901 M * Bertl so I think endianess is not an issue here
1141994908 M * dev_ A slogan for OpenVZ came to my mind: We virtualize the iniverse for you :)
1141994922 M * dev_ Parallel worlds etc. :)
1141994923 M * Bertl (although we could fix the endianess like for networking)
1141994987 M * Bertl and 64bit values seem sufficient, it would roughly make 8 entries a 64bit for each limit, right?
1141995001 M * Bertl so 64bytes per limit
1141995028 M * Bertl or 64 entries per 4k page
1141995251 M * weasel I wonder if anybody has written any nagios checks relating to vservers?
1141995282 M * weasel like vserver_check_procs similar to the normal check_procs?
1141995296 M * Bertl maybe, you might ask on the list ...
1141995338 M * weasel maybe I will :)
1141995641 Q * Wenix Quit: leaving
1141995736 J * matta ~matta@71.224.125.126
1141996050 Q * matt1 Read error: Operation timed out
1141996067 J * matt1 ~matta@71.224.125.126
1141996277 Q * matta Ping timeout: 480 seconds
1141996706 M * Bertl nap attack ... back later ...
1141996717 N * Bertl Bertl_zZ
1141996792 Q * matt1 Ping timeout: 480 seconds
1141996851 J * coocoon ~coocoon@p54A0696D.dip.t-dialin.net
1141997055 Q * Loki|muh Ping timeout: 480 seconds
1141998215 J * Wenix ~wenix@81.7.189.11
1141998565 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1141998782 J * Loki|muh loki@satanix.de
1141998893 J * phedny ~mark@volcano.p-bierman.nl
1141999223 Q * phycho Ping timeout: 480 seconds
1141999574 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1142000085 J * f_ ~f_@83-215-237-2.seek.stat.salzburg-online.at
1142000109 Q * f_ Quit: 
1142000609 Q * Greek0 Ping timeout: 480 seconds
1142001107 J * Greek0 ~greek0@85.255.145.201
1142002060 J * King_of_Queens ~sag@pD9F9B3B6.dip.t-dialin.net
1142002080 J * mmouse ~chatzilla@office.haefft.de
1142002141 M * mmouse hi there
1142002181 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1142002226 M * mmouse I'd like to ask a question, I didn't find an answer to on the wiki pages
1142002293 M * mmouse How do I configure a vserver guest (sarge), that a user of the guest can do a clean reboot inside the guest?
1142002425 M * King_of_Queens can anyone speak german hear?
1142002437 M * harry ein wenig
1142002439 M * mmouse ja
1142002441 M * King_of_Queens cool
1142002450 M * harry probier mal
1142002450 M * harry ;0
1142002451 M * harry ;)
1142002457 M * King_of_Queens ist des hier ein englischer server?
1142002494 M * harry ich spreche normalerweise niederlandisch
1142002522 M * harry also fur mich ist englisch ahmm... wie sagt man das... mehr einfach
1142002537 M * harry aber Bertl_zZ specht deutsch
1142002551 M * King_of_Queens aha
1142002558 M * harry aber du hast eine frage?
1142002578 M * harry (entschuldigung, ich habe keine estzet (they funny B ;))
1142002589 M * King_of_Queens nö... hey ich wollte den channel german grade gründen den gibts aba schon... auch gut
1142002598 M * King_of_Queens ^^
1142002612 M * King_of_Queens gibts hier gar keine owners oda so?
1142002622 M * harry weiss ich night
1142002628 M * harry nicht?
1142002659 M * harry brrrr... mein deutsch ist wirklich schlecht!
1142002696 M * King_of_Queens nö ist doch gut... deutsch ist glaube ich eine sehr schwierige sprache
1142002715 M * harry richtig :)
1142002716 J * phycho ~phycho@ext-gw.darktech.org.uk
1142002718 A * King_of_Queens kann es nicht so genau wissen weil es seine muttersprache ist
1142002728 M * harry deutsch schreiben ist hell!
1142002735 M * cehteh King_of_Queens: normalerweise ist der channel hier englisch .. und afaik k?nnen sich leute @ per chanserv holen wenn wer scheisse baut
1142002741 M * phycho eek.. german
1142002750 M * SNy hell, rofl
1142002756 M * SNy ITYM leicht
1142002757 A * phycho pretends what he knows what your sayinh
1142002761 M * King_of_Queens aha
1142002766 M * King_of_Queens hell harry ?¿?
1142002788 A * cehteh just wanted to say its better so speak englisch here and not start to troll :)
1142002790 M * harry gar nicht einfach
1142002791 M * phycho weeeeeeeeeeeeeeeeeeeeee
1142002795 M * King_of_Queens ^^
1142002799 M * phycho got an apple g4 on ebay
1142002801 M * phycho for 30pounds
1142002802 M * phycho lol
1142002807 M * King_of_Queens LautesOnlineLachen
1142002820 M * cehteh 30pounds of apples? :)
1142002823 M * harry roflmao
1142002836 M * harry even worst: roflmaoabmhatwRRh
1142002838 M * cehteh cheap deal .. but still lacks 2 mouse buttons
1142002841 M * phycho hahaha
1142002842 Q * michal` Ping timeout: 480 seconds
1142002847 M * phycho good enough for me..
1142002848 M * phycho =)
1142002858 M * harry rolling on the floor laughing my ass of and banging my head against the wall really really hard
1142002863 M * King_of_Queens rofl
1142002901 M * harry ow!!! 16h!!!
1142002907 M * harry time for... 0xc0ffee!!!!!!!!
1142002918 M * King_of_Queens hmmund was ist das hier für ein server
1142002928 M * harry King_of_Queens: linux-vserver.org
1142002934 M * harry sehen sie mahl
1142002940 M * harry gucken sie mahl
1142002947 M * harry bwerk... c0ffeetime
1142002949 M * SNy without the 'h'
1142002961 M * harry hm... tnx :)
1142003054 M * King_of_Queens aha
1142003057 M * King_of_Queens ^^
1142003063 M * King_of_Queens dehr informativ
1142003067 M * King_of_Queens ...
1142003080 M * King_of_Queens «harry»hast du n channelö
1142003081 M * King_of_Queens ?¿?
1142003132 M * cehteh uhm, King_of_Queens how old are you? 12?
1142003150 M * King_of_Queens nö why?
1142003166 M * phycho harry - i got my vserver to work with grsec =)
1142003177 M * phycho on 2.4
1142003182 M * King_of_Queens «cehteh»
1142003228 M * cehteh because you act like that
1142003282 M * mmouse How do I configure a vserver guest (sarge), that a user of the guest can do a clean reboot inside the guest?
1142003359 M * King_of_Queens act act act... was heißt nochmal act
1142003363 M * King_of_Queens ?¿?
1142003434 M * cehteh dict.leo.org
1142003695 A * King_of_Queens ich muss gehen ich wünsche euch noch eine schöne zeit im irc und sitzt ned zu lange vorm pc, denn dann kann man hirnschäden bekommen (spreche aus erfahrung) lol also dann schönen tag noch
1142003730 Q * shedi Quit: Leaving
1142003761 M * daniel_hozac mmouse: with recent patches and utils, that should be possible without doing anything.
1142003776 A * King_of_Queens cu
1142003779 Q * King_of_Queens Quit: jetzt bin ich weg aber es ist nicht aller tage abend, ich komm wieder keine frage... vergesst mich nicht lol
1142003812 Q * Greek0 Read error: Connection reset by peer
1142003820 M * mmouse daniel: unfortunately it isn't (util-vserver 0.30.209, patch 2.0.2-rc10)
1142003837 M * daniel_hozac mmouse: what initstyle?
1142003856 M * mmouse daniel: perhaps because I'm using a different vserver directory than /lib/vservers?
1142003868 M * mmouse daniel: none defined (so it should be sysv?)
1142003875 M * daniel_hozac the default for everyone not using debian is /vservers :)
1142003902 M * mmouse i've a rebootmgr task running, but no /dev/reboot inside the guest...
1142003910 M * daniel_hozac rebootmgr is legacy stuff.
1142003922 M * daniel_hozac so running reboot -f inside the guest does not reboot it?
1142004028 M * mmouse reboot -f does, umh, something...
1142004049 M * mmouse it stops the vserver, vserver-stat afterwards shows a newly started guest
1142004080 M * mmouse but if I do vserver <guest> enter it gives an error "suexec is supported for running vservers only"
1142004101 M * daniel_hozac so what guest does vserver-stat show as running?
1142004185 Q * matta Read error: Operation timed out
1142004193 M * daniel_hozac how did you create the guest?
1142004239 P * Roey Leaving
1142004248 M * mmouse seems like the guest is restarted and then killed again. wait a second, I'll paste a few lines of the terminal
1142004471 M * daniel_hozac please use pastebin.com or similar
1142004482 Q * phycho Quit: 
1142004704 M * mmouse ok, http://pastebin.com/594560
1142004801 M * daniel_hozac you might want to use static contexts instead.
1142004838 M * daniel_hozac how long between the reboot -f and the enter?
1142004872 M * daniel_hozac it's possible it was just still shutting down. (usually there's killall5 -TERM; sleep 5; killall5 -KILL or similar)
1142004877 M * mmouse just 10 seconds  or so. I wondered why there are no messgaes from the init-scripts...
1142004892 M * mmouse i'll try again with more time
1142004893 M * daniel_hozac they vanish into thin air.
1142004932 M * mmouse how do I use static contexts. can I define it somewhere in /etc/vservers or must I define it at build time of the guest?
1142004991 M * daniel_hozac echo <some number between 2 and 49151> > /etc/vservers/<name>/context
1142005014 M * daniel_hozac you could try mkdir -p /etc/vservers/.defaults/apps/vshelper; touch /etc/vservers/.defaults/apps/vshelper/logfile and see if the logs tell you anything.
1142005075 M * mmouse ok, if i wait for 1 minute after the reboot-f the guest is gone completely, seems it shutdown instead of rebooting
1142005087 M * daniel_hozac ok.
1142005107 M * daniel_hozac this is where the vshelper logfile might be handy.
1142005197 M * mmouse i did that already, logfile says: verver 'vgoldm' already running 
1142005215 M * mmouse seems like it tries to restart before the shutdown finished ;-)
1142005261 M * daniel_hozac does a manual vserver <name> restart do The Right Thing(tm)?
1142005441 M * mmouse static context doesn't change anything
1142005450 M * mmouse vserver vgoldm restart works perfectly
1142005539 Q * ||Cobra|| Remote host closed the connection
1142005836 J * coocoon ~coocoon@p54A07B55.dip.t-dialin.net
1142005984 M * mmouse daniel: how is reboot from inside the guest supposed to work (the non-legacy way)? Does it need any special devices or a pipe or something?
1142006300 J * gerrit_ ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1142006841 J * matta ~matta@71.224.125.126
1142007058 J * Smutje_ ~Smutje@xdsl-87-78-63-213.netcologne.de
1142007104 Q * rs Quit: rs
1142007164 Q * Smutje Ping timeout: 480 seconds
1142007164 N * Smutje_ Smutje
1142007635 M * mmouse daniel_hozac: I restarted the host and turned on vshelper debugging. Log seems perfectly normal, but the host processes immediately after the reboot -f are strange
1142007638 M * mmouse http://pastebin.com/594641
1142007766 M * doener_ fell to the floor once too often...
1142007772 M * doener_ oops...
1142007824 M * doener_ maybe I should start putting 1 Euro somewhere everytime i mess up input focus in irssi
1142007955 M * Wenix heh
1142008019 M * Wenix doener_: that'll probably not stop you from messing up, and you'll just end up poor ;)
1142008071 M * doener_ probably
1142008159 J * EreaserT3 ~some@0-1pool154-250.nas10.spokane1.wa.us.da.qwest.net
1142008186 J * gudi ~maurer@p54A7B711.dip0.t-ipconnect.de
1142008188 M * gudi hi
1142008197 M * gudi is it possible to use openvpn in vservers ?
1142008204 M * gudi cause i can not get it to work
1142008224 M * Wenix gudi: I use it
1142008228 M * gudi how ?
1142008233 M * gudi any special caps ?
1142008244 M * Wenix gudi: oh, wait - I actually run it on the host.. because I had troubles running it in guests
1142008269 M * gudi hmm.. i need to over it to a guest
1142008325 M * Wenix yup, I understand - I were just a bit too fast here
1142008325 M * Wenix (didn't think)
1142008325 M * gudi or is it possible to run it on the vserver and over the routes to the guest ?
1142008376 M * Wenix gudi: I'm not sure I understand you correctly.. but you want OpenVPN on host, and make the clients only reach certain guests?
1142008439 M * gudi Wenix, i have a openvpn server running on a other server and want to connect on guest to it to reach the networks after it
1142008534 M * tokkee Is there any way to bind a vserver to a virtual device (like tap)? Can anybody point me to a howto?
1142008624 M * tokkee IMHO it's pretty annoying to bind each network daemon to the vserver IP in any vserver and the host...
1142008692 M * cehteh huh .. chbind?
1142008706 M * daniel_hozac mmouse: does it leave those processes running for a longer period of time?
1142008745 M * daniel_hozac mmouse: it shouldn't run for more than 30 seconds under any circumstances.
1142008775 M * daniel_hozac mmouse: and it doesn't need anything, the kernel intercepts the reboot/halt calls and uses vshelper to restart/stop.
1142008792 M * tokkee cehteh: Could you please point me to some documentation about it?
1142008792 M * mmouse daniel: yes, running quite exactly 30 seconds 
1142008807 M * doener_ tokkee: ? limit the vserver's ip addresses, then manual binding is only required on the host...
1142008832 M * daniel_hozac mmouse: does the vshelper log show you a list of processes that were left running in the guest after stoping it?
1142008833 M * tokkee doener_: Ah... okay... didn't know that ;-) Thx
1142008843 M * mmouse daniel: I set a shorter timeout in .../vshelper/sync-timeout, then the message "vserver vgoldm is already running" appears quicker ;-)
1142008857 M * daniel_hozac mmouse: that might be an 0.30.210 thing, though.
1142008861 Q * EreaserT3 autokilled: On join spammer.  Mail support@oftc.net if you feel this ban to be in error.
1142008866 M * Wenix gudi: OpenVPN client is on Vserver guest, and you OpenVPN server is on a seperate server. You want to route traffic from the guest system over the VPN tunnel to a network behind the OpenVPN server? .. I'm sorry I ask you this.. but I need to be sure what you are asking before I (test and) reply
1142008876 M * mmouse daniel: no, no list
1142008886 M * daniel_hozac mmouse: could you paste testme.sh and vserver-info - SYSINFO?
1142008904 M * gudi Wenix, yes
1142008937 M * Wenix gudi: ok, hold on - I'll do some testing here
1142008945 M * tokkee doener_: Is echo $IP > /etc/vservers/users/interfaces/0/ip; echo 32 > /etc/vservers/users/interfaces/0/prefix all I need to do?
1142008998 M * doener_ a 'dev' file is also needed, in either interfaces/ or interfaces/0/
1142009015 M * daniel_hozac only if the IP isn't already setup.
1142009016 M * Wenix gudi: only the guest should be allowed to route traffic over the tunnel? and traffic from the other guests should not be allowed?
1142009037 M * doener_ then it needs a 'nodev' file
1142009053 M * doener_ or isn't that required anymore?
1142009057 M * tokkee doener_: Yes... and I can use the same device for each vserver, right?
1142009060 M * daniel_hozac indeed it is.
1142009092 M * doener_ tokkee: you can even share ip address if you need it, it's not recommended though
1142009104 M * tokkee doener_: Alright... thx again :-)
1142009113 M * doener_ you're welcome
1142009115 M * tokkee I guess I should read some more documentation ;-)
1142009166 M * mmouse daniel: is there an option to run testme.sh without colored output?
1142009175 M * tokkee Do I have to "reboot" the vserver after changing settings in interfaces/0/*?
1142009186 M * daniel_hozac for them to take effect? yes.
1142009213 M * daniel_hozac mmouse: i think so, check -h.
1142009218 M * tokkee There's no way to do that without a reboot? Something like ifconfig or whatever?
1142009269 M * daniel_hozac not by using the utils.
1142009302 M * mmouse daniel: doesn't say anything. just commented out the controlcodes in the script ;-)
1142009340 M * daniel_hozac i could've sworn someone got Bertl to apply a patch for a no-color option.
1142009365 M * mmouse daniel: http://pastebin.com/594708
1142009403 N * Bertl_zZ Bertl
1142009416 M * Bertl back now ... seems I missed ome fun :)
1142009419 M * mmouse daniel: testfs can do it, testme not, apparently 
1142009437 M * gudi hmm what is more problem sat the moemnt..
1142009456 M * gudi how can i set a real device only for one vserver ?
1142009469 M * Bertl daniel_hozac: the no-color will be in the next release
1142009469 M * daniel_hozac mmouse: could you perhaps try upgrading to 0.30.210, and compile with dietlibc instead of glibc?
1142009472 M * gudi i nned diffrent gateways for diffrent vservers
1142009500 M * daniel_hozac gudi: http://archives.linux-vserver.org/200311/0470.html
1142009507 M * Bertl gudi: how is both related? real device means a network interface?
1142009517 M * gudi Bertl,yes
1142009531 M * mmouse daniel: yes, I try, got the sources already
1142009533 M * Bertl gudi: then check out the url from daniel_hozac!
1142009548 M * gudi i allready read that..but don't understand
1142009581 M * Bertl gudi: it's basic linux routing, you have to assign different routing tables for different guests
1142009616 M * gudi Bertl, maybe..but i don't understand..
1142009633 M * gudi i have one vserver which habe ip 192.168.0.157.. and one with 192.168.200.100
1142009652 M * Bertl okay, and the gateways would be?
1142009653 M * gudi the first need to get routet to 192.168.0.1 as gateway and the secont 192.168.200.1
1142009716 M * Bertl now replace 10.0.0.0/16 by 192.168.200.0/24 and 10.0.0.1 by 192.168.200.1 (in the example)
1142009763 M * Bertl similar 10.0.0.2 becomes your 192.168.200.100
1142009764 M * gudi Bertl, still not understand sorry
1142009871 M * Bertl well, the example pretty much explains everything, so what is the part you do not understand?
1142009888 M * gudi i need it to be separated per network interface..
1142009898 M * gudi my first vserver has eth0 the second eth2
1142009901 M * gudi ups eth1
1142009907 M * daniel_hozac interfaces aren't selected until after routing.
1142009913 M * Bertl gudi: that's nice, but not relevan
1142009917 M * Bertl *relevant
1142009923 M * gudi sorry maybe um to dump..
1142009954 M * Bertl gudi: no, you have the same misconception folks usually have, that the networking is interface based, while it is IP based
1142009998 M * h01ger hmmmm.... is often happens, that my vservers dont really come up after reboot, the reason shows df: "df: cannot read table of mounted filesystems: No such file or directory"
1142010007 M * gudi Bertl, can you plz paste the commands i have to type in
1142010016 M * Bertl gudi: so, it's perfectly fine that you have two separate interfaces for your two networks -- doesn't change anything
1142010058 M * gudi Bertl, is it right to assign the ips via vserver ?
1142010068 M * gudi in interfaces/*
1142010090 M * daniel_hozac h01ger: why would that stop them from coming up after a reboot?
1142010096 M * daniel_hozac h01ger: guest or host reboot?
1142010101 M * h01ger host
1142010113 M * Bertl gudi: it doesn't hurt, but it's probably easier for you to set it up beforehand, and elt the guests use the IPs
1142010115 M * h01ger they come up, but nothing works without the fs..
1142010142 M * daniel_hozac h01ger: what?
1142010151 M * Bertl h01ger: vprocunhide?
1142010163 M * gudi Bertl, that not help me much sorry :-(
1142010174 M * Bertl h01ger: incombination with a link from /etc/mtab to proc?
1142010199 M * Bertl gudi: on what network is your host?
1142010225 M * h01ger Bertl, what do you mean with "vprocunhide"? i restarted /etc/init.d/vprocunhide but with no effect..
1142010258 M * gudi 192.168.200.0 and 192.168.0.0
1142010285 M * Bertl that's a network address, so the host cannot have those IPs
1142010312 M * gudi Bertl, ok 192.168.200.10 and 192.168.0.5
1142010330 M * Bertl that's better .. so you already have two IPs on the networks
1142010361 M * gudi yes on on one guest and on on the other.. the cserver itselv have ip 192.168.100.10
1142010362 M * Bertl that means you should do the setup on the host anyway, and have the guests start with their own IPs, which would be?
1142010387 M * Bertl ah, so the host now has 192.168.100.10 ?
1142010388 M * gudi the guests ips are 192.168.200.10 and 192.168.0.5
1142010398 M * gudi yes the host habe 192.168.100.10
1142010409 M * Bertl and is on a third network?
1142010411 M * Wenix prw-r--r--   1 root root   0 Mar 10 11:57 hostname
1142010414 M * Wenix sorry
1142010424 M * gudi what for a third network.. your really confuse me
1142010434 M * Bertl 192.168.100.0/24 ?
1142010445 M * gudi thats in which the vserver hangs itself..
1142010456 M * gudi the networks of the guests are others like i said
1142010463 M * Bertl vserver = host?
1142010516 M * Bertl gudi: look, start/reboot your server, then upload the output of the following commands to pastebin.com (without starting any guests)
1142010542 M * Bertl gudi: 'ip addr ls'  'ip route ls'
1142010550 M * gudi Bertl, vserver 192.168.100.10 = gateway 192.168.100.1, guest1 192.168.0.5 = gateway 192.168.0.1 , guest2 192.168.200.10 = gatewqy 192.168.200.1
1142010571 J * michal` ~michal@www.rsbac.org
1142010586 M * gudi Bertl, not possible at the moment
1142010664 M * Bertl okay, so let's assume you have rebooted it
1142010683 M * Bertl gudi: but you can upload the current output of those commands
1142010734 M * gudi Bertl, nope..
1142010741 M * gudi no access at the moment :-(
1142010876 M * h01ger Bertl, what do you mean with " incombination with a link from /etc/mtab to proc?" ?
1142010924 M * Bertl gudi: well, then I'd suggest you come back when you have access, as the theory is already explained in the example, and IMHO it doesn't make much sense to 'just' repeat it here, if you cannot test the steps on your machine
1142010967 M * Bertl h01ger: was jsut a shot in the dark, does any of your /etc/mtab entries actually consist of a link into procfs?
1142011052 Q * matta Read error: Connection reset by peer
1142011070 M * gudi Bertl, ok
1142011081 M * h01ger http://paste.debian.net/5073 - omega is the host, alpha is a vserver
1142011089 J * Dr4g Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk
1142011090 M * gudi Bertl, thx
1142011093 Q * gudi Quit: Verlassend
1142011104 M * h01ger i've edited /etc/vservers/alpha/fstab with a editor on omega
1142011136 M * Bertl h01ger: okay, so I missed :) could you upload the error message too?
1142011149 J * mef ~mef@targe.CS.Princeton.EDU
1142011156 M * Bertl welcome mef!
1142011161 M * h01ger Bertl, df: cannot read table of mounted filesystems: No such file or directory
1142011164 M * mef hey there.
1142011179 M * Bertl h01ger: okay, and this comes from the vserver scripts?
1142011184 M * h01ger no
1142011197 M * Bertl where does it come from?
1142011198 M * h01ger thats inside the vserver
1142011201 M * h01ger a sec
1142011209 M * mef hopefully the folks in asia will show up sometime, but I don't really know whether they will.
1142011230 M * Bertl mef: yeah, well, we can hope :)
1142011248 M * Bertl mef: maybe I should add the channel and server info?
1142011321 M * mef please do... tell them that it is the best/expedient way to get things done.
1142011329 M * h01ger Bertl, init.d/vprocunhine and vserver-defaults dont show any errors, when i start it with "vserver alpha start" i get http://paste.debian.net/5074
1142011335 M * mef especially wrt doing anything technical.
1142011578 M * mmouse daniel_hozac: ok, compiled the utils and tried again: exactly the same behaviour :-(
1142011641 J * matta ~matta@71.224.125.126
1142011680 M * Bertl h01ger: okay, how is that related to the df part?
1142011827 M * h01ger df is just a symptom of the vserver not running
1142011885 M * Bertl h01ger: well, the startup looks fine so far, no?
1142011886 M * h01ger what i find most strange, that after one reboot i had one out of six vservers running. while after all the other reboots today, none ran. i cannot see the console as the machine is co-located.
1142011942 M * restill I just realized I have been logged in for days.  Hrm.
1142011971 M * h01ger the last time i started vservers, i also needed quite a few reboots to get all up, but it only were 4... this is so completly whacky+out-of-control and i feel like i dont understand vservers at all :-/
1142012016 M * h01ger there must be a reason why it sometimes works, and sometimes dont. 
1142012019 M * h01ger (tm)
1142012043 M * Bertl restill: is that bad?
1142012062 M * Bertl h01ger: well, first, I'd think about cleaning up your guests a little
1142012079 M * Bertl h01ger: so that they do not try all that useless stuff
1142012151 M * h01ger like?
1142012172 M * restill I don't know.  I just hear about IRC hacking, and I am not watching my client.
1142012246 M * Bertl h01ger: hmm, okay, maybe that just looks like bad cleanup .. let me try another shot in the dark ...
1142012256 M * coocoon h01ger: which guests u have
1142012270 M * Bertl h01ger: could it be you are using filesystem tagging in combination with dynamic contexts?
1142012301 M * Bertl h01ger: let's do and upload the typical 'testme.sh' please
1142012389 M * h01ger re: could it be...: yes, could be, dunno :-// i created them with vserver $1 build -m debootstrap --hostname $1 --interface eth0:$2
1142012419 M * Bertl okay, that is missing a --context entry, so they will use dynamic contexts
1142012426 A * h01ger looks for the testme.sh script (will find it, had it already...)
1142012428 M * Bertl what about the filesystem tagging?
1142012466 M * Bertl h01ger: http://vserver.13thfloor.at/Stuff/SCRIPT/
1142012508 M * h01ger /usr/share/doc/util-vserver/example/testme.sh.gz also had it
1142012513 M * h01ger all test ran fine
1142012538 M * h01ger i use "tagxid" for the vserver partition
1142012559 J * shedi ~siggi@inferno.lhi.is
1142012561 M * h01ger and setattr --barrier
1142012563 M * Bertl ah, okay, well then this shot was a full hit :)
1142012569 M * h01ger :)
1142012581 M * Bertl every time your guest restarts, you get a new xid
1142012596 M * Bertl files written by the guest will be tagged with that xid
1142012609 M * h01ger aaaaarg
1142012611 M * h01ger :)
1142012621 M * Bertl when you start it a second time, access to those files will be blocked
1142012633 M * Bertl you get a message in the log (kernel log)
1142012649 M * h01ger is there a easy way to fix the old guest ? and how to prevent that ?
1142012658 M * Bertl so once again, here is a good example why dynamic xids are bad :)
1142012659 A * h01ger looks into kernel.log again. didnt see anything
1142012664 A * h01ger nods
1142012667 A * h01ger nods
1142012671 M * Bertl the solution is simple
1142012688 M * Bertl first, figure a static xid for each of your guests (2-49151)
1142012714 M * Bertl then, assign that with something like: echo 1001 >/etc/vservers/guest1/context
1142012727 M * Bertl (make sure all guests are stopped)
1142012738 M * h01ger .oO( defining xid is easy: the last byte of the ip-address )
1142012751 M * Bertl after that, fix up the filesystem taggings with chxid
1142012765 A * h01ger reads man chxid
1142012794 M * Bertl then you should be able to start the guests 
1142012813 M * Bertl there is a small catch here, are the guests unified somehow?
1142012818 M * h01ger wow - thanx. sounds real easy indeed.
1142012825 M * h01ger unified? 
1142012829 M * Bertl (i.e. do they share files)
1142012831 M * h01ger how would that be ?
1142012832 M * h01ger no
1142012840 M * Bertl okay, then it should be perfectly fine
1142012851 M * h01ger woot. 
1142012853 M * h01ger :-)
1142012862 M * Bertl and always remember, dynamic xids are evil :)
1142012872 M * daniel_hozac mmouse: what does the vshelper log contain?
1142012901 M * doener_ Bertl: OT: do you know if there's a way to do "syntax" highlighting for inline patches in mutt?
1142012920 M * mmouse same as before, and nothing about processes still running
1142012924 M * h01ger yup. i have a script to create the vservers (and maintain them with fai afterwards), i will fix the script now and never make that mistake again. _and_, most important, i have a logical explaination for something which looked pretty unreasonable to me some minutes ago :-))
1142012927 J * alexx ~alexx@proxy.ikse.net
1142012933 M * mmouse do i have to enable this somehow
1142012949 M * daniel_hozac mmouse: could you paste the relevant lines?
1142013079 M * Bertl doener_: hmm ... there should be a 'way' especially as patches are quite simple (in the pattern)
1142013204 M * Bertl doener_: IIRC you can even specify a 'viewer' so you might get full syntax highlighting from vim or so?
1142013304 Q * alexx Quit: Bye
1142013410 M * h01ger Bertl, cheers!! it worked! thanx! i 0w3 you a beer! (at least!) :-)
1142013418 M * h01ger all up & running now
1142013479 M * Bertl excellent!
1142014360 M * mmouse hmm, is there a way to show what xid a file has?
1142014502 M * Bertl mmouse: yep, lsxid will do so
1142014649 J * acb ~acb@targe.CS.Princeton.EDU
1142014656 M * Bertl welcome acb!
1142014943 M * mmouse bertl: thanks
1142014953 M * mmouse lots of !!ERR!! 
1142014986 M * Bertl means that xid tagging is not enabled for those files
1142015088 M * mmouse how does that come? testfs.sh doesnt show any error, and vserver <guest> start is working
1142015122 M * daniel_hozac mmouse: you need to mount the filesystem with tagxid.
1142015184 M * Bertl mmouse: testfs.sh creates its own filesystems and mounts them accordingly
1142015245 M * mmouse ok, do I need this for the fs of the guest only, or for the host filesystems also?
1142015270 M * daniel_hozac whichever filesystem /vservers/<name> lives on.
1142015285 M * daniel_hozac if you have a separate filesystem for each guest, using tagxid makes little sense though.
1142015338 M * Bertl mmouse: you do not strictly need it, and you do not really want it on host filesystems
1142015369 M * mmouse daniel: ah, ok, so I better don't use it. Just thought this could be related to my restart problem
1142015398 M * Bertl what issues do you have with restart?
1142015429 M * mmouse bertl: reboot -f in the guest stops the guest but doesn't start it again. vshelper logfile complains "vserver xxx already running"
1142015696 M * mmouse daniel, bertl: logfile + sysinfo is here: http://pastebin.com/594890
1142015767 M * mmouse daniel: sorry, took some time, because I destroyed the vshelper script in between ;-)
1142015906 M * Bertl mmouse: could you throw in a testme.sh output too? :)
1142016030 M * mmouse err, yes. appended it here: http://pastebin.com/594904
1142016450 M * Bertl okay, sorry folks, short interruption (mmouse we'll fix that in 15 mins)
1142016463 M * Bertl daniel_hozac, doener_: got a few minutes?
1142016473 M * mmouse bertl: np
1142016483 M * doener_ yup
1142016489 M * daniel_hozac sure.
1142016509 M * Bertl we (acb and I) were talking about the 'new' scheduler and how to test/improve it
1142016548 M * Bertl acb has already done a few tests regarding small loads and we now try to figure a good way to get detailed information
1142016585 M * Bertl sidenote: acb is the guy from princeton who designed the new scheduler with me :)
1142016619 M * Bertl so, we came up with the following idea how to get more information
1142016637 M * Bertl we would like to add something like the history tracing for the token buckets
1142016670 M * Bertl i.e. some kind of circular buffer which 'record' the changes to the buckets and allows userspace to retrieve that information in larger chunks
1142016684 M * daniel_hozac sort of like dmesg?
1142016685 M * Bertl so that they can be analyzed and graphed later
1142016704 M * Bertl daniel_hozac: yeah, something like that, probably via some test syscall 
1142016724 M * Bertl the interesting parts (we still have to figure) are:
1142016741 M * Bertl - we probably want to base the information on jiffies
1142016756 M * Bertl - but we have to tie them to wall clock time somehow
1142016776 M * Bertl - we also do not want an entry every time a token is removed from the bucket
1142016797 M * Bertl - i.e. we want to mark when a process starts draining tokens and when it stops
1142016811 M * Bertl - finally we have to do that 'per cpu'
1142016835 M * Bertl acb: did I miss something?
1142016850 M * acb that's a good summary
1142016897 M * Bertl okay, so we are flexible to design that interface as we like it, but we should make sure that it is able to provide all that information
1142016930 M * Bertl I'd prefer to start with a short brainstorming ...
1142016947 M * Bertl (so just let me know what ideas you folks come up with :)
1142017051 M * daniel_hozac forgive my ignorance, but what's a jiffie?
1142017084 M * Bertl the basic time unit in the kernel, basically a counter incremented on every timer interrupt
1142017116 M * Bertl (it is used for all kind of things inside the kernel, including scheduler decisions)
1142017184 M * daniel_hozac and the number of timer interrupts is not constant per time-unit?
1142017220 M * Bertl it usually is, i.e. older kernels had 100HZ, newer kernels have 250HZ, all 2.6 kernels until recently had 1000HZ
1142017250 M * Bertl thecounter intentionally starts at -300 seconds or so
1142017262 M * Bertl to trigger overflow issues early
1142017339 M * Bertl okay, if there are no spontaneous ideas, let's move on to the entries
1142017376 M * Bertl I'd really prefer to have fixed size entries, unless we find a really good reason not to do so
1142017394 M * Bertl but we can write more than one entry for one change/action
1142017433 M * Bertl of course, entries should be quite small as we want to get as many as possible in a reasonably large buffer
1142017507 M * acb bertl: I need to drop off, I'll check back later
1142017522 M * Bertl ok, np
1142017534 Q * acb Quit: Leaving
1142017891 M * Bertl okay, so what kind of records do we need?
1142017920 M * Bertl 1) changes in the scheduler settings
1142017935 M * Bertl 2) refills when they happen
1142017946 M * Bertl 3) start and stop of processes
1142017967 M * Bertl am I missing something?
1142018050 M * Bertl okay, let's get back to the usual stuff, but feel free to throw in ideas if you ahve some ...
1142018182 M * Bertl mmouse: I assume something is keeping the guest alive beyond the vkill
1142018212 M * Bertl mmouse: could it be that there are some 'helpers' hanging around on the host?
1142018253 M * mmouse bertl: ok, how to find out? vserver xxx restart in the host is working btw
1142018258 M * Bertl could you check with 'vps auxwww' after the restart failed?
1142018318 M * mmouse I got khelper, khubd and so on, but nothing special. And I killed rebootmgr, which debian starts by default
1142018348 M * Bertl doener_, daniel_hozac: btw, I'd like to put some things into the stable release very soon, do you think that we should make a stable release (2.0.2) without that stuff and a 2.0.3 shortly after?
1142018377 M * Bertl (thinking about the initpid and kill changes)
1142018396 M * mmouse ok, after the reboot -f, I got a "killed" almost immediately, then in the host
1142018428 M * mmouse there's a vwait process which waits for fd 3 44 (which is /dev/ttyrc?) until timeout of 30 sec
1142018463 M * doener_ Bertl: i'm not up to date regarding that stuff, so i can't make a reasonable vote :(
1142018639 M * mmouse bertl: appended the vps output here: http://pastebin.com/594966
1142018741 M * daniel_hozac Bertl: i guess making it part of 2.0.2 would make the most sense.
1142018762 M * mmouse seems that /var/lock/vserver.etcvserversvgoldm.startup never gets deleted?
1142018788 M * Bertl well, more important, you have two stop processes hanging there?
1142018806 M * Bertl one restart and one startup
1142018824 M * Bertl and still the reboot inside the guest
1142018835 M * mmouse yes, but they're both new, there was no process before the reboot -f
1142018886 M * Bertl do you have any special flags set for the guest?
1142018977 M * Hollow Bertl: if persistant (could we change that to persistent btw, please?), reboot_kill and the new initpid stuff would be in 2.0 i guess vserver-utils will also work with 2.0
1142019038 Q * Dr4g Quit: Leaving
1142019054 M * Bertl Hollow: guess or know?
1142019069 M * Bertl and yes for the spelling correction ...
1142019105 M * Hollow well, not 100% sure, but i can't think of a future missing except those 3.. have to test it first, let me know if you have a patch
1142019122 M * Bertl okay
1142019135 M * mmouse bertl: I did it again and updated the vps with parent PID : http://pastebin.com/594984
1142019187 M * mmouse bertl: no special flags. just changed vdirbase and set logfile and debug for vshelper
1142019250 M * mmouse set .../init/mark for default startup and .../interfaces/0/name to see the interface in ifconfig
1142019255 M * Bertl and after the 30 seconds, how does it look then?
1142019278 J * doener ~doener@i5387F6F2.versanet.de
1142019344 M * mmouse bertl: then the "vserver already running" in the vshelper log appears and all processes are gone, the vserver isn't running and /var/lock/vserver.name.startup is still there
1142019367 J * lonewolf1 lonewolff@adleman.lonewolff.info
1142019397 M * Bertl I'd say it is the reboot -f still running inside
1142019416 M * mmouse the vserver resides in its own LVM volume, is there something special about LVM+vserver?
1142019421 M * Bertl but I'm not sure how that could have changed since it was implemented, any ideas?
1142019456 M * Bertl I just assume that Enrico tested it at some point, wouldn't make sense otherwise, no?
1142019481 Q * lonewolff Ping timeout: 480 seconds
1142019484 M * daniel_hozac the reboot -f inside guests?
1142019498 M * Bertl yup
1142019547 M * daniel_hozac WORKSFORME.
1142019566 M * Bertl okay, so let's figure what the difference is ...
1142019596 M * Bertl daniel_hozac: could you enable the same stuff (regarding logging) as mmouse has?
1142019616 M * Bertl and see if there is any difference in the execution path?
1142019635 M * Bertl daniel_hozac: ah, and are you using the stable branch?
1142019666 M * daniel_hozac yep, ancient release though...
1142019676 M * daniel_hozac i'll fire up my test machine.
1142019681 M * Bertl excellent, tx!
1142019687 M * daniel_hozac (previous tests were just on the laptop)
1142019694 Q * doener_ Ping timeout: 480 seconds
1142019770 M * mmouse what is vserver-info name XID supposed to display?
1142019807 M * Bertl the context id for that guest ...
1142019850 M * mmouse umh... vserver-info CONTEXT gives 44 (as configured), vserver-info XID gives 0
1142019887 M * daniel_hozac try vserver-info name XID false
1142019906 M * mmouse daniel: 0 also
1142019915 M * Bertl is it running?
1142019930 M * mmouse yes, and vserver-stat shows 44 as CTX
1142020005 J * matt1 ~matta@71.224.125.126
1142020054 J * PilatomiK ~tek@ADijon-151-1-147-89.w81-50.abo.wanadoo.fr
1142020084 M * Bertl welcome PilatomiK!
1142020100 M * PilatomiK holla holla
1142020112 M * Bertl mmouse: well, that might even be fine, no idea about the various vserver-info options
1142020190 N * lonewolf1 lonewolff
1142020303 J * rs ~rs@office.dailymotion.com
1142020340 M * mmouse bertl: ok, this reboot really hangs around the whole 30 seconds. don't know why
1142020409 Q * matta Ping timeout: 480 seconds
1142020618 M * Bertl welcome rs!
1142020633 M * rs hi
1142020672 M * Bertl mmouse: well, that is somewhat okay, if there is something else in the context, but we do not know what happens once the timeout is reached
1142020738 M * daniel_hozac 2.6.15-1.1833_FC4.vs2.0.2.0.rc10.1 with util-vserver 0.30.210 handles reboot -f as expected, except for the raised priority.
1142020809 M * Bertl okay, any obvious differences in the kernel setup (see testme.sh lines) or the guest setup?
1142020909 Q * matt1 Ping timeout: 480 seconds
1142020911 M * mmouse daniel: do you have a tty entry in .defaults/apps/init?
1142020919 M * daniel_hozac no.
1142021042 M * Bertl mmouse, daniel_hozac: maybe you could exchange the config tree for a test?
1142021083 M * mmouse yes, i have mine as tgz, where should I send it?
1142021108 M * Bertl do you have some place to upload it? if not dcc might be an option?
1142021139 M * daniel_hozac i have Lg in addition to Tb, n and P.
1142021140 M * mmouse sorry, no dcc, but I'll upload it
1142021227 M * Bertl daniel_hozac: that means legacy support enabled
1142021241 M * daniel_hozac ah, yes.
1142021260 M * Bertl tools have other interfaces than v13,net too?
1142021330 M * daniel_hozac no.
1142021341 M * mmouse ok, my config: http://www.checon.net/etcvservers.tar.gz
1142021348 M * Bertl daniel_hozac: okay, then the same API should be used ...
1142021419 M * daniel_hozac it should use the same API regardless.
1142021429 M * daniel_hozac the tools will always use the newest supported one.
1142021441 M * Bertl okay
1142021475 M * Bertl after all, you are the tool expert in our oracle group :)
1142021502 M * daniel_hozac lol
1142021847 M * daniel_hozac the vkill's vshelper is doing look fishy though.
1142021918 M * daniel_hozac IMHO, it should just let vserver ... restart do its thing on reboot, rather than first trying to kill the context itself.
1142021954 M * Bertl okay, but that doesn't really explain why it works for you, does it?
1142021959 M * daniel_hozac no, not at all.
1142021975 M * daniel_hozac the same config works fine too.
1142022099 Q * mmouse Read error: Connection reset by peer
1142022128 J * mmouse ~mmouse@office.haefft.de
1142022158 M * mmouse sorry
1142022164 M * Bertl np
1142022349 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1142022460 M * mmouse ok, I tried to kill the running vserver manually: vkill -s 9 --xid 44
1142022478 M * mmouse works normal, so I don't understand why this reboot task lives on...
1142022521 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1142022868 M * daniel_hozac could you try commenting the spawn killContext lines in vshelper?
1142023046 M * daniel_hozac i can't see that making any difference, but it can't hurt...
1142023147 M * daniel_hozac Bertl: will sys_reboot keep the reboot task in kernel space until vshelper has been started, or until it's done?
1142023167 M * Bertl depends on the flags, sync vs async
1142023210 M * Bertl but let me check that for stable (sec)
1142023212 M * daniel_hozac ah, so that's what it's for.
1142023415 J * dearaujo ~dan@cpe-66-25-189-193.austin.res.rr.com
1142023436 M * Bertl daniel_hozac: hmm, the legacy mode makes a difference here
1142023446 M * Bertl #ifndef CONFIG_VSERVER_LEGACY ret = do_vshelper(vshelper_path, argv, envp, 1);
1142023446 M * Bertl #else ret = do_vshelper(vshelper_path, argv, envp, 0);
1142023446 M * Bertl #endif
1142023475 M * Bertl last argument is sync
1142023480 M * Bertl welcome dearaujo!
1142023511 M * dearaujo hi Bertl
1142023515 M * Bertl mmouse: enabling legacy support should fix that as it seems
1142023582 M * daniel_hozac Bertl: aah, ok.
1142023624 M * dearaujo im a bit confused regarding vunify and vhashify.  Does it take into account packages? That is, if I have gcc installed on vserver1 and I unify/hashify vserver1 & vserver2, will gcc be available on vserver2?
1142023654 M * dearaujo i assume that's not the right idea
1142023658 M * Bertl dearaujo: no :)
1142023673 M * Bertl both, vunify and vhashify compare the installed files
1142023685 M * Bertl vunify looks at packages and pathes
1142023689 M * daniel_hozac Bertl: hmm, will sync ever work?
1142023691 M * mmouse bertl: stupid question: how do I enable legacy support? At compile time of the utils?
1142023700 M * daniel_hozac mmouse: compile time of the kernel.
1142023704 M * Bertl dearaujo: while vhashify jsut looks at the hash values
1142023723 M * mmouse argh :)
1142023766 M * Bertl daniel_hozac: well, if the tools handle it properly, I'd say yes
1142023777 M * daniel_hozac Bertl: what would properly be?
1142023789 M * daniel_hozac wouldn't the reboot process always be stuck inside the context?
1142023823 M * Bertl the vshelper is supposed to _return_ after the guest context was 'killed' i.e. sent the signals
1142023848 M * Bertl at this time, it should have launched the 'waiter' which will do the restart, once the context disappeared
1142023850 M * daniel_hozac ah, so that's why it's not using vserver ... stop.
1142023862 M * Bertl (at least that is how it was planned)
1142023879 M * Bertl probably superceeded by the much simpler rkill stuff
1142023989 M * dearaujo Bertl: so vunify would work for packages then
1142023995 M * dearaujo not hashify
1142024001 M * mmouse ok, I'll build a new kernel tomorrow, then let you know
1142024014 M * daniel_hozac dearaujo: hashify will also work _for_ packages.
1142024026 M * Bertl dearaujo: well, both (IIRC) use the package information to find config files
1142024036 M * mmouse a real big thank you, daniel and Bertl
1142024048 M * Bertl mmouse: thank you for testing this stuff!
1142024083 M * Bertl daniel_hozac: so, the question is, do we work around that in the kernel (dropping the sync behaviour) or in userspace?
1142024109 M * mmouse bertl: np at all
1142024117 M * daniel_hozac Bertl: i'm not really able to parse vshelper right now, but it seems to just send the signals and then exit when sync is used.
1142024131 M * mmouse see you guys, thx!
1142024133 Q * mmouse Quit: ChatZilla 0.9.61 [Mozilla rv:1.7.11/20050728]
1142024136 M * Bertl which would be the RightThing(tm)
1142024162 M * daniel_hozac right.
1142024172 M * Bertl daniel_hozac: but I think the problem is the reboot -f
1142024191 M * dearaujo please forgive my ignorance - so in order to have gcc in both vservers - I'd have to install it on both...
1142024198 M * daniel_hozac dearaujo: yep.
1142024201 M * Bertl it probably doesn't handle the returning sys_reboot() that well
1142024220 M * Bertl dearaujo: yep, but you can unify/hasify them to save space
1142024234 M * daniel_hozac Bertl: well, it works here...
1142024236 M * dearaujo lol - now my confusion ensues...
1142024254 M * daniel_hozac and mmouse's error message did state that the vserver was still running.
1142024256 M * dearaujo so I install on both vservers and vhashify both vservers...
1142024271 M * Bertl dearaujo: take a step back and forget about vunify/hashify for a moment
1142024277 J * Viper0482 ~Viper0482@p5497742B.dip.t-dialin.net
1142024279 M * dearaujo done :)
1142024283 M * Bertl welcome Viper0482!
1142024295 M * Bertl dearaujo: now think what you remember about hard links?
1142024344 M * Bertl daniel_hozac: well without the legacy enabled?
1142024357 M * Bertl dearaujo: you know what hardlinks are? what they do?
1142024367 M * dearaujo pretty much another name pointing to the the same data inode?
1142024372 M * Bertl exactly
1142024382 M * Bertl so they do not use up much space, right?
1142024387 M * dearaujo right
1142024404 M * Bertl now consider you have the very same 'bash' binary in guest 1 and 2
1142024411 M * dearaujo ok
1142024419 M * Bertl wouldn't it save space if you had hardlinks?
1142024426 M * dearaujo absolutely
1142024431 M * daniel_hozac Bertl: right, so it seems that sync is in fact not working.
1142024439 M * Bertl dearaujo: okay, what's the problem with that approach?
1142024478 M * Bertl daniel_hozac: okay, so I think we drop the sync handler as it isn't really used, does that make sense?
1142024508 M * dearaujo hmm - im not so sure
1142024515 M * daniel_hozac hmm, wait, now i get how it's supposed to work.
1142024534 M * Bertl dearaujo: well, two names pointing to the same inode means that you are looking at the same data
1142024551 M * dearaujo but why would it matter if it's a binary?
1142024554 M * Bertl dearaujo: so if guest1 decides to write the evil hack binary over the bash, guest 2 will suffer
1142024560 M * dearaujo ah
1142024562 M * dearaujo ok
1142024577 Q * Viper0482 Quit: bin raus, 
1142024581 M * daniel_hozac i still don't understand where vshelper is getting its variables from...
1142024589 M * Bertl dearaujo: okay, so smart folks got the idea to make those hardlinks immutable
1142024600 Q * f_ Quit: Leaving
1142024611 M * Bertl dearaujo: this basically protects against such changes, but it has a different issue
1142024617 M * dearaujo oh?
1142024628 M * Bertl dearaujo: consider you want to upgrade bash from 2.05 to 3.0 inside guest 1
1142024638 M * Bertl would not really work, would it?
1142024645 M * dearaujo ok
1142024651 M * Bertl daniel_hozac: okay, are you trying to figure it?
1142024675 M * Bertl dearaujo: so there was another change, the so called immutable link inversion
1142024680 M * daniel_hozac ah, of course, vshelper functions in another file...
1142024706 M * Bertl dearaujo: now the final solution is a hard link which can be removed, but not modified
1142024734 M * Bertl dearaujo: this allows for updates in the usual way (i.e. remove the old one, install a new one)
1142024759 M * Bertl dearaujo: obviously this should not be done for config or log files which might be edited or appended to
1142024773 M * Bertl everything clear so far?
1142024780 M * dearaujo yes - it is
1142024792 M * dearaujo you explain well
1142024808 M * Bertl excellent, now one left out part is how to get those hardlinks
1142024819 M * Bertl and this is where vunify or vhashify come into play
1142024836 M * Bertl both look for identical files (avoiding config and log files)
1142024852 M * Bertl and 'unify' them in the beforementioned way
1142024866 M * Bertl thus reducing disk usage
1142024896 M * Bertl the only difference between them is 'how' they find duplicates
1142024919 M * dearaujo you mean duplicates between vservers
1142024922 M * dearaujo i assume
1142024925 M * Bertl the older one (vunify) just looks at pathes, the newer one (vhashify) generates hash values
1142024944 M * Bertl vhahsify can also 'unify' identical files inside the _same_ guest
1142024964 M * Bertl (e.g. /bin/bash and /usr/bin/bash)
1142024973 M * dearaujo ahh
1142024979 M * dearaujo interesting
1142024992 M * Bertl doesn't really matter where they are, as long as they are the same data
1142025184 M * Bertl okay, have to get something to eat now .. brb
1142025188 M * dearaujo so if i want to save some space - i would install the same binaries (e.g, gcc) on both guests and hashify/unify
1142025198 M * dearaujo i think i got it now
1142025209 M * dearaujo thanks!
1142025246 M * daniel_hozac Bertl: if i'm reading vshelper correctly, it's not starting the waiter.
1142025338 M * daniel_hozac or, maybe, it's just not doing it sync at all.
1142025744 M * daniel_hozac it seems to be a problem with the utils either way.
1142025936 M * Bertl dearaujo: you're welcome!
1142025963 M * Bertl daniel_hozac: okay, so I take it you are still investigating
1142026020 Q * djudko_ Quit: Leaving: Keep Your Powder Dry
1142026708 Q * mef Remote host closed the connection
1142027174 P * dearaujo 
1142027324 J * Viper0482 ~Viper0482@p5497742B.dip.t-dialin.net
1142028005 Q * restill Quit: Leaving
1142028468 J * jayeola ~jayeola@host-87-74-46-211.bulldogdsl.com
1142028810 M * Bertl welcome jayeola!
1142028815 M * jayeola hey there.
1142029193 J * chris2000 ~family@147.red-62-57-142.user.auna.net
1142029200 M * Bertl welcome chris2000!
1142029220 M * chris2000 hi :)
1142029245 M * chris2000 I just thought I'd see if I could connect ok.
1142029260 M * Bertl excellent, and it seems it worked :)
1142029271 M * chris2000 so it does.
1142029275 M * doener works
1142029286 M * doener wrong window... again... :(
1142029301 M * chris2000 now I'll be able to drill you all on Mo0nday when I get to work.
1142029438 M * chris2000 I'm running into problems moutn nfs from a guest. I've seen on the list that this can be done including 'capabilities' in the vserver config.
1142029451 M * chris2000 binary_mnount and secure_mount (from memory)
1142029467 M * chris2000 but I can't see anywhere to do that.
1142029476 M * Bertl hmm?
1142029494 M * chris2000 hang on, I'll find the url
1142029499 M * Bertl what's whte problem adding those flags?
1142029511 M * Bertl s/whte/the/
1142029535 M * chris2000 I created a flags file and included on per line.
1142029569 M * chris2000 vserver name start: gave me errors about incorrecto flag names.
1142029585 M * Bertl maybe your tools are too old?
1142029593 M * Bertl what tool version do you use?
1142029595 M * chris2000 I haven't got my equipment here. I'm at home now. This is probably better to do from work.
1142029615 M * Bertl okay, then enjoy your visit :)
1142029623 M * chris2000 Ah yes, I've seen that suggested. I'm using 204
1142029659 M * chris2000 Bertl, I see from your info you are Herbert?
1142029671 M * Bertl indeed I am, so?
1142029689 M * chris2000 A great pleasure to meet you.
1142029707 M * Bertl well, nice to meet you too :)
1142029752 M * chris2000 let's see if I can learn and make a contribution to the project.
1142029777 M * Bertl excellent idea ...
1142029821 M * chris2000 I'll update the utils on monday before I get  back about this problem. havce a good weekend. :)
1142029831 M * Bertl you too!
1142029835 P * chris2000 
1142030153 J * samv_home ~samv@watts.utsl.gen.nz
1142030546 J * matt1 ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1142030825 Q * hallyn Quit: leaving
1142030954 M * Bertl welcome samv_home!
1142031000 Q * matta Ping timeout: 480 seconds
1142031029 Q * matt1 Ping timeout: 480 seconds
1142031032 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1142031219 M * samv_home hey Bertl 
1142031299 M * samv_home things are looking good for making it to Essen
1142031338 M * Bertl good ...
1142031438 M * Bertl okay, I'm currently finalizing a few things I'd like to get into stable if they make sense to all of you ...
1142031470 M * Bertl so I'd like to have at least doener, daniel_hozac, samv_home and Hollow have a look at them ... just to make sure
1142031545 M * Bertl here is the first patch containing various fixes (as a warmup)
1142031574 M * Bertl note, all of them are changes in devel which are considered stable enough to get into stable
1142031583 M * Bertl http://vserver.13thfloor.at/Experimental/delta-var-stab01.diff
1142031620 M * Bertl feel free to ask funny questions :)
1142031637 Q * Viper0482 Remote host closed the connection
1142031828 Q * meandtheshell Quit: bye bye ... 
1142032004 M * samv_home why no capabilities check in vc_set_namespace?
1142032055 M * Bertl check should happen in switch.c
1142032086 M * Bertl *checing now*
1142032091 M * Bertl +k
1142032129 M * samv_home in proc_pid_vx_info, you seem to be putting a reference not guaranteed to be non-null
1142032140 M * samv_home +	if (!vxi)
1142032141 M * samv_home +		goto out_put;
1142032146 M * samv_home not just goto out?
1142032188 M * Bertl good point!
1142032202 M * samv_home same thing in proc_pid_nx_info
1142032215 M * Bertl yeah, that's probably a copy/paste issue
1142032269 M * Bertl at the point we reach vc_set_namespace() we must have CAP_CONTEXT
1142032292 M * Bertl (or be the setup process in the legacy case)
1142032436 M * samv_home was VCI_KCBIT_LEGACY_VERSION just not used before?
1142032545 M * Bertl it was, but I'd like to move it to that bit location
1142032568 M * Bertl well, it is not used on stable
1142032600 M * Bertl at least I think so .. checking
1142032642 M * Bertl well, it is used but only for reporting back a setting
1142032648 M * Bertl so we can safely change that
1142032673 M * Bertl IMHO it's better to have it in sync with devel
1142032707 M * samv_home ok, so long as we're not breaking the utils :)
1142032801 M * Bertl here is the next one, actually a simple rename:
1142032807 M * Bertl http://vserver.13thfloor.at/Experimental/delta-lookup-stab01.diff
1142032914 M * samv_home that one looks straightforward enough.  I guess if it builds you've got it right :)
1142032928 M * Bertl yup, my thought too ...
1142032944 M * Bertl http://vserver.13thfloor.at/Experimental/delta-helper-stab01.diff
1142033185 M * doener hm, where's vs_reboot called from?
1142033192 M * daniel_hozac sys_reboot
1142033207 M * daniel_hozac proc_vnet_readdir first hunk, is that a problem on stable? (fix for highest nid shown twice, right?)
1142033217 M * daniel_hozac (delta-var-stab01)
1142033218 M * Bertl yup
1142033258 M * daniel_hozac how do you reproduce it?
1142033282 M * Bertl ls in the proc dir should work
1142033315 M * daniel_hozac ls /proc/virtnet shows all nids just once here.
1142033319 M * doener ah, misread the function name change as declarations...
1142033388 M * Bertl daniel_hozac: checking now ...
1142033407 M * samv_home hmm, _REBOOT_KILL and _PERSISTENT aren't referred to in that patch
1142033423 M * samv_home (delta-helper-stab01)
1142033428 M * Bertl yep
1142033449 M * Bertl will be used in the following patches
1142033456 M * Bertl (just didn't want to tear that aparat)
1142033459 M * Bertl *apart
1142033573 M * Bertl Hollow: how did you trigger the vnet entry issue
1142033872 M * Bertl http://vserver.13thfloor.at/Experimental/delta-persist-stab01.diff
1142034065 M * Bertl daniel_hozac: the fact that virtnet works fine in both cases is indeed interesting
1142034165 M * Bertl ah, no, it's fine
1142034176 M * Bertl the interesing case is for xid=1
1142034201 M * Bertl so to reproduce, the following should work:
1142034359 M * Bertl nah, works in all cases, but is fine after removing current
1142034388 M * Bertl so do not consider it a fix, but only removal of case 3 (current)
1142034428 M * Bertl http://vserver.13thfloor.at/Experimental/delta-init-stab01.diff
1142034434 M * Bertl http://vserver.13thfloor.at/Experimental/delta-exit-stab01.diff
1142034470 M * daniel_hozac hehe, ok.
1142034648 M * Bertl and the final one, which improves the _HERE_ stuff
1142034657 M * Bertl http://vserver.13thfloor.at/Experimental/delta-debug-stab01.diff
1142034683 M * Bertl samv_home: here is the 'fix' for the put, which applies to all branches
1142034684 M * Bertl http://vserver.13thfloor.at/Experimental/delta-pidinfo-fix01.diff