1123113617 P * stefani I'm Parting (the water) 1123114237 M * micah hey Bertl how was wth? 1123114814 M * Bertl hmm .. mainly wet :) 1123115116 M * ray6 but we also had quite some sun... 1123115161 M * micah I heard it was pretty wet 1123115165 M * ray6 Bertl gave a great talk on vserver which hopefully raised some interest :) 1123115180 M * micah yeah I hope to see the video version 1123115239 M * Bertl hmm, did they tape it? 1123115263 M * ray6 Bertl: I think so, yes, all talks were supposed to be recorded... you weren't told? :) 1123115278 M * ray6 should be on the rehash mirrors by now 1123115283 M * Bertl no, but it's fine for me ... 1123115304 M * micah yes, they were trying to record all of them 1123115313 M * micah I've seen my roommate's talk alread 1123115314 M * micah y 1123115367 M * micah http://rehash.whatthehack.org/wth/rawtapes/wth_linux_vserver/wth_linux_vserver_140.mp4 1123115409 M * micah bbiab 1123115589 M * ray6 ftp://ftp.uni-erlangen.de/.mirrors/ftplinux/rehash.whatthehack.org/wth/rawtapes/wth_linux_vserver/wth_linux_vserver_140.mp4 is possibly faster 1123116009 M * ray6 Bertl: already downloading to check how you look on video? :) 1123116034 M * Bertl no, would probably take too long 1123116109 A * ray6 hopes to get a disk with all recordings on friday 1123118291 Q * mugwump Remote host closed the connection 1123119473 M * Bertl okay folks, I'm off to bed now ... back tomorrow ... 1123119481 M * Bertl have a good one everyone ... 1123119487 N * Bertl Bertl_zZ 1123120890 J * zimb0 ~zimbo@callisto.dom.bonis.de 1123121302 Q * zimbo Ping timeout: 480 seconds 1123123455 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1123124638 Q * xf_ Ping timeout: 480 seconds 1123126579 Q * mugwump Ping timeout: 480 seconds 1123127188 Q * DaPhreak Read error: Connection reset by peer 1123127217 Q * meebey Ping timeout: 480 seconds 1123127356 J * meebey meebey@booster.qnetp.net 1123127397 J * DaPhreak ~phreak@styx.xnull.de 1123127666 Q * aba jupiter.oftc.net plasma.oftc.net 1123127829 J * DaPhreak_ ~phreak@styx.xnull.de 1123127883 Q * DaPhreak Read error: Connection reset by peer 1123128025 J * aba ~aba@2001:a60:f006::2 1123130264 J * mugwump ~samv@watts.utsl.gen.nz 1123136535 Q * monrad Quit: Leaving 1123137596 J * Doener` ~doener@p54877468.dip.t-dialin.net 1123138029 Q * Doener Ping timeout: 480 seconds 1123139110 Q * Matthew-1 Ping timeout: 480 seconds 1123140160 Q * lilo_ Ping timeout: 480 seconds 1123140366 J * lilo ~lilo@lilo.usercloak.oftc.net 1123143034 N * Bertl_zZ Bertl 1123143050 M * Bertl morning folks! 1123144359 M * eyck morning 1123144421 M * Bertl hey eyck! everything fine? 1123144747 J * monrad ~monrad@195.97.130.53 1123144850 M * eyck I overslept 1123144902 M * Bertl eyck: well, could be worse, no? 1123144906 M * Bertl morning monrad! 1123145144 M * eyck Bertl: is there a reason why I can't 'vserver sth enter' non-running server with new style configuration? 1123145521 M * Bertl probably because enrico does not want to do the startup of the guest as sideeffect ... 1123145543 M * Bertl it's not really defined _what_ to do on enter when the guest is not running 1123145561 M * Bertl for example, what about mounts or limits? should they be set? 1123145809 M * eyck no, why would they? 1123145869 M * Bertl well, consider you have a guest, where you mount something on /usr (at startup) 1123145898 M * Bertl doing enter on a non running guest would put you into a non-working version (missing /usr) 1123145957 M * eyck well, since I'm supposed to be the one who configured it that way, that would expected, right. 1123145986 M * sid3windr maybe 1123145988 M * sid3windr maybe not 1123145992 M * sid3windr maybe you would want mounts to be done? 1123146020 M * sid3windr well maybe not you, but someone else? :) 1123146025 M * sid3windr like, me 1123146077 M * eyck so, you prefer not beaing able to enter your vserver AT ALL? 1123146080 Q * Aiken Ping timeout: 480 seconds 1123146119 M * Bertl eyck: define 'enter' 1123146135 M * eyck 'vserver test enter' 1123146146 M * Bertl okay, and _what_ should be done? 1123146172 M * eyck exactly what happens when I do that now, with normal 'legacy' config 1123146207 M * eyck for me, it would be enough to chbind, chcontxt and chroot 1123146209 M * Bertl regardless if that is what happens on the guest when started? 1123146221 M * eyck what? 1123146240 M * Bertl so you would be fine with chroot instead of namespaces, and missing mounts, etc? 1123146248 M * eyck yes. 1123146297 M * Bertl you know that if you start any process inside (and leave it running) it would cause very strange effects once you try to start the guest? 1123146326 M * monrad morning 1123146332 A * monrad is a bit slow today 1123146333 M * eyck yes. 1123146360 M * eyck hmm, define 'strange effects'? 1123146375 M * Bertl eyck: well, then please file a feature request for some half-enter option to savannah 1123146413 M * eyck can I file just "stop removing features" as a request? 1123146430 M * Bertl no features where removed 1123146433 M * Bertl *were 1123146469 M * Bertl for legacy guests (not using namespaces and such stuff) it's still supported no? 1123146504 M * eyck then, I'm supposed to stay with legacy? 1123146553 M * Bertl well, it's no problem to either a) start the guest, or b) write a small 'hack' script which does the half-enter stuff ... 1123146571 M * eyck what is half-enter? 1123146592 M * Bertl whatever you consider as 'enter' for a newstyle guest ... 1123146612 M * eyck I'm feeling abandoned, 1123146661 M * Bertl what is the advantage you see in (half-)'entering' a non running guest? 1123146687 M * eyck well, for one, you can "ENTER" a non-running guest. 1123146736 M * sid3windr and what would you do there? 1123146753 M * eyck for example, finish configuring vserver, 1123146760 M * sid3windr umm 1123146766 M * sid3windr what would you finish to configure? 1123146778 M * eyck which "vserver tst build" stopped doing, for some strange reason 1123146790 M * eyck leaving broken images laying around 1123147064 M * Bertl sounds more like a bug you want to report ... 1123147373 M * eyck why bother, let's move to yet another configuration style and kernel interface, and write everything from scratch, forgetting half the staff that was finally done OK in previous version 1123147416 M * Bertl eyck: hmm, you are free to do so, and you are even welcome to submit a patch which 'adds' whatever feature you have in mind ... 1123147495 M * eyck you wanted to say - "adds" whatever "feature" you have in mind. eeeh, bitter, am I, today. 1123147516 M * Bertl eyck: but please don't complain about 'removed' features which have never been there ... 1123147539 M * eyck you know they were there... 1123147547 M * eyck why do you keep 'quoting' ? 1123147581 M * Bertl because nothing was removed, show me the tool to enter a newstyle namespace based guest (which isn't running) 1123147600 M * Bertl and/or show me the change which 'removed' that feature 1123147621 M * Bertl (putting aside the fact that you are talking to the wrong person :) 1123147629 M * eyck well, you seem to be implying that this whole 'newstyle' broke everything 1123147643 M * Bertl no, it changed a lot of things ... 1123147659 M * Bertl for one example, we do not depend on the chroot anylonger 1123147662 M * eyck yeah...removed features... 1123147696 M * eyck why not? 1123147722 M * Bertl because the namespaces do a much better protection there .. including support for guest mounts and such 1123147766 M * eyck I think I don't understand what 'namespace' in this situation is. 1123147772 M * eyck time to wake up 1123147813 M * Bertl okay, I'm not using new-style now, I'm using 'legacy' for the old stuff, and everything else I refer to is new .. okay? 1123147839 M * Bertl legacy guests were based on using chroot() + barrier ... 1123147857 M * Bertl now guests (by default) use private namespaces 1123147884 M * Bertl this allows you (for example) to do a --bind mount or similar inside the guest without affecting the host 1123147917 M * Bertl it also enhances security, as there just is nothing above the 'chroot' 1123147939 M * Bertl (so it's really hard to escape :) 1123148003 M * eyck sounds nice, so that's why everything else was sacrificed. 1123148022 M * Bertl if you prefer to see it this way ... 1123148082 M * sid3windr "everything else" ... :) 1123148153 M * eyck isn't namespace interface available only in 2.6.x? 1123148348 M * Bertl yes 1123148463 M * eyck good, so now, that I'm on 2.4.x, and new-style config stops me from 'vserver sth enter'... 1123148503 M * eyck (not to mention proper guest builds...) 1123148702 M * Bertl don whine, change it ... or leave it ... 1123148723 M * sid3windr or use old-style config? ;) 1123148819 M * eyck OK, let's leave it broken. as you wish. 1123151481 J * frz ~frzzzz100@jaim.at 1123151496 M * frz hello 1123151612 M * Bertl welcome frz! 1123151703 M * eyck be affraid, they're ready to ignore your issues. 1123151761 M * Bertl yeah right, please feel free to ignore eyck's whining too :) 1123152149 M * frz *gg* 1123152494 M * Bertl frz: so as you can see, we are a friendly and funny channel ... can we do anything for you? 1123152530 M * DaCa-no :) 1123152565 M * frz bertl: yes - some kin of help would be fine - 1sec. just a tel. call 1123152576 M * frz : 1123152579 M * frz :) 1123153238 N * DaPhreak_ DaPhreak 1123154462 M * anonymousc hi bertl - are you aware of any issues with nscd (glibc 2.3.5) as a guest? Since upgrading my gentoo vservers (clients - not hosts), the nscd process is reluctant to close and times-out before being killed off. Should I be looking into the changelogs for an answer (the problem wasn't present with glibc 2.3.4) 1123154505 M * Bertl hmm, nscd is the name service cache daemon, right? 1123154545 M * Bertl what do you mean by 'times-out before being killed'? 1123154550 M * anonymousc yup - multithreaded process - can cache the passwd, group, hosts tables and other nss service requests 1123154621 M * anonymousc * Shutting down Name Service Cache Daemon... [ ok ] 1123154621 M * anonymousc A timeout occured while waiting for the vserver to finish and it was 1123154621 M * anonymousc killed by sending a SIGKILL signal. Please investigate the reasons 1123154621 M * anonymousc and/or increase the timeout in apps/vshelper/sync-timeout. 1123154631 M * eyck and is known for unreliable behaviour 1123154645 M * anonymousc yup - not my favourite daemon 1123154651 M * Bertl anonymousc: do you have the output of testme.sh at hand? 1123154686 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh (if possible, please upload to pastebin.com) 1123154726 M * anonymousc I have vservers on the same machine that are still at 2.3.4 and they don't exhibit the problem. 1123154756 M * Bertl good, it's just the easiest way for me to get a first impression of your setup :) 1123154766 M * anonymousc Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl 1123154766 M * anonymousc chcontext is working. 1123154766 M * anonymousc chbind is working. 1123154766 M * anonymousc Linux 2.6.12.3-vs2.0-rc8.1 i686/0.30.208/0.30.208 [Ea] (0) 1123154766 M * anonymousc VCI: 0002:0001 273 03000036 1123154766 M * anonymousc --- 1123154768 M * anonymousc [000]# succeeded. 1123154768 M * anonymousc [001]# succeeded. 1123154770 M * anonymousc [011]# succeeded. 1123154770 M * anonymousc [031]# succeeded. 1123154772 M * anonymousc [101]# succeeded. 1123154772 M * anonymousc [102]# succeeded. 1123154774 M * anonymousc [201]# succeeded. 1123154774 M * anonymousc [202]# succeeded. 1123154776 M * anonymousc grr - sorry about the multiple lines. 1123154822 M * Bertl hmm .. you sure that the nscd is the one still running? 1123155020 M * anonymousc personally i lean toward it being some issue with the vserver client init scripts - but I was just curious as to whether it could be related to the locking fixes that went into rc8.1. I have a 2.0rc9 system which procudes the same output with testme.sh. And now that you point it out - the nscd *is* already shutdown at that point - its complaining about whatever is remaining. Thanks for the pointer - I just assumed it was nscd since its a comp 1123155041 Q * albeiro Ping timeout: 480 seconds 1123155043 M * anonymousc ...st before the problem appeared. 1123155078 M * Bertl hmm, we had some reports about some minilogd remaining ... 1123155109 M * Bertl (which basically is a bug in the distro scripts of the guest) 1123155125 M * Bertl doesn't hurt, but is easily fixed too 1123155164 M * anonymousc I use a patched metalog - I removed the klogd component so it would work in a vserver. Could well be that since it isn't mentioned in the list of processes being shutdown. I'll take a look at the logger script... 1123155189 M * Bertl btw, syslog is virtualized now, so klogd should work fine 1123155203 M * Bertl (might need a flag/ccap though) 1123155422 M * anonymousc I share an ip address between host and the vserver - hence the vserver shutdown script won't delete that interface (RTNETLINK answers: Cannot assign requested address). Could that be related to this? 1123155450 M * Bertl yep, but looks like a config issue ... 1123155493 M * Bertl what do you have in your interface config? 1123155580 M * anonymousc I think I've mucked up my metalog patches - the ones with the nscd shutdown issue no longer have the klog portion excluded. So it tried to start the klog and userland portions. Is the discussion about the minilogd issue in the irc logs? 1123155650 M * Bertl I guess so ... 1123155652 J * albeiro ~albeiro@graffias.estrefa.pl 1123155678 M * anonymousc interface 0: dev=bond0, ip=, name=blah, prefix=24 1123155700 M * Bertl hmm, I thought you wanted to _share_ it with the host? 1123155718 M * Bertl in that case, you would want: 1123155720 M * anonymousc interface 1: dev=bond0, ip=192.168.xx.xx, name=blahp, prefix=24 1123155751 M * Bertl nodev, ip=w.x.y.z (no name, no prefix, no dev) 1123155752 M * anonymousc well - the private ip is shared with the host 1123155768 M * frz dear bertl - we are using now 2.4.30-vs1.2.10 with vroot (separate partitions) to have quotas inside vservers. at testcase for 2.6 (2.6.11.8-vs1.9.5) how to handle quotas inside vserver without this vroot loopdevice? 1123155811 M * Bertl frz: <- dear, 2.6.12.3-vs2.0-rc9 does already include the vroot device :) 1123155819 M * anonymousc mmm - very good point. ta for that 1123155826 M * Bertl anonymousc: yw! 1123155838 M * frz :) really - so i only have to load module and set it up 1123155853 M * Bertl yes, and no .. 1123155865 M * frz why no? 1123155887 M * Bertl the 2.6/vs2.0 does not support shared context quota (only shared disk limits and quota on separate partitions) yet 1123155923 M * Bertl (while the 2.4 quota patches also support shared quota) 1123155951 M * Bertl so in your case it will work (separate partitions) 1123155954 Q * monrad Quit: Leaving 1123155955 M * frz so we are using separate partitions - i guess this should work without vservers shared disk kernel stuff 1123155973 M * Bertl yes, it's supposed to do so ... 1123155981 M * frz :) fine - will test it out and continue migration to 2.6 after this 1123156001 M * frz thanks alot again for your work and help 1123156018 M * Bertl you're welcome! and you know we have a donations page :) 1123156032 M * frz yes i will forward to my boss :d 1123156040 M * Bertl excellent idea .... 1123156045 M * frz *gg* yes 1123156140 M * Bertl anonymousc: correcting the interface setup is supposed to fix your RTNETLINK issue ... 1123156243 M * anonymousc Bertl: indeed - I was just wondering whether vserver complaining about the timeout whilst waiting for the vserver to finish was related to the netlink message - I doubt it since I've got other (misconfigured :) vservers that are ok. Just looking for my metalog patch now... 1123156478 J * prae ~prae@gut75-1-81-57-27-189.fbx.proxad.net 1123156580 M * Bertl welcome prae! 1123156603 M * prae Bertl ! 1123156608 M * prae DaPhreak ! 1123156717 Q * albeiro Ping timeout: 481 seconds 1123156857 Q * cryo Remote host closed the connection 1123157186 J * cryo ~say@212.86.243.154 1123157205 J * albeiro ~albeiro@graffias.estrefa.pl 1123157231 M * Bertl wb say! albeiro! 1123157375 M * anonymousc a-hah - jumped into the vserver just before it complained about the timeout and found that another process (pglogd) was still running (even though the shutdown script has supposedly killed it off). Looking into it now. 1123157423 J * jsambrook ~jsambrook@aelfric.plus.com 1123157439 P * jsambrook 1123157621 M * Bertl anonymousc: you could file a feature request to savannah (util-vserver) for something like a ps auxwww tracing just before the timeout killing starts ... 1123157698 M * eyck but then, they'll ignore it, and tell you to stop whining... so there you go, it's your choice. 1123157758 M * Bertl eyck: I'm missing the funny smiley at the end of your line ... maybe you have a serious problem? 1123157795 M * anonymousc problem solved - bertl right as always - pglogd not happy and not being shutdown (or responding to normal kill signals...). Heh - no real need to get that feature - you can always just vserver enter and see whats still running. so simple. 1123158018 M * Bertl anonymousc: okay, so I can safely forget about the nscd issues .. right? 1123158048 M * anonymousc certainly - just me being too thick to check my facts... 1123158080 M * Bertl np, just making sure if that pops up in the future ... 1123158109 M * anonymousc yup - it was the glibc upgrade that had me looking in the wrong direction. 1123158125 M * DaPhreak prae ! ;) 1123159088 M * frz bye 1123159096 P * frz 1123159103 J * xf_ ~i@ppp244-55.lns2.adl2.internode.on.net 1123159122 M * Bertl welcome xf_! 1123159861 M * Bertl eyck: I'm sorry, let's try to improve stuff together! friends? 1123159879 M * DaPhreak Bertl: any complaints yet (about -rc9) ? 1123159895 M * Bertl DaPhreak: not that I know of, you? 1123159915 M * DaPhreak nope :) 1123159963 M * Bertl I assume there is some accounting bug for RSS (maybe caused by processes being killed when entering the context, e.g. by the OOM killer) 1123160000 M * Bertl but that's nothing I can verify/reproduce right now and it can probably be fixed once we know how to reproduce ... 1123160013 M * eyck Bertl: OK. 1123160077 M * Bertl eyck: what about a --force option, which does the same as the typical startup would do, but instead forks a bash inside? 1123160105 M * Bertl vserver enter --force 1123160115 M * Snow-Man That'd be kind of nice. 1123160116 M * eyck that would be cool 1123160136 M * Snow-Man I don't like this whole concept of a 'started' or 'not-started' vserver, it's silly and artificial. 1123160143 M * Bertl I think we can do that easily by just abusing the 'start' helper 1123160174 M * Bertl Snow-Man: well, yeah, but there are good reasons for differenciating between them ... 1123160200 M * Bertl there is a lot of stuff which happens on startup nowadays ... 1123160222 M * Bertl and it also requires to do some things at shutdown (which should happen paired to startups) 1123160238 M * Snow-Man Bertl: That actually sounds like a bad thing. :) 1123160261 M * Bertl well, just think about adding/removing interfaces/aliases 1123160277 M * Snow-Man vservers shouldn't be doing that. Mine certainly don't. 1123160297 M * Bertl once ngnet is available, they will have to, no? 1123160304 M * eyck hmm, yes, that's another thing that goes wrong when you move to new-better-style, 1123160308 M * eyck config, 1123160319 M * Snow-Man Bertl: That would be unfortunate. 1123160329 M * eyck it happily starts guests for which interface/alias does not exist 1123160339 M * Snow-Man I don't want vserver start/stop messing around with my interfaces/aliases. 1123160368 M * Bertl Snow-Man: well, but a lot of folks actually do ... 1123160374 M * Snow-Man Bertl: So? 1123160393 M * Snow-Man Bertl: You could claim alot of people would like the kernel to run a web server. 1123160404 M * Snow-Man Doesn't make it a good idea. 1123160413 M * Bertl hmm, we are not doing Snow-Man vserver, we are doing linux-vserver ... and there is tux! :) 1123160417 M * eyck Snow-Man: you just want an option '--dont-touch-my-private-parts' 1123160425 M * eyck and maybe '--please' 1123160430 M * Snow-Man Bertl: tux, which was later removed, no? 1123160432 M * eyck to vserver start/stop 1123160444 M * eyck and an ability to make it default maybe? 1123160444 M * Bertl it's sufficient to use nodev in every interface config 1123160447 M * Snow-Man eyck: I believe in a seperation of duties. 1123160461 M * Snow-Man Bertl: I do use nodev. :) 1123160469 M * Bertl in this case the tools will not touch the interfaces at all 1123160491 M * Snow-Man Bertl: It'd suck if ngnet broke using nodev, which is what it sounded like you were implying would happen. 1123160503 M * Bertl IMHO the 'enter' functionality should not exist at all 1123160510 M * Snow-Man erm. 1123160529 M * Snow-Man What possible sense does that make? 1123160534 M * Bertl you can not 'enter' any physical server .. so why do it for virtual servers? 1123160542 M * eyck You can 1123160546 M * Snow-Man Because they're *virtual*? 1123160553 M * Bertl eyck: how? 1123160556 M * eyck you walk to the physical server... 1123160572 M * Bertl eyck: and? 1123160582 M * eyck attach keyboard and monitor, 1123160592 M * Bertl eyck: to what? 1123160593 M * Snow-Man enter is one of those very useful features of vservers. 1123160612 M * Snow-Man It's one of those things that actually adds a benefit to using vservers over seperate machines. 1123160625 M * Bertl eyck: a console device ... so you could use something like that on guests too ... 1123160625 M * Snow-Man Bertl: You'd like to drop context 1 too then? 1123160643 M * eyck Bertl: yes, but without such device, vserver sth enter is the next best thing. 1123160654 M * Bertl eyck: or use ssh, if you do not want to 'walk' there 1123160670 M * eyck Bertl: well, I've got vserver that has no ssh, 1123160682 M * eyck and are not supposed to have it, 1123160703 M * Snow-Man Not to mention the utter stupidity of having to get the networking stack involved. 1123160708 M * Bertl eyck: well, then they either need a terminal/tty or have to live without access to the outside 1123160735 M * Snow-Man Good grief, can we quit with the stupidity, please? 1123160741 M * Bertl I'm just pointing out that the 'enter' is in no way natural to a guest 1123160741 M * eyck Bertl: I think you need to broaden your horizons a little, 1123160747 M * eyck Bertl: get some sleep or sth 1123160764 M * Snow-Man Bertl: It's not *for* the guest. 1123160771 M * Snow-Man It's for the admin on the host. 1123160777 M * Bertl the 'enter' is a compromise, which is done to get a nice feature ... 1123160790 M * eyck well, 1123160800 M * Bertl the problem here is, that with this nice feature all kind of issues arise 1123160802 M * eyck the whole 'vserver' idea is a compromise, which is done to get nice features. 1123160809 M * Snow-Man The start/stop crap is a compromise, put there just to run the various init scripts/. 1123160810 M * eyck what kind of issues? 1123160854 M * Bertl okay, let's look at the current 'features' which depend/interact with a startup: 1123160869 M * Bertl - private namespaces (bound to a process) 1123160877 M * Bertl - per context mounts 1123160890 M * Bertl - limits (u and r ones) 1123160898 M * Snow-Man vservers would be much *less* useful as vmware-like instances. 1123160900 M * Bertl - cpu scheduler (token bucket) 1123160918 M * Bertl - network interfaces/aliases/ips 1123160949 M * Bertl so, doing an 'enter' is supposed to do what of the above? 1123160971 M * Snow-Man You've got things mixed up there, to some extent. 1123160971 M * eyck - private namespace and network. 1123160996 M * Snow-Man There's two different issues here, really, contexts and processes. 1123161000 M * Bertl well, after startup (i.e. on a running guest) all those features are reflected and applied ... 1123161021 M * Snow-Man contexts do need to be configured and set up appropriately. 1123161023 M * Bertl you enter the guest and see the same stuff the processes inside get 1123161043 M * Snow-Man processes, however, can just change their context. 1123161069 M * Snow-Man The only real question is when is a context set up. 1123161086 M * Snow-Man My feeling is that it'd be set up the first time a process is asks for that context. 1123161110 M * Bertl okay, and when is it going to be removed? 1123161119 M * Bertl s/removed/shutdown/ 1123161134 M * Snow-Man If you can actually do it when a process first asks for the context, then when the last process leaves the context. 1123161148 M * Snow-Man You've got to set up some policies in the kernel for the contexts, really. 1123161158 M * Snow-Man That's the 'startup', setting those policies. 1123161193 M * Bertl there is a context helper which will be called on startup and shutdown of a context 1123161212 M * Bertl and IMHO no other policy in the kernel is required 1123161248 M * Snow-Man hmmm, not sure I like that. 1123161279 M * Bertl what policy do you want inside the kernel? 1123161283 M * Snow-Man I'm not suggesting that policy be coded directly into the kernel, just that the kernel supports having policies set from userspace, and remembers what those policies are. 1123161313 M * Snow-Man And there really should be system-wide policies and per-vserver policies. 1123161337 M * Snow-Man It'd be neat to be able to run a process in a vserver with just a default policy. 1123161366 M * Snow-Man Where the vserver is created on the fly and lasts only for the duration of that process. 1123161368 M * Bertl what is that policy supposed to do? 1123161395 M * Bertl I mean, there is nothing like a vserver guest without processes 1123161399 M * Snow-Man The default policy? It's just the defaults if there aren't per-vserver overrides. 1123161451 M * Snow-Man Bertl: My thinking would actually be quite the opposite. 1123161472 M * Snow-Man Since I'd seperate contexts from processes. 1123161501 M * Snow-Man And allow for a context to be 'configured', or have a policy spelled out against it, even if there are no processes in that context currently. 1123161504 M * Bertl well, but that's not how linux-vserver is designed 1123161517 A * Snow-Man shrugs. 1123161535 M * Snow-Man I'm not really talking about linux-vserver. 1123161546 M * Snow-Man I'm talking about what I would picture as a good solution. 1123161546 M * Bertl ah, well, we are :) 1123161575 M * Snow-Man linux-vserver is a decent solution and does alot of what I need but it has some annoying quirks that a redesign (along the lines of what I described above) would resolve. 1123161597 M * Bertl how? 1123161602 M * Bertl (in what way) 1123161636 M * Snow-Man Bertl: You could set up vservers and then enter them without actually 'start'ing them, for one. 1123161653 M * Snow-Man Bertl: vservers wouldn't have to have processes in them all the time keeping them 'alive' for another. 1123161655 M * eyck yeah baby, 1123161669 M * eyck well 1123161673 M * eyck that makes no sense 1123161678 M * Snow-Man Sure it does. 1123161688 M * eyck why do you need guest to be alive, where there are no processess inside? 1123161699 M * Snow-Man I want to have a certain process that's only run every so often to run in its own vserver. 1123161712 M * Snow-Man For security reasons. 1123161714 M * eyck hmm, you want external cron? 1123161726 M * Snow-Man To do that now I'd have to actually have a process in the vserver keeping it alive. 1123161736 M * Snow-Man Let me give you another example. 1123161741 M * Snow-Man I've got postgresql in a vserver, right? 1123161747 M * Snow-Man That's the *only* thing in that vserver. 1123161753 M * eyck ok. 1123161758 M * Snow-Man Now, what happens when I issue a 'restart' command to postgres from outside? 1123161774 M * Snow-Man And I goofed on the postgres configure? 1123161778 M * Snow-Man And it doesn't restart? 1123161780 M * eyck it re-execs itself? 1123161803 M * Snow-Man eyck: It shuts down, attempts to start, fails, and then the restart command finishes and *poof*, no more vserver. 1123161814 M * Snow-Man Which makes it much more difficult to examine the situation. 1123161822 M * Hollow morning 1123161826 M * Snow-Man And I can't start the vserver back up, because postgres is misconfigured and won't run for more than a second. 1123161829 M * Bertl Snow-Man: what about having a simple init, like minit inside? 1123161832 M * eyck hmm, take a look at 'runit' and 'svscan' 1123161850 M * Snow-Man Bertl: I don't like it because there's no point to it other than to just keep the vserver alive, which seems awfully silly to me. 1123161862 M * eyck Snow-Man: well, you vserver postgres enter, fix the config and voile'a :) 1123161866 M * xf_ why vserver, and not a standard chroot environment? 1123161874 M * Snow-Man eyck: Can't enter a vserver that hasn't got any processes... 1123161880 M * Snow-Man eyck: I'd need that --force thing. :) 1123161892 M * eyck Snow-Man: you just need to avoid those new-style silllyness 1123161894 M * Snow-Man xf_: I don't want postgres to see other processes? 1123161919 M * Snow-Man I also don't want it to have access to other interfaces? 1123161920 M * Snow-Man etc. 1123161929 M * Bertl Snow-Man: why not just use the basic elements (vcontext, vnamespace, ...) for your once in a time program? 1123161953 M * Bertl (or simply on your postgresql startup) 1123161956 M * eyck because 'vserver sth enter/exec' makes more sense. 1123161972 M * Snow-Man Bertl: Possible, but I'd rather just have to use them once to set the policy and then just have the one chcontext to actually run it. 1123161987 M * Snow-Man Less mess, imv. :) 1123162003 M * Snow-Man Anyway, gotta get back to installing Debian on my new box, talk at ya'll later. :) 1123162106 M * Bertl well, I guess it would not be too hard to let vserver contexts hang around even without processes, but it's kind of moot to have process isolation without processes ... 1123162121 M * eyck agree 1123162151 M * eyck and it's kind of moot having vservers you can't enter :( 1123162227 M * Bertl I can agree if you add 'running' before 'vservers' :) 1123162275 M * Bertl but anyway, I guess something which does the following: 1123162303 M * Bertl - startup the guest as usual, but don't run services inside, spawn a bash instead 1123162315 M * Bertl - and on exit, shutdown the guest (as usual) 1123162333 M * Bertl should suffice for an 'enter' on a stopped guest? 1123163474 M * eyck yes. 1123163500 M * eyck although mounting stuff wouldn't be required as such 1123163552 M * Bertl but I guess it would not hurt either ... 1123163688 M * eyck whichever is cleaner 1123164246 M * Hollow Bertl: am i right that the default reboot syscall will definitly halt/reboot the machine, no matter what happens..? 1123164284 M * Bertl you mean on the host? 1123164287 M * Hollow yup 1123164300 M * Bertl well, if the permissions and magic cookies are there, yes 1123164314 M * Hollow so, the vshelper should act the same, no? 1123164329 M * Hollow if it is kalled, kill the context, no matter what's up 1123164332 M * Hollow *called 1123164359 M * Bertl hmm, yes ... 1123164378 M * Hollow and afterwards bring down the configuration/interfacces whatever 1123164419 M * Bertl in userspace, yes 1123164568 M * Bertl Hollow: any point you want to make? 1123164612 M * Hollow Bertl: no, i just wanted to confirm that i got the procedure right ;) 1123164635 M * Bertl ah, okay ... writing on some 'reboot' deamon? 1123164658 M * Hollow well, for the new tools anyway, but atm just thinking how to fix the current utils 1123164709 M * Bertl i.c. digging into util-vserver code? well, maybe you could comment on the planned --force extension to the enter later? 1123164738 M * Hollow well, i'm already digged in, but it's really really difficult.. if you change X you also have to change A-z ;) 1123164900 M * Hollow the problem is, with plain init style, it you call vserver ... stop, it sends SIGINT to init, which in turn shuts down all processes, but not itself, which leads to a sync timeout 1123164913 M * Hollow so one could say, call halt and let vshelper kil the context 1123164937 M * Hollow well, if you kill init with SIGKILL using vshelper the following vserver ... stop fails to bring down the config because no vsevrer is running anymore 1123165152 M * Bertl somehow I have the feeling that the entire start/stop/restart/shutdown stuff is borked (in userspace) 1123165160 A * Hollow nods 1123165224 M * Hollow it's also problematic if you call halt inside the context... it'll send SIGINT to init then it calls vservr ... stop which in turn sends SIGINT and waits for init to finish which leads again to the timeout 1123165251 M * Bertl which is also wrong ... IMHO 1123165259 M * Hollow yup 1123165333 M * Hollow we#D need separation of stop and halt 1123165365 Q * cryo Remote host closed the connection 1123165409 M * Bertl Hollow: let me write up a 'simple' howto for userspace behaviour/kernel interaction regarding startup/shutdown ... 1123165419 M * Hollow would be great 1123165480 M * Hollow i'm just starting to think about the new tools, so i'm open to all suggestions ;) 1123165490 M * eyck Hollow: you're going to write new tools? 1123165505 M * Hollow well, i'd appreciate some help, but yeah ;) 1123165534 M * Hollow eyck: libvserver already made the beginning of these new tools 1123165611 M * Hollow i'd like to keep the idea of low-level tools (vcontext, vflags, vnet, etc) + a vserver management script (like the current vserver) 1123165767 M * eyck ok 1123165786 M * Hollow maybe we should add a new tools wishlist to the wiki ;) 1123165823 M * eyck I've got one - "don't break older stuff" 1123165868 M * Hollow well, tbh no legacy code will ever be included in these tools 1123165903 M * Hollow you can reuse your guests, but probably not the config 1123165929 M * eyck why not? 1123165942 M * eyck parsing config files in C is too hard or sth? 1123165979 M * Bertl no, the legacy config is just insufficient to describe a guest properly 1123165997 M * Hollow no, maybe one could write a converter for the config, but i don't think that the current config layout (etc/vservers) is very well designed 1123166003 M * Bertl and it's easier to 'convert' the sometimes cryptic legacy config to something newer 1123166117 M * eyck insufficient? what exactly is missing? 1123166135 N * kevinp|gone kevinp 1123166136 M * eyck well, here I agree, all those symlinks and directories, what a mess, 1123166168 M * Bertl eyck: for example the limits ... or the various networking aspects ... 1123166186 M * eyck and cool things like you need to create fil called "dev" with "eth0" inside it, AND file called "eth0" 1123166210 M * kevinp just catching up, but on the postgres problem, if it's a config issue, why couldn't he just fix the config file from the host (since the host can see the entire file system) and then start the vserver? 1123166216 M * eyck Bertl: ok, so no limits == no limits, what insufficient about that? 1123166217 M * Bertl eyck: you don't create files called 'eth0' right now ... 1123166221 M * Hollow all these 1000+ files horrible imo 1123166252 M * eyck no? 1123166308 M * Bertl kevinp: yes, should work fine ... 1123166355 M * kevinp Hollow: I'm currently working on a converter script for migrating old to new configs, but it relies on a skel config tree that the script populates based off the old config 1123166376 M * Hollow Bertl: apropos symlinking and xid<->name resolution... with the CONTEXT field in vhi it should be possible to recursivly lookup the name, no? 1123166392 M * kevinp It seems to work fine though, is there a better way to do it? 1123166418 M * Hollow kevinp: well, we're talking about tools here which doesn't exist yet, so the (new-)new-config can't be converted yet ;) 1123166422 M * Bertl Hollow: you mean, you could 'walk' all contexts looking for the name, right? 1123166433 M * Hollow yup 1123166461 M * Bertl yes, you can do that ... it's not very efficient, but it should work 1123166474 J * cryo ~say@212.86.243.154 1123166490 M * kevinp ahh 1123166506 M * Hollow well, question is what's less efficient... 10 symlinks or 100 syscalls ;) 1123166524 M * Bertl 100 syscall, definitely :) 1123166527 M * Hollow k.. ;) 1123166528 M * kevinp so you would need to include functionality that would be able to convert both of the now older configs 1123166543 M * Bertl but, I honestly do not see the need for this kind of reversion ... 1123166551 Q * cryo Remote host closed the connection 1123166565 M * Hollow well, we could still keep the conversion in userspace 1123166566 M * Bertl usually I'd suspect you have some /etc/vservers/* 1123166578 M * Bertl whatever kind of config it might be ... 1123166594 M * Bertl so you will do the name -> xid via that config file, no? 1123166619 M * Hollow if you completely disregard dynmaic contexts yup 1123166621 M * Bertl OTOH, the xid -> name resolution can be done by getting the CONTEXT field ... 1123166637 M * Bertl Hollow: dynamic contexts for guests are evil! 1123166637 M * Hollow yeah, but not the name -> xid resolution 1123166646 M * Hollow Bertl: i know, but they're still possible 1123166655 M * Bertl we can change that easily :) 1123166674 M * Bertl okay, I have to leave now .. will be back later ... 1123166676 M * Hollow at least make it a Kconfig.. 1123166679 M * Hollow cya 1123166686 N * Bertl Bertl_oO 1123166758 M * kevinp Is there a command like vserver-stat that shows all the vdlimits? 1123167017 M * Hollow iirc no 1123167041 J * cryo ~say@212.86.243.154 1123168246 Q * cryo Remote host closed the connection 1123168612 M * kevinp is anyone running the patched 208 utils that can confirm if it fixed the problem where once you shutdown the vserver the IP address remains assigned? 1123168943 J * cryo ~say@212.86.243.154 1123169659 Q * lilo Read error: Connection reset by peer 1123170263 J * lilo ~lilo@lilo.usercloak.oftc.net 1123170592 J * stefani ~stefani@superquan.apl.washington.edu 1123170708 J * monrad ~monrad@213083190130.sonofon.dk 1123171221 M * eyck hmm 1123171222 M * eyck #14034 Vserver shutdown does not remove IP address 1123171239 M * eyck why would you want 'vserver shutdown' to remove IP address? 1123171247 M * eyck what if something else is using this address? 1123171560 M * kevinp each vserver has it's own ip address 1123171668 J * zimbo ~zimbo@callisto.dom.bonis.de 1123171995 Q * zimb0 Ping timeout: 480 seconds 1123172345 M * eyck oh really? are you sure? would you bet your life on it? 1123172462 M * kevinp let me be more specific, all of my vservers have their own ip address 1123172496 M * eyck good for you, 1123172519 M * kevinp which, if it is setup that way, that it creates the ip address, it should know that and also remove it 1123172568 M * eyck that's why vserver shouldn't create IP addressess in the first place :) 1123172631 M * kevinp So you are saying that this is a deliberate change in the way it works? AFAIK, it has always worked correctly in previous versions. 1123172643 M * kevinp s/correctly/this way/ 1123172757 M * eyck nope, I'm all for backwards compatibility, 1123172777 M * eyck i'm just saying that it's not that good of idea to automatically spring interfaces to life 1123172815 M * kevinp I can understand that as well 1123173154 M * kevinp although at the same, the encapsulation within the start and stop is very nice for my situation 1123173164 M * kevinp s/same/same time/ 1123173322 M * eyck yes, but it would be nice for this behaviour to be optional, 1123176062 M * sid3windr heh, why would you want to keep them bound to the main server? 1123176620 Q * prae Quit: Execute Order 69 ! 1123179078 Q * lilo Quit: Lost terminal 1123179105 J * lilo ~lilo@lilo.usercloak.oftc.net 1123179524 J * prae ~benjamin@sherpadown.net 1123180304 N * Bertl_oO Bertl 1123180318 M * Bertl evening folks! 1123180350 M * kevinp howdy 1123180384 M * Bertl hey kevinp! regarding the vdlimit: no there is none ... 1123180413 M * Bertl there is not even a good kernel interface to get this information 1123180448 M * kevinp hmm, simply looping through running contexts? 1123180465 M * Bertl and through all filesystems :) 1123180522 M * kevinp So what does vserver-stat use to look for running vservers? 1123180569 M * Bertl probably the processes and context information in proc 1123180615 M * kevinp so that gives a list of running contexts, that could then be queried for vlimits 1123180654 M * kevinp interesting, I was just in a vserver (through enter) and shut down the vserver from another session, and it kicked me off the host 1123180663 M * kevinp as well as the vserver 1123180673 M * Bertl are you talking about limits, or disk (as in vdlimit) limits? 1123180690 M * kevinp yeah vdlimits 1123180702 M * kevinp disk limits still 1123180711 M * Bertl so vdlimits are two dimensional 1123180730 M * Bertl (x,y) x = context id, y = superblock 1123180772 M * kevinp the shutdown thing also reminds me that it would be good to send a message out to all users logged in on a vserver that the "server" is shutting down when someone executes a stop on the host 1123180799 M * kevinp and have a 10 second delay on the shutdown or something 1123180829 M * kevinp Oh, I see, you would need the superblock to make the query 1123180852 M * kevinp hence the loop through the file system 1123180864 M * kevinp or at least the config files 1123180868 M * Bertl well, I guess the shutdown and similar could be greatly improved in the future 1123180936 M * kevinp I guess the scripts directory that you can include in the new configs could facilitate sending the message, although I don't know if they run within the vserver guest or on the host 1123181168 M * kevinp Bertl: what do you think on the ip address creation and removal topic? 1123181345 M * Bertl I think the entire startup/shutdown process should be redesigned 1123181368 M * Bertl unfortunately enrico seems to either have no time, or not to be interested in talking this through ... 1123181447 M * Bertl basically we have support for hooks on startup/shutdown, and probably the best thing would be to have some kind of 'init' running on the host ,which either has a child (the init of the guest) inside the context, or 'just' waits for the context to end ... 1123181470 M * Bertl this way all the different start/stop actions could be synchronized and coordiated ... 1123181506 M * Bertl of course, this is only 'my' kernel perspective and a lot of other possibilites come to my mind ... 1123181577 M * kevinp there are definitely some synchronization issues on shutdown, the host doesn't wait for all of the vservers to shutdown before rebooting is the first thing that comes to mind 1123181590 M * Bertl kevinp: btw, thanks for submitting the bugreports/feature requests 1123181607 M * kevinp no prob, hope I have annoyed enrico or anyone 1123181615 M * kevinp s/have/haven't/ 1123181618 M * Bertl lol 1123181633 M * kevinp oops! :) 1123181641 M * Bertl classical freudian slip :) 1123181648 M * kevinp definitely! 1123182722 M * Bertl Hollow: you around? 1123182757 M * Hollow yup 1123182772 M * Hollow seems like we have to skip our meeting tomorrow 1123182805 M * Bertl ah, why's that? 1123182811 M * Hollow -> query *g* 1123182824 M * Bertl *grmpf* :) 1123182832 M * Hollow coordination problems :P 1123182848 M * Bertl k, well, so we'll meet at another time ... 1123182882 M * Hollow yeah, but i'd say in the next 2-3 weeks ;) 1123183060 M * Hollow Bertl: you know anything interessting in/near by salzburg to do within a timeframe of 2-3 hours? 1123183321 M * Bertl hmm .. except for sightseeing, not really :) 1123183491 M * Bertl http://www.cityreview.at/salzburg/salzburg/sehenswuerdigkeiten/ 1123183612 M * Bertl okay, folks! I'm off to bed now .. really tired today ... 1123183623 M * Bertl so, cya later/tomorrow then ... 1123183635 N * Bertl Bertl_zZ 1123183699 M * micah seeya Bertl_zZ 1123186279 J * jonsmel_zZ ~jscottorn@209.33.206.3 1123186308 M * jonsmel_zZ Hi all, anyone know if VS2.0 has been released yet 1123186316 N * jonsmel_zZ jonsmel 1123188110 M * micah jonsmel: it has not yet 1123188938 Q * lilo Remote host closed the connection 1123188953 J * lilo ~lilo@lilo.usercloak.oftc.net 1123191697 Q * jonsmel Ping timeout: 480 seconds 1123193990 J * Aiken ~james@tooax6-211.dialup.optusnet.com.au 1123195027 Q * Doener` Quit: Leaving