1227052934 Q * ntrs__ Ping timeout: 480 seconds 1227053894 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1227054107 Q * bonbons Quit: Leaving 1227054627 J * pisco_ ~pisco@86.59.118.153 1227054636 Q * pisco Ping timeout: 480 seconds 1227055312 N * Bertl_oO Bertl_zZ 1227055337 M * Bertl_zZ night everyone! 1227055794 Q * dkg Ping timeout: 480 seconds 1227057112 Q * dowdle Remote host closed the connection 1227058107 Q * FireEgl Ping timeout: 480 seconds 1227058653 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1227058752 Q * nenolod Read error: Connection reset by peer 1227058784 J * nenolod ~nenolod@ip70-189-74-62.ok.ok.cox.net 1227059317 Q * geb Remote host closed the connection 1227059526 Q * FireEgl Quit: Leaving... 1227059794 J * dallas ~dallas@sf.idallas.com 1227059936 Q * dallas 1227064062 J * FireEgl ~FireEgl@173-16-9-10.client.mchsi.com 1227064162 N * quinq qzqy 1227065005 Q * FireEgl Quit: Leaving... 1227067299 Q * sardyno Ping timeout: 480 seconds 1227069476 Q * derjohn_mob Ping timeout: 480 seconds 1227069571 Q * eyck Ping timeout: 480 seconds 1227070204 Q * hparker Remote host closed the connection 1227070384 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1227073023 Q * hparker Remote host closed the connection 1227073149 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1227073665 J * eyck BNCA88kx@nat06.nowanet.pl 1227075435 Q * nou Ping timeout: 480 seconds 1227075438 J * nou Chaton@causse.larzac.fr.eu.org 1227075883 J * sharkjaw ~gab@149-67-194.231210.adsl.tele2.no 1227076272 J * ktwilight_ ~ktwilight@181.123-66-87.adsl-dyn.isp.belgacom.be 1227076548 Q * ktwilight Ping timeout: 480 seconds 1227077605 J * derjohn_mob ~aj@e180222109.adsl.alicedsl.de 1227078826 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1227079709 J * davidkarban ~david@193.85.217.71 1227079993 Q * derjohn_mob Ping timeout: 480 seconds 1227080299 Q * larsivi Ping timeout: 480 seconds 1227080311 Q * hparker Remote host closed the connection 1227080432 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1227080857 J * ntrs ~ntrs@77.29.15.222 1227080948 J * ssd ~gernot@83-64-146-228.klosterneuburg.xdsl-line.inode.at 1227082204 Q * hparker Remote host closed the connection 1227082316 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1227082588 J * ntrs_ ~ntrs@77.29.13.204 1227082606 Q * esa Ping timeout: 480 seconds 1227082729 Q * mtg Quit: Verlassend 1227083017 Q * ntrs Ping timeout: 480 seconds 1227083439 J * esa bip@62.123.8.187 1227084128 J * larsivi ~larsivi@85.221.53.194 1227084954 Q * ntrs_ Ping timeout: 480 seconds 1227085311 Q * esa Ping timeout: 480 seconds 1227085696 N * Bertl_zZ Bertl 1227085706 M * Bertl morning folks! 1227085921 N * pmenier_off pmenier 1227086352 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1227086977 Q * hparker Remote host closed the connection 1227087053 M * PowerKe Bertl, do you already have something planned for 13-16 August 2009? http://har2009.org :) 1227087093 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fe60:79d4 1227087258 M * Bertl PowerKe: no, I don't think I have ... 1227087294 M * PowerKe It's the follow-up of What The Hack in 2005 1227087306 M * Bertl yep, I got that from the web page ... 1227087328 J * ktwilight__ ~ktwilight@101.73-66-87.adsl-dyn.isp.belgacom.be 1227087334 M * PowerKe Just wondering if you were maybe giving a new presentation 1227087338 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1227087362 M * Bertl PowerKe: I'm pretty sure we can arrange something :) 1227087396 M * Bertl (if there is interest, bla bla ...) 1227087448 J * kir ~kir@swsoft-msk-nat.sw.ru 1227087449 M * PowerKe It was the first time I heard of it in 2005, so at least I thought it was interesting then 1227087621 Q * ktwilight_ Ping timeout: 480 seconds 1227087862 J * mtg ~mtg@vollkornmail.dbk-nb.de 1227088034 J * chI6iT41 ~chigital@services.mivitec.net 1227088491 M * ghislainocfs2 morning ! 1227088648 M * pflanze Bertl: I've written a start of an importer script to get the patches into Git; it's looking at the linux-* paths in the patch and uses them as source and target tags 1227088674 M * pflanze This doesn't work out for most patch series, though, since with those you don't change the target dir name :) 1227088760 M * pflanze (i.e. it would try to create existing tags) 1227088773 M * Bertl hmm? 1227088805 M * pflanze let me get an example. 1227088858 M * pflanze ah, also, some of the patches have a source dir name which is not generated by any of the other patches, 1227088874 M * pflanze for example Experimental/delta-tag-feat01.diff is based on 2.6.22.2-vs2.3.0.17.1, 1227088912 M * pflanze but there is no patch creating that dir; there is one for 2.6.22.1 iirc, so of course you didn't release a new patch for new upstream. 1227088926 M * pflanze but that's less of a problem, still something I'll have to find a solution for. 1227088983 M * Bertl not really a problem, i.e. if you tell me what is missing, I can provide that, I guess 1227089002 M * pflanze example: 1227089010 M * pflanze bertest-import: importing patch 'Experimental/del-vs2.0.1-pre3/23_limit.diff'... 1227089010 M * pflanze fatal: tag 'v2.6.14-vs2.0.1-pre3' already exists 1227089010 M * pflanze bertest-import: importing patch 'Experimental/del-vs2.0.1-pre3/30_split.diff'... 1227089010 M * pflanze fatal: tag 'v2.6.14-vs2.0.1-pre3' already exists 1227089010 M * pflanze bertest-import: importing patch 'Experimental/del-vs2.0.1-pre3/12_netiso.diff'... 1227089012 M * pflanze fatal: tag 'v2.6.14-vs2.0.1-pre3' already exists 1227089027 M * pflanze and so on. They all use the same target dir name. 1227089047 M * pflanze Which may make sense in some way -- I just have to find out how to deal with it. 1227089142 M * Bertl yes, that's because those a split patches 1227089147 M * arekm huhu, will vserver project use git now? 1227089149 M * Bertl i.e. you have to handle them differently 1227089170 M * pflanze arekm: it's just an experiment 1227089174 M * Bertl pflanze is giving it a try :) 1227089189 M * Bertl pflanze: the split patches all add up to a complete release patch 1227089201 M * Bertl but they are applied in parallel 1227089212 M * arekm pflanze: too bad that "just" ;-) 1227089220 M * Bertl pflanze: i.e. they are not invremental changes ... 1227089220 M * pflanze The arrangement of these patches into definite ordered series is what's expected in a system like Git (commits with clear parents). 1227089232 M * pflanze While Darcs finds out the possible orderings by itself. 1227089250 M * pflanze Now I wonder whether I should try to write code to find out about the orderings (huh), 1227089267 M * Bertl they should not have any order constraints (the split patches, that is) 1227089269 M * pflanze or in how far the ordering should be left unspecified (difficult to deal with in Git then). 1227089290 M * pflanze yes, I see 1227089291 M * Bertl pflanze: it's like this: 1227089328 M * Bertl - 2.6.16-vs2.0.1 (ficctional base) 1227089344 M * Bertl - delta-01 - delta-10 ontop of that 1227089356 M * Bertl - 2.6.17-vs2.0.2 (new release) 1227089376 M * Bertl - 2.6.17-vs2.0.2 split patches (all together result in vs2.0.2 patch) 1227089396 M * pflanze The split patches are again the delta-01 - 10 right? 1227089396 M * Bertl the deltas before do not necessarily relate to the split patches 1227089417 M * pflanze adapted to the new upstream, that is 1227089418 M * Bertl no, they are the complete patch against mainline 1227089436 M * Bertl so 2.6.17 + split -> 2.6.17-vs2.0.2 1227089464 M * Bertl while 2.6.16-vs2.0.1 + delta-2.6.16->2.6.17 + deltas -> 2.6.17-vs2.0.2 too 1227089491 M * pflanze ah 1227089545 M * Bertl the split patches are broken down in (mostly) independant changes on different areas 1227089565 M * Bertl while the deltas contain progress (i.e. changes to existing code) 1227089633 J * dna ~dna@52-200-103-86.dynamic.dsl.tng.de 1227090135 J * ghislainocfs21 ~Ghislain@adsl2.aqueos.com 1227090461 Q * ghislainocfs2 Ping timeout: 480 seconds 1227090666 M * pflanze I'll pursue it further, rather mostly next week since I'm rather busy this week. 1227090677 M * Bertl k, np 1227090694 M * pflanze I've just noticed that the vserver guest on my test machine binds to 127.0.0.1 and this is actually reachable from the host. 1227090697 M * Bertl I think you only want to import the deltas and the patches though 1227090712 M * pflanze Well, I thought I wanted to import everything, 1227090720 M * pflanze then see how all of the patches match up. 1227090729 M * pflanze I'll only create commit histories of part of them though. 1227090737 M * Bertl maybe the splits in separate patches 1227090746 M * pflanze yes, probably in separate branches. 1227090755 M * Bertl connect to 127.0.0.1 is usually a misconfiguration 1227090755 M * pflanze dunno yet for sure. 1227090793 M * Bertl i.e. guests on older kernels are not supposed to have 127.0.0.1 at all, and newer kenels (vs2.3) have to have the isolation configured 1227090827 M * pflanze yes, I've explicitely said no to the automatic localhost, so as to (in my hope) be able to just reuse my fake localhost + public ip settings 1227090883 M * pflanze CONFIG_VSERVER_AUTO_SINGLE=y #because daniel told me yesterday to use that 1227090912 M * Bertl yes, that makes sense, with a single guest IP you should not have/see 127.0.0.1 1227090938 M * pflanze VSERVER_AUTO_LBACK=b 1227090941 M * pflanze ehr =n 1227090997 M * pflanze My guests all have two ip's, a fake localhost one as a first ip (10.0.x.x), and a "public" one (which is supposed to be seen from other vservers, and through port forwardings) in the 192.168.x.x range. 1227091020 M * pflanze What I'm seeing is that my guest binds to both of those but one service additionally also to 127.0.0.1 1227091058 M * pflanze tcp * 22 root 9203 /usr/sbin/sshd 1227091058 M * pflanze tcp 10.0.1.1 631 gdm 9103 /usr/sbin/cupsd 1227091058 M * pflanze tcp 10.0.1.1 2207 hplip 9124 python /usr/sbin/hpssd 1227091058 M * pflanze tcp 127.0.0.1 2208 root 9121 /usr/sbin/hpiod 1227091058 M * pflanze udp * 517 root 9180 /usr/sbin/inetd 1227091098 M * Bertl question is, do you want to keep your setup for longer, or do you want to get it right? 1227091107 M * pflanze ifconfig from within the guest only reports lo without ip, lo:1loc with 10.0.1.1, lo:1pub with 192.168.1.1 1227091125 M * Bertl in the former case, you probably want to set the lback to your 10.x address and enable reamping 1227091151 M * Bertl in the latter case, I'd get rid of the 10.x addresses and use 127.0.0.1 with full isolation 1227091173 M * pflanze I think for now I'd like to keep my setup to avoid work right now (and in case the new patches aren't stable). 1227091176 M * Bertl (you can probably mix both approaches for the time being) 1227091200 M * Bertl i.e. with 2 ip, you have no advantage in the single ip special casing anyway 1227091210 J * tramjoe_merin ~tramjoe@193.41.238.151 1227091230 M * Bertl so enable the localhost isolation, and keep the 10.x (in addition to that) for now 1227091259 M * Bertl once you're sure that everything works, remove the 10.x 1227091305 M * pflanze hm, still unclear. If I set CONFIG_VSERVER_AUTO_SINGLE=n, will the 127.0.0.1 binding for /usr/sbin/hpiod be at 10.0.1.1 instead? 1227091334 M * Bertl the auto single just assigns the isolation IP automatically 1227091344 M * pflanze (VSERVER_AUTO_LBACK=y would mean it will still use 127.0.0.1 but it'll be secure then, I guess.) 1227091346 M * Bertl i.e. you do not have to take care of that yourself 1227091371 M * Bertl with LBACK_REMAP enabled (nflag) you get the isolation 1227091372 J * ktwilight_ ~ktwilight@87.66.207.161 1227091372 M * pflanze I want CONFIG_VSERVER_AUTO_SINGLE=n, I think, right? 1227091374 Q * tramjoe_merin 1227091377 Q * _gh_ Ping timeout: 480 seconds 1227091389 J * tramjoe_merin ~tramjoe@193.41.238.151 1227091404 M * Bertl pflanze: if you don't want the kernel to auto assign the isolation ip (127.x.x1) then yes, but I see no reason why not 1227091411 M * pflanze ok 1227091419 M * pflanze I don't want the guest to have 3 ip's 1227091431 M * Bertl it already has 3 ips, atm 1227091448 M * pflanze exactly; with earlier kernels, it only had two. 1227091456 M * Bertl the lback address and two assigned ips, just that the lback is now unset 1227091476 M * Bertl i.e. if you want to get the old behaviour, set the lback to the first ip 1227091488 M * pflanze how do I do that? 1227091501 M * Bertl entry in the config file 1227091513 M * Bertl (or manually with naddress IIRC) 1227091552 M * pflanze I'll just see what happens if I set CONFIG_VSERVER_AUTO_SINGLE=n 1227091566 M * Bertl nothing will change for you 1227091573 M * pflanze hm k 1227091577 M * Bertl with 2+ ips, this one is disabled anyway 1227091622 M * pflanze did the kernel or the utils change (to give that 3 ip setup now)? 1227091653 M * Bertl the kernel now provides separate lback and first ip 1227091676 Q * ktwilight__ Ping timeout: 480 seconds 1227091681 M * Bertl before, they were always assigned the same value (not really, but that's how it worked out) 1227091714 M * Bertl so, if you want to keep the 2ip setup, just make lback identical to the first ip 1227091744 M * pflanze k 1227091752 M * Bertl daniel_hozac: btw, I don't see an option to set lback in naddress, missing --help? 1227091838 M * Bertl k, off for now .. bbl 1227091842 N * Bertl Bertl_oO 1227094884 J * jsambrook ~jsambrook@aelfric.plus.com 1227094906 P * jsambrook 1227094943 Q * davidkarban Remote host closed the connection 1227095139 J * davidkarban ~david@193.85.217.71 1227095334 Q * ssd Quit: Ex-Chat 1227096652 Q * nkukard Quit: Leaving 1227096841 Q * opuk Remote host closed the connection 1227096876 J * opuk ~kupo@potatisbulle.com 1227097310 M * nox i have a strange permission problem: http://paste.linux-vserver.org/12607 1227097320 M * nox could it be vhashify related? 1227097387 M * nox kernel is 2.6.26.3-vs2.3.0.35 utils are 0.30.216~r2772-3 (debian testing) 1227099807 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1227100509 M * PowerKe nox: Have you enabled copy on write in the kernel? 1227100528 M * PowerKe hmm, that wouldn't block, but just change in all guests... 1227100536 M * PowerKe (not enabling I mean) 1227100568 M * PowerKe Rather an error with immutable bits then 1227100984 Q * mtg Quit: Verlassend 1227101401 M * nox PowerKe: http://paste.linux-vserver.org/12608 doenst see the prob :( 1227101556 J * jsambrook ~jsambrook@aelfric.plus.com 1227101568 P * jsambrook 1227101714 N * qzqy quinq 1227101848 M * PowerKe nox: You should have uppercase UI for unlinkable 1227101877 M * PowerKe (on the files, you only have the vserver root in your paste) 1227103860 M * daniel_hozac Bertl_oO: yeah 1227103861 Q * sharkjaw Quit: Leaving 1227104028 M * daniel_hozac nox: did you upgrade your kernel recently? 1227104452 M * ghislainocfs21 hello daniel and bertl, is there any work done on the hard limit cpu scheduler lately ? 1227104460 M * ghislainocfs21 for 2.3 ? 1227104472 M * daniel_hozac for 2.6.24+, you mean? 1227104542 J * chip ~chip@195.128.77.5 1227104907 Q * chip Quit: Leaving 1227105745 M * nox daniel_hozac: is 29 Aug recently? 1227105789 M * daniel_hozac what did you upgrade from? 1227105820 M * nox 2.6.25.4-vs2.3.0.34.11 1227105872 M * nox running 2.3 since 5. of may 1227105974 M * daniel_hozac that's your problem. 1227106074 M * ghislainocfs21 daniel: yes for the new vserver version 1227106078 M * daniel_hozac if you boot the old kernel, run http://people.linux-vserver.org/~dhozac/t/save-vsdata.sh, and then restore them, everything should be fine. 1227106321 Q * larsivi Remote host closed the connection 1227106513 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1227107225 M * nox old means 2.2 daniel_hozac? 1227107294 M * daniel_hozac old means the one you used to run. 1227107355 M * nox sry ... to run what? 1227107362 M * nox the script? 1227107376 M * daniel_hozac yes. 1227107399 M * nox can not remember executing it *confused* 1227107964 M * nox so i run "./save-vsdata.sh --root /vservers --file /tmp/vsdata.txt"? 1227108134 M * daniel_hozac you want --unset too. 1227108157 M * daniel_hozac then you reboot to the new kernel, and run sh /tmp/vsdata.txt 1227108619 M * nox uhm, how to find the right kernel now? 1227108628 M * daniel_hozac what? 1227108657 M * nox the right past kernel i have to boot to fix it 1227108675 M * daniel_hozac so you ran a kernel before the upgrade, right? 1227108680 M * daniel_hozac that's the one. 1227108709 M * nox great i will try tonight thx for help again 1227108803 M * nox so the result then should be "----Bui- /vservers/proxy"? 1227108983 Q * chI6iT41 Ping timeout: 480 seconds 1227110606 Q * eyck Ping timeout: 480 seconds 1227110755 N * morrigan morrigan_oO 1227111087 J * eyck ivs9i3Ft@nat06.nowanet.pl 1227111354 J * dkg ~dkg@lair.fifthhorseman.net 1227111868 Q * davidkarban Quit: Ex-Chat 1227112379 Q * ensc Ping timeout: 480 seconds 1227112436 Q * eyck Ping timeout: 480 seconds 1227112441 J * doener ~doener@i577AC660.versanet.de 1227112506 M * daniel_hozac nox: no. 1227112546 Q * doener_ Ping timeout: 480 seconds 1227112568 J * dowdle ~dowdle@scott.coe.montana.edu 1227112918 J * eyck ENyT5nEh@nat05.nowanet.pl 1227113647 J * nkukard ~nkukard@196.38.64.208 1227114466 Q * tramjoe_merin Remote host closed the connection 1227114721 J * chI6iT41 ~chigital@tmo-096-124.customers.d1-online.com 1227114746 Q * nkukard Read error: Connection reset by peer 1227114769 J * nkukard ~nkukard@196.38.64.208 1227114851 J * larsivi ~larsivi@9.80-202-30.nextgentel.com 1227115211 Q * chI6iT41 Ping timeout: 480 seconds 1227115311 J * chI6iT41 ~chigital@tmo-100-109.customers.d1-online.com 1227115367 Q * chI6iT41 Remote host closed the connection 1227115799 J * _nkukard_ ~nkukard@196.38.64.208 1227115978 Q * nkukard Ping timeout: 480 seconds 1227116009 Q * mtg Quit: Verlassend 1227116431 J * geb ~geb@4.4.82-79.rev.gaoland.net 1227116931 Q * kir Quit: Leaving. 1227117003 Q * _nkukard_ Ping timeout: 480 seconds 1227118811 J * cga ~weechat@94.36.130.212 1227118854 J * ntrs ~ntrs@77.29.19.26 1227119646 J * sardyno ~me@pool-96-235-18-120.pitbpa.fios.verizon.net 1227120532 J * ensc ~irc-ensc@77.235.182.26 1227121462 J * _gh_ ~gerrit@c-71-193-204-84.hsd1.or.comcast.net 1227121871 Q * cga Ping timeout: 480 seconds 1227121957 J * nkukard ~nkukard@196.212.73.74 1227122995 J * Mojo1978 ~Mojo1978@ip-88-152-50-100.unitymediagroup.de 1227125261 M * mnemoc hi, how can one know how much memory is consuming each context? (vs:2.2) 1227125297 J * bliz42 ~ksmith@c-98-193-150-250.hsd1.tn.comcast.net 1227125319 M * daniel_hozac vserver-stat 1227125335 M * daniel_hozac which uses the same values as in /proc/virtual//limit 1227125385 M * bliz42 hello all. i've been looking around the wiki and all over google trying to find some tips, but have not come across something. hopefully someone can help? is there a way to set a different time and/or date on an individual vserver (not timezone) 1227125429 N * Bertl_oO Bertl 1227125432 M * Bertl back now .. 1227125463 M * micah daniel_hozac: what do you think of #505292? 1227125468 M * Bertl bliz42: yes, you can do that with the proper cflags 1227125491 M * Bertl (in this case, VIRT_TIME, see http://linux-vserver.org/Capabilities_and_Flags for other flags) 1227125530 M * bliz42 ok thank you 1227125759 M * Bertl np 1227125775 M * daniel_hozac note that it requires kernel support too. 1227125790 M * Bertl ah, note, that you need to enable that in the kernel too (guest time), otherwise you'll only have timezones 1227125831 J * ntrs_ ~ntrs@77.29.11.70 1227125850 M * daniel_hozac micah: i don't think cron is a vital system service. 1227125894 M * daniel_hozac and to be honest, the only reason i see to leave syslog enabled is so the guests work on kernels where persistent contexts aren't supported. 1227125975 M * mnemoc daniel_hozac: oh, sorry... somehow I forgot that was also in vserver-stat 1227126042 M * mnemoc daniel_hozac: i clearly need vacations :( 1227126160 J * ntrs__ ~ntrs@77.29.11.70 1227126229 Q * ntrs_ Read error: Connection reset by peer 1227126262 Q * ntrs Ping timeout: 480 seconds 1227127164 Q * gnuk Quit: NoFeature 1227127924 M * micah daniel_hozac: if you are coming from the perspective where you create contexts to exec a process, then I see what you mean. however, most people contexts as mini-servers, and are surprised when fundamental system elements are missing 1227127967 M * daniel_hozac people should enable the services they want. 1227127968 M * micah daniel_hozac: there are many cases of packages that have executables you might want to exec in a context that also carry with them maintainence cron jobs 1227127981 M * daniel_hozac if they want cron, enable cron. 1227128021 M * micah you are worse than debian ;) 1227128035 M * Hawq hello 1227128101 M * daniel_hozac yeah, i think debootstrap comes with way too much crap by default :-) 1227128115 M * micah someone who debootstraps a debian guest, expects a minimal debian installation, with the important pieces all in place. That includes a basic functioning library set, which you aren't wanting to take away, right? :) 1227128207 M * Hawq Bertl: do you have a while to fight with this X thing of mine again? :) 1227128211 M * micah removing something like cron is only going to provide fuel to people writing things like vserver-debianutils, which is something we want to discourge, right? 1227128237 M * daniel_hozac ideally we'd be able to debootstrap just glibc and sysv-rc. 1227128239 M * Bertl Hawq: any new clues? 1227128266 M * micah daniel_hozac: and then how would people build a guest from there? 1227128286 M * daniel_hozac oh right, we don't have external package management for dpkg. 1227128290 M * daniel_hozac so add apt-get to the list. 1227128329 M * micah the point of debootstrap is to create a debian base system from scratch, without requiring the availability of dpkg or apt 1227128396 M * Hawq Bertl: nope. we were about to revert some something but patch to revert was for 2.6.26 1227128405 M * micah your approach is a good one, I think, but I would argue that some people want that, and some people would like a minimal guest with some basic packages... perhaps two profiles could be provided, one that does the bare-minimum, and one that does what it does now (with cron ;) 1227128445 M * daniel_hozac yes, profiles are on my TODO. 1227128477 M * micah i suspect that all the people who have been used to vserver debootstrap build operations up to this point will be quite surprised to find out that cron is now not included 1227128500 M * micah if you remove cron, why not remove all kinds of other stuff, like say bash 1227128518 M * daniel_hozac bash is a service that consumes resources needlessly? 1227128559 M * micah cron does? its takes up like 300bytes of memory 1227128560 M * micah heh 1227128573 M * Bertl Hawq: and you couldn't revert it successfully? 1227128575 M * daniel_hozac it's a conformity thing. 1227128584 M * daniel_hozac all guests come up with just syslog running. 1227128590 M * daniel_hozac if you want other services, enable them 1227128606 M * Bertl Hawq: actually I remember that the patch itself should revert the stuff in question 1227128674 M * micah ok, I'll see if I can fight this battle with people. I've already got three people asking me why cron doesn't exist in new vservers. I suspect I will tire of defending this decision after a while and hope that profiles come soon 1227128676 M * nox yeah profiles for debootstrap would be great imho 1227128748 M * micah you can always pass to debootstrap --include=cron,xgalaga,freeciv,sl 1227128807 J * m_o_d ~kane@host.ltv.pl 1227128826 M * daniel_hozac exactly. 1227128891 M * nox yes so the job simply is to create fitting [in|ex]clude list for different purposes 1227128892 M * micah well I am going to reassign this bug back to vserver-debianutils then, because if they want to provide that package, they can 1227128907 M * daniel_hozac well, the package is installed already. 1227128918 M * daniel_hozac just the initscript hsa been disabled. 1227128944 M * micah err, the name is 'vserver-debiantools' 1227129033 M * Hawq Bertl: delta-vspid-revert03.diff fails at revert on arch/s390/kernel/ptrace.c, arch/sparc/kernel/ptrace.c, arch/v850/kernel/ptrace.c, fs/proc/base.c and include/linux/vs_pid.h 1227129085 M * Hawq Bertl: but I'll try revert failing parts manually. just a moment 1227129088 M * Bertl well, I think you don't have s390, sparc or v850, so no big deal there 1227129133 M * Bertl the proc/base is probably trivial, and the vs_pid.h maybe can be ignored too (or manually applied) 1227129229 M * micah i could be wrong, but I think the majority of people want cron to be running 1227129285 M * daniel_hozac that depends entirely on the use-case. 1227129305 M * nox i use cron a lot but i would be able to enable it 1227129329 M * micah you have to be aware of every package you install on your system, and if it uses cron or not, and when it does, you will need to enable it 1227129340 M * nox but i agree most will expect 1227129351 M * Hawq Bertl: reverted manually. now recompiling and will give it a try 1227129380 M * Bertl excellent! 1227129403 M * micah which is different from how you normally do things, you install a package and you expect the cronjobs, if there are any included with that package, to just work, without having to twiddle the cron startup links 1227129414 M * Bertl Hawq: double check that the result is working as intended, i.e. you should be able to see all pids inside the guest, and send signal to non-guest processes 1227129427 Q * dna Quit: Verlassend 1227129535 M * micah personally, I think it makes more sense to disable cron, if i do not want it, than enable it after I have tracked down why something doesn't work in my guest to the fact that cron is not running (say for example logrotation will not happen and guests will just fill up their disk until you notice this is happening and then login and see giant log files and wonder why logrotation hasnt happened) 1227129598 M * micah i do think there is an argument for paring down things as much as possible, thats why I run Debian and not Redhat ;) but if the removal of something is going to cause problems in the default case, then the desire to trim the fat has perhaps gone too far (especially when we are talking about 300bytes of memory) 1227129609 M * Hawq Bertl: it failed to compile after revert :( http://pld.pastebin.com/m48669e9 1227129685 M * daniel_hozac micah: well, when you're running 300 guests, that's 90 MiB of RAM. 1227129705 M * micah who doesn't have 90MiB of RAM if they are running that many guests?! 1227129716 M * daniel_hozac 90 MiB of _wasted_ RAM. 1227129742 M * micah i waste like 1000x that amount of ram just launching firefox ;) 1227129742 M * daniel_hozac but again, memory isn't the real issue. 1227129784 M * daniel_hozac it's a conformity issue. i don't want Debian guests to come with all sorts of random crap, when Fedora/CentOS/etc. guests don't. 1227129805 M * micah Fedora/CentOS/etc. don't enable cron? 1227129812 M * daniel_hozac it's not even installed, no. 1227130291 M * Bertl Hawq: pick the hunk (patch part) from the original patch there and revert it too 1227130478 M * Hawq Bertl: can't do so. its kernel/vserver/signal.c and in original patch its addition of new file. 1227130541 M * Bertl ah, sorry, I read that as the 'normal' signal file, just replace the vx_initpid with 1 then 1227130633 M * Hawq ok, compiling. 1227130762 Q * nox Quit: If the world is without walls and fences -- who needs Windows and Gates ? 1227131636 Q * m_o_d Remote host closed the connection 1227132083 Q * sladen Ping timeout: 480 seconds 1227132165 J * sladen paul@starsky.19inch.net 1227132532 Q * ntrs__ Ping timeout: 480 seconds 1227133039 J * esa ~esa@87.238.2.45 1227133649 Q * bonbons Quit: Leaving 1227133711 M * Hawq Bertl: just booted the kernel. I see entries in proc, except processes. 1227133744 M * Bertl what about signaling? 1227133834 M * Hawq Bertl: how should I check? I can't see any process numbers 1227133848 M * Hawq Bertl: guests doesn't start too 1227133853 M * Bertl start e.g. sleep 100 on the host 1227133873 M * Bertl ahem, you mean you don't see any even on the host? 1227133877 M * Hawq yes 1227133892 M * Bertl that's strange then 1227133919 M * Hawq patch fault? it was for 2.6.26.5 1227133927 M * Bertl can you get me a diff between your current kernel and mainline? 1227133940 M * Bertl (mainline being vanilla kernel.org) 1227133952 M * Hawq or some hunk reverted incorrectly 1227133970 M * Hawq sure, just a moment 1227134162 J * noxx ~nox@p579FA76C.dip.t-dialin.net 1227134242 M * noxx daniel_hozac: hit some probs executing the save-vsdata.sh 1227134254 M * daniel_hozac oh? 1227134279 M * noxx first it had probs with () in filenames 1227134300 M * noxx i quoted them in the result file 1227134343 M * noxx but now i have vc_migrate_context(): Function not implemented 1227134369 M * Bertl what util-vserver version? 1227134405 M * noxx debian lenny 0.30.216~r2772-3 1227134418 M * Bertl update to a newer one, known bug 1227134483 M * noxx hmm long time ago that i build my last one 1227134497 M * Bertl using an older one works fine too, btw 1227134719 M * Hawq Bertl: problem. diff is huge, 600 MBs even after make clean in my tree. 1227134736 M * Bertl can you bz2 and upload it somewhere? 1227134784 M * noxx ok switched back to 212 and looks good except: vserver-stat /n chdir(): Permission denied 1227134787 M * daniel_hozac Hawq: does lsdiff show a lot of files that shouldn't be there? 1227134876 M * Hawq daniel_hozac: yes, seems so. ie. build-done dir 1227134895 M * Bertl you might want to use --exclude 1227135050 M * Hawq all right, after removing build-done dir its now 3 MBs of diff. I'm uploading it 1227135190 M * Bertl excellent! 1227135437 M * Hawq http://hawk.furud.net/files/vs.diff.bz2 1227135459 M * Bertl ERROR 403: Forbidden. 1227135494 M * Hawq try now 1227135502 M * Bertl works 1227135817 Q * Hollow Remote host closed the connection 1227135889 Q * padde Remote host closed the connection 1227135918 Q * Loki|muh Remote host closed the connection 1227136049 Q * biz_ Remote host closed the connection 1227136068 Q * Mojo1978 Remote host closed the connection 1227136072 Q * DLange Remote host closed the connection 1227136080 Q * mcp Read error: Connection reset by peer 1227136084 J * Hollow ~hollow@shiva.xnull.de 1227136085 Q * mnemoc Remote host closed the connection 1227136092 J * DLange ~DLange@dlange.user.oftc.net 1227136092 J * mcp ~mcp@wolk-project.de 1227136097 J * mnemoc ~amery@shell.opensde.net 1227136159 P * openblast http://quassel-irc.org - Chat comfortably. Anywhere. 1227136250 J * padde ~padde@patrick-nagel.net 1227136286 M * noxx hmm no 212 alone didn't help :( 1227136312 M * noxx naddress: vc_net_add(): Invalid argument 1227136342 M * Bertl Hawq: just revert all patches to fs/proc/ in your branch 1227136385 M * Bertl none of those should be required for our test 1227136392 M * daniel_hozac noxx: you want more like 0.30.215. 1227136403 M * noxx ok 1227136450 J * derjohn_mob ~aj@p5B23D490.dip.t-dialin.net 1227136558 M * Hawq Bertl: 7 of them. reverting and compiling 1227136599 M * Bertl ah, sec, daniel_hozac, what Linux-VServer specific proc entries are required for util-vserver to funtion? 1227136602 M * Bertl *function 1227136666 M * daniel_hozac hmm. /proc/virtual for vserver-stat. 1227136678 M * Bertl okay, nothing for a guest startup? 1227136686 M * daniel_hozac i don't think so... 1227136692 M * Bertl excellent! tx! 1227136761 A * arekm wonders... is it possible to see "own" quota in guest if quota is enabled on host mounted fs + bind in guest? 1227136787 M * Bertl depends on the filesystem, but usually yes 1227136805 M * daniel_hozac but only if the entire filesystem is bind mounted. 1227136879 M * Bertl the kernel should be able to provide quota info without the quota files 1227137039 M * Hawq Bertl: just booted updated kernel. I still don't see any processes on host 1227137396 M * Bertl well, as we removed the hide check too, no idea why that would be so 1227137430 M * Bertl but I'm off to bed now .. so let's continue tomorrow, yes? 1227137457 M * Hawq ok 1227137473 M * Hawq I'll be online at evening 1227137492 M * Hawq cu then 1227137500 M * Bertl cya! 1227137508 N * Bertl Bertl_zZ 1227137529 M * noxx cu Bertl_zZ 1227138585 M * noxx opendir /proc: Permission denied (Permission denied) 1227138615 M * noxx i give up, too tired to fix anything 1227138627 M * noxx hotfixing seem to make everthing worse 1227138862 M * daniel_hozac noxx: 2.6.27.6-vs2.3.0.35.10? 1227138934 M * noxx yes 1227138995 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-proc-fix03.diff 1227139000 M * noxx wanted to use the reboot for kernelupdate 1227139138 J * jescheng ~jescheng@proxy-sjc-1.cisco.com 1227139167 M * jescheng is there a maximum limit to the number of ip per vserver?