1143158590 M * Bertl daniel_hozac: any ideas regarding vc_set_vhi_name(): Function not implemented (ML)?
1143158603 M * daniel_hozac someone else got that too?
1143158604 M * daniel_hozac finally!
1143158628 M * daniel_hozac i enabled vserver debugging to see if the switch was called at all, and that made it disappear.
1143158628 J * hauntmisery ~hauntmise@h145.65.40.69.ip.alltel.net
1143158634 M * Bertl daniel_hozac: I suspect a return code which gets messed up
1143158642 M * Bertl welcome hauntmisery! :)
1143158646 M * hauntmisery hey!
1143158647 M * hauntmisery thanks
1143158664 M * daniel_hozac i set errno to 0 before the call, and errno was equal to ENOSYS and return value -1 after.
1143158688 M * Bertl do you have the assembelr code of that part?
1143158709 M * Bertl i.e. 10 lines before the syscall, and 10 lines after ...
1143158771 M * Bertl hauntmisery: so, what server talk did you have in mind?
1143158801 M * daniel_hozac Bertl: well, it's in a shared library linked against another shared library...
1143158808 J * lilalinux__ ~plasma@dslb-084-058-202-169.pools.arcor-ip.net
1143158994 M * daniel_hozac Bertl: http://daniel.hozac.com/vserver/libvserver.so.objdump http://daniel.hozac.com/vserver/rpm-fake.so.objdump
1143159092 M * Aiken Bertl about 1 minute longer with the std kernel
1143159104 M * Bertl great!
1143159251 Q * lilalinux_ Ping timeout: 480 seconds
1143159313 P * hauntmisery 
1143159496 Q * ntrs Quit: Leaving
1143159926 Q * doener Quit: leaving
1143160358 Q * matta Ping timeout: 480 seconds
1143160776 M * Bertl daniel_hozac: can you reproduce this`
1143160781 M * Bertl s/`/?/
1143160803 M * daniel_hozac the rpm-fake issue? yes, it's totally reproducible.
1143160815 M * daniel_hozac not on my current kernel though.
1143160824 M * Bertl could you use gdb and stop just before the syscall
1143160827 J * dev0 ~arno@85-124-3-80.dynamic.xdsl-line.inode.at
1143160829 M * dev0 hi
1143160834 M * Bertl daniel_hozac: then dump registers
1143160841 M * Bertl welcome dev0!
1143160876 M * daniel_hozac Bertl: will gdb work over the context creation?
1143160893 M * daniel_hozac that's where i got my ~1 minute hangs with strace.
1143160909 M * Bertl hmm, we could disable that temporarily
1143160922 M * Bertl I was thinking of making that a config option actually
1143160948 M * dev0 a question: is it possible, to use loop aes inside a vserver (and controlling from inside the vserver).  I have full root privileges on the master. 
1143160955 M * daniel_hozac oh, cool.
1143160969 M * daniel_hozac well, i'll see if this new kernel fixes it.
1143160977 J * knoppix_ ~knoppix@68-188-37-15.dhcp.stls.mo.charter.com
1143160991 M * Bertl dev0: yes, I thinks so, but it will at least require to put a loop device into the guest
1143161016 M * Bertl dev0: unless you want to mount it on the host
1143161046 M * dev0 indeed, I need to patch the kernel.
1143161117 M * Dr4g Hello Bertl :D
1143161128 M * dev0 but my problem is, I'm missing some devices, e.g. /dev/urandom and /dev/loop0 
1143161142 M * dev0 may I be able to create them with mknod?
1143161143 M * Bertl Dr4g: hey!
1143161156 M * Bertl dev0: you can copy them from the host
1143161168 M * dev0 ok that sounds well
1143161184 M * Bertl dev0: but be aware that the guest can then do certain things with the loop device which reduce security
1143161199 M * dev0 I don't care, it's just me and me ;)
1143161211 M * dev0 I don't use vserver for security reasons
1143161222 M * Bertl excellent, then go ahead
1143161251 M * Bertl you might need one or the other ccap (or cap) to allow mounting/unmounting and the key stuff
1143161267 M * dev0 indeed
1143161297 M * dev0 I got problems with mount
1143161312 M * dev0 but later, I'm now trying to build a suitable kernel module
1143161321 M * Bertl are you using the stable 2.0.x or devel 2.1.x branch?
1143161553 M * dev0 oh :o)
1143161556 M * dev0 I'm using 2.0
1143161570 M * dev0 2.0.1
1143161584 J * mazsola ~skh@84.21.10.3
1143161587 M * mazsola hi all
1143161600 M * daniel_hozac hi
1143161758 M * dev0 urgs I need to build the whole kernel I think *g*
1143161873 Q * coocoon Ping timeout: 480 seconds
1143162503 Q * knoppix_ Quit: Leaving
1143163031 J * Smutje_ ~Smutje@xdsl-87-78-43-79.netcologne.de
1143163158 Q * Smutje Ping timeout: 480 seconds
1143163158 N * Smutje_ Smutje
1143163258 M * dev0 memlock: Cannot allocate memory <- uhm, a security setting in vserver I forgot?
1143163264 M * dev0 Couldn't lock into memory, exiting.
1143163269 M * Bertl yep
1143163276 M * Bertl you need to add that capability
1143163327 M * Bertl CAP_IPC_LOCK
1143163505 M * dev0 better.
1143163988 M * dev0 ioctl: LOOP_SET_FD: Inappropriate ioctl for device <- next problem. isn't there a page where alle the capabilities are documented, that would make your life easier, since I don't need to ask you *g*
1143164010 M * Bertl /usr/include/linux/capability.h
1143164032 M * Bertl but it's interesting that the loop setup fails
1143164085 M * Bertl argh, seems kernel folks decided that this needs CAP_SYS_ADMIN
1143164093 M * Bertl Allow setting encryption key on loopback filesystem
1143164119 M * dev0 indeed, that's where it fails
1143164122 M * Bertl you probably want to 'adjust' that a little
1143164146 M * Bertl i.e. change the kernel, because you do not want to give SYS_ADMIN
1143164152 M * dev0 I don't?
1143164170 M * Bertl well, you can, of course, but it basically renders all security stuff useless
1143164206 M * dev0 as said that's not the main goal, however I think dropping a line in the source is not a problem.
1143164220 M * dev0 well, let's take a look on the aes loop
1143164241 M * Bertl this sounds useful enough to me to add it to linux-vserver (for the existing crypto loop part)
1143164262 M * Bertl what kernel/patches do you use atm?
1143164279 J * Bobi Bobi@68-188-37-15.dhcp.stls.mo.charter.com
1143164282 M * dev0 vanilla 2.6.14 with patched loop aes. 
1143164289 M * dev0 and vserver of course
1143164358 M * Bertl do you ahve a problem with switching to 2.6.16?
1143164358 M * dev0        if (lo->lo_encrypt_key_size && lo->lo_key_owner != current->uid &&
1143164358 M * dev0             !capable(CAP_SYS_ADMIN))
1143164358 M * dev0  <- well I remove those line and problem is solved :o)
1143164365 M * dev0 uhm why?
1143164389 M * Bertl because that is where the current devel branch is :)
1143164400 M * dev0 lol yes
1143164427 M * dev0 however I'm not that happy to build and boot new kernels on remote machines where I depend on ssh
1143164443 M * Bertl no remote console?
1143164485 M * dev0 you mean serial? no. 
1143164489 M * dev0 pure eitelkeit :D
1143164553 M * Bertl ah, well, okay, so ... url for the aes patch(es)
1143164568 M * dev0 I did it already myself
1143164579 M * dev0  * Still To Fix:
1143164580 M * dev0  * - Advisory locking is ignored here.
1143164580 M * dev0  * - Should use an own CAP_* category instead of CAP_SYS_ADMIN <- btw. in the header of the loop-aes
1143164676 M * dev0 so. "patched" module loaded again
1143164792 M * dev0 hrm, still does not work, probably this cap isn't just needed in loop.ko?
1143164806 M * Bertl well, it probably checks in several places
1143164832 M * Bertl as I said, we can make that a ccap in 2.6.16-vs2.1.x
1143164877 M * dev0 what exactly would you do?
1143165060 M * dev0 http://rafb.net/paste/results/OAw39D57.html, my patch against http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.1c.tar.bz2 - however, ther perm might still be checked outside loop.c
1143165375 M * Bertl well, I'll have a short look at the patch, and the required changes in the kernel, then you get a patch for testing ...
1143165411 M * dev0 that's definitively the best support I ever got for something.
1143165438 M * daniel_hozac welcome to vserver ;)
1143165451 M * Bertl ah, I forgot, folks expect that I charge something, otherwise it is not considered serious ... nah, just kidding :)
1143165506 M * Bertl dev0: but in return, you can write up a wiki page to explain how this can be done ... (i.e. what is required and such, once we are finished)
1143165525 M * dev0 to set-up loop-aes? I'll.
1143166335 M * dev0 btw. "Prepared a course for students and taught some years object oriented Software Engineering at the Technical University of Vienna." <-  holy shit, I'm studying there software engineering :o)
1143166372 M * Bertl well, I do not teach there anymore :)
1143166398 M * dev0 where have you been? complang?
1143166408 M * dev0 institute I mean
1143166501 M * Bertl nope, IFS
1143166712 M * dev0 woho I did eprog there I think. 
1143166755 M * Bertl yeah, probably also fun with Gerald F. :)
1143166779 Q * mazsola Quit: 
1143166817 M * dev0 and rudolf f. too, I just saw you proceeding *eg*
1143166876 M * dev0 +r
1143168065 M * Bertl dev0: okay, you ahve to change all occurrences of
1143168074 M * Bertl !capable(CAP_SYS_ADMIN)
1143168076 M * Bertl to
1143168095 M * Bertl !capable(CAP_SYS_ADMIN) && !vx_ccaps(VXC_CRYPTO_LOOP)
1143168102 M * Bertl in the AES patches/files
1143168115 M * dev0 having 2.1 of the vserver patch?
1143168147 M * Bertl well, probably doesn't matter, but the following kernel patch is against 2.1.1-rc14
1143168197 M * Bertl you also want to include vs_base.h in the files which give you warnings about vx_ccaps not being declared
1143168226 M * dev0 well, I think at least that is clear
1143168230 M * Bertl the patch I'll upload shortly should fix the issue for mainline cryptoloop
1143168249 M * dev0 I'll give a try to 2.0 and my kernel first though
1143168272 M * Bertl #define VXC_CRYPTO_LOOP         0x00200000
1143168282 M * Bertl that's the new context capability
1143168288 M * dev0 good
1143168314 M * Bertl you have to use ^21 for now, tools do not know about it
1143168329 M * dev0 however the name isn't that good. cryptoloop isn't loop-aes
1143168345 M * dev0 of you capability I mean
1143168355 M * Bertl I know, but it is what the capability unlocks in mainline
1143168366 M * dev0 ok
1143168382 M * Bertl i.e. setting the crypto loop parameters (key and such)
1143168423 M * Bertl but if you have a better name (more general) please let me know
1143168461 M * dev0 I don't I just wanted to let you know, that cryptoloop is another concept than loop-aes
1143168470 M * dev0 however I think you might know that pretty well
1143168470 M * Bertl yeah, I know
1143168477 M * dev0 *g*
1143168492 M * dev0 ok, I'm building a new kernel.
1143168520 M * dev0 stable is ok, or you want even -git? *g*
1143168520 M * Bertl hmm, you are still missing my patch :)
1143168528 M * dev0 I know
1143168537 M * Bertl 2.6.16 is fine
1143168580 M * dev0 I have to adapt the .config too, so there is still time to get the patch ;)
1143168600 M * Bertl yeah, it's just test compiling right now
1143168875 M * dev0 the utils need a rebuild too?
1143168892 M * Bertl only if you want to add an option name :)
1143168904 M * Bertl out of the box ^21 should do fine
1143168924 M * dev0 I've 2.0.1 currently, so I do need.
1143168962 M * dev0 oh no, utils are still the same
1143168963 M * Bertl well, it won't hurt, but the kernel has compatibility support (if you enable it)
1143168974 M * Bertl 0.30.210 is recent
1143169010 M * dev0 yes, I don't know why, but I took 0.30.210 utils, and 2.0.1 patch 
1143169028 M * dev0 so still the same.
1143169034 M * Bertl well, that's fine then
1143169039 M * dev0 indeed
1143170880 J * knoppix_ ~knoppix@68-188-37-15.dhcp.stls.mo.charter.com
1143171232 Q * knoppix_ Quit: Leaving
1143171403 M * Bertl dev0: http://vserver.13thfloor.at/Experimental/delta-cloop-feat01.diff
1143171545 M * dev0 oh, I was just wondering, it's a patch for the patch ;)
1143171565 M * Bertl no, it's ontop of 2.6.16-vs2.1.1-rc14
1143171642 M * dev0 yes, but still needs patch-2.6.16-vs2.1.1-rc14.diff nor? ;)
1143171647 M * dev0 that's what I meant.
1143171653 M * Bertl yes
1143171970 M * dev0 well, building.
1143172079 Q * Bobi Quit: Leaving
1143172675 M * dev0 The system is going down for reboot NOW!
1143172707 M * Bertl will it come up again? :)
1143172714 M * dev0 I hope *g*
1143172725 M * dev0 however lilo -R is a great geature
1143172728 M * dev0 feature.
1143172738 M * Bertl yeah, grub has something similar now
1143172743 M * dev0 really?
1143172756 M * Bertl yes, it's a little more complicated to use, but works fine
1143172778 M * dev0 that's is/was definitively a K.O. reason for grub on remote machines
1143172799 M * Bertl well, the missing shell is one for me (on remote machines with console :)
1143172818 M * dev0 2.6.16-vs2.1.1-rc14 #1 Fri Mar 24 04:56:14 up and running
1143172828 M * Bertl good :)
1143172842 M * dev0 Bertl: say it to my boss. he has to pay the sercon ;)
1143172858 M * Bertl nah, a serial cable will do nicely
1143172868 M * Bertl or do you have only one machine?
1143172893 M * dev0 I don't but a serial cable doesn't give me control up from bios
1143172917 M * Bertl on recent systems even that, but control via grub is usually more than sufficient
1143172931 M * dev0 grub can be accessed via serial cable?
1143172938 M * cehteh lilo too
1143172939 M * Bertl yes, of course
1143172961 M * dev0 I think I will do a session in the dc soon *g*
1143172984 M * Bertl interxion?
1143172985 M * cehteh and old compaq bioses had that too ... unfortunally a serial terminal for the bios never became mainstream :(
1143173027 M * dev0 me? no. germany, nuremberg. 
1143173032 M * dev0 ip-exchange
1143173038 M * Bertl ah, ic ...
1143173154 M * dev0 05:07:00 up 6 min,  2 users,  load average: 51.34, 19.55, 7.24
1143173154 M * dev0  <- I think there is a problem
1143173179 M * Bertl how many guests did start up?
1143173198 M * dev0 no one, I just logged in and typed uname -a
1143173206 M * dev0 err one starts automatically
1143173220 M * Bertl is the load rising or falling?
1143173238 M * dev0 still raising
1143173251 M * Bertl what does top or vps report?
1143173264 M * Bertl something respawning maybe?
1143173302 M * Dr4g Hey dev0 Bertl 
1143173312 M * dev0 my shell is lagging ...
1143173315 M * dev0 mompl
1143173339 M * Bertl hey Dr4g!
1143173395 M * dev0 Cpu(s):  0.6% us, 10.2% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi, --> 89.2% si
1143173395 M * dev0  <--
1143173406 M * dev0 qq
1143173427 M * Bertl soft interrupts ... nice
1143173433 M * dev0 indeed
1143173468 M * Bertl udev maybe?
1143173482 M * dev0 deactivated
1143173491 M * dev0 or: not using
1143173499 M * Bertl what do you use?
1143173504 M * Bertl static dev?
1143173509 M * dev0 yes
1143173639 M * Bertl any processes shown in ps/vps?
1143173653 M * Bertl I mean any processes which are there several times
1143173684 J * matta ~matta@71.224.125.126
1143173686 M * dev0 of course, the usual httpds, but they are more or less idle, in fact the whole machine is idling currently
1143173696 M * Bertl welcome matta!
1143173707 M * Bertl dev0: still a high/rising load?
1143173724 M * dev0 yes, I will reboot now. 
1143173732 M * Bertl okay, do so
1143174017 M * dev0 ok, reup again, everything ok.
1143174129 M * Bertl strange, check the logs please
1143174146 M * dev0 I do
1143174148 M * Bertl look for something like modprobe failing or so
1143174177 M * Bertl i.e. if you forgot to install the modules ...
1143174227 M * dev0 I didn't, I don't even have any modules except loop-aes which has to be a module, but I didn't build that until now for 2.6.16
1143174235 M * dev0 built
1143174471 M * Bertl well, it's not vserver or patch specific ...
1143174477 M * Bertl  04:27:28 up 0 min, load average: 0.09, 0.02, 0.00
1143174494 M * Bertl that's the supposedly same kernel here ...
1143174540 M * dev0 and my logs are clearer than clear. nothing unusual
1143174570 M * Bertl did you make a copy of 'ps auxwww' and dmesg somewhere?
1143174614 M * dev0 I have an idea.
1143174689 M * dev0 but I really don't want to bug you, I'm with you, when you say it's not a vserver problem.
1143174757 M * Bertl let's hear
1143174883 M * dev0 I see, the kernel makefile builds genrtc as module (I really should know my configs *g*), software interrupts + no realtime clock should be evil. 
1143174953 M * Bertl which would point to the modprobe issue :)
1143174986 M * dev0 hrm, but that's really strange. I don't see *where* I load genrtc for the current kernel.
1143175012 M * Bertl kernel automatic module loading
1143175023 M * dev0 well, /etc/modules is empty.
1143175029 M * Bertl will invoke userspace '/sbin/modprobe' or so
1143175130 M * dev0 -rw-r--r--  1 root root 12706 Mar 24 04:57 /lib/modules/2.6.16-vs2.1.1-rc14/kernel/drivers/char/genrtc.ko does exist though.
1143175153 M * Bertl what about the modules.dep file?
1143175159 M * Bertl (jsut an idea :)
1143175266 M * dev0 blah. there is only one way to find out *g*
1143175396 M * dev0 nope still the same and genrtc is loaded.
1143175509 M * Bertl ps auxwww 
1143175515 M * dev0 i saved one.
1143175523 M * Bertl okay, stop the guest, just to make sure
1143175818 M * dev0 never seen before. everything but the ksoftirqd is sleeping.
1143175841 M * dev0 and ps of course.
1143175863 M * Bertl hmm, what does /proc/interrupts show=
1143175872 M * Bertl and did you enable irq balancing?
1143175892 M * Bertl (is it an SMP kernel at all?)
1143175927 M * dev0 single amd64 arch
1143175943 M * Bertl x86_64 kernel or just x86?
1143175986 M * dev0 x86
1143176024 M * dev0 I'll take a look on the kernel makefile.
1143176029 M * Bertl hmm, hmm, could you try with vanilla 2.6.16 and the config you used right now (just to make sure it really isn't a vserver issue)
1143176043 M * dev0 even ok.
1143176084 M * Bertl will make myself some breakfast, and go to bed then, but I'll wait for your results :)
1143176117 M * dev0 the night is still young *g*
1143176138 M * dev0 just a question of the date I'd say
1143176840 Q * Dr4g Quit: Open Source Development :: http://dynamichell.org
1143176937 M * dev0 you're right, not a vserver matter. the vanilla kernel has the same problem.
1143176938 M * Bertl right, but the daystar has already risen ...
1143176950 M * Bertl okay, glad to hear
1143176958 M * dev0 for you at least *g*
1143176978 M * Bertl and the thousand other linux-vserver users :)
1143177028 M * Bertl okay, so I'm off to bed .. feel free to hang around and discuss this with the folks still/yet awake
1143177044 M * dev0 nope, I'm going to bed too
1143177060 M * Bertl I'm definitely interested in any results you get and what actually causes this behaviour
1143177077 M * dev0 I'll investigate later(TM).
1143177091 M * Bertl OTOH, the patch should work for older kernels too ...
1143177097 M * Bertl okay, cya, have a good one!
1143177108 M * dev0 you too, and thank you for your help.
1143177112 M * Bertl night everyone! off to bed ...
1143177118 M * Bertl dev0: you're welcome!
1143177122 N * Bertl Bertl_zZ
1143177134 Q * dev0 Quit: later. for sure.
1143180007 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143180077 Q * f_ Quit: 
1143181556 J * DIABLO666 DIABLO666@chello080109193028.1.graz.surfer.at
1143181708 Q * DIABLO666 Quit: 
1143183997 J * Dr4g Dr4g@82-40-203-70.stb.ubr06.uddi.blueyonder.co.uk
1143185021 J * Nick1 Fiona@h-67-100-65-162.chcgilgm.covad.net
1143186466 P * Nick1 
1143186808 J * meandtheshell ~markus@85-124-37-130.dynamic.xdsl-line.inode.at
1143187230 J * gautama ~2235@proxy.dip-badajoz.es
1143187287 P * gautama 
1143187400 J * wolf ~wolf@85.233.97.254
1143187619 Q * wolf Quit: 
1143187956 J * wolf ~wolf@85.233.97.254
1143187969 M * wolf hello... anybody there? 
1143188335 J * Aiken_ ~james@tooax8-172.dialup.optusnet.com.au
1143188533 Q * wolf Quit: Leaving
1143188662 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl
1143188683 J * wogri ~wolf@85.233.97.254
1143188698 Q * Aiken Ping timeout: 480 seconds
1143188960 Q * wogri Quit: 
1143189550 J * pagano ~pagano@lappagano.cnaf.infn.it
1143189664 Q * derjohn Ping timeout: 480 seconds
1143189866 J * wogri ~wolf@85.233.97.254
1143191414 P * frz 
1143191493 Q * shedi Quit: Leaving
1143191638 Q * pagano Ping timeout: 480 seconds
1143191697 J * kir ~kir@swsoft-mipt-nat.sw.ru
1143191698 Q * kir Quit: 
1143191712 J * kir ~kir@swsoft-mipt-nat.sw.ru
1143191730 Q * mkhl Quit: 
1143193421 J * rayk ~rayk@86.59.25.121
1143193447 P * rayk 
1143195036 Q * Smutje Quit: leaving
1143195097 Q * Dr4g Quit: Open Source Development :: http://dynamichell.org
1143195104 J * Dr4g ~Dr4g@82-40-203-70.stb.ubr06.uddi.blueyonder.co.uk
1143195183 J * frzzz ~frz@86.59.25.121
1143198011 J * kir_ ~kir@swsoft-mipt-nat.sw.ru
1143198013 Q * kir_ Quit: 
1143198672 M * Roey hello!
1143199075 M * cmantito hmm, is there a good way to give a vserver a "proper" network interface?
1143199203 M * SiD3WiNDR not at the moment... it's being developed afaik though
1143199485 J * coocoon GrTB0T@p54A06B44.dip.t-dialin.net
1143199489 M * coocoon hello to all
1143199498 M * cmantito SiD3WiNDR: thanks.
1143200181 M * kir cmantito, ngnet is still in development AFAIK. you can do that with openvz though - it has venet virtual network device, and also you have an ability to export a real net device (like eth1) into a guest
1143200213 M * cmantito I'm looking more for the former primarily.
1143200229 M * cmantito openvz? danke :)
1143200280 M * kir cmantito, did you have any problems with openvz? I'd love to hear about it...either technical or political
1143200304 M * cmantito nope, I hadn't considered it primarily because most of the people I talk to work with vserver or UML.
1143200317 M * cmantito but if it does what I need, I'll take a look at it.
1143200380 M * cmantito thanks for the thought, kir :)
1143200456 M * kir cmantito, I believe it does, if you are looking for a way to have a normal dedicated IP for a guest, say to run bind or smth.
1143200467 M * cmantito essentially.
1143200591 J * derjohn ~derjohn@80.69.37.19
1143200876 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1143201013 Q * kir Quit: Leaving
1143201080 M * SiD3WiNDR kir = spammer
1143201081 M * SiD3WiNDR :p
1143201214 J * coocoon GrTB0T@p54A06B44.dip.t-dialin.net
1143201441 M * Roey so when is this ngnet coming to fruition?
1143201449 J * kir ~kir@swsoft-mipt-nat.sw.ru
1143201863 P * Dr4g Open Source Development :: http://dynamichell.org
1143202468 J * shedi ~siggi@tolvudeild-199.lhi.is
1143202643 J * lilalinux_ ~plasma@dslb-084-058-236-034.pools.arcor-ip.net
1143202995 J * |coocoon| GrTB0T@p54A06B44.dip.t-dialin.net
1143203026 J * lilalinux ~plasma@dslb-084-058-202-126.pools.arcor-ip.net
1143203076 Q * lilalinux__ Ping timeout: 480 seconds
1143203083 Q * coocoon Ping timeout: 480 seconds
1143203174 J * lilalinux__ ~plasma@dslb-084-058-230-040.pools.arcor-ip.net
1143203250 Q * tokkee Quit: reboot
1143203286 Q * lilalinux_ Ping timeout: 480 seconds
1143203346 J * lilalinux_ ~plasma@80.69.35.186
1143203521 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com
1143203556 Q * lilalinux Ping timeout: 480 seconds
1143203656 Q * lilalinux__ Ping timeout: 480 seconds
1143203975 Q * Aiken_ Quit: Leaving
1143204272 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143204652 N * Bertl_zZ Bertl_oO
1143205848 J * kir_home ~kir@swsoft-mipt-nat.sw.ru
1143206063 Q * |coocoon| Ping timeout: 480 seconds
1143206333 N * Bertl_oO Bertl
1143206342 M * Bertl morning folks!
1143206452 M * phedny hi Bertl 
1143206463 M * phedny and bye again, i'm gonna take a break :)
1143206548 M * daniel_hozac morning Bertl!
1143206793 M * wogri gomoagn! 
1143206840 M * Bertl gomoagn wogri!
1143206867 M * wogri thanks for rc14 (i was called 'wolf' yesterday), it works like a charm. 
1143206885 M * Bertl ah, good to hear!
1143207489 Q * entroposcope Remote host closed the connection
1143207662 Q * ntrs Quit: Leaving
1143207754 M * Bertl waldi: ping!
1143207762 M * waldi Bertl: icmp echo reply
1143207783 M * Bertl ah, excellent ... did you see the latest changes for rc14 yet?
1143207829 M * waldi yes
1143207858 M * Bertl good, the sched and sendfile stuff is important, but you probably already incorporated that, right?
1143207868 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com
1143207875 M * Bertl wb entroposcope!
1143207881 M * waldi yes, release is scheduled for tomorrow
1143207903 J * Loki|muh loki@satanix.de
1143207908 M * Bertl waldi: excellent! tx-a-lot! :)
1143207919 M * Bertl welcome Loki|muh!
1143207930 M * Loki|muh thanks :) 
1143207931 M * Loki|muh finally
1143208047 M * waldi Bertl: we got a "rueffel" as each new release produces between 1 and 1.5 GiB new packages
1143208068 M * SNy a "rueffel", hehe
1143208078 M * Loki|muh hrhr
1143208111 M * Bertl waldi: well, that's why I usually release patches :)
1143208185 M * Loki|muh 1GB? per day? per week?
1143208213 M * waldi Loki|muh: per release
1143208237 M * waldi i386 and amd64 produces 150 MiB binary packages each
1143208354 M * wogri wow; thats not nothing. On the other hand: Probably there shouldn't be such a short cycle between the releases. To avoid the 'umadumrueffeln'
1143208407 M * Hollow hm, i produce 2K on each new kernel release :)
1143208457 M * Bertl hehe, nearly all kernels since 1.0 are on a 26GB partition
1143208517 J * knoppix_ ~knoppix@68-188-37-15.dhcp.stls.mo.charter.com
1143208575 M * Loki|muh hmmm so, is a mirror needed?
1143208648 Q * wasser Remote host closed the connection
1143209255 Q * harry Ping timeout: 480 seconds
1143210115 Q * matta Ping timeout: 480 seconds
1143210141 J * Viper0482 ~Viper0482@p54977A4C.dip.t-dialin.net
1143210178 M * Bertl waldi: did micah get in touch with you (or the other way round)?
1143210304 M * waldi yep, at least sometimes
1143210952 M * daniel_hozac Bertl: do you really want the sendfile fixes for 2.6.15?
1143210985 M * Bertl nah, just realized that
1143211036 J * harry ~harry@d54C2508C.access.telenet.be
1143211368 M * Bertl welcome harry!
1143211368 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1143211372 M * Bertl wb matta!
1143211739 M * matta hi!
1143212442 Q * wogri Quit: Leaving
1143213545 Q * knoppix_ Quit: Leaving
1143216054 Q * phreak`` Quit: leaving
1143216089 J * phreak`` ~phreak``@styx.xnull.de
1143216419 M * Bertl wb phreak``!
1143216432 M * Bertl Hollow: ping!
1143216460 M * Hollow Bertl: pong
1143216472 M * Bertl do you have a few minutes for me?
1143216477 M * Hollow sure
1143216521 M * phreak`` thanks Bertl :)
1143216528 M * Bertl Hollow: do you think you could 'hack' together a small test program which excercises vserver syscalls with your library?
1143216551 M * daniel_hozac doesn't the util-vserver test suite test most of them?
1143216561 M * Hollow hm, yeah, guess we could do that..
1143216572 M * Bertl daniel_hozac: maybe, not sure ...
1143216576 M * daniel_hozac sorry, no. it doesn't seem to test much of anything.
1143216581 M * Bertl let me elaborate what I'm thinking about
1143216587 M * Hollow *nod*
1143216603 M * Bertl lets assume there are 20 different commands
1143216623 M * Bertl some set something, other get some values, still others create stuff and so on
1143216650 M * Bertl we also have four potential states
1143216660 M * Bertl host, watch, setup and guest
1143216732 Q * shedi Quit: Leaving
1143216739 M * Bertl now, it would be great if the test code would basically exercise a complete cycle of create, set, get and finally kill/exit
1143216767 M * Bertl recording the return values, but continuing unconditional
1143216792 M * Hollow ok, but still plain simple syscall tests, no complete guest startup or things like that..?
1143216792 M * Bertl of course, the path through the various commands has to be chosen carefully
1143216816 M * Bertl Hollow: no, you can assume that a context is running or someting like that
1143216820 M * Hollow ok
1143216833 M * Bertl probably one context for each category
1143216850 M * Hollow and where do the four states appear/belong to?
1143216871 M * Bertl well, the test program will be run from each of those states
1143216900 M * Bertl so basically the state should not concern you
1143216923 M * Bertl except for the setup case
1143216950 M * Bertl because I'm not sure yet we can put the test program in the setup state, though vcontext should do that
1143217020 M * Hollow so, a typical cacle would look like: vx_create(xid); vx_get_flags(xid); vx_set_flags(xid); vx_get_flags(xid); remove_persistent_flag();
1143217024 M * Hollow *cycle
1143217180 M * Bertl sec, brb
1143218193 J * knoppix_ ~knoppix@68-188-37-15.dhcp.stls.mo.charter.com
1143218402 P * frzzz 
1143218420 M * f_ bertl pls_
1143218439 Q * cryo Ping timeout: 480 seconds
1143219279 J * shedi ~siggi@inferno.lhi.is
1143219747 Q * ||Cobra|| Remote host closed the connection
1143220265 Q * knoppix_ Quit: Leaving
1143220504 J * dev0 ~arno@85-124-3-80.dynamic.xdsl-line.inode.at
1143220506 M * dev0 hi
1143220532 M * daniel_hozac hello
1143220658 M * Wonka for german speakers: http://www.heise.de/newsticker/meldung/71236
1143220684 M * Wonka openvz seems to want to get into main
1143220711 M * Wonka at the moment, i would rather want linux-vserver in there...
1143220733 M * kir_home Wonka, why's that?
1143220742 M * daniel_hozac i'd prefer it if neither got in.
1143220783 M * Wonka kir_home: in linux-vserver, you can do just a chcontext. openvz doesn't have such a thing.
1143220805 M * kir_home Wonka, in my opinion, if we all work together and merge sensible parts of OpenVZ, and VServer, and some stuff from Eric Biederman, and some stuff from the IBM folks that would be great. I mean -- merge what is best.
1143220842 M * kir is it someting like env_create in OpenVZ?
1143220859 M * kir sorry looks like I am using two machines at the same time. oh my what a freak am i
1143220885 M * phreak`` kir: haha, great trick :)
1143220916 M * Wonka :)
1143220918 M * kir_home I am two in one
1143220961 M * kir still can not type on two keyboards in parallel :( 
1143220978 M * kir Wonka, can you elaborate on your 'do just a chcontext' for me?
1143220994 M * Wonka there was an example somewhere
1143221001 M * Wonka "chcontext apache"
1143221014 M * Wonka start an httpd in another security context
1143221025 M * phreak`` kir: what is the env_create about ?! does it just set up the container ? then its nearly the same as the chcontext
1143221042 M * Bertl Wonka: chcontext --xid 100 /path/to/something
1143221072 M * Wonka so someone exploiting a httpd bug could cause much less havoc
1143221106 M * Bertl yes, you can ombine that with arbitrary capability restrictions
1143221117 M * Bertl i.e. remove all caps apache doesn't need
1143221121 M * Wonka which is entirely not possible with openvz
1143221139 M * Bertl and apache will just see his threads (and a fake init if you configure that)
1143221144 M * Wonka yes
1143221158 M * Bertl okay, off for dinner now .. back shortly ..
1143221161 M * kir well you can run *just* httpd inside a VPS, no probs, I did that
1143221162 M * Wonka this is something i like about linux-vserver and dislike about openvz
1143221166 N * Bertl Bertl_oO
1143221194 M * phreak`` kir: well problem seems to be, you would need a whole template for that right ?
1143221195 M * Wonka in openvz, you need a complete userland
1143221269 M * kir you need httpd and it's deps (libs it needs). do not need to be the whole userland. if you compile apache statically you need just apache and its data
1143221277 M * Wonka at the moment, i fear linus will accept openvz rather fast, and then say to linux-vserver, what do you want, we already got virtualization
1143221293 M * kir or do you mean you can run smth and then change a context of a running app, or what?
1143221296 M * kir bb in 20 minutes
1143221299 A * kir is away: gone home
1143221326 J * tokkee tokkee@ssh.faui2k3.org
1143221610 Q * Viper0482 Remote host closed the connection
1143221768 Q * kir_home Ping timeout: 480 seconds
1143221774 J * Viper0482 ~Viper0482@p54977A4C.dip.t-dialin.net
1143221971 J * doener ~doener@i5387E7A4.versanet.de
1143222331 J * liquid3649_ ~Viper0482@p54977D74.dip.t-dialin.net
1143222337 Q * liquid3649_ Quit: 
1143222493 Q * Viper0482 Ping timeout: 480 seconds
1143222556 N * Bertl_oO Bertl
1143222568 M * doener evening Bertl!
1143222577 M * Bertl hey doener!
1143223123 M * Hollow Bertl: so...? :)
1143223147 M * Bertl Hollow: sorry, had an emergency
1143223171 J * Viper0482 ~Viper0482@p54977D74.dip.t-dialin.net
1143223187 M * Bertl to make it short, it would be cool to have a test tool which executes all the syscalls and records the return values
1143223204 M * Hollow ok, will try that
1143223210 M * Bertl an alternative would be a tool to do an arbitrary syscall
1143223220 M * Bertl (i.e. only one syscall command with arguments)
1143223236 M * Bertl this could then be used in a test script
1143223255 M * dev0 oh, Bertl, do you remember me? I just solved my interrupt problem. 
1143223286 M * Bertl dev0: yep, I do ...
1143223291 M * Bertl dev0: and, what was it?
1143223293 M * dev0 CONFIG_LBD is evil�
1143223307 M * Bertl aha .. interesting ...
1143223310 M * dev0 indeed
1143223336 M * dev0 I'll now try the loop.ko
1143223370 M * Bertl Hollow: so maybe something where you select the syscall command id, and then pass n arguments which get filled into the right structure?
1143223390 M * Bertl Hollow: that would probably allow for all kind of tests ...
1143223876 M * Bertl okay, off for now, translocating ... back in a few hours ...
1143223885 N * Bertl Bertl_oO
1143224166 M * micah the newer chkrootkit doesn't seem to work properly in a vserver guest because of no init running... it does this:    if (kill (1, SIGXFSZ) == -1 && errno == 3)
1143224184 M * micah { printf("SIGINVISIBLE Adore found\n"); }
1143224215 M * micah when it used to just kill(1, 100) if ( errno == 3)
1143224438 M * ddlp micah: hrm, i notice that too
1143224446 M * micah i guess I will need to do the fakeinit style 
1143224487 M * micah ddlp: i think my guests don't have init running, this is why, but putting "fakeinit" in   /etc/vservers/name-of-the-vs/apps/init/style
1143224492 M * micah might do it...
1143224514 J * dearaujo ~dan@cpe-66-25-189-193.austin.res.rr.com
1143224558 M * daniel_hozac you'd want plain.
1143224574 M * dearaujo Im not sure im doing hashify correctly - is there a way to tell if I did it right?
1143224590 M * dearaujo I can walk you through my steps if needed
1143224614 M * daniel_hozac vserver <name> hashify will do it correctly.
1143224628 M * dearaujo right - but here's the issue
1143224651 M * dearaujo i went to my fs on one vserver and a .hash dir exists
1143224657 M * dearaujo with 00, 01 .. ff
1143224664 M * micah daniel_hozac: isn't plain the default?
1143224673 M * daniel_hozac micah: no, sysv is the default.
1143224680 M * daniel_hozac micah: sysv is the initless one.
1143224684 M * dearaujo i went to another vserver fs and I didnt see a .hash dir - is that right?
1143224692 M * micah daniel_hozac: ah, ok, thanks I was confued
1143224734 M * daniel_hozac dearaujo: do you have your vservers on different filesystems?
1143224740 M * dearaujo no
1143224742 M * dearaujo same
1143224748 M * daniel_hozac dearaujo: /vservers/.hash should be the only hash directory.
1143224763 M * dearaujo hmmm
1143224767 M * daniel_hozac dearaujo: it will contain the hashes for all files in all vservers.
1143224795 M * dearaujo i followed the instructions on http://linux-vserver.org/alpha+util-vserver
1143224804 M * dearaujo but that's not what I got - strange
1143224847 M * daniel_hozac the instructions on there specify /vservers/.hash too...
1143224871 M * dearaujo question - what's the "0"?
1143224885 M * dearaujo any specific reason?
1143224889 M * daniel_hozac it's just a number.
1143224895 M * daniel_hozac the link has to be called something.
1143224900 M * dearaujo i see
1143224937 M * dearaujo so I assum when I go to /vservers/.hash i should see some dirs
1143224952 M * daniel_hozac 00 .. ff, yes.
1143224993 M * dearaujo hmm some reason it ended up in /vservers/<vserver-name>/.hash
1143225160 J * kir_home tis-6b2df7@213.152.157.70
1143225594 Q * kir_home Quit: Ухожу я от вас
1143225965 J * Dr4g ~Dr4g@82-40-203-70.stb.ubr06.uddi.blueyonder.co.uk
1143226095 Q * Dr4g Quit: 
1143227314 J * rofel ~rofel@cable-dynamic-87-245-81-230.shinternet.ch
1143228528 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com
1143228729 Q * f_ Quit: This computer has gone to sleep
1143228839 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143228968 M * micah daniel_hozac: with the 'plain' init style, stopping hangs with the message, "A timeout occured while waiting for the vserver to finish and it will be killed by sending a SIGKILL signal. The following process list might be useful for finding out the reason of this behavior:" and then there are no processes
1143229039 M * micah going to see whats running in there during stop
1143229124 M * micah seems others had this problem with gentoo on the list, not seeing a resolution (http://list.linux-vserver.org/archive/vserver/msg10716.html)
1143229154 M * daniel_hozac yeah, it does that sometimes.
1143229436 M * micah hmm looks like if 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
1143229474 P * dearaujo 
1143229521 M * micah Hollow: it looks like you looked at this issue in-depth, did you find a good solution to it?
1143229668 M * daniel_hozac IIRC this is why the REBOOT_KILL flag was added.
1143230298 J * Dr4g ~Dr4g@82-40-203-70.stb.ubr06.uddi.blueyonder.co.uk
1143230319 M * Hollow the thing is... the reboot_kill flag has nothing to do with vserver...stop
1143230344 M * micah only for reboots issued inside the guest?
1143230351 M * Hollow exactly
1143230404 J * kir_home tis-40b963@213.152.157.70
1143230410 M * Hollow well, in theory, the shutdown procedure of the guests init system calls sys_reboot in the end, which in turn calls vshelper
1143230423 M * Hollow so vshelper should kill init
1143230452 M * Hollow not sure how things are implemented atm
1143230457 M * daniel_hozac i thought the killing was done by the kernel, and vshelper isn't called at all?
1143230482 M * SNy No, actually, killing is done by Chuck Norris.
1143230484 M * SNy ;p
1143230497 M * Hollow ah right.. we're investigating a stop issue
1143230500 M * Hollow :)
1143230506 M * Hollow confused myself
1143230518 M * Hollow daniel_hozac: for reboot_kill yes
1143230577 M * Hollow hm, i don't know how we fixed this in gentoo, or if we fixed it at all
1143230590 M * Hollow it sometimes still happens afaik
1143230654 M * micah when that happens, does that mean that there is a stray init process that will continue to run regardless?
1143230686 M * daniel_hozac i don't think so.
1143230699 M * Hollow *nod* but it still _may_ be, no?
1143230714 M * daniel_hozac i think we would've heard more screaming from users then.
1143230724 M * daniel_hozac starting said vserver would be impossible after that.
1143230726 M * Hollow or does a vc_ctx_kill really ensure all processes are killed?
1143230739 M * Hollow daniel_hozac: indeed
1143230792 M * micah was this related to the weird mount -oremount / hack?
1143230844 M * micah the mount -o remount,rw /proc
1143230851 M * daniel_hozac no, not at all.
1143230890 M * micah oh ok, I thought that the proc entry (in /proc/<pid>...) will remain until the proc inodes are purged, and werent on vserver stop
1143231151 Q * Roey Quit: Leaving
1143231347 N * Bertl_oO Bertl
1143231353 M * Bertl back now ...
1143231855 M * daniel_hozac micah: what distro is your guest?
1143231922 M * micah daniel_hozac: debian
1143231943 M * daniel_hozac which one? my sarge doesn't do it.
1143231947 M * daniel_hozac is it reproducible?
1143231972 M * micah its sarge guests running on sarge host with 2.6.8 kernel (might be why)
1143231996 M * micah daniel_hozac: yes, it seems to happen every time with 'plain' init style and vserver <vserver> stop
1143232121 M * daniel_hozac i've got a sarge guest here, but i can't reproduce it.
1143232161 M * daniel_hozac this is on 2.6.16 based with vs2.0.2-rc14 though.
1143232201 M * Bertl I had a thought on the reboot/shutdown too
1143232256 M * Bertl I think we should make the vshelper async by default (maybe with a kernel build time option) as no tools use the sync stuff atm (please correct me if I'm wrong)
1143232282 M * Bertl further, I think that the reboot_kill can be made default, unless deactivated
1143232300 M * Bertl this leaves us with the 'normal' shutdown
1143232341 Q * Dr4g Ping timeout: 480 seconds
1143232342 M * daniel_hozac won't reboot_kill mean that all processes in the guest are killed by the kernel rather than using their shutdown scripts?
1143232358 M * daniel_hozac for the reboot -f inside the guest case
1143232358 Q * Vudumen Ping timeout: 480 seconds
1143232360 J * zarathustra ~ich@mezcal.fi-p.unam.mx
1143232383 M * Bertl daniel_hozac: yep, but only when the init process issues the sys_reboot()
1143232396 M * daniel_hozac for the sysv case?
1143232407 M * daniel_hozac i.e. initless?
1143232414 M * Bertl it would not be called, unless you do reboot -f somewhere
1143232431 M * daniel_hozac so how would you reboot guests from the inside on sysv guests?
1143232443 M * daniel_hozac and get "proper" shutdown?
1143232446 M * Bertl killall5, reboot -f ?
1143232458 M * zarathustra hi, I have a question, I hope you can help me. I have debian, and I want to install gentoo as a vserver, how can I do that ?  Ive found info only using debootstrap
1143232478 M * Bertl daniel_hozac: no idea, maybe we should make the reboot_kill only default for init based guests?
1143232499 M * Bertl daniel_hozac: I'm open for suggestions, but it seems that the tools are not able to handle it properly
1143232511 M * daniel_hozac Bertl: that will make reboot/reboot -f do different things.
1143232535 M * Bertl we have those issues since a long time now and I want them fixed somehow ...
1143232576 M * daniel_hozac well, i agree that the sync should probably be made the default for non-legacy too.
1143232585 M * Bertl async
1143232587 M * daniel_hozac umm, right.
1143232608 M * daniel_hozac does anything really need reboot_kill though?
1143232635 M * daniel_hozac IIRC, Hollow started testing reboot_kill, but then it solved itself in some other way where it was no longer needed...
1143232658 M * dev0 mhm Bertl? may I simply add VXC_CRYPTO_LOOP to bcap?
1143232668 M * daniel_hozac zarathustra: you could try using vserver-new and the Gentoo stage tarballs.
1143232668 M * Bertl ccap
1143232674 M * dev0 oh ok
1143232683 M * Bertl dev0: and you ahve to use ^21 as I told you
1143232694 M * dev0 indeed, I do now
1143232704 M * daniel_hozac zarathustra: the first may not work, i'm not sure. ask Hollow or phreak`` ;)
1143232724 M * zarathustra ok, thanks daniel_hozac 
1143232743 M * zarathustra  dont have a vserver-new command :(
1143232759 M * dev0 Unknown ccap 'VXC_CRYPTO_LOOP' <- still the same problem. linux 2.6.16-vs2.1.1-rc14 
1143232760 M * dev0 grep "VXC_CRYPTO_LOOP" include/linux/vserver/context.h
1143232760 M * dev0 #define VXC_CRYPTO_LOOP         0x00200000
1143232776 M * zarathustra I ^
1143232781 M * Bertl daniel_hozac: you reported that the sync behaviour cannot be handled by util-vserver, Hollow reported something similar for vserver-utils, and we introduced the 'requested' reboot_kill whichs sounds somewhat naturally to me 
1143232782 M * daniel_hozac dev0: you need to add it to the list.
1143232792 M * dev0 which list?
1143232802 M * Bertl dev0: as I said, you _have_ to _use_ ^21 :)
1143232804 M * daniel_hozac dev0: lib/ccaps-v13.c, IIRC.
1143232837 M * Bertl dev0: oh, you are patching the tools right now?
1143232847 M * dev0 nope tools are already 21
1143232851 M * daniel_hozac zarathustra: right, it's a Gentoo script. i think you should be able to extract it from the ebuilds.
1143232855 M * dev0 util-vserver-0.30.210
1143232871 M * Bertl dev0: instead of VXC_CRYPTO_LOOP, you ahve to use '^21'
1143232880 M * Bertl which means the bit number 21
1143232894 M * Bertl 0x00200000 = 2^21
1143232903 M * dev0 yes, starts.
1143232912 M * Bertl as the tools do not know about the capability
1143232933 M * Bertl so, you have to add '^21' (literally) to your ccapabilities list
1143232940 M * dev0 already done, starts now
1143232961 M * dev0 but I'm still getting ioctl: LOOP_SET_FD: Inappropriate ioctl for device
1143232963 M * Bertl good, check with /proc/virtual/<xid>/* if this bit is set
1143232975 M * Bertl (on the host)
1143232999 M * Bertl then check with crypto_loop first, maybe I forgot something
1143233002 J * Vudumen ~vudumen@perverz.hu
1143233026 M * dev0 BCaps:  00000000344c44ff
1143233026 M * dev0 CCaps:  0000000000200101
1143233028 M * dev0 seems ok
1143233030 M * Bertl dev0: when this works, make sure that you did the described modifications to the aesloop
1143233037 M * dev0 I did. 
1143233043 M * dev0 do you want the patch?
1143233047 M * Bertl yep, please
1143233075 M * Bertl then, if that still fails, do an strace -fF -o trace ... of the setup
1143233086 M * Bertl and upload the output somewhere ...
1143233110 M * dev0 http://rafb.net/paste/results/JGBA9L92.html <- the patch
1143233125 M * Bertl daniel_hozac, Hollow: for me the only question is, do you see a way to 'fix' the reboot stuff and make the behaviour somewhat sane without kernel changes?
1143233151 M * daniel_hozac Bertl: isn't it already rather sane?
1143233180 M * Bertl daniel_hozac, Hollow: IMHO plain and sysv/gentoo style can have different semantics, as they server different purposes
1143233202 Q * kir_home Ping timeout: 480 seconds
1143233222 M * Bertl daniel_hozac: well, as far as I can tell (from listening to folks) it still does kill off everything on a timeout basis
1143233241 M * daniel_hozac right, is that a bad thing?
1143233241 M * Bertl which is not what I want when I do 'vserver name stop'
1143233264 M * Bertl yes, it is bad, as it shows that something is not working properly
1143233284 M * Bertl either there is an init, in which case we should end the guest once sys_reboot() is called
1143233319 M * Bertl or there is no init, in which case the runlevel scripts should terminate, and all remaining processes should be killed off immediately
1143233342 M * Bertl only, in the case the runlevel scripts do not terminate within a given timeout
1143233358 M * Bertl such a kill should happen, no?
1143233367 M * daniel_hozac yeah.
1143233397 M * Bertl so, I wonder what goes wrong in 90% of all guest shutdowns
1143233399 P * zarathustra 
1143233420 M * Bertl dev0: patch looks good, how does crypto_loop do?
1143233454 M * dev0 mompl, I'm having a look on the strace
1143233547 M * dev0 ioctl(4, 0x4c00, 0x3)             = -1 ENOTTY (Inappropriate ioctl for device) <- that's the point where it fails. 4 is the fd of /dev/loop0. 
1143233565 M * daniel_hozac what is /dev/loop0?
1143233572 M * dev0 a loopback device
1143233596 M * daniel_hozac are you sure? what does ls -l /dev/loop0 say?
1143233671 M * dev0 I think you're right daniel_hozac 
1143234052 J * coocoon ~coocoon@p54A07F99.dip.t-dialin.net
1143234056 Q * coocoon Quit: 
1143234206 J * mkhl ~mkhl@200-148-41-203.dsl.telesp.net.br
1143234775 Q * f_ Ping timeout: 480 seconds
1143234805 J * bonbons ~bonbons@83.222.39.180
1143235108 M * dev0 hmm can't I simply copy devices into the vserver?
1143235135 J * coocoon ~coocoon@p54A060B9.dip.t-dialin.net
1143235142 M * coocoon ok now hello to all
1143235176 M * bonbons dev0: You can, just cp -a /dev/{...} /vservers/guest/dev/ (note the -a!)
1143235265 J * prio ~prio@tor-irc.dnsbl.oftc.net
1143235296 M * dev0 ah. better. thank you bonbons 
1143235846 M * dev0 ioctl(4, 0x4c00, 0x3)             = -1 EPERM (Operation not permitted), I think there is still somewhere a permission missing. CCaps:  0000000000200101, BCaps:  00000000344c44ff. 
1143235862 M * dev0 4 is still /dev/loop0
1143235920 M * bonbons what are you trying to do with /dev/loop0? Mount it somewhere?
1143235946 M * dev0 yes, set-up loop-aes inside a virtual server, Bertl helped me already a lot.
1143236002 M * Bertl dev0: did you try crypto_loop yet?
1143236014 M * dev0 what do you mean?
1143236023 M * Bertl just don't use the aes loop
1143236031 M * Bertl for example use xor on loop or so
1143236053 M * Bertl just to see if the issue comes from the aes-loop part or from the kernel itself
1143236054 M * dev0 I could mount a simple loopback?
1143236070 M * Bertl also add the mount capabilities
1143236078 M * Bertl secure_mount and friends
1143236100 M * Bertl (otherwise you will not be able to actually mount anything)
1143236110 P * meandtheshell 
1143236508 J * drfick ~drfick@dsl-146-247-191.telkomadsl.co.za
1143236514 M * dev0 secure_mount *_mount is set. a simple loopback does not work (dd if=/dev/zero of=container ..., mkfs.ext2 container, mount -t ext2 -o ro,loop=/dev/loop0 container /mnt/)
1143236525 P * drfick 
1143236649 M * Bertl dev0: okay, where does it fail?
1143236657 M * dev0 in strace?
1143236663 M * dev0 de mount fails
1143236669 M * dev0 ioctl: LOOP_SET_FD: Operation not permitted
1143236701 M * dev0 10074 ioctl(4, 0x4c00, 0x3)             = -1 EPERM (Operation not permitted)
1143236729 M * dev0 4 is: 10074 open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 4
1143236738 M * Bertl okay, that probably points into the right directions
1143236748 M * Bertl give me a few minutes to check that with the source
1143236796 M * dev0 backtrace shoul point to loop_set_fd(), but I'm unsure.
1143236798 M * dev0 +d
1143236820 M * Bertl nah, I think the ioctl gets blocked earlier
1143236913 Q * prio Ping timeout: 480 seconds
1143236965 M * Bertl try to give CAP_SYS_RAWIO
1143237048 M * dev0 still the same, BCaps:  00000000344e44ff
1143237139 M * Bertl okay, IMHO lo_ioctl() is called, because nothing should now stop the ioctl from happening
1143237165 M * dev0 do you want a full backtrace?
1143237180 M * Bertl kernel side, yes please
1143237264 M * dev0 kernel side? I'm not a kernel hacker, I just want to be *g* how do I?
1143237283 M * Bertl well, not that easy, actually :)
1143237333 M * Bertl but have a look at the kernel source for a moment, I point you to the relevant files
1143237341 M * dev0 that's fine
1143237351 M * Bertl drivers/block/loop.c loop_set_fd()
1143237362 M * Bertl around line 740
1143237388 M * Bertl this one does not return EPERM in _any_ case
1143237403 M * dev0 but I don't use this loop anyway. loop-aes replaces *this* loop.c
1143237423 M * dev0 without aes cipher it just acts as the normal loop
1143237424 M * Bertl that's why I said you should check with _this_ loop first :)
1143237438 M * dev0 hld on 
1143237596 M * Bertl daniel_hozac, Hollow: okay, so to pick up the reboot/stop/kill issue once again, could you provide some 'minimal' requirements from each tool PoV (sorry Daniel for urging you to do Enricos job :)
1143237646 M * Bertl i,e, how should a clean stop, restart and reboot look like
1143237665 M * Bertl let's use restart for *reboots* from outside
1143237679 M * Bertl and reboot for the guest-side stuff
1143237714 M * Bertl Hollow: did you already invest time into the test stuff I asked you before?
1143237732 M * dev0 well, the original loop does not give an error, however it does an infinite loop or a blocking wait. I'll have look Bertl 
1143237760 M * Bertl could it be trying to load a module or so?
1143237772 M * dev0 mount?
1143237787 M * Bertl yep, ext2/3/whatever
1143237790 M * dev0 I did mount -t ext2 -o ro,loop=/dev/loop0 container /mnt/      
1143237802 M * Bertl maybe split that up into
1143237806 M * dev0 ext2 ist statically linked into the bzimage
1143237807 M * Bertl losetup and mount?
1143237818 M * dev0 ok
1143237858 M * dev0 indeed, losetup /dev/loop0  container hangs too
1143237970 M * dev0 *g* I can't even kill thos process
1143237972 M * Bertl any kernel messages?
1143237986 M * Bertl maybe a kernel trace in 'dmesg'
1143238023 M * dev0 nope, last is loop: loaded (max 8 devices)
1143238044 M * dev0 I'm even unable to kill the whole vserver
1143238058 M * Bertl well, probably stuck in the kernel
1143238079 M * Bertl but I wonder how that can happen without giving a trace
1143238141 M * dev0 state is D    Uninterruptible sleep (usually IO)
1143238154 M * dev0 13856    50 vhost0        pts/0    D      0:00 losetup /dev/loop0 container
1143238227 M * Bertl yup, will require a reboot to get rid of that
1143238242 M * Bertl but you still have loop1-7 to test with :)
1143238251 M * dev0 lol
1143238331 M * Bertl will spend some time with my SO right now, but will be back later .. and I will try to recreate it here
1143238344 M * dev0 no problem
1143238355 M * Bertl you might want to look in the AES loop code for the EPERM
1143238362 M * dev0 and?
1143238371 M * dev0 ah look on the caps
1143238382 M * Bertl well, there must be some kind of check which returns that
1143238420 M * Bertl at this place, you probably want to extend that check by testing the VXC_CRYPTO_LOOP
1143238430 M * dev0 I'll have a look
1143238441 M * Bertl okay, cya
1143238449 N * Bertl Bertl_oO
1143240903 Q * coocoon Ping timeout: 480 seconds
1143241273 J * Aiken ~james@tooax6-092.dialup.optusnet.com.au
1143242879 Q * bonbons Quit: Leaving
1143243740 Q * matta Ping timeout: 480 seconds