1155945669 M * Bertl wb derjohn! 1155945718 M * derjohn ehlo Bertl ! (You could have called me castrator now ... the handmade patch worked!) 1155945719 M * Bertl daniel_hozac: what are you willing to add/modify on util-vserver in the near future? 1155945771 M * Bertl daniel_hozac: I mean, what kind/level of changes would you do, and where is the limit? :) 1155945995 Q * suka Quit: Leaving 1155946038 M * derjohn Bertl, with unionfs there was the problem that it called stuff like vfs_unlink(a,b,c) and after the BME externsion the prototype is like vfs_unlink(a,b,c,d). On all 'wrong' occurrances I replaced function calls with vfs_unlink(a,b,c, NULL) to make it complile (work?). Wouldnt it make sense in general to add an 'overloaded' prototype to namei.c like "int vfs_unlink(a,b,c)" that calls vfs_unlink(a,b,c, NULL)? Or doenst this approach work for all non-vanilla 1155946039 M * derjohn filesystems? 1155946117 M * Bertl no, not at all, once the BME is in mainline, this (or similar) arguments will be standard 1155946149 M * Bertl and putting NULL there is basically the WrongThing(tm) 1155946157 M * derjohn when will once be ? is there current effort? 1155946163 M * Bertl i.e. you should put the nameidata stuff there 1155946184 M * derjohn hm, wrong in as sense it could do harm? or wrong in a sense that BMEs dont work? 1155946187 M * Bertl derjohn: dhansen is doing a good job and seems to make some progress there 1155946210 M * Bertl derjohn: yes, in the sense that BME won't work on NULL arguments 1155946248 M * derjohn I dont have the slightest idea, what "namei" stand for ... neither what to put in there :/ 1155946301 M * Bertl well, you could have a look at the other places calling the vfs_unlink() for example 1155946325 M * derjohn Bertl, this We I dont have time to look at (guest at a wedding), but if you enlighten me lateron, I'll try. 1155946331 M * dhansen derjohn: nameidata is the per-filesystem call data that helps turn a dentry into an inode 1155946342 M * dhansen (anong other things) 1155946368 M * Bertl hey dhansen! as I said, good work, nice progress so far! 1155946392 M * dhansen Bertl: thanks. I've been meaning to send up the remainder of the patches again, but I've had a bit of email to read :) 1155946515 M * derjohn dhansen, thanks. I seems that patching implies understanding how files/filesystems in the kernel work. till now I always thought every entity on the fs has an inode, I wasnt aware that there is some state in-between. 1155946555 M * dhansen derjohn: yeah, dentries are in-between 1155946611 M * Bertl derjohn: basically this is a separate layer (vfs) ontop of the filesystem(s) 1155946630 M * Bertl derjohn: it's the part which makes --bind mounts possible 1155946634 Q * yarihm Quit: Leaving 1155946659 M * derjohn and dentry == directory entry? or what is the d for? 1155946676 M * dhansen derjohn: yeah 1155946712 M * dhansen they have a specific meaning in the filesystems themselves, but their meaning in the VFS is a little different. 1155946758 M * Bertl yeah, dirent is something different :) 1155946852 M * derjohn well, i think i gonna read some filesystem tutorial before stessing this channel any longer. besides that I have to leave office now! Bertl dhansen : Merci ! 1155946945 M * Bertl cya! and have fun! 1155947027 M * derjohn Bertl, yes .. ah and: abiut the testing environment: I found two ROL/F Ethernet NICs, which have a Reset-On-Lan feature! So with the sreial console combined everything should be cool. 1155947028 M * derjohn n8 1155947044 M * Bertl great! tx! 1155947355 M * daniel_hozac Bertl: anything that's needed, i suppose ;) 1155947484 M * Bertl daniel_hozac: okay, I'm toying with the idea of getting rid of the 32bit compat stuff in a revised command interface for the 2.2.x branch 1155947521 M * Bertl i.e. remove the legacy commands as already discussed, and declare a few new command versions where appropriate 1155947536 M * Bertl of course, that would require proper util-vserver support too 1155947564 M * Bertl (probably small and simple changes, but in several locations) 1155947579 M * daniel_hozac hmm? 1155947661 M * Bertl check the *_cmd.h definitions 1155947720 M * Bertl for example: vc_add_dlimit_x32() or vc_get_rlimit_x32()) 1155947726 M * daniel_hozac yeah. 1155947743 M * Bertl we could get rid of all that code if we slightly restructure the interfaces (at least I think so) 1155947784 M * daniel_hozac like for rlimit moving the id last? or what? 1155947834 M * Bertl or using proper padding if necessary 1155947878 M * daniel_hozac padding as in an empty uint32_t? 1155947890 M * Bertl yes, for example 1155947924 M * Bertl there are several solutions, we could decide depending on the structure or data passed 1155947926 M * daniel_hozac ok. 1155948165 J * MrX ~fallacy@219.95.9.131 1155948294 M * Bertl welcome MrX! 1155948320 M * Bertl daniel_hozac: recently we had a namespace collision in the socket area, do you remember what clashed there? 1155948346 M * daniel_hozac cacct_cmd.h's SOCK_PACKET and linux/net.h. 1155948362 M * MrX Hi 1155948373 M * daniel_hozac in kernel/vserver/switch.c 1155948379 M * daniel_hozac (probably other files as well) 1155948390 M * daniel_hozac but i believe it's only with bonbons' patch. 1155948408 M * Bertl okay, guess we should move the SOCK_* enum into the h file and add some prefix for that 1155948417 M * Bertl at least I think this one caused it 1155948435 M * Bertl include/linux/vserver/cacct_cmd.h (enum sock_stat_field) 1155948439 M * daniel_hozac yeah. 1155949970 Q * meandtheshell Quit: bye bye ... 1155950906 M * Bertl daniel_hozac: what about this one? http://vserver.13thfloor.at/Experimental/delta-cacct-clean02.diff 1155951145 M * daniel_hozac looks fine, and compiles. 1155951200 M * Bertl while I'm at it, shouldn't we change the -EFAULT on vc_get/set_vhi_name() (for !name) to EINVAL? 1155951300 M * daniel_hozac that does sound more correct. 1155951340 M * Bertl okay, will do a patch for that too ... 1155951371 M * Bertl should apply to stable as well, hope it doesn't change the tools' behaviour ... 1155951442 M * daniel_hozac it really shouldn't, or i guess we'd already be seeing Bad address errors. 1155951456 M * Bertl good point! 1155952651 M * matti :-) 1155953406 M * Bertl okay, and here is the first vstat command: http://vserver.13thfloor.at/Experimental/delta-vstat-feat02.diff 1155953646 M * Bertl hmm, I think the sock_acc_field might need to go to cmd after all, so that userspace can use this 1155954294 M * Bertl okay, off to bed now ... have a nice one everyone, and cya tomorrow! 1155954321 N * Bertl Bertl_zZ 1155955888 J * ntrs ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1155955888 Q * ntrs_ Read error: Connection reset by peer 1155956120 J * ntrs_ ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1155956120 Q * ntrs Read error: Connection reset by peer 1155956583 J * ntrs ~ntrs@207-119-222-200.dyn.centurytel.net 1155956963 Q * ntrs_ Ping timeout: 480 seconds 1155965904 M * doener Bertl_zZ, Hollow: patch went into -mm 1155967260 M * Hollow doener: great! :) 1155967319 M * doener and -1 makes sense now, too 1155967383 M * Hollow ah? 1155967390 M * doener Hollow: in-kernel execve really behaves like a syscall, returns -1, error in errno 1155967414 M * doener see include/asm-i386/unistd.h __syscall_return 1155967437 M * Hollow ah, like i thought in the first place.. 1155967581 M * doener hm, would a patch to get the real error code make sense? 1155967769 M * Hollow doener: i don't need it atm, but it would probably make sense 1155967845 J * dna ~naucki@132-194-dsl.kielnet.net 1155968026 M * doener Hollow: http://www.13thfloor.at/~doener/various/____call_usermoderhelper-execve-errno.diff 1155968030 M * doener would you test that? 1155968050 M * doener eek, missing whitespace 1155968081 M * doener ok, updated it (just cosmetic ;) 1155968119 M * Hollow surprisingly simpel :o 1155968134 M * doener well, as in userspace ;) 1155968275 M * Hollow doener: btw, do you know when asm-offsets changes? the last patches caused only recompile of the patched files, but some patches cause a whole kernel recompile (because asm-offsets changes) 1155968429 M * doener probably you touched struct thread_info 1155968473 Q * dna Quit: Verlassend 1155969261 Q * Hollow Quit: Konversation terminated! 1155969410 J * Hollow ~hollow@2001:a60:f026::1 1155969472 M * Hollow doener: /foo: (startup 42) returned sync with 2 :) 1155969506 M * doener ok, so we miss a - no 1155969510 M * doener s/no/now/ 1155969525 M * Hollow well.. errno is positive (in userspace) 1155969539 M * doener yeah, patch must have -errno 1155969547 M * doener this is still kernelspace ;) 1155969555 M * Hollow yeah, probably better to stay conform with kernelspace 1155969654 M * Hollow off to breakfast, brb 1155970382 M * doener Hollow: updated the files once more, this looks better, right? 1155970497 J * s0undt3ch_ rfslicd@bl7-245-41.dsl.telepac.pt 1155970933 Q * s0undt3ch Ping timeout: 480 seconds 1155970933 N * s0undt3ch_ s0undt3ch 1155971177 M * Hollow doener: yep, looks cleaner 1155971631 J * ybanafa ~ybanafa@82.114.177.65 1155972140 P * ybanafa Leaving 1155972600 J * Viper0482 ~Viper0482@p54976877.dip.t-dialin.net 1155972660 M * doener Hollow: ok, patch is out 1155972666 M * Hollow fine :) 1155972849 J * meandtheshell ~markus@85-124-36-123.dynamic.xdsl-line.inode.at 1155973527 J * Zaki_ ~Zaki@212.118.109.16 1155973902 Q * Zaki[] Ping timeout: 480 seconds 1155974495 J * pisco ~pampel@p5087B120.dip0.t-ipconnect.de 1155974534 M * Hollow awesome.. the socket accounting syscalls works 1155974538 M * Hollow Bertl_zZ: ^ 1155974588 M * Hollow but the limit accounting syscall is missing 1155974594 M * Hollow although define as VCMD 1155974598 M * Hollow *defined 1155974756 J * pisc1 ~pampel@p50878A71.dip0.t-ipconnect.de 1155975159 Q * pisco Ping timeout: 480 seconds 1155976891 J * NetAsh ~NetAsh@62-212-199-5.elsis.lt 1155976918 P * NetAsh 1155977936 J * bonbons ~bonbons@83.222.36.236 1155978304 N * Belu_zZz Belu 1155978501 Q * ebiederm Quit: Leaving 1155979414 M * h01ger thanks for all the fish, keep up the good work and i'll be back :) 1155979420 P * h01ger Leaving 1155980644 J * pisco ~pampel@p50878A71.dip0.t-ipconnect.de 1155981479 Q * pisc1 Ping timeout: 480 seconds 1155981828 M * doener Hollow: http://lkml.org/lkml/2006/8/19/14 -- harder this time ;) 1155982194 M * Hollow doener: harder? ;) 1155982260 M * doener look at the follow ups... they want a kernel_execve (not that I think that that is a bad idea ;) 1155982329 M * Hollow ah.. missed the follow up links 1155982331 M * Hollow quite hidden 1155982376 M * Hollow well, as long as we get errno, it's fine with me 1155982826 J * pisc1 ~pampel@p50878A71.dip0.t-ipconnect.de 1155984529 Q * cehteh Ping timeout: 480 seconds 1155985879 N * Bertl_zZ Bertl 1155985883 M * Bertl morning folks! 1155985925 M * Hollow morning Bertl! 1155985939 M * Bertl so the first step works as expected, as I see? :) 1155985946 M * Hollow yep :) 1155985950 A * Belu is away (iŽll be back later...) 1155985952 N * Belu Belu_zZz 1155986228 M * Hollow Bertl: btw, what is the difference between count and total? packets and bytes? 1155986236 M * Bertl yep 1155986239 M * Hollow ok.. 1155986384 M * Bertl doener: wasn't the utsname recently extended to 256 chars or so? 1155986519 M * Bertl seems I was just dreaming that .... :) 1155987288 M * doener back now... battery went out... 1155987315 M * doener Bertl: hm, should be in -mm IIRC 1155987323 M * doener maybe it was dropped again? 1155987510 M * Bertl could be ... 1155987606 M * doener hm, not in any mm announcement in my lkml mbox, weird... 1155987619 M * Bertl Hollow: http://vserver.13thfloor.at/Experimental/delta-vstat-feat03.diff 1155987647 M * Bertl getting some breakfast now .. back shortly 1155988298 Q * Hollow Quit: Konversation terminated! 1155988442 J * Hollow ~hollow@2001:a60:f026::1 1155988552 M * Hollow Bertl: seems to work :) 1155988682 M * Bertl good to hear :) 1155988915 M * Hollow Bertl: i assume that rlimit_mask applies to rlimit_stat as well? 1155988996 M * Bertl not necessarily 1155989017 M * Hollow i.e. we should introduce another field to rlimit_mask struct? 1155989033 M * Bertl yes, for accounting only values 1155989129 Q * pisc1 Ping timeout: 480 seconds 1155989177 J * |gerrit| ~kvirc@dslb-084-060-208-093.pools.arcor-ip.net 1155990232 Q * coocoon Quit: KVIrc 3.2.0 'Realia' 1155990596 Q * Greek0 Quit: Changing server 1155990657 A * Skram yawns 1155990840 M * Bertl okay, have to get some groceries before the shops close ... will be back later ... 1155990850 N * Bertl Bertl_oO 1155991900 M * doener wow, shops closing so early? that's even worse than in germany ;) 1155992584 M * kaner :) 1155992973 J * Ensesst ~zx8cf7l@81.214.171.114 1155992998 P * Ensesst 1155993471 J * ntrs_ ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1155993589 J * Greek0 ~greek0@85.255.145.201 1155993932 Q * ntrs Ping timeout: 480 seconds 1155994472 M * Skram morning all.. 1155994475 A * Skram takes a big gulp of his Chai Tea Latte 1155995000 M * doener morning Skram 1155995030 M * Skram morn 1155995235 J * ybanafa ~ybanafa@198.69.12.16 1155995772 P * ybanafa Leaving 1155996578 N * Bertl_oO Bertl 1155996581 M * Bertl back now ... 1155996834 M * Viper0482 hi 1155996944 M * Bertl hey! what's up? 1155997107 M * Viper0482 to run a tftp server inside a vserver do i have to set same capabilitis? 1155997257 M * Bertl tftp uses tcp/udp, so IMHO no 1155997271 M * Skram I know I have run tftp inside a vps with no problems 1155997282 M * Skram I dont remember any special caps needing to be enabled/set 1155997311 M * Viper0482 ok thank you will try it 1155997702 M * Bertl np 1155997724 Q * weasel Quit: Reconnecting 1155997725 J * weasel weasel@asteria.debian.or.at 1155998151 M * Bertl wb weasel! 1155998280 M * sid3windr hmm, 2.6.17.7 with that patch, which I didn't find what made it crash, suddenly lost network connectivity to the vservers ... 1155998285 M * sid3windr "ip a" inside vserver doesnt return anything anymore 1155998297 A * sid3windr going back to 2.6.17.6 ;[ 1155998300 M * weasel moin 1155998424 M * Bertl sid3windr: strange ... 1155998446 M * sid3windr yeah 1155998448 M * sid3windr very :) 1155998457 M * sid3windr I don't know if it's vmware related 1155998474 M * Bertl maybe, but maybe you are experiencing gcc issues too 1155998477 M * sid3windr but nagios just sent me alerts so I logged into the host, which also couldn't ping them anymore - vserver enter'd it 1155998484 M * sid3windr ip a = empty 1155998497 M * sid3windr my gcc is standard debian etch's gcc 1155998498 M * Bertl you should definitely give QEMU a try, works like a charm here 1155998504 M * sid3windr only I can't ;) 1155998519 M * Bertl you have no computer or what? 1155998535 M * sid3windr indeed 1155998544 M * sid3windr what should I do with qemu? 1155998558 M * Bertl boot the vserver kernel there, and test it 1155998578 M * sid3windr to see if it's vmware related? 1155998586 M * Bertl yep 1155998602 M * doener Bertl: btw, just found the utsname related mails, didn't go in because posix is on crack (sic) 1155998608 M * sid3windr I'll try 1155998611 M * sid3windr but not now :) 1155998625 M * Bertl doener: ah, okay, so no need to worry right now :) 1155998694 J * Hurga nobody@p508A8876.dip0.t-ipconnect.de 1155998694 M * Bertl doener: btw, would appreciate a short look over the patches since rc29 (and maybe the whitespace cleanups too) 1155998777 M * doener the increasing feat# patches are incremental or replacing? 1155998798 M * doener ie. helper-feat0{1,2,3,4} 1155998803 M * Hurga Hi... I'm having a little trouble with the prepre-start script. It works, but at the end it gives me: 1155998803 M * Hurga No command given; use '--help' for more information. An error occured while executing the vserver startup sequence; when there are no other messages, it is very likely that the init-script () failed. 1155998821 M * Hurga Works fine without the script, though. 1155998841 M * Hurga Does it need a special command that the end? 1155998846 M * Bertl doener: some are incremental, others are replacements :/ 1155998875 M * doener Bertl: guess we need to extend the naming scheme ;) 1155998890 M * Bertl Hurga: could it be that the script returns non zero? 1155998902 M * Bertl Hurga: mabe try to have 'true' as last command 1155998922 M * Hurga thx, I'll check 1155998927 M * Bertl doener: yes, seems so ... 1155998980 M * Bertl doener: helper starts at feat03 1155999013 M * Hurga Bertl: Nope, no change 1155999043 M * Bertl and when you remove the prepre-start script, everything works fine? 1155999072 M * Hurga Yes. I need to manually mount the LVM volume in that case, though. 1155999088 M * Bertl hmm, for the guest? 1155999093 M * doener Hurga: what does the script look like? 1155999095 M * Hurga Yes. 1155999100 M * Bertl that's your problem 1155999110 M * Bertl the prepre-start is a misnomer 1155999118 M * Bertl it is executed _after_ mounting the rootfs 1155999145 M * Bertl I have a patch somewhere to have an initialize script, which is run before anything is done 1155999168 M * Bertl but for a simple lvm volume, it should not be required to do that by yourself 1155999172 M * Hurga Would that be preprepre-start? 1155999177 M * Bertl you could add that to the fstab 1155999180 Q * michal_ Ping timeout: 480 seconds 1155999207 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/util-vserver-0.30.210-initialize.patch 1155999327 M * doener Bertl: hm, what about whitespace in for-loops, like this: 1155999339 M * Hurga Bertl: I prefer not to have it in the fstab, because the machine is 300km away and if something goes wrong which adding the entries, it'll drop to a root shell while booting. 1155999341 M * doener for (i=0; i0) { /* check if x > 0 */ 1156000973 M * doener Hollow: indeed, mixed space/tab indentation with a seemingly undefined tabwidth is by far too common 1156001011 M * Hollow doener: yep.. i pay most attention to this.. 1156001059 M * doener Bertl: a friend of mine got instructions by his professor to do sth. like this _to avoid compiler optimization_: int foo; foo = 0; foo = function_param; foo <<= 8; foo |= param2; return foo; 1156001117 M * Hurga Now I have a vserver in limbo... 1156001129 M * Hurga root@kabelmarder:~# vserver services start 1156001129 M * Hurga vserver 'services' already running 1156001130 M * Hurga root@kabelmarder:~# vserver services stop 1156001130 M * Hurga No command given; use '--help' for more information. 1156001130 M * Hurga root@kabelmarder:~# vserver services enter 1156001131 M * Hurga No command given; use '--help' for more information. 1156001154 M * Hollow i love util-vservers descriptive error messages :D 1156001178 M * doener Hurga: vserver --debug services start 2>&1 > start-log 1156001179 M * doener ;) 1156001255 M * Bertl doener: well, with M$ C that might help, no? 1156001329 M * doener nothing helps with that 1156001364 M * doener well, I have no ideas about the more recent ones, but V6 sucked badly 1156001372 M * Hurga doener: The vserver is *somehow* running, ist shows in vserver-stat. Trying to stop gives me: 1156001378 M * Hurga ++ /usr/bin/nice -n 0 /usr/sbin/vnamespace --enter 49179 -- /usr/sbin/vcontext --silent --migrate --chroot --xid 49179 -- 1156001378 M * Hurga No command given; use '--help' for more information. 1156001403 M * doener Bertl: they were working on some *nix though 1156001467 M * doener Hurga: could you provide the full log? (http://paste.linux-vserver.org) 1156001475 M * Bertl Hurga: looks like dynamic contexts to me :) 1156001494 M * Hurga doener: of the stop command? 1156001522 M * doener yep 1156001605 A * Hollow is looking forward to legacy removal 1156001607 M * Hollow :) 1156001623 M * Hurga http://paste.linux-vserver.org/261 1156001666 M * Bertl btw, we should put something on http://www.howtoforge.com/ (regarding Linux-VServer installation or so) 1156001691 Q * FireEgl Server closed connection 1156001749 M * Hollow Bertl: query? 1156001876 M * doener Hurga: sysv initstyle? 1156001918 M * Hurga the vserver? Yes. 1156001972 Q * Viper0482 Ping timeout: 480 seconds 1156001976 M * doener the tools cannot find the rc script 1156002004 M * Hurga can I just kill everything with vkill? 1156002008 M * doener you should probably enter the vserver's namespace and check the mount situation 1156002040 M * doener that might give you an idea what went wrong 1156002072 M * Bertl it might be a tool issue, I observed something similar with per guest root mounts 1156002080 M * Bertl Hurga: try the following: 1156002095 M * Hurga I can guess what went wrong... the postpost-stop stript is not post everything, but rather somewhere in beween, right? 1156002097 M * Bertl 'vserver exec bash' 1156002118 M * Bertl it worked for me, although 'vserver enter' failed 1156002134 M * Hurga yep, works 1156002215 M * Bertl no idea what causes this behaviour ... maybe daniel_hozac has a clue ... 1156002286 M * Hurga I guess I know... I tried to unmount the LVM in the postpost-script 1156002294 J * FireEgl FireEgl@Sebastian.Atlantica.US 1156002343 M * Hurga But that wasn't post everything, but somewhere in between, so the shutdown got stuck. 1156002362 M * Hurga I just killed the processes and the vserver was gobe. 1156002364 M * Hurga gone 1156002421 A * Hurga thinks the start/stop scripting is inadequately named and insufficiently explained. :/ 1156002513 M * Bertl Hurga: I'm sure a good wiki page might help here *hint* 1156002622 M * Hurga Well, that flower page didn't really help. I'd be happy to add some info somewhere, but I have to understand it myself, first. 1156002651 M * Bertl of course, I already did some testing back then, you might want to do similar 1156002816 M * Bertl http://vserver.13thfloor.at/Experimental/UTIL-VSERVER/SCRIPTS/ 1156002867 M * Hurga thanks. 1156002868 M * Bertl I'm pretty sure that changed since, but it should be easy to get this (and similar info) from a generic script template 1156002908 M * Bertl interesting aspects IMHO are: environment, arguments, namespace, context(s), caps, mounts 1156003019 M * doener Bertl: hm, in helper-feat0{3,4}, what about making out_unhash: -> error: and moving it below out:? 1156003119 M * Bertl thought about that, but I didn't see any advantage in doing so 1156003236 M * Bertl well, probably the 'hot' path is success, so it might speed that up, but I don't think it is really that hot ... but I don't have a problem with a path doing that :) 1156003343 M * doener yeah, performance is not such a problem there, I just think that a mix of success/non-success jumps harms readability 1156004006 M * doener Bertl: other patches look good to me 1156004030 M * Bertl okay, good ... tx! 1156004047 M * doener np 1156004275 M * Hurga Bertl: The "initialize" script patch doesn't work for me, BTW. 1156004294 M * Bertl how so? 1156004304 M * Hurga Gives me the same shutdown problems again. 1156004331 M * Bertl I mean, it's trivial, so it _should_ do what it is supposed to do, didn't say it would fix your issues :) 1156004379 M * Hurga OK, it does stuff, but it doesn't seem to be pre-everything. 1156004403 M * Bertl check the patch, it is done before the rootfs is mounted (you can also check the script) 1156004405 M * Hurga I mean, if I run the initialize manually, and then stert the vserver, everything is fine. 1156004440 M * Hurga If I run initialize from the scripts dir by starting the vserver, it hangs at shutdown. 1156004526 M * Bertl what does your initialize script contain right now? 1156004537 M * Bertl and what your fstab entry in the config? 1156004551 M * Hurga weit a sec, I'll try something 1156004669 M * Hurga ok, here are the contents... 1156004676 M * Hurga echo "initialize: cleaning and mounting services fs" 1156004676 M * Hurga vgmknodes 1156004677 M * Hurga e2fsck -p /dev/vg1/services 1156004677 M * Hurga mount /dev/vg1/services /vservers/services 1156004774 M * Hurga fstab is default, no special entry... does that matter? 1156005005 M * Bertl no, looks fine 1156005106 M * Bertl what I do differently here is: 1156005126 M * Bertl I do not mount the rootfs in the script, instead I add an entry to the fstab 1156005156 M * Bertl so the tools mount it for me (with another fix) completely inside the context 1156005246 M * Hurga hm. 1156005280 M * Hurga What bugs me is that what I'm trying to do here was no problem with the old style config. 1156005313 M * Hurga and now it seems impossible to do cleanly. 1156005353 M * Hollow Bertl: btw, do you think it is a good idea to let guests mount everything from inside, and drop the mount support from the utils? 1156005366 M * Hollow mounting with utils is very ugly 1156005372 M * Bertl well, the 'old style' config wasn't able to get the simplest things working, but yeah, it might have worked for your purpose 1156005390 M * Hollow s/utils/vcd/ 1156005391 M * Hollow ;) 1156005422 M * Bertl Hollow: well, yes and no, personally I favor the sysv based setup, which requires tool support to get the mounts right 1156005447 Q * Johnnie Quit: G'bye! 1156005454 J * Johnnie ~john@dynamic-acs-24-154-53-237.zoominternet.net 1156005460 M * Hollow oh.. i removed init-less support from vcd some days ago ;) 1156005469 M * Hollow well, not really 1156005474 M * Hollow but we have no init styles anymore 1156005489 M * Hollow instead you specify the command like on kernel command line init=/sbin/foo 1156005516 Q * Johnnie 1156005522 M * Bertl well, that would be a ko reason for me, as I have many guests which are just sysv (no init inside, not even the executable) 1156005524 J * Johnnie ~john@dynamic-acs-24-154-53-237.zoominternet.net 1156005530 Q * Johnnie Read error: Connection reset by peer 1156005531 Q * kaner Server closed connection 1156005551 J * kaner kaner@strace.org 1156005557 M * Hollow hm.. i really dislike init-less guests 1156005582 M * Bertl that's one useless process less IMHO 1156005633 M * Hollow well, it introduces much special case ugliness 1156005657 M * Bertl like? 1156005698 M * Hollow like shuttind down the guest on sys_reboot instead of just killing it, like a normal system would do, reboot inside does not work, just reboot -f etc pp 1156005813 M * Bertl well, it will probably disappoint you, that those guests do not have a reboot either :) 1156005840 M * Hollow as i said... too much special case ugliness... 1156005845 M * Bertl the desire of mail and web servers to reboot is limited IMHO :) 1156005919 M * Hollow well, if people really demand it, i probably have no choice ;) 1156005964 M * Bertl IMHO it is an important feature regarding light-weight 1156005977 M * Bertl especially if you have lw units of 4-5 processes 1156005994 M * Bertl (in which case init easily covers 20% or so) 1156006032 M * Hollow would it be ok to simply kill on sys_reboot? that would probably require no change then.. 1156006074 M * Bertl I think the best solution would be to use the various sys_reboot() codes to do different things 1156006099 M * Bertl check a typical reboot -f (on gentoo?) with the debug functionality 1156006118 M * Bertl you will (probably) see that this is not a single syscall 1156006171 M * Bertl the helper could easily use that fact to first do some shutdown (maybe with a time limit?) and then kill off the context 1156006218 M * Hollow i will take a look, maybe things got easier with the state change approach now 1156006245 M * Bertl I also think that a 'gentoo' version of the sysv init is quite doable 1156006253 M * Hollow regarding the mounts, i have to think of a better solution.. 1156006260 A * Hurga is always surprised how complicated the vserver stuff can be. 1156006262 M * Hollow yep, it is 1156006301 M * Bertl Hurga: 60% is functionality and 40% is workarounds for 'broken' assumptions 1156006312 M * Hollow heh 1156006322 M * Hurga Bertl: yes, looks about right :) 1156006427 M * Bertl Hollow: in general, it would be advisable to do guest mounts from the host, within the guest namespace, and context 1156006434 M * Hollow Bertl: the ugly thing here is to call /bin/mount, but IIRC this is needed because of mount helpers for some filesystems, right? 1156006445 M * Hurga But it's an interesting opportunity to learn more about the dirty details of unix/linux. 1156006449 M * Hollow a simple mount(2) will probably not do, right? 1156006516 M * Bertl AFAICR, the helpers also utilize sys_mount() at least for all (currently) relevant filesystems, only the options are handled by those helpers 1156006555 M * Bertl but it is probably easier to wrap mount(1) 1156006570 M * Hollow probably easier, yep.. but uglier too :) 1156006581 M * Hollow anyway, will thiink about it 1156006689 M * Bertl are we currently missing any functionality (for your tools) in 2.1.x? 1156006715 M * Hollow including the latest helper and accounting patches, no 1156006750 M * Bertl btw, the last patch changed the include files a little, so that the SOCK types do not collide, and they got moved into an userspace include file 1156006776 M * Hollow yep, i saw it, already integrated into libvserver 1156006796 M * Bertl will add a few #defines or enums for the field indexes too (like read/write/error) 1156006814 M * Hollow yep, sounds good 1156006828 M * Hollow ah, one feature is missing... the accounting part in rlimit_mask 1156006845 M * Bertl okay, are you interested in the slab and page accounting stuff too? 1156006860 M * Hollow yeah, why not... 1156006864 M * Bertl (and probably scheduler info) 1156006873 M * Hollow also extending vx_info with running thread, uptime etc would probably be nice 1156006938 M * Bertl okay, I also plan to add a somewhat contraversal flag (maybe it should get a special compile time option) to hide away an entire context :) 1156006952 M * Bertl *contro 1156006963 M * Hollow lot of paranoia stuff lately ;) 1156006994 M * Bertl I feel like we have ignored that area for some time, although there were demands and suggestions 1156007032 M * Bertl the folks who planned to do honey pots and supervision contexts always asked for such things 1156007069 M * Hollow honey pot? 1156007079 M * Bertl and to be honest, I felt like it was too dangerous, but I think with a proper option, everybody can decide for themselves 1156007087 M * matti Bertl: You can add some permanent sysctl. 1156007099 M * matti Bertl: Like grsec_lock in grsecurity. 1156007115 M * matti Bertl: Once activated, cannot be changes till reboot. 1156007143 M * Bertl hmm, yeah, maybe we do something like that for certain things, good idea 1156007173 M * Hollow currently sysctl is completely EPERM, right? 1156007175 M * matti Bertl: For example vserver.permanent.hide.context = 1156007188 M * Hollow ah.. you mean on the host 1156007208 M * matti Bertl: Or somethinf. 1156007218 M * Bertl matti: I would more tend to a syscall command, but the concept is the same 1156007219 A * matti is really tired, sorry for any typos. 1156007235 M * matti Bertl: Indeed. 1156007247 M * matti :-) 1156007262 M * Hollow Bertl: what is honey pot? 1156007269 M * matti BTW, sorry for interrupting discution. 1156007271 M * matti ;] 1156007279 M * Hollow and don't we have a supervision context? xid=1? 1156007289 M * Bertl http://en.wikipedia.org/wiki/Honeypot_(computing) 1156007290 M * matti s/discution./discussion 1156007337 M * Bertl yes, thing is, you could have a logger running on a vserver host, you want to stay invisible, for example 1156007338 M * Hollow i.e. honey pot = completely hide ctx? 1156007388 M * Bertl OTOH, if this feature is easily available, it could as well be used for hiding spyware and/or viral stuff 1156007421 M * Bertl so it might make sense to limit this to an early host startup case or so 1156007462 M * matti Bertl: Well, this sounds almost bad like blue pill for virtualization and hardware that supports vt bit ;p 1156007507 M * Bertl hehe, was just an idea, and it will definitely be off by default 1156007520 M * matti " 1156007522 M * matti :-)) 1156007524 M * matti Hehehe. 1156007593 M * matti Bertl: Maybe only some certain socket or some limited functionality only? 1156007602 M * matti Bertl: Is such hidden context? 1156007678 M * matti Bertl: Enforcing some limited functionality? To keep some sanity over possible insanity usage ;] 1156007732 M * matti Bertl: But, ability to do some hidden information accounting from guest would be nice. 1156007756 M * Hollow well, the privacy option already hides certain things, no? 1156007763 M * Hollow maybe just extend that one 1156007788 M * matti Hollow: Yes, but. What will happen, when someone will take control over host? 1156007788 M * Hollow and let userspace fine-tune the privacy features if enabled 1156007796 M * Bertl http://paste.linux-vserver.org/262 1156007804 M * Bertl something like this :) 1156007810 A * matti looking. 1156007830 M * Hollow Bertl: isn't it quite the same as privacy? 1156007836 M * matti Bertl: Sounds nice. 1156007846 M * Hollow and not using state_admin 1156007847 M * Bertl no, privacy blocks you from entering the guest 1156007864 M * Hollow i thought privacy disables certain things in xid = 1? 1156007865 M * Bertl it still shows all the tasks and resources (like in vserver-stat) 1156007880 M * Hollow and state_admin is the one to not allow migrates 1156007887 M * Hollow (and other things) 1156007893 M * Bertl administration in general 1156008017 M * Hollow it seems we need two things here: 1) hide info in xid = 1, 2) prohibit admin commands 1156008020 M * Hollow right? 1156008032 M * matti Yep. 1156008040 M * matti Something like fire and forget. 1156008041 M * matti ;] 1156008046 M * matti Until reboot ;p 1156008097 M * Bertl well, basically we have a minor bug in the current logic, but I'm working on that ... 1156008112 M * Bertl the syscall commands fall into three categories 1156008121 M * Bertl - information gathering 1156008135 M * Bertl - context/flag/whatever manipulation 1156008143 M * Bertl - context creation/destruction 1156008169 M * Bertl the manipulation part falls into two subcategories 1156008180 M * Bertl + changes for the context 1156008193 M * Bertl + changes for tasks/users 1156008214 M * Hollow the first being flags, the second rlimits, e.g.? 1156008233 M * Bertl no, the second being migration and signalling 1156008239 M * Hollow ah, ok.. 1156008261 M * Bertl now, from the 'old days' we have two 'basic' flags 1156008281 M * Bertl (which always get confused, even by myself as you can see in the code) 1156008285 M * matti ;] 1156008297 M * Bertl INFO_LOCK and INFO_PRIVATE 1156008317 M * Bertl my recent patch _again_ used INFO_LOCK instead of INFO_PRIVATE 1156008354 M * Bertl (but that will be fixed soon :) 1156008368 M * Bertl in addition to that, we have now STATE_ADMIN 1156008368 M * Hollow lock should prohibit migration? 1156008385 M * Bertl migration _from_ inside a context to _another_ context, yes 1156008393 M * Hollow hu? 1156008406 M * Hollow shouldn't that be impossible at all? 1156008415 M * Bertl yeah, that's the problem, it isn't implemented yet 1156008449 M * Hollow ah.. i remember.. this should be used together with prolific in the future? 1156008451 M * Bertl but given that there is some buisness logic behind that (like parent/child relations) that would not be a problem 1156008477 M * Bertl now for the privacy aspects, I see two flags/cases 1156008484 M * matti k, I need some sleep. 1156008488 M * Hollow night matti 1156008488 M * Bertl - the already present STATE_ADMIN 1156008490 M * matti Too long uptime. 1156008493 M * matti Hollow: Thanks. 1156008493 M * Bertl matti: good nicht! 1156008496 M * matti Bertl: Thanks :) 1156008497 M * Bertl *nigh! 1156008505 M * Hollow night is nich good 1156008506 M * Hollow ;) 1156008520 M * matti I see "things" - this means "you probably need some sleep now" ;] 1156008520 M * Bertl - and a future STATE_INFO 1156008524 M * matti So, later. 1156008525 M * matti ;) 1156008571 M * Hollow Bertl: ah, and xid = 1 should respect those flags as well then? 1156008597 M * Bertl while the STATE_ADMIN is supposed to allow manipulation, the STATE_INFO should allow information gathering 1156008618 M * Hollow another thing comes to my mind here: spectator cap, i read that in some comments.. 1156008642 M * Hollow but i'm probably too fast :) 1156008650 M * Bertl yeah, I'd like to make that a capability, but the capability system is currently frozen with 32caps 1156008683 M * Bertl so it would require to extend that, and I made a few suggestions there (on lkml) but got no feedback 1156008698 M * Hollow as always.. 1156008699 M * Hollow ;) 1156008711 M * Bertl and I'm not sure that we want to carry around a second BME for two years :) 1156008719 M * Hollow heh 1156008750 M * Bertl OTOH, once mainline uses up the last cap (currently used for CAP_CONTEXT) we have some work to do anyways :) 1156008784 M * Hollow maybe some of the patient ibm folks can push it *gg* 1156008790 M * Bertl lol 1156008797 M * Hollow like with bme 1156008814 M * Bertl dhansen: what about promoting 64bit caps after BME? 1156008818 M * Hollow hehe 1156008874 M * Bertl if he says yes, then I got myself some extra work right now :) 1156008909 M * Bertl so basically the ADMIN will fall into two flags 1156008926 M * Bertl one which allows info syscalls, and the other which allows admin syscalls 1156008953 M * Bertl the necessary categorization is already present after the switch changes, which drastically simplified the logic 1156008975 M * Hollow yep, i finally had the time to got through the switch changes, looks very clean now 1156009028 M * Bertl but the aim of the hide flag is a little different, it is supposed to make the guest invisible as far as possible 1156009044 M * Bertl i.e. you can detect it quite easily, if you probe for it 1156009047 Q * fs Ping timeout: 480 seconds 1156009060 M * Bertl (or stumble over it when you try the same xid) 1156009077 M * Bertl but it will not show up by default ... 1156009081 M * Hollow well, if you prohibit info + admin syscalls, and respect it in xid = 1 too, it should be ok, no? 1156009181 M * Hollow and respect it in /proc/virt* too of course 1156009189 M * Bertl probably, another question would be, who uses INFO_HIDE right now? 1156009217 M * Bertl I would be inclined to move that functionality to a new flag, called HIDE_VINFO 1156009246 M * Hollow i don't use it, it would render the vserver changes to gentoos baselayout useless 1156009269 M * Bertl and reuse the INFO_HIDE for the STATE_INFO inverse 1156009269 M * Hollow since we check for VxID in /proc/self/status to disable certain things 1156009312 M * Bertl doener, daniel_hozac: do the tools (in any version) use INFO_HIDE as some default? 1156009374 M * Bertl while the STATE_ADMIN has a good reason to be a one-time flag, the hiding/info has no reason to be 1156009403 M * Hollow i.e. STATE_* flags should be one-time flags? 1156009418 M * Bertl AAMOF, they are :) 1156009464 M * Hollow ok.. ;) 1156009499 M * Bertl originally I planned to call them OTSC_SETUP 1156009500 M * Hollow yeah, info_hide sounds more logical.. 1156009515 M * Hollow one-time-state-change? 1156009517 M * Bertl but I thought nobody would figure that acronym 1156009682 M * Hollow Bertl: apropos INFO_* flags.. do you plan reusing the legacy ones? (sched, proc, ulimit, nspace, AFAICR) 1156009696 M * Hollow *nproc 1156009704 M * Bertl btw, even with INFO_HIDE/HIDE_INFO you could detect the 'guest' case easily in your scripts 1156009715 M * Bertl the XID: information is printed regardless 1156009751 M * Bertl ULIMIT and NSPACE is purely userspace 1156009752 J * fs fs@213.178.77.98 1156009755 M * Bertl wb fs 1156009766 M * Bertl LOCK will have to wait for later 1156009769 M * Hollow hm.. where is xid printed in case of info_hide? 1156009797 M * Bertl /proc/self/status should have it 1156009819 M * Hollow it doesn't... http://paste.linux-vserver.org/263 1156009860 M * Bertl interesting ... checking now 1156009898 M * Hollow well, we do not need xid, just some point where to check if we are a guest would suffice 1156009942 M * Bertl the important question is, why do you need to check? (i.e. what functionality is missing inside a guest)? 1156009970 M * Bertl IMHO it would be better to check for that functionality instead 1156009994 M * Bertl e.g. if your scripts usually create devices (like suse seems to do) 1156009999 M * Hollow e.g. virtualized /dev/console, keymap settings, clock settings (this should be possible with the virtualized time feature now, right?) 1156010010 M * Hollow mounting 1156010016 M * Bertl then checking for the ability (to create devices) is probably the best choice 1156010019 M * Hollow ok, we have secure_mount foir this 1156010046 M * Hollow dinner.. brb 1156010055 M * Bertl k, enjoy your meal! 1156011420 M * daniel_hozac Bertl: re: the context-mount patch, that won't work for dynamic contexts, will it? 1156011447 M * Bertl no, but they will be gone after 2.2.0 anyways 1156011458 M * daniel_hozac yeah, i figured :) 1156011466 M * Bertl so I can live with some kind of special casing there 1156011468 M * doener but that explains Hurga's problems with it 1156011505 M * Bertl i.e. have an fstab.xid or so, which warns/bails out with dynamic contexts 1156011522 M * daniel_hozac yeah. 1156011522 M * Bertl in general the tools should do one of two things (in the future) 1156011544 M * Bertl - either print a big fat warning on dynamic contexts that they will go aways RSN 1156011581 M * Bertl - or do some dynamic allocation and handle the upper range as available (with the proper revision number) 1156011615 M * Bertl the second one would disable 'classic dynamic' contexts right now 1156011630 M * Bertl (and probably avoid many special cases/bugs) 1156011634 J * yarihm ~yarihm@84-74-17-70.dclient.hispeed.ch 1156011648 M * daniel_hozac i guess enrico would oppose the latter before the config stuff is written... 1156011675 M * Bertl config stuff? 1156011691 M * daniel_hozac i.e. an API to access the configuration tree. 1156011698 M * daniel_hozac preferably with exchangable backends. 1156011710 M * Bertl ah, well, is he writing on that? 1156011723 M * daniel_hozac i don't know... 1156011741 M * Bertl okay, me neither ... but yeah, might be .... 1156011759 M * Bertl to some extend, you are the victim here :) 1156011776 M * daniel_hozac hehe. 1156011799 M * daniel_hozac i've been meaning to work on it myself, but i've been dragging my feet about it. it's not really "fun" and exciting stuff :) 1156011826 M * Bertl yes, what about making it dead simple, something like: 1156011843 M * doener daniel_hozac: maybe you want to work on a kernel_execve? or at least figure out its requirements for me? ;) 1156011859 M * Bertl start with the highest available (non-dynamic) pid, and check for 'existing' context files via some grep 1156011862 M * daniel_hozac lol, doener, that's your thing ;) 1156011866 M * doener might be fun and exciting, especially exciting when it bails out in funny ways :) 1156011899 A * Hurga tries to find out what dynamic contexts are 1156011900 M * Bertl then simply take that (at config/build time) and 'declare' this context id was chosen, if you want to change it, bla bla 1156011900 M * daniel_hozac Bertl: the config stuff was mostly so we don't use an existing but not started guest's xid. 1156011940 M * doener Hurga: each context has a unique number assigned to it, called xid 1156011941 M * Bertl AFAICT, all configs _must_ reside in /etc/vservers (or the proper config path for that) right? 1156011950 M * daniel_hozac well, technically, no. 1156011967 J * tatiane ~tatiane@201009018147.user.veloxzone.com.br 1156011973 M * doener Hurga: if you don't explicitly assign one, it gets a dynamic one, ie. it might change on each start of the vserver 1156011976 M * daniel_hozac i haven't actually tried it, but it should be theoretically possible to use another directory for a single guest. 1156011991 M * Bertl so a simple 'egrep '^$' /config/dir/*/context should suffice, no? 1156012001 M * Bertl daniel_hozac: for the config? 1156012004 M * daniel_hozac yeah. 1156012012 M * Bertl how would you specify that?! 1156012026 M * Bertl I mean, how would the tools ever find it? :) 1156012028 M * daniel_hozac vserver /path/to/guest/config start 1156012031 M * daniel_hozac etc. 1156012035 M * daniel_hozac the support is all there. 1156012045 Q * tatiane 1156012049 M * daniel_hozac in fact, it's how the utils usually invoke themself. 1156012050 M * Hurga doener: So it would be better to assign a context in /etc/vservers/vserver-name/context ? 1156012070 M * doener Hurga: yes, and it will be required sometime in the future 1156012076 M * Bertl daniel_hozac: fascinating but probably irrelevant in this case ... 1156012080 M * doener but only add that file when the vserver is stopped 1156012087 M * Hurga *nod* 1156012090 M * daniel_hozac Bertl: agreed, we can never really cater to that case. 1156012110 M * Hurga arbitrary number? 1156012114 M * daniel_hozac 2-49151. 1156012121 M * Bertl (for now) 1156012125 M * Hurga ok... 1156012130 M * Bertl 2.2.x will have full range 1156012140 M * daniel_hozac well 2+? 1156012152 M * daniel_hozac i mean, 0 and 1 will still be special, right? 1156012166 M * Bertl yep, 2-65535 maybe 0 and 1 too (but unlikely) 1156012199 M * Bertl but I might be open to moving the spectator to -1 :) 1156012207 A * Hurga thinks 49149 contexts are sufficient for him. 1156012224 M * Bertl this is something I'm thinking about for some time now, btw ... 1156012263 M * Bertl it would at least avoid the issues folks have using xid=1, but would require to move current -1 meaning to -2 or so 1156012280 M * Bertl s/meaning/functionality/ 1156012325 M * daniel_hozac isn't -1 and -2 used? 1156012337 M * Bertl at least -1 is 1156012344 M * daniel_hozac IIRC there at least one syscall that uses -2 for some special meaning. 1156012350 M * daniel_hozac i can't remember what or which syscall though. 1156012360 M * Bertl probably legacy and fake init :) 1156012362 J * pisc1 ~pampel@p50878A71.dip0.t-ipconnect.de 1156012367 M * Bertl wb pisc1! 1156012578 M * daniel_hozac legacy indeed, "dirty hack for capremove" is what the kernel has to say. 1156012709 M * Bertl so that would go away then 1156012748 M * daniel_hozac wouldn't it be better to make it a cap while we're at it? 1156012757 M * Bertl assumed we can make the spectator a capability, then there would be no need ... my words :) 1156012812 M * Bertl Hollow already suggested to get support from 'the patient IBM folks' and do 64bit caps for mainline :) 1156012824 M * daniel_hozac hehe. 1156012994 M * daniel_hozac any particular reason it has to be a regular cap and can't just be a ccap? 1156013042 M * Hollow i already wndered about that too 1156013106 M * Hollow sorry, have to go again.. will be back in an hour 1156013667 M * Bertl daniel_hozac: we don't have ccaps on xid=0? 1156014423 Q * virtuoso Ping timeout: 480 seconds 1156014479 J * h01ger ~holger@217.114.79.23 1156014742 M * daniel_hozac Bertl: so we want xid=0 to be the spectator? 1156014776 M * daniel_hozac i.e. without doing anything special. 1156014778 J * Hurga- nobody@p508A98C6.dip0.t-ipconnect.de 1156014781 M * Bertl well, no, but we want xid=0 to _be able_ to _become_ a spectator too 1156014806 M * Bertl at least I would think that this would be one goal 1156014823 M * daniel_hozac ok then. 1156014842 M * Bertl but yes, it's not necessary to extend the mainline cap system for that 1156014853 M * Bertl we could just add 'per task' caps on our own 1156015139 Q * Hurga Ping timeout: 480 seconds 1156015810 M * Bertl well, actually a few task flags would suffice ... now that I think of it ... 1156016382 M * daniel_hozac Hollow: did you ever answer my question about compatibility in libvserver? i.e. will there be any? 1156016711 J * crazy_penguin ~Unknown@86.105.69.248 1156016725 M * crazy_penguin Good evening all! 1156016888 M * Bertl evening crazy_penguin! 1156016912 M * crazy_penguin yo Bertl! 1156018004 Q * pisc1 Ping timeout: 480 seconds 1156018620 M * comfrey_ yo yo. 1156018645 M * comfrey_ any one else having system halts on dual core procs? 1156018683 M * Bertl nope, where do you have that and what exactly happens? 1156019416 Q * gerrit Read error: Connection reset by peer 1156019436 J * virtuoso ~s0t0na@shisha.spb.ru 1156019573 M * Bertl wb virtuoso! 1156020135 M * Bertl daniel_hozac: I wonder if I'm paranoid, but shouldn't we lock the task before doing clr_vx_info() in e.g. free_task() = 1156020139 M * Bertl s/=/? 1156020300 M * Hollow daniel_hozac: hm, compatibility to what? 1156020301 M * daniel_hozac hmm, why? 1156020334 M * daniel_hozac Hollow: 2.0, 2.1, 2.2, etc... i.e. backwards-compatibility, or will it just require the current latest-and-greatest kernel? 1156020335 M * Bertl well, the task lock protects against vx_info changes, clearing that out certainly is such a change 1156020357 M * Bertl what if the following happens: 1156020389 M * Hollow daniel_hozac: well, depends... e.g. we have support for both sched_v3 and v4 with one interface in libvserver 1156020396 M * Hollow but it also depends on the libvserver release 1156020407 M * Hollow you will need 2.1.1 for all features, or you'll get ENOSYS 1156020415 M * Hollow but that is not that tragic too 1156020440 M * daniel_hozac obviously for features that aren't implemented at all, that's correct. 1156020461 M * daniel_hozac i was thinking more about supporting the older interfaces that 2.0 is using of all the commands. 1156020479 M * daniel_hozac (IMHO support for <2.0 is not that interesting) 1156020510 M * Hollow well, we might introduce real backwards compatibility, if folks want to use libvserver on <2.1.1 1156020515 Q * ntrs_ Read error: Connection reset by peer 1156020524 J * ntrs_ ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1156020570 M * Bertl daniel_hozac: http://paste.linux-vserver.org/264 1156020574 M * daniel_hozac i was just thinking if it would be feasible to use it as a backend for util-vserver. 1156020611 M * Hollow daniel_hozac: PITA IMO... the libvserver of util-vserver is bloated with lots of stuff, either you create an own lib for these (libutil-vserver or so) 1156020619 M * Hollow or you really change a lot of code 1156020646 M * daniel_hozac bloated with what? 1156020670 M * Bertl I _think_ daniel is just referring to the compat syscalls 1156020689 M * daniel_hozac Bertl: haven't you already lost if thread A is running free_task? 1156020695 M * Hollow fmt functions, list functions, flag conversion functions.. 1156020718 M * Hollow various parsers.. 1156020723 M * daniel_hozac ah right, that's true. 1156020776 M * daniel_hozac vc_xidopt2xid for instance is really handy though. 1156020859 M * Hollow well, the implementation util-vserver uses various high level function, to access the util-vserver config... not libvservers job imo 1156020899 M * daniel_hozac ok, so the libvservers have entirely different goals. 1156020925 M * Hollow i'd say so.. but the approach with splitting things in libvserver and libutil-vserver or so would probably make most sense 1156020927 M * Bertl daniel_hozac: not sure, for example proc might have a reference to the task (not sure that is an accounted one yet) 1156020982 M * Bertl and free_task_struct() does not necessarily free it 1156021056 J * ntrs__ ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1156021056 Q * ntrs_ Read error: Connection reset by peer 1156021093 M * daniel_hozac it doesn't? 1156021106 M * Bertl checking now 1156021130 M * Bertl okay, it takes a reference 1156021150 M * Bertl guess it is fine then ... 1156021279 M * Bertl okay, nap attack ... maybe back later ... 1156021285 N * Bertl Bertl_zZ 1156021292 M * daniel_hozac good night! 1156021311 M * Hollow daniel_hozac: regarding backwards compatibility, i'd like to release libvserver-2.0 for 2.1.1/2.2, and maintain backward compatibility for it as long as the abi does not need to change, if it does need, we will just release a new libvserver with .so-version++ (that may be compatible to olde relases as well then) 1156021384 M * daniel_hozac ok. 1156023110 Q * virtuoso Ping timeout: 480 seconds 1156023205 M * matti Hollow: Hello there :) 1156023222 M * matti Hollow: What about hidden guest issue? 1156023333 M * Hollow matti: hm? 1156023368 M * matti Hollow: Any ideas around that? 1156023381 M * matti I just woke up. 1156023384 M * matti From little nap. 1156023386 M * matti :> 1156023410 M * Hollow which hidden issue? you mean the contexts with persistent, no process and no state_admin? 1156023432 M * matti Yes. 1156023438 M * matti Sorry, I was a bit tired ;p 1156023521 M * Hollow well, no.. this needs a kernel fix 1156023527 M * Hollow or a reboot :p 1156023585 M * crazy_penguin Good night! Sleep well! :) 1156023611 M * daniel_hozac the ~state_admin on shutdown isn't implemented yet? 1156023621 M * Hollow daniel_hozac: not that i know of 1156023626 M * daniel_hozac ok. 1156023702 M * Hollow daniel_hozac: well, if you create a persistent context with no processes ever in it, there will be no shutdown invoked iirc 1156023766 M * daniel_hozac hmm, true. i guess persistent and ~state_admin are rather conflicting. 1156023814 M * Hollow well, an idea would be to remove persistent on vx_kill 1156023822 M * daniel_hozac i think that's a hack. 1156023824 M * Hollow so you could at least get rid of it 1156023841 M * Hollow hm.. why a hack? 1156023847 M * Hollow ah sure 1156023850 M * Hollow kill sends signals 1156023851 M * daniel_hozac IMHO it would be better to return EINVAL if you try to set persistent without state_admin, or something equivalent. 1156023875 M * daniel_hozac because the combination just doesn't make sense. 1156023876 M * Hollow mhm, that sounds better indeed 1156023899 J * dna ~naucki@53-230-dsl.kielnet.net 1156023902 J * virtuoso ~s0t0na@80.253.205.251 1156024045 Q * crazy_penguin Quit: Ex-Chat 1156024207 Q * dna Quit: Verlassend 1156024338 Q * virtuoso Read error: Connection reset by peer 1156024350 J * virtuoso ~s0t0na@shisha.spb.ru 1156024571 Q * meandtheshell Quit: bye bye ... 1156025124 Q * |gerrit| Quit: KVIrc 3.2.0 'Realia' 1156025264 M * Hollow off to bed now, cu tomorrow 1156026971 J * Johnnie ~jdlewis@dynamic-acs-24-154-53-237.zoominternet.net 1156027338 M * Skram peace, Hollow 1156027598 J * Michi JavaApplet@p548D99C4.dip0.t-ipconnect.de 1156028068 Q * bonbons Quit: Leaving 1156028302 M * michal_ Bertl_zZ: ping;) 1156028345 M * daniel_hozac don't you know it's evil to poke people who are sleeping? ;) 1156028397 M * michal_ nah...it's gone into queue and will poke him just after waking up ;p 1156028423 P * Michi 1156028465 M * daniel_hozac hehe. 1156028511 M * michal_ i'm just wondering ...how to ge ta backtrace so i will know which function has been called from interrupt (and it should not be) 1156028517 M * michal_ not in vserver code 1156028584 M * michal_ or rather - i know which one 1156028588 M * michal_ i don't know who has called it :] 1156028590 M * daniel_hozac WARN_ON(1)? 1156028776 M * michal_ hm, thx, that might work :] 1156028779 M * michal_ will try now 1156028970 M * daniel_hozac worked for me :)