1143331270 M * daniel_hozac lol
1143331333 M * Bertl okay, so what are the minimal changes you did?
1143331351 M * Bertl int __attribute__((__const__)) *__errno_location(void) {
1143331357 M * daniel_hozac right.
1143331399 M * Bertl what are the gcc options?
1143331433 M * daniel_hozac gcc -S -DHAVE_CONFIG_H -I. -I. -I. -I ./lib -I ./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -std=c99 -Wall -pedantic -W -funit-at-a-time -c sysct.c  -fPIC -DPIC -o sysct.S
1143331441 M * daniel_hozac i'm still seeing which ones are required.
1143331511 M * Bertl gcc -Wall -fPIC -DPIC -O2 -S -o sysct.s sysct.c
1143331563 M * Bertl does the right thing here
1143331891 Q * f_ Quit: This computer has gone to sleep
1143331895 M * daniel_hozac removing -O2 makes it work.
1143331986 M * Bertl ah, so that one fails for you? the line I wrote?
1143332031 M * Bertl if so, could you try the following change:
1143332048 M * daniel_hozac yep.
1143332074 M * Bertl right above the "i"(273)
1143332084 M * Bertl change the lonesome '.'
1143332088 M * Bertl *arg*
1143332091 M * Bertl ':'
1143332095 M * Bertl to
1143332118 M * Bertl ':"=a"(__res)
1143332131 M * Bertl and remove "eax" from the clobberlist
1143332170 M * daniel_hozac nope, still broken.
1143332231 M * Bertl ah, and remove the 'dummy save' line
1143332259 M * daniel_hozac no change.
1143332279 M * Bertl okay, good, looks like we got an interesting case, let's simplify it
1143332290 M * Bertl (i.e. give me a few minutes to prepare something)
1143332308 M * Bertl or do you like to hack on that yourself?
1143332343 M * Bertl (if so, try to replace the entire __asm__ cruft by the exmaple addition in the inline assembler howto
1143332415 M * daniel_hozac i don't really feel comfortable with asm yet...
1143332425 M * Bertl okay, np :)
1143333233 Q * mnemoc Ping timeout: 480 seconds
1143333498 M * Bertl daniel_hozac: another idea, what happens if you change the register long __res __asm__("eax");
1143333508 M * Bertl to just long __res;
1143333520 M * Bertl (keeping the changes you did so far)
1143333603 M * daniel_hozac that did it.
1143333631 M * Bertl hmm, okay, will medidate on that for a few minutes, then update the syscall wrapper accordingly ...
1143333652 M * Bertl I'm in asm mood today :)
1143333686 M * daniel_hozac :)
1143333818 M * daniel_hozac what i'm wondering is why it didn't hit all the other syscalls.
1143333843 M * Bertl it's definitely some 'strange' optimization behaviour
1143333866 M * Bertl but I really can't blame gcc for that, as the 'tricks' I used are basically undocumented
1143333911 M * daniel_hozac well, certainly it should save the value returned by a function before calling the next one.
1143333914 M * Bertl nevertheless it should still be possible to make the assignment more _strict_ without breaking backwards compatibility
1143333930 M * Bertl daniel_hozac: the thing is, we define the __res as register value
1143333947 M * daniel_hozac yes, but won't it be a register anyway?
1143333949 M * Bertl so gcc (the 4.x one) blindly takes that as 'fixed'
1143333956 M * daniel_hozac oh, no, it's inline.
1143335770 M * Bertl daniel_hozac: okay, please give this one a try:
1143335771 M * Bertl http://vserver.13thfloor.at/Experimental/SYSCALL/syscall_shiny9.h
1143335797 M * Bertl you have to merge it with the utils, but I guess you know that already
1143336291 M * daniel_hozac Bertl: yep, that does it, thanks a lot.
1143336310 M * Bertl okay, let's see if that works as expected with my ancient compilers then :)
1143336321 M * Bertl do you have a delta agains util-vserver?
1143336342 M * Bertl maybe some 'other' useful patches for that too, when I'm going to update the rpms
1143336430 M * daniel_hozac http://daniel.hozac.com/vserver/util-vserver-0.30.210-shiny9.patch
1143336578 M * daniel_hozac http://cvs.hozac.com/viewcvs/util-vserver/fedora-5/?root=rpms i guess -fc5 and -cru-vps aren't _that_ relevant.
1143336621 J * everon ~ybbot@ACBD2816.ipt.aol.com
1143336683 Q * everon Quit: Yourbot IRC Bot 4.5> You can get this bot at http://www.ybbot.com/.
1143338726 Q * doener_ Quit: leaving
1143339274 M * daniel_hozac Bertl: hmm, while shiny9 fixed my simple test case, it seems to have broken everything else...
1143339360 M * Bertl well, that's not so good then ...
1143339397 M * daniel_hozac lots of Function not implemented, as well as Interrupted system call.
1143339484 M * Bertl well, give me a few minutes to try something else then
1143339524 M * daniel_hozac it doesn't appear to actually call the kernel either.
1143339769 M * daniel_hozac oh, it does, just with an entirely incorrect syscall number. 7025?
1143339805 M * Bertl ah, hmm, guess I forgot that one ...
1143339847 M * Bertl lol
1143339869 M * Bertl 	__casm(n,0,1,	"movl	%0,%%eax"	,			)\
1143339880 J * matta ~matta@c-68-81-35-243.hsd1.pa.comcast.net
1143339883 M * Bertl change the %0 to %1 here 
1143339898 M * Bertl in #define__sysc_pre(n) (i386)
1143339928 J * matt1 ~matta@c-68-32-202-140.hsd1.pa.comcast.net
1143340343 M * daniel_hozac Bertl: much better, thanks.
1143340363 Q * matta Ping timeout: 480 seconds
1143340379 M * Bertl okay, updated in place, with some whitespace fixes
1143340855 M * Bertl btw, does anybody here have/know a list of syscall arguments for linux syscalls?
1143340867 M * Bertl number of arguments that is
1143340987 M * daniel_hozac what do you mean? like a list of syscalls and the number of arguments they need?
1143341048 M * Bertl yep, precisely
1143341623 M * Bertl daniel_hozac: what is the cru-vps stuff for?
1143341656 M * daniel_hozac Cru has some packages that lets you remove unneeded packages from guests.
1143341672 M * daniel_hozac like the kernel, udev, MAKEDEV, mkinitrd, etc.
1143341687 M * Bertl i.c. but that is fc specific, yes?
1143341698 M * daniel_hozac Fedora and CentOS, yes.
1143341737 M * Bertl and what does the uid patch do?
1143341777 M * daniel_hozac it makes vcontext's --uid accept usernames.
1143341798 M * Bertl ah, cool, taken from inside or outside the guest?
1143341802 M * daniel_hozac inside.
1143341814 M * Bertl nice, and the vlogin actually works?
1143341814 M * daniel_hozac it also sets up the groups if it's given a username.
1143341831 M * daniel_hozac it has some odd issues i haven't quite tracked down yet, but for the most part, yes.
1143341878 M * daniel_hozac the child vcontext sometimes get's stuck in a SIGWINCH loop.
1143346827 J * Dr4g ~Dr4g@82-40-40-41.cable.ubr06.uddi.blueyonder.co.uk
1143346906 M * Bertl okay, I'm off to bed for today ... after all, we lost an hour :)
1143346922 M * Bertl have a nice whatever everyone! cya tomorrow!
1143346929 N * Bertl Bertl_zZ
1143350286 Q * dev0 Quit: Peace, Love & Linux
1143352273 Q * Dr4g Ping timeout: 480 seconds
1143355884 J * Neato ~Coolguy@S0106001346a8a4c1.ed.shawcable.net
1143355973 J * _mcp ~hightower@wolk-project.de
1143356014 P * Neato 
1143356065 Q * nox Read error: Operation timed out
1143356077 Q * mcp Read error: Operation timed out
1143356087 N * _mcp mcp
1143356087 Q * weasel Read error: Operation timed out
1143356155 J * nox ~nox@noxlux.de
1143356262 J * weasel weasel@asteria.debian.or.at
1143357575 M * Hollow daniel_hozac: ping
1143358784 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143359886 Q * ddlp Remote host closed the connection
1143360246 J * Neato ~Coolguy@S0106001346a8a4c1.ed.shawcable.net
1143360291 Q * micah Read error: Operation timed out
1143360678 J * micah ~micah@69.90.134.205
1143360684 J * hijacker ~hijacker@cable-84-43-140-185.mnet.bg
1143360688 M * hijacker morning all
1143360702 Q * micah Quit: 
1143360738 Q * Neato Ping timeout: 480 seconds
1143360738 J * micah ~micah@69.90.134.205
1143361849 J * ddlp ~ddlp@sarayi.kariva.org
1143362838 Q * hijacker Ping timeout: 480 seconds
1143362855 J * hijacker ~hijacker@cable-84-43-140-185.mnet.bg
1143363313 Q * f_ Quit: This computer has gone to sleep
1143364418 J * f_ ~f_@83-215-237-1.seek.stat.salzburg-online.at
1143368073 J * mnemoc ~amery@user4-2.tutopia-dialup.ifxnw.cl
1143368525 J * Viper0482 ~Viper0482@p54975189.dip.t-dialin.net
1143369053 Q * Viper0482 Quit: bin raus, 
1143369140 P * hijacker Leaving
1143370845 J * bonbons ~bonbons@83.222.39.180
1143371293 J * Viper0482 ~Viper0482@p54975189.dip.t-dialin.net
1143371745 J * lilalinux ~plasma@h1-gw.of.net-lab.net
1143372039 J * Dr4g ~Dr4g@82-40-40-41.cable.ubr06.uddi.blueyonder.co.uk
1143374376 M * SiD3WiNDR is there a way to run syslog-ng inside a vserver?
1143374389 M * SiD3WiNDR Error opening file /proc/kmsg for reading (Operation not permitted)
1143374389 M * SiD3WiNDR Error initializing configuration, exiting.
1143374389 M * SiD3WiNDR  start failed.
1143374391 M * SiD3WiNDR :/
1143374500 M * derjohn SiD3WiNDR, I switched back to std syslog, so if you find a solution, pls tell. ( I assume there is a capability problem ... ?)
1143375502 J * Loki|muh loki@satanix.de
1143376098 J * doener ~doener@i5387D54C.versanet.de
1143376258 Q * mnemoc Ping timeout: 480 seconds
1143377068 M * Hollow SiD3WiNDR, derjohn: remove the /proc/kmsg from syslog-ng.conf
1143377392 M * doener morning folks
1143377400 M * phreak`` morning doener :)
1143377506 Q * phreak`` Quit: leaving
1143377590 M * SiD3WiNDR thanks :)
1143377598 M * SiD3WiNDR should have figured that out by myself I guess :/
1143377957 J * phreak`` ~phreak``@134.68.220.30
1143377970 Q * phreak`` Quit: 
1143378051 J * phreak`` ~phreak``@134.68.220.30
1143379413 J * pflanze ~chris@84-73-54-54.dclient.hispeed.ch
1143379501 J * virtuoso_ ~s0t0na@shisha.spb.ru
1143379502 Q * virtuoso Read error: Connection reset by peer
1143379895 M * bubulak pica
1143380212 Q * Dr4g Quit: Open Source Development :: http://dynamichell.org
1143380879 J * hggh ~jonas@mx.brachium-system.net
1143380909 P * hggh 
1143381174 J * Dr4g ~Dr4g@82-40-40-41.cable.ubr06.uddi.blueyonder.co.uk
1143381605 J * meandtheshell ~markus@85-124-32-111.dynamic.xdsl-line.inode.at
1143383835 Q * matt1 Ping timeout: 480 seconds
1143385332 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1143386201 M * daniel_hozac Hollow: pong
1143386221 M * derjohn Hollow, SiD3WiNDR , /me , too ;) 
1143386263 M * Hollow daniel_hozac: hm, regarding the SIGWINCH loop, did you find out anything?
1143386278 M * daniel_hozac Hollow: no, i've been busy tracking down all the FC5 issues.
1143386297 M * daniel_hozac Hollow: i guess moving the signal handler setup to after the if (pid == 0) should fix it.
1143386350 M * Hollow mhm, sounds logical..
1143386379 M * Hollow will try it.. also have put your --secure patch in gentoo, thanks for that one.
1143386444 M * Hollow any instructions on how to reproduce the loop?
1143386454 M * daniel_hozac no, it seems to be fairly random.
1143386460 M * Hollow great!
1143386461 M * Hollow :)
1143386465 M * daniel_hozac it seems to occure quite often with vserver .. exec <command> though.
1143386487 M * Hollow hm.. does exec even use vlogin?
1143386500 M * Hollow i thought only enter would do that
1143386504 M * daniel_hozac me too.
1143386527 M * daniel_hozac but i guess enter/exec/etc. all use the same code.
1143386568 M * Hollow probably... anyway i'm trying to fix it later today, afk for a while now
1143386569 M * Hollow cu
1143386587 M * daniel_hozac thanks, let me know how it goes.
1143388982 N * Bertl_zZ Bertl
1143388982 Q * doener Read error: Connection reset by peer
1143388988 J * doener_ ~doener@i5387F76A.versanet.de
1143388991 M * Bertl evening folks!
1143389000 M * doener_ evening Bertl 
1143389064 N * doener_ doener
1143389288 M * daniel_hozac evening!
1143389376 M * Bertl hey, is Hollow still here?
1143391464 J * bragon ~bragon@sd866.sivit.org
1143391472 M * bragon lo *
1143392162 M * Bertl welcome bragon!
1143392368 M * rmoriz hi
1143393425 Q * mkhl Quit: 
1143394881 J * liquid3649_ ~Viper0482@p54975C02.dip.t-dialin.net
1143394915 M * Bertl wb liquid3649_!
1143395108 Q * liquid3649_ Quit: 
1143395118 J * liquid3649_ ~Viper0482@p54975C02.dip.t-dialin.net
1143395182 Q * liquid3649_ Quit: 
1143395313 Q * Viper0482 Ping timeout: 480 seconds
1143396021 M * Hollow Bertl: pong?
1143396079 M * Bertl ah, well, let's see if the others are still around now
1143396092 M * Bertl doener, daniel_hozac: ping?
1143396146 M * doener pong! *going to get a coffee*
1143396233 M * doener ok, ready now ;)
1143396273 M * Bertl daniel_hozac: around?
1143396308 M * Bertl okay, let me try to describe the problem/topic (daniel already knows the stuff)
1143396340 M * Bertl Hollow: thing is, we should figure a usable way to handle stop/restart/reboot of guests
1143396351 M * Hollow indeed
1143396358 M * Bertl for the terminology: stop and restart is _outside_ on the host
1143396371 M * Bertl reboot is solely _inside_ from the guest
1143396389 M * Hollow you mean stop and start, right?
1143396398 M * Hollow ah no
1143396399 M * Hollow ic
1143396404 M * bonbons Evening Bertl, Hollow, doenoer and the others
1143396416 M * Bertl we also know that the plain (init based setup) should let init do the job, and then kill off the rest with reboot_kill
1143396419 M * Bertl hey bonbons!
1143396427 M * bonbons s/doenoer/doener/
1143396439 M * Bertl bonbons: please join the stop/restart/reboot discussions
1143396451 M * bonbons I have an idea too for the stop/restart/reboot thing :)
1143396471 M * doener ugh, that topic again... *was lost when he participated the last time*
1143396509 M * bonbons I had some thoughts about acpi-power-botton (like) events for the guests
1143396510 M * Bertl okay, first, do we agree on the terminology?
1143396516 M * Hollow yep
1143396576 M * bonbons I'ok ok with the terminology as well
1143396603 M * doener dito
1143396612 M * Bertl okay, as I said, if init is running (plain init style) then we want init to handle most/all of the actions, except for the final killoff
1143396629 M * Bertl for the sysv (and maybe a future gentoo?) init style
1143396652 M * Bertl we have to set actions from outside (runlevel scripts and such) to do a proper shutdown
1143396657 M * Hollow Bertl: even with reboot_kill we still need someone to start the guest again (i.e. vshelper)
1143396668 M * Bertl yes, I'll get to that shortly
1143396672 M * Hollow ok
1143396702 M * Bertl we also have a bunch of (possible?) 'helper hooks'
1143396727 M * Bertl i.e. context creation, sys_reboot, context destruction
1143396772 M * Bertl let's forget for a moment about the current setup, kernel and tool procedures and think about the necessary information
1143396789 M * Bertl first, stop from outside:
1143396810 M * bonbons Bertl: should we do something "new" for this, or just put a virtual instance of something existing on host for the guest? (ACPI, CTRL-ALT+DEL, ...)
1143396830 M * Bertl in the init case, we want to signal init, and let it do the shutdown
1143396852 M * Bertl IIRC, almost all inits understand a certain signal, correct?
1143396876 M * Bertl (the ctrl-alt-del should send such a signal kernel side)
1143396876 M * daniel_hozac SIGINT is the ctrl+alt+del signal, if i understand the documentation correctly.
1143396886 M * Bertl ah, daniel_hozac! great!
1143396899 M * Hollow i think so too
1143396916 M * Bertl so the stop via SIGINT to init, plus a timeout/killoff should work
1143396939 M * Hollow well... init should call sys_reboot
1143396943 M * Hollow without timeout
1143396947 M * bonbons for triggering a restart that is ok
1143396953 M * daniel_hozac but if it doesn't, the timeout will do it.
1143396953 M * Hollow and sys_reboots kills the remaining procs
1143396961 M * Hollow do i/we want that?
1143396969 M * daniel_hozac the timeout is just to make sure the guest really dies.
1143396973 M * Bertl let's ignore all 'other' mechanisms for now, just a signal
1143396975 M * Hollow well, that could be configurable..
1143396984 M * Hollow ok, go on
1143396992 M * daniel_hozac so if the init doesn't understand SIGINT, the guest will die.
1143397005 M * Bertl the hard way, yes
1143397025 M * Bertl in the init-less case we have something very similar
1143397045 M * Bertl instead of signalling init, we spawn a thread which executes the runlevel stuff
1143397064 M * Bertl again, either that finishes, or we kill the guest after a timeout
1143397092 M * Bertl now, how to detect that the guest is gone in both cases?
1143397108 M * daniel_hozac vc_wait_exit?
1143397109 M * Bertl simple, we introduce a mechanism to wait for guest exit
1143397134 M * Bertl an alternative to that would be the helper hook at context destruction
1143397144 M * Bertl note: one is sync, the other would be async
1143397180 M * Bertl the restart case is just a combination of stop and start, agreed?
1143397192 M * daniel_hozac yes.
1143397192 M * Hollow but the process waiting for guest exit has to be running all day, no?
1143397202 M * daniel_hozac Hollow: no, it's started on stop.
1143397214 M * daniel_hozac and also responsible for doing the timeout kill.
1143397229 M * bonbons depending on the (host-side) use-case either one would be useful (sync and async)
1143397233 M * Bertl it's sufficient to start it before the guest is exiting
1143397234 M * Hollow but how is one sync and the other async, if both are called like vshleper
1143397249 M * daniel_hozac neither is called as vshelper, i thought we were discussing stop?
1143397257 M * Bertl Hollow: the vc_wait_exit doesn't require any vshelper
1143397266 M * Hollow hm
1143397273 M * Hollow but who does call vc_wait_exit?
1143397281 M * daniel_hozac the stop process.
1143397286 M * Bertl the userspace tool doing the stop
1143397295 M * Hollow well, he notices it when there is nor more context..
1143397300 M * Hollow or am i missing something?
1143397311 M * daniel_hozac but we want the timeout.
1143397312 M * Hollow while test -d /proc/virtual/123; do foo bar;done
1143397320 M * Bertl nope, let me give an example:
1143397323 M * bonbons Hollow: noticing when there is no context left is kind of polling..
1143397333 J * phedny ~mark@volcano.p-bierman.nl
1143397337 M * Bertl user does: vserver hansi stop
1143397348 M * daniel_hozac Hollow: that's like advocating kill(pid, 0) over wait(...)...
1143397370 M * Bertl 1) script starts a thread, with vc_wait_exit() and 120sec timeout
1143397384 M * Bertl 2) script sends a signal/executes runlevel scripts
1143397415 M * Bertl 3) at some point, thread from 1 returns, either because the context disappeared or the timeout happened
1143397436 M * Bertl 4) vkill kills off anything remaining (in the timeout case)
1143397498 M * Bertl guest dead
1143397500 M * Bertl okay?
1143397524 M * Hollow yup
1143397538 M * Bertl now this gets extended by:
1143397547 M * Bertl 5) restart guest hansi 
1143397551 M * Bertl in the restart case
1143397574 M * daniel_hozac right
1143397584 M * Bertl this should work for _all_ init styles and _all_ distros without any helper, right?
1143397604 M * daniel_hozac yes.
1143397628 M * Bertl welcome phedny, btw!
1143397632 M * phedny hi :)
1143397632 M * Hollow so, what about reboot?
1143397643 M * bonbons I am also for guest-distro/init independence
1143397648 M * Bertl okay, so here is how I _originally_ planned the helper to work
1143397670 M * phedny what does "vserver build --interface" do? only create a interfaces/0 dir with 3 files?
1143397679 M * daniel_hozac phedny: yes.
1143397687 M * phedny so if I later want to add an additional entry, I can just create a interfaces/1 dir and restart vserver?
1143397695 M * daniel_hozac phedny: well, the number of files is dependent on how many optional pieces you supply.
1143397710 M * Bertl phedny: yes, but better is to shut it down, change then start again
1143397717 M * phedny okay
1143397729 M * Bertl okay, so here is how I _originally_ planned the helper to work (try2)
1143397753 M * Bertl 1) the guest does reboot/halt or reboot -f/halt -f
1143397755 M * phedny what happens if there is no entry in the interfaces dir? can a vserver access every IP of none at all?
1143397765 Q * eyck Ping timeout: 480 seconds
1143397779 M * daniel_hozac phedny: no IPs, IIRC.
1143397817 M * Bertl note: I'm not sure if the halt/halt -f case really makes sense inside a guest, but for completeness we should handle it correctly
1143397848 M * daniel_hozac yeah, i agree.
1143397851 M * Bertl 2) when the guest is init based, init will kill off most things, then do reboot -f/halt -f
1143397862 M * Bertl in any case we end up here:
1143397886 M * Bertl 3) the vshelper is called _synchronously_ with the cmd (reboot/halt)
1143397929 M * Bertl 4) the userspace helper records the command, and sets up a waiter thread similar to 1) in the stop case
1143397945 M * Bertl 5) the userspace helper _returns_
1143397987 M * Bertl note here, that in the init-less case, the userspace helper
1143397998 M * Bertl has to execute the shutdown scripts before returning
1143398004 M * daniel_hozac why before?
1143398016 M * Bertl so maybe make that 4b) the shutdown procedures are executed
1143398022 M * Bertl because of:
1143398038 M * Bertl 6) the kernel kills off everything which remains
1143398083 M * Bertl note that the function of the waiter is slighly different
1143398098 M * Bertl as it basically has to kill off the helper not the guest
1143398131 M * Bertl now we have two options for the reboot case
1143398149 M * Bertl either the waiter initiates the 'start'
1143398173 M * Bertl or the context destruction helper is used for that 
1143398180 M * Bertl IMHO the former is much cleaner
1143398195 M * Hollow *nod*
1143398209 M * Hollow the wait could be a child of VCD
1143398212 M * Hollow *waiter
1143398213 M * Bertl and note: none of those would need async helpers or context change hooks
1143398230 M * bonbons I'm also for the context-destruction helper to execute the new start
1143398237 M * Hollow hu?
1143398256 M * Bertl bonbons: we are not for that option :)
1143398274 M * Hollow context-destruction helper reminds me of state-change-handler..
1143398284 M * Bertl yes, that's it
1143398285 M * Hollow and the netlink discussion etc
1143398296 M * bonbons destructed, not destruction-required
1143398301 M * Bertl okay, I'm not doing the userspace stuff, so my questions are now:
1143398319 M * Bertl a) does this procedure sound sane for the involved parties
1143398338 M * Bertl b) what is the current procedure and why was it chosen?
1143398354 M * Bertl c) how complicated would it be to adopt this procedure
1143398363 M * Hollow for the vserver-utils part b) doesn't apply i guess
1143398364 M * Bertl d) what issues do we see/expect?
1143398380 M * Hollow we didn't implement any of those features yet
1143398384 M * Hollow in v-u
1143398418 M * Hollow a) yup :)
1143398428 M * Hollow c) i will include that into the vcd spec
1143398446 M * daniel_hozac the synchronous part makes the implementation a bit harder.
1143398451 M * Hollow i think the procedure will be like this: kernel calls helper -> rpc command to vcd -> spawn child -> wait
1143398455 M * Bertl okay, unfortunately Enrico is not here, and I have to bug daniel_hozac regarding util-vserver (but we should send the suggested sequence to Enrico for commenting on)
1143398463 M * Bertl daniel_hozac: please elaborate
1143398468 M * daniel_hozac i could ping Enrico on freenode if you want.
1143398477 M * Bertl ah, is he there?
1143398479 J * eyck ~eyck@195.242.124.92
1143398499 M * daniel_hozac well, he's online, i'm not sure if he's there.
1143398500 M * Hollow btw... did any of you take a look at http://home.xnull.de/work/vserver/vcd.spec.html ?
1143398507 M * Bertl daniel_hozac: would be great as I consider this important
1143398508 M * bonbons reboot is currently not supported by v-u, restart is a stop - start (stop waits for guest to be gone)
1143398544 M * Bertl bonbons: okay, the restart sounds sane, the only remaining question is 'how do you check for the guest gone part'
1143398562 M * Bertl (i.e. polling /proc is not a good choice :)
1143398564 M * daniel_hozac ok, i msg'ed him.
1143398576 M * Hollow i guess that's what we do currently
1143398599 M * Hollow but i'm not sure for the 1.0* branch anymore, didn't look at it for some time
1143398610 M * Bertl okay, is there any issue using the vc_wait_exit() ?
1143398614 M * Hollow i'm currently all into vcd
1143398621 M * Hollow guess not
1143398645 M * daniel_hozac Bertl: synchronous means we need to do different things for the different initstyles.
1143398682 M * daniel_hozac Bertl: now, it just calls vserver ... stop/restart and uses the regular procedure.
1143398736 M * Bertl okay, but the implication of async is that we have to decide what
1143398742 M * bonbons v-u 1.0.* is polling for the context with vx_get_info syscall
1143398749 M * Bertl the kernel should do once the helper was spawned, no?
1143398754 M * Hollow ah, right.
1143398780 M * daniel_hozac yeah, sync really is better from the kernel/sys_reboot returning side of things.
1143398783 M * Bertl bonbons: okay, I guess a change to vc_wait_exit() should not be complicated
1143398832 M * bonbons Bert: that should be no problem at all
1143398910 P * hallyn 
1143399323 M * Hollow Bertl: did you look at the vcd spec?
1143399336 M * Bertl some time ago, IIRC, url?
1143399343 J * ensc ~irc-ensc@p54B4D89A.dip.t-dialin.net
1143399350 M * ensc hi
1143399353 M * Bertl ah, the master approaches!
1143399357 M * Hollow hm, it is just 2 days old, so... http://home.xnull.de/work/vserver/vcd.spec.html
1143399359 M * Bertl welcome ensc! LTNS!
1143399400 M * Bertl ensc: sorry to bother you, but we are trying to fix the stop/restart/reboot issue once and for all
1143399436 M * Bertl http://irc.13thfloor.at/LOG/2006-03/LOG_2006-03-26.txt
1143399463 M * Bertl starting with 1143396308
1143399476 M * Bertl ensc: how is it going, btw?
1143399495 A * ensc is reading the log currently...
1143399500 M * ensc good, but much work
1143399504 M * ddlp Data from Defect Lists
1143399522 M * ddlp err... wrong window guys :)
1143399580 M * ensc 1143397370 M * Bertl 1) script starts a thread, with vc_wait_exit() and 120sec timeout ...
1143399582 Q * eyck Ping timeout: 480 seconds
1143399585 M * ensc sound like the current way
1143399694 M * daniel_hozac yeah, stop/restart are ok. reboot is the troublesome one.
1143399717 M * ensc the '1143397945 M * Bertl 5) the userspace helper _returns_' sounds problematic, because the reboot(2) syscall will return in the vserver
1143399764 M * daniel_hozac the idea is that reboot_kill would be made standard functionality.
1143399780 M * daniel_hozac i.e. killing all the guest processes left after vshelper returns with SIGKILL.
1143399938 M * daniel_hozac and as things are right now, reboot(2) will return.
1143399943 M * ensc ok; the current problem is, that vserver will be started before the reboot(2) was handled completely in the kernel?
1143399988 M * daniel_hozac for the synchronous case, yes.
1143400000 M * daniel_hozac (which is what you get if you disable legacy support in the kernel)
1143400046 M * Bertl the following changes sound reasonable to me:
1143400061 M * Bertl - ensure that the helper runs on the host (100%)
1143400080 M * Bertl - when the helper returns, execute the reboot_kill
1143400105 M * Bertl because this is probably the most 'natural' behaviour we can get
1143400121 M * Bertl after all issuing the reboot -f will do the same
1143400142 M * daniel_hozac hmm, well, for the initless case, the helper cannot run only on the host.
1143400151 M * daniel_hozac it will have to enter the vserver to execute the shutdown sequence.
1143400181 M * Bertl yes, that is fine, but currently the helper is still half way inside the guest
1143400214 M * daniel_hozac what do you mean?
1143400234 M * Bertl implementation detail, kernel side, not so relevant
1143400247 M * Bertl basically we have to drop xid info before executing the helper
1143400310 M * daniel_hozac shouldn't that be done for all kernel threads?
1143400389 M * Bertl yes, but the sys_reboot is a little special here
1143400430 M * Bertl (as I said, implementation detail, not that relevant)
1143400477 M * daniel_hozac ok.
1143400481 M * Bertl ensc: do you basically agree that the sync helper is a good thing? (because the kernel must not return from the sys_reboot() unless it isn't permitted)
1143400554 J * eyck ~eyck@195.242.124.92
1143400562 M * Bertl wb eyck!
1143400668 M * Bertl ensc: if not, please elaborate on alternatives ... (i.e. how you would want the mechanisms to work)
1143400670 M * ensc Bertl: yes, but I do not have a good idea how the 'start' can be done without an external helper
1143400689 M * Bertl external helper in this case means?
1143400730 M * Bertl what about the following scenario (short version):
1143400753 M * Bertl 1) guest calls reboot -f (init case, after all was killed)
1143400754 M * ensc somehow, it must be signaled that reboot_kill (which happens after vshelper returns) was executed
1143400767 M * daniel_hozac ensc: vc_wait_exit should work for that, no?
1143400786 M * Bertl 2) reboot helper is called, spawns waiter thread with timeout
1143400804 M * Bertl 3) init case: reboot helper exits
1143400809 M * ensc daniel_hozac: I do not think so; vc_wait_exit() is needed for 'stop'
1143400832 M * Bertl 3b) init less case: reboot helper executes runlevel scripts, then exits
1143400835 M * daniel_hozac ensc: right, but when vc_wait_exit returns, you're safe to restart the guest.
1143400848 M * Bertl 4) kernel does reboot_kill
1143400858 M * Bertl 5) context exits, the waiter kicks in
1143400905 M * ensc e.g. sequence is 'reboot -f' -> reboot(2) -> vshelper -> stop (vc_wait_exit) -> start thread waiting on something -> vshelper returns -> reboot_kill -> started thread calls 'start'
1143400907 M * Bertl 6a) if it was a timeout, send vkill, still waiting for exit
1143400918 M * Bertl 6b) if it was an exit, restart guest
1143400962 M * Bertl ensc: yep that should work
1143400990 M * ensc how to I synchronize the reboot_kill -> started thread calls 'start' transition?
1143400992 M * Bertl ensc: but the start thread would not have to wait for anything
1143401011 M * Bertl let's split that into two parts, the stop part
1143401014 M * ensc what happens, when 'vserver start' will be executed before 'reboot_kill'?
1143401030 M * ensc will the newly created context not be killed?
1143401057 M * Bertl ensc: the context will not exit before the helper returned, so that is not possible with a sync helper
1143401086 M * Bertl you basically controll the earliest point when the guest can vanish
1143401106 M * Bertl (regardless of the init case!)
1143401220 M * Bertl of course, starting the guest before the vc_wait_exit() triggers, will fail, as the guest already exists
1143401248 M * Bertl the only case not handled here would be the 'sudden guest death case'
1143401387 M * daniel_hozac what happens if you call vc_wait_exit on a non-existant context?
1143401402 M * Bertl -ESRCH imho
1143401464 J * ensc_ ~irc-ensc@p54B4C178.dip.t-dialin.net
1143401475 M * ensc_ sorry, daily reconnect of my provider...
1143401481 M * ensc_ 21:25 <      ensc> ok, then the 'stop (vc_wait_exit)' part will not work
1143401504 M * Bertl np, do you read the logs?
1143401524 N * ensc_ Guest5118
1143401532 M * Guest5118 yes
1143401562 M * Bertl so basically before you do not return from the reboot helper, the guest cannot go away
1143401578 Q * ensc Ping timeout: 480 seconds
1143401581 N * Guest5118 ensc
1143401584 M * Bertl once you return, the only thing which should happen is a force kill with newer kerneö
1143401588 M * Bertl *kernels
1143401622 M * daniel_hozac vshelper reboot would have to modified to if (init-less) { run shutdown sequence; } launch waiter.
1143401663 M * ensc when will vc_wait_exit() return? After the last process was killed, or after vshelper returned?
1143401683 M * Bertl ensc: after the context disappeared and you can start a new one
1143401696 M * Bertl (similar to the 'normal' wait)
1143401721 M * Bertl the reason for the context end can be:
1143401722 M * ensc does this mean "before vshelper exits"? ;)
1143401742 M * Bertl nope, as I said, as long as the reboot helper does not return
1143401747 M * daniel_hozac vshelper will keep the process calling sys_reboot in D state, no?
1143401750 M * Bertl the context cannot disappear
1143401763 M * Bertl here are a set of simple dependancies:
1143401775 M * Bertl vshelper has to return before context can go
1143401790 M * ensc so, the 'stop' case must be rewritten too in the userspace
1143401795 M * Bertl context has to go before the vc_wait_exit() will return
1143401814 M * Bertl tasks have to be killed before the context can go
1143401833 M * Bertl reboot_kill will not kick in before reboot helper returns :)
1143401839 M * daniel_hozac why would stop have to be rewritten?
1143401916 M * ensc the current 'vshelper -> stop (vc_wait_exit) -> vshelper returns' sequence will not work anymore; 'stop' must be executed in the background and there must be some synchronization in vshelper to delay the return
1143401946 M * daniel_hozac hmm, no, for init-less guests, the stop should be synchronous.
1143401959 M * daniel_hozac for init guests, init should've already stopped almost everything.
1143401984 M * daniel_hozac before it calls sys_reboot.
1143402041 M * Bertl precisely, the only job in the init case would be to start the waiter and add the delay
1143402059 M * Bertl (if a delay would be desireable in this case)
1143402064 M * Bertl IMHO it isn't
1143402086 M * Bertl so init-less: 
1143402091 M * Bertl - helper starts waiter
1143402099 M * Bertl - helper executes shutdown
1143402102 M * Bertl - helper exits
1143402107 M * ensc 'delay' does not mean sleep. It means to wait for 'vserver stop' to finish stop tasks (e.g. executing stop-scripts)
1143402154 M * Bertl ensc: as far as I figured the waiter and the 'timeout?' are one process, right?
1143402190 M * ensc timeout will/should be only a hack to avoid hanging contexts
1143402199 M * Bertl yes, of course
1143402237 M * Bertl so, let's assume, vc_wait_exit() and the timeout (alarm?) happens in the same process
1143402245 M * ensc in current 'vserver stop' implementation, the waiter runs in an own process
1143402258 M * ensc but 'vserver stop' waits on it
1143402268 M * Bertl this can have exactly two results, a) the wait_exit() returned, b) the timeout occured
1143402305 M * Bertl in the timeout case, you could send a vkill, and restart
1143402329 M * Bertl (of course, logging remaining processes and such)
1143402348 M * Bertl i.e. the waiter logic would look like this:
1143402362 M * Bertl - wait for context exit, or timeout
1143402376 M * Bertl - if timeout, send vkill, list processes and goto start
1143402393 M * Bertl - if context exit, do whatever has to be done (e.g. start)
1143402428 M * Bertl now the reboot helper would start such a waiter regardless of the init style
1143402450 M * Bertl and, in the init-less style, start executing the runlevel scripts, then simply exit
1143402486 M * Bertl nothing of those would require any further synchronizations, what am I missing?
1143402490 M * ensc the "wait for context exit" part is the complicated one. How will this interact with 'vshelper'?
1143402516 M * ensc as long as vshelper is running 'wait for context exit' will not return
1143402529 M * Bertl precisely
1143402538 M * daniel_hozac which is why vshelper must return ;)
1143402553 M * ensc when vshelper returns, all remaining process will be killed
1143402566 M * Bertl in the newer kernels, yes
1143402579 M * Bertl (i.e. starting with 2.0.2 /2.1.1(
1143402580 M * ensc so, I will always run in the timeout
1143402587 M * Bertl nope, why?
1143402620 M * Bertl let's talk bash here, maybe that clarifies some things:
1143402627 M * Bertl vshelper (for reboot):
1143402632 M * Bertl #!/bin/bash
1143402650 M * Bertl waiter xid=xy timeout=120 &
1143402673 M * Bertl [ -n sysv ] && shutdown context
1143402694 M * Bertl exit
1143402747 M * Bertl now the wait process will not encounter vc_wait_exit() before this script is done
1143402748 M * ensc the 'shutdown context' must not happen before the last process in the context exited
1143402770 M * Bertl the shutdown context _is_ the execution of the runlevel scripts to shut down the context
1143402788 M * Bertl s/shutdown context/call rc S/
1143402792 M * ensc e.g. because 'shutdown context' might destroy network interfaces which are needed during the shutdown phase of some processes
1143402799 M * daniel_hozac shutdown context is vserver ... exec /etc/rc.d/rc 0.
1143402802 M * Hollow Bertl: could you confirm i got things right here: http://home.xnull.de/work/vserver/vcd.spec.html#kernel-user-space-helper
1143402856 M * daniel_hozac Hollow: why such complex logic for stop?
1143402868 M * Hollow ehm, that's what we discussed above
1143402948 M * Bertl Hollow: 3/4 could be part of the waiting process in 1
1143402966 M * Hollow Bertl: well, the difference here is the timeout, no?
1143402977 M * Bertl okay, let's find terminology for some things which seem unclear atm
1143402979 M * Hollow since sys_reboot will kill all processes
1143403007 M * Bertl ensc: how do you call the process of executing the runlevel scripts for guest shutdown (inside the guest) in the init less case?
1143403071 M * Hollow Bertl: in the init case, for 4) nothing is appropriate..
1143403082 M * Bertl let's call the waiting process 'killer' or something like that
1143403103 M * Bertl although it will typically do two things:
1143403118 M * Bertl a) wait for the timeout/context exit and kill after the timeout
1143403130 M * Bertl b) take some action to get the guest running again
1143403309 M * Bertl ensc: ah, I guess now I understand what you meant
1143403319 M * Bertl please correct me if I'm wrong:
1143403350 M * Bertl you need additional synchronization to ensure that the 'shutdown' part finishes _before_ you start-up the guest
1143403369 M * Hollow vc_wait_exit?
1143403373 M * Bertl where the shutdown part is everything which happens _after_ the last task exited and the context is destroyed
1143403380 M * Hollow hm
1143403411 M * Hollow what does this "shutdown part" include?
1143403443 M * Bertl removing interfaces, and such
1143403445 M * daniel_hozac network interfaces, saving disk limits, executing scriptlets.
1143403453 M * Bertl yep, precisely
1143403478 M * Hollow well, wait_exit, run shutdown part, start again... where do we need synchronisation?
1143403524 M * Bertl let me make that more obvious, let's make that thre steps:
1143403541 M * Bertl step1: executing rc scripts and/or killing tasks
1143403552 M * Bertl step2: executing outside shutdown stuff
1143403560 M * Bertl step3: starting the guest again
1143403581 M * Bertl now, we know that step1 would happen inside the reboot helper
1143403597 M * Hollow so?
1143403602 M * Bertl but it will not terminate there, instead it will terminate in the killer
1143403615 M * Bertl then the killer has to do step2 and step3
1143403691 M * Hollow define it
1143403747 M * Bertl but IMHO that is all the synchronization which is required
1143403758 M * Hollow what is "it"?
1143403773 M * Bertl it = the process
1143403785 M * Hollow killer, helper, guest?
1143403815 M * Bertl the process of step1 will not terminate inside the helper
1143403847 M * Hollow why so?
1143403874 M * Bertl because the vc_wait_exit() cannot happen before the helper exits
1143403966 M * daniel_hozac now you lost me. step1 would happen in the helper synchronously, no?
1143403978 M * Hollow so, the helper runs rc script. these rc scripts finish, and the child of the helper terminates. now the helper returns. i don't get it..
1143403979 M * ensc ok, works when splitting the sequence in the current 'vserver stop'
1143403999 M * Bertl ensc: that's what I meant, and here is where we had the misunderstanding
1143404035 M * Bertl okay, so once again, to make sure that we all think and mean the same things:
1143404045 M * Bertl killer does:
1143404059 M * Bertl - vc_wait_exit() and timeout
1143404074 M * Bertl - if timeout, then vkill, and back to start
1143404101 M * Bertl - on vc_wait_exit() do shutdown part II, and optional restart
1143404112 M * Bertl reboot helper does:
1143404128 M * Bertl - if sysv (or gentoo?) execute runlevel stuff
1143404142 M * Bertl - exit
1143404145 M * Hollow forget gentoo init style..
1143404153 M * daniel_hozac you forgot start killer ;)
1143404165 M * Bertl oops, sorry, good thinking :)
1143404172 M * Bertl so reboot helper does:
1143404176 M * Bertl - start killer
1143404182 M * Bertl - if sysv (or gentoo?) execute runlevel stuff
1143404185 M * Bertl - exit
1143404206 M * Bertl the timeout will ensure that the runlevel stuff is killed off, if it doesn't return
1143404222 M * daniel_hozac right.
1143404238 M * Hollow i thought sys_reboot will kill the rest..
1143404240 M * Bertl now the only remaining thing is that the reboot helper must communicate the reboot/halt command to the killer, but that should be trivial
1143404250 M * Bertl Hollow: it will, on newer kernels
1143404257 M * daniel_hozac Hollow: not until the helper returns.
1143404258 M * Hollow great, i don't care about legacy
1143404277 M * Bertl Hollow: regardless, the steps are the same
1143404288 M * Hollow hm, maybe i'm too tired to get it..
1143404326 M * Bertl the things is, if you do not vkill after timeout, then an init-less guest could hang around forever
1143404357 M * ensc I think it will not need very much changes to util-vserver... vshelper will do there 'vserver ... restart/stop & wait-for-sync; exit'. 'vserver ... stop' will issue the sync-signal before vc_wait_exit()
1143404456 M * Bertl okay, is it a problem to keep the reboot kill a flag?
1143404510 M * ensc it should not be a problem
1143404512 M * Bertl ensc: sidenote, we are going to bump the version to 0x00020101 and 0x00020002
1143404560 M * ensc but I will come into problems with regression tests...
1143404560 M * Bertl okay, so we will add the independant reboot_kill and make the helper synchronous on non-legacy, yes?
1143404579 M * Bertl ensc: we can do a lot of testing for you I guess
1143404589 M * ensc ok
1143404612 M * Bertl after all this seems to be _the_ main issue right after not being able to copy a guest :)
1143404645 M * daniel_hozac ensc: shouldn't vserver ... stop's post-stop actions be delayed until after reboot_kill has triggered, and the context is really gone?
1143404690 M * Hollow Bertl: hm.. why should it not be possible to copy guests?
1143404702 M * ensc daniel_hozac: this will be delayed; 'vserver stop' will execute 'do-pre-actions; execute-initrd; issue-sync-signal; vc_wait_exit(); do-post-actions'
1143404705 M * Hollow you copy as in clone, right?
1143404717 M * Hollow +mean
1143404737 M * daniel_hozac ensc: but that means it has to happen in the waiter.
1143404741 M * ensc Bertl: this is blocked by a non-existing configuration API...
1143404741 M * Bertl yep, this is the most often asked question, especially from folks using templates
1143404759 M * Hollow cp -ra, rsync -a
1143404773 M * Hollow + -m skeleton
1143404779 M * ensc daniel_hozac: I will not have an explicit waiter; 'vserver ... stop' will have the wait functionality
1143404781 M * Bertl yep, precisely, a 'build -m skeleton' + copy would suffice
1143404799 M * Hollow so, you mean these two combined into vserver foo clone?
1143404800 M * ensc afais, only the sync-part is missing and perhaps omitting some actions
1143404832 M * daniel_hozac ensc: what do you mean? vshelper has to return after initrd has been run...
1143404857 M * ensc yes, 'vserver ... stop' will be executed in the background
1143404869 M * ensc 'vserver ... restart/stop & wait-for-sync; exit'
1143404912 M * daniel_hozac ensc: ah, ok, now i get it.
1143404915 M * ensc wait-for-sync might be reading from a pipe which is filled by 'vserver ... stop'
1143404975 Q * FireEgl Quit: Bye...
1143405105 M * daniel_hozac Bertl: ugly hack variant of clone: http://daniel.hozac.com/vserver/util-vserver-0.30.210-clone.patch
1143405232 M * Bertl yeah, soemthing like this
1143405347 M * daniel_hozac Hollow: btw, moving the signal handler setup to after the if (pid == 0) seems to have fixed it.
1143405661 M * Bertl okay, kernel side changes should be minimal
1143405679 M * Bertl the reboot_kill should only be activated with versions >= 20002
1143405710 M * Bertl helper should be sync for non legacy per  default
1143405747 M * Bertl sounds like a plan, thanks everybody for (hopefully) solving this
1143405779 M * Bertl ensc: let us know when you have a test version, we will then test it extensively
1143405793 M * ensc how do you tell vshelper whether it will be called synchronous or not?
1143405813 M * Bertl currently we decide that in the kernel config
1143405824 M * Bertl i.e. if you enable legacy, you get async
1143405837 M * daniel_hozac those ifs get really ugly and rather hard to read though ;)
1143405875 M * Bertl ensc: would you prefer a falg value for that?
1143405889 M * ensc 1143404456 M * Bertl okay, is it a problem to keep the reboot kill a flag?
1143405908 M * Bertl reboot_kill != sync vs async
1143405910 M * daniel_hozac that's VXF_REBOOT_KILL.
1143405939 M * derjohn if I enable CFQ for my guests, what if about  the scheduling per guest? I mean the iosched shares fair among all guest, but what about the share per process group within one guest? can e.g. cyrus eat up all iopower and cyrus is starving (virtual webhost setup, one per customer) ?
1143405976 M * ensc what's the difference?
1143405981 M * Bertl derjohn: you can see it as a noop scheduler inside the guest
1143405985 M * Hollow Bertl: could you check http://home.xnull.de/work/vserver/vcd.spec.html#kernel-user-space-helper again?
1143406000 M * daniel_hozac ensc: you can enable/disable reboot_kill on a per guest basis.
1143406008 M * Bertl ensc: VXF_REBOOT_KILL tells the kernel that it will send a vkill to the context
1143406008 M * daniel_hozac sync/async is kernel configuration dependent.
1143406012 M * Hollow hm, well.. the anchor dissapeared
1143406028 M * Bertl ensc: while the helper can be called synchonous and asynchronous, independant from that
1143406067 M * ensc that influence the vc_wait_exit() behavior?
1143406081 M * derjohn ehlo ensc! Nice to have you se you here on the channel!
1143406140 M * daniel_hozac ensc: nothing should influence vc_wait_exit's behaviour.
1143406172 P * meandtheshell 
1143406191 M * ensc in current asynchronous case, vc_wait_exit() can return within vshelper. In synchronous case, it will never return during vshelper, right?
1143406195 M * Hollow hm, maybe reboot 4) should state to do it in background
1143406211 M * daniel_hozac ensc: right.
1143406253 M * daniel_hozac ensc: but that's only because vshelper keeps the process which called sys_reboot around.
1143406306 M * ensc ah ok
1143406346 J * mnemoc ~amery@user4-2.tutopia-dialup.ifxnw.cl
1143406348 M * ensc at least, I need a way to check which variant of reboot(2) is in use
1143406381 M * ensc I am not sure, whether an environment variable would be too far away from current vserver style
1143406424 M * Bertl wb mnemoc!
1143406431 M * Bertl ensc: we have several options here:
1143406440 M * mnemoc thx Bertl :)
1143406482 M * Bertl a) we could add an env var stating async vs. sync, but that would not be before 2.0.2/2.1.1, and IIRC we do not need async there anylonger, except for older tools, which will not check the env var
1143406516 M * Bertl b) we can agree on sync as default for 2.0.2/2.1.1 unconditional
1143406528 M * daniel_hozac Bertl: well, people like myself would be using recent utils on kernels with legacy support.
1143406547 M * Bertl c) we could keep it as is, i.e. legacy enables async 
1143406637 M * Bertl d) we could make that a flag, and let userspace control it, default would probably have to be async then
1143406665 M * Bertl in any case, the tools can use the version information to detect the support
1143406673 M * Hollow i'd prefer c)
1143406693 M * daniel_hozac i'd prefer d :)
1143406769 M * Hollow yeah, ok as well..
1143406775 M * Bertl ensc: ?
1143406813 M * ensc I tend to c
1143406856 M * ensc but I am not sure if bundling with CONFIG_.._LEGACY is the best way
1143406909 M * daniel_hozac that's why i prefer d.
1143406917 M * daniel_hozac the tests for legacy become terrible.
1143406940 M * Bertl ensc: you know that you can read most config options at runtime, yes?
1143406954 M * ensc Bertl: how?
1143407039 M * Bertl when you give the recent testme.sh a try, you will see that it reads the VCI config and also interprets it
1143407056 M * Bertl VCI = Vserver Configuration Information
1143407059 M * daniel_hozac [ $[ ($[ 16#$(awk '/VCIKernel:/ { print $2 }' /proc/virtual/info) ] >> 1) & 1 ] -ne 0 ] && echo legacy!
1143407086 M * daniel_hozac as i said, it's not pretty ;)
1143407102 M * rmoriz hrm. old-style util-vserver created vserver seem to have problems accessing /proc. newly create vserver context are working fine. mtab and fstab look identical
1143407103 M * ensc does there exist a syscall for reading it? (I do not mean open(2))
1143407108 Q * lilalinux Remote host closed the connection
1143407118 M * Bertl lol
1143407157 M * Bertl ensc: no, not at the moment, but we can add that
1143407180 M * Hollow extend vc_get_vx_info?
1143407196 M * Hollow hm, no
1143407201 M * Hollow that's xid specific
1143407283 M * Bertl we would do that with a separate command
1143407293 M * Bertl which returns certain config informations
1143407310 M * ensc ok
1143407331 M * ensc extending VCMD_get_version would not be a good idea...
1143407339 M * Bertl IMHO not
1143407364 M * Bertl although we could make a new version of that
1143407367 M * Hollow ok, will leave to bed now... night all
1143407374 M * daniel_hozac good night Hollow!
1143407375 M * Bertl Hollow: good night!
1143407445 M * ensc Bertl: no; VCMD_get_version API should stay as is for all vserver versions because it is used to check for existing APIs
1143407483 M * Bertl ensc: okay, good that we agree there :)
1143407510 M * Bertl apropos APIS, will the new scheduler API be supported soon?
1143407553 M * ensc I can live for now with bundling async reboot(2) with legacy, but the query-config syscall should be kept in eye
1143407595 M * Bertl okay, I will add it to 2.02 and 2.1.1, you can get the API in a day or so
1143407626 M * ensc I will see; finished my FC5 transition yesterday so I should have some time for vserver now
1143407635 M * Bertl sidenote: why is the --enable-apis option called NOLEGACY when you have to enable it on LEGACY systems?
1143407694 M * daniel_hozac ensc: while on the topic of FC5, do the packages in FE5 work? utilvserver_checkCompatVersion gets miscompiled here. (shiny9 fixes that though)
1143407720 M * ensc because it disables the old Jaques API which was called 'legacy'
1143407737 M * daniel_hozac maybe call that ancient instead?
1143407754 M * ensc daniel_hozac: really? I am using it here and do not see problems
1143407786 M * ensc Bertl: the recent kernel 2.4 API is called 'compat' ;)
1143407797 M * ensc I am not got in inventing names ;)
1143407799 M * daniel_hozac ensc: i haven't tested the packages, but the ones i built got that.
1143407813 M * ensc daniel_hozac: do you have a testcase?
1143407828 M * daniel_hozac ensc: LD_PRELOAD=/usr/lib/util-vserver/rpm-fake.so ls -l
1143407854 M * ensc why do you think that this shall work? 
1143407857 M * Bertl yeah, the library seems to have issues with recent gcc
1143407861 M * ensc you have to set some envrionment variables
1143407865 M * daniel_hozac it shouldn't, but it also shouldn't return ENOSYS.
1143407879 M * daniel_hozac utilvserver_checkCompatVersion will return the location of errno as the version.
1143407903 M * daniel_hozac ensc: basically, the No chroot specified etc. means success.
1143407906 M * Bertl ensc: it's an optimization issue with gcc4.x
1143407969 M * ensc [root@kosh ~]# LD_PRELOAD=/usr/lib/util-vserver/rpm-fake.so ls -l
1143407969 M * ensc No chroot specified; aborting...
1143407969 M * ensc rpm-fake.so: failed to initialize communication with resolver
1143407979 M * ensc [ensc@kosh devel]$ rpm -qi util-vserver
1143407981 M * ensc Install Date: Sa 25 Mär 2006 17:36:38 CET      Build Host: hammer1.fedora.redhat.com
1143407996 M * ensc (that's the package from the Fedora Extras repository)
1143407998 M * daniel_hozac ok, cool.
1143408023 M * ensc                        CC: gcc, gcc (GCC) 4.1.0 20060228 (Red Hat 4.1.0-1)
1143408032 M * daniel_hozac ah, this is 4.1.0-3.
1143408061 M * daniel_hozac or do you have a non-standard memory split?
1143408066 M * Bertl in any case, the shiny9 also adds mips support
1143408068 M * ensc ok, I will check this
1143408083 M * ensc CONFIG_HIGHMEM4G=y
1143408084 M * ensc CONFIG_VMSPLIT_3G=y
1143408088 M * Bertl it's straight forward and only a change in my alternative syscall stuff
1143408223 M * rmoriz what could be the reason that i don't get /proc on one vserver (migrated from old util-vserver) but on a newly created one? i could not find configuration changes :(
1143408253 M * daniel_hozac rmoriz: did you migrate to the new configuration style?
1143408260 M * rmoriz daniel_hozac: yes
1143408285 M * daniel_hozac rmoriz: so you have /etc/vservers/<name>/fstab, which contains a line with proc?
1143408291 M * rmoriz ftab/mtab in /etc/<vserver> and /vserver/<vserver>/etc are the same for workin/non working guests
1143408327 M * rmoriz none    /proc           proc    defaults                0 0
1143408348 M * rmoriz it's the same for working and non working context :(
1143408410 M * daniel_hozac rmoriz: how did you create the new configuration for the old guest? with vserver ... build -m skeleton?
1143408429 M * rmoriz yes
1143408462 M * daniel_hozac and what makes you think that you do not have proc inside the guest?
1143408480 M * rmoriz ns1:/# w
1143408480 M * rmoriz Error: /proc must be mounted
1143408492 M * daniel_hozac does /proc contain anything?
1143408502 M * rmoriz yes
1143408536 M * daniel_hozac such as? have you run vprocunhide on the host?
1143408624 M * rmoriz loadavg cpuinfo loadavg  etc
1143408632 M * rmoriz yes i run vprocunhide
1143408653 M * rmoriz it only affects "old" vservers i think :(
1143408678 M * daniel_hozac there's is no difference between a new and an old vserver if you have migrated it to the new configuration style.
1143408681 M * Bertl okay, I'm off for now ... back later ...
1143408690 N * Bertl bertl_oO
1143408698 M * rmoriz cu bertl_oO 
1143408713 M * bertl_oO ensc: thanks for your time!
1143408741 M * daniel_hozac rmoriz: could you run strace -fF -o w.strace w and upload w.strace somewhere? (like phpfi.com)
1143408848 M * rmoriz http://rafb.net/paste/results/eU7qTM73.html
1143408893 M * daniel_hozac rmoriz: on the host, execute setattr --~hide /proc/stat
1143408952 M * rmoriz hm /proc/stat is missing on the newly vservers and w still works there
1143408990 M * daniel_hozac and are they using the same version of w?
1143408994 M * rmoriz now "w" and "ps" work on the old vserver, but i'm getting "Unknown HZ value! (114) Assume 100" as 1st line with "w"
1143409027 M * rmoriz oh. you're rigth
1143409029 M * rmoriz right
1143409037 M * rmoriz broken: procps version 2.0.7
1143409050 M * rmoriz working: procps version 3.2.1
1143409064 M * rmoriz i thought both are sarge hrm.
1143409088 M * daniel_hozac i guess one's a woody.
1143409125 M * rmoriz so older tools workin on /proc do have some problems when some "keys" are missing.
1143409171 M * rmoriz thank you :)
1143409204 M * daniel_hozac well, yes, the older tools don't know that 2.6 reorganized things.
1143409260 M * rmoriz oh damn. i forgot that :(
1143409269 M * rmoriz i'm sorry for asking such stupid questios ;(
1143409300 M * rmoriz the old box is still running 2.4 - i just forgot that >:(
1143410632 P * f_ Leaving
1143411393 Q * matta Ping timeout: 480 seconds
1143412476 J * matta ~matta@71.224.125.126
1143412679 J * Aiken ~james@tooax6-102.dialup.optusnet.com.au
1143415470 Q * click Ping timeout: 480 seconds
1143415858 Q * entroposcope Read error: Connection reset by peer
1143417062 Q * bonbons Quit: Leaving