1140393741 M * mugwump cool... Perl Linux::VServer module on it's way :)
1140393888 M * NikDaPhreak off to bet... no luck tonight with this host.. may be better tomorrow... night folks!
1140393954 Q * NikDaPhreak Quit: Hybernating my brain....
1140394205 Q * Doener Quit: Leaving
1140395561 J * Efort ~Proced@ACB549AD.ipt.aol.com
1140395753 Q * vrwttnmtu Quit: Leaving
1140395770 N * Efort Genius
1140396490 N * Genius Geniuss
1140396697 Q * Geniuss Quit:
1140397435 Q * VxJasonxV Ping timeout: 480 seconds
1140397776 J * VxJasonxV ~jason@ip68-110-115-17.ph.ph.cox.net
1140398601 M * mugwump oh, libvserver.so doesn't build a shared lib?
1140398640 M * ebiederm It is very badly names if it doesn't !
1140398650 M * mugwump er, more of a typo ;)
1140398654 M * mugwump s/.so//
1140399056 M * mugwump hmm, 0.4 managed to build a shared lib ok
1140399129 M * mugwump ah, it disables shared libs if dietlibc is detected
1140404085 Q * mkhl Ping timeout: 480 seconds
1140405920 Q * kilian Ping timeout: 480 seconds
1140407348 J * cehteh foobar@cehteh.homeunix.org
1140407677 J * matta ~matta@71.224.125.126
1140407870 J * kilian kk@projects.verfaction.de
1140409095 J * shuri ~boafroid@64.235.209.226
1140412159 Q * VxJasonxV Remote host closed the connection
1140412353 Q * shuri Quit: Quitte
1140412399 M * Hollow mugwump: libvserver depends on dietlibc, and will only built static libs
1140412543 J * VxJasonxV ~jason@ip68-110-115-17.ph.ph.cox.net
1140413497 Q * Aiken Remote host closed the connection
1140413523 M * Cru morning
1140413542 J * Aiken ~james@tooax6-037.dialup.optusnet.com.au
1140414154 M * Skram Mornin'
1140414184 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1140414572 M * ebiederm Night all
1140414577 N * ebiederm ebiederm_zZ
1140416415 Q * gerrit Ping timeout: 480 seconds
1140416889 Q * Aiken Ping timeout: 480 seconds
1140418332 M * eyck night
1140418337 M * eyck nighty night
1140418433 M * eyck hmm, why would anyone put noatime,nodiratime on / ?
1140421826 J * meandtheshell ~markus@85-125-225-161.dynamic.xdsl-line.inode.at
1140423981 M * Cru on a notebook computer? ;)
1140424154 M * eyck hmm, ok.
1140424359 J * Doener doener@i5387D9A6.versanet.de
1140424403 M * Doener morning
1140425046 Q * shedi Quit: Leaving
1140426169 M * phreak`` diogo: ask you question :)
1140426179 M * phreak`` morning all :)
1140426602 M * Doener hey phreak``
1140427536 J * bonbons ~bonbons@83.222.39.180
1140428280 Q * matta Ping timeout: 480 seconds
1140428332 M * phreak`` Doener: *uh* that patch made it into -mm ?! :)
1140428356 M * Doener yeah, the third version ;)
1140428374 M * Doener (fourth if you count Bertl's)
1140428430 M * phreak`` heh :)
1140428575 M * phreak`` Doener: do you happen to know the exact name for the patch (in -mm that is) ?
1140428622 M * Doener hm, check the topic of the second thread ;)
1140428672 M * phreak`` ah, the daemonize_detach :) thanks :D
1140428943 J * tudenbart ~willi@xdsl-213-196-240-16.netcologne.de
1140429274 Q * dothebart Read error: Connection reset by peer
1140429801 Q * matti Remote host closed the connection
1140429875 J * shedi ~siggi@tolvudeild-204.lhi.is
1140430355 Q * Duckx Ping timeout: 480 seconds
1140430355 Q * DuckMaster Ping timeout: 480 seconds
1140430380 J * Duckx ~duckx@195.75.27.158
1140430386 J * DuckMaster ~duckx@195.75.27.158
1140431548 J * romke ~romke@acrux.romke.net
1140431985 J * matti matti@linux.gentoo.pl
1140432437 Q * mire Ping timeout: 480 seconds
1140433098 J * mire ~mire@176-166-222-85.COOL.ADSL.VLine.Verat.NET
1140433208 J * Smutje_ ~Smutje@xdsl-87-78-63-164.netcologne.de
1140433359 Q * Smutje Ping timeout: 480 seconds
1140433729 Q * Smutje_ Ping timeout: 480 seconds
1140434073 J * Smutje ~Smutje@xdsl-87-78-63-164.netcologne.de
1140437349 M * Bertl morning folks!
1140437424 M * phreak`` morning Bertl :)
1140437530 M * Hollow morning Bertl
1140437554 M * Hollow Bertl: is http://vserver.13thfloor.at/Stuff/SYSCALL/syscall.h up to date?
1140437668 M * Bertl let me check
1140437902 M * Bertl seems it's not the latest and greatest, still PIC code missing, IMHO
1140438192 M * Hollow hm, 0.30.210 should have the latest?
1140438266 M * Bertl the mdk rpm I have somewhere, yes
1140438281 M * Hollow ok, will look
1140438303 M * Bertl but I'm not sure the pic changes did make it into it
1140438323 M * Bertl (will look into it after answering my email)
1140438342 M * Hollow hm, just grpped for it.. seems like i have a PICed version already
1140438365 M * Hollow and 210 seem to have that one too
1140438383 M * Hollow guess i'm up to date ;)
1140438864 M * Doener hey Bertl :)
1140438985 Q * brc Quit: [BX] Mike Tyson says BitchX BITES! Do you HEAR what I'm saying?!
1140439000 J * brc bruce@20151181056.user.veloxzone.com.br
1140439289 Q * monrad Ping timeout: 480 seconds
1140440368 J * pflanze ~chris@unk-110.ethz.ch
1140440572 M * Bertl welcome pflanze!
1140440578 M * pflanze Hi!
1140440593 M * pflanze I've just noticed something maybe not-so-good:
1140440611 M * pflanze ipcs on the host shows the ipc items from all vservers.
1140440622 M * pflanze without needing a chcontext --ctx 1
1140440681 M * Bertl with 2.6.16-rc4-vs2.1.1-rc* or 2.0.2-rc*?
1140440697 M * pflanze 2.6.15.4-vs2.0.2-rc5
1140440815 M * pflanze Something else, about which I'm not sure what happens, is: root@vserver-foo ipcs does not show a semaphore owned by someuser@vserver-foo.
1140440836 M * pflanze But I'm not sure if it is supposed to.
1140440879 M * pflanze On a non-vserver machine, ipcs run as root and as user outputs the same info; but maybe there is a way to create semaphores which are hidden from other users including root?
1140440943 M * Bertl no, sounds more like a bug ...
1140440961 M * Bertl do you have some test programs to verify the ipc functionality?
1140440990 M * pflanze Not really, I'm using apache and a fastcgi application of mine which creates a semaphore.
1140441019 M * pflanze Do you want a few lines of perl for creating them ?
1140441020 M * Bertl how did you test/discover this?
1140441036 M * Bertl that would be great!
1140441199 M * pflanze perl -MIPC::Semaphore -MIPC::SysV=IPC_PRIVATE,S_IRWXU,IPC_CREAT,SEM_UNDO -we '$s= new IPC::Semaphore(IPC_PRIVATE, 1, S_IRWXU | IPC_CREAT); $s->setall(1)'
1140441225 M * pflanze well the $s->setall can be omitted.
1140441273 J * lilalinux ~plasma@h1-gw.of.net-lab.net
1140441287 M * Bertl okay, and this done on the host (or within a context) should create a per context semaphore, yes?
1140441299 M * pflanze Run this as non-root user inside a vserver.
1140441309 M * pflanze ipcs as this user will show it.
1140441315 M * pflanze ipcs as root in the vserver will not show it.
1140441320 M * pflanze ipcs as root on the host will show it.
1140441365 M * Bertl okay, and on a 'normal' system, the user and root sees it, yes?
1140441390 M * pflanze yes
1140441409 M * Bertl okay, have to get the perl files into my test guest first
1140441576 M * eyck apt-get install ... ;)
1140441613 J * monrad ~mikkel@213.83.190.131
1140441630 M * Bertl eyck: the hsot+guest is 32MB
1140441669 M * eyck there is microperl in perl bootstrap
1140441670 M * eyck hmm,
1140441687 M * eyck I don't see it..
1140441692 M * Bertl nah, I already have perl there, jsut the files are missing
1140441706 M * eyck one vserver doesn't see the other vserver's sem/msg/shm
1140441725 M * eyck at least on my machine
1140441736 M * pflanze eyck: that's right, and ok. But the host sees them, without needing ctx 1.
1140441755 M * eyck hmm,
1140441758 M * pflanze eyck: and, what's strange, the root of the vserver does *not* see them whereas it should.
1140441759 M * Bertl pflanze: the -MIPC::SysV is mapped to use IPC::SysV right? but how to map the =IPC_PR...?
1140441769 M * Bertl (I'm trying to make it a script :)
1140441772 M * eyck I don't see that as a problem, not even a nuicance..
1140441794 M * eyck lack of elegance, maybe :)
1140441812 M * pflanze Bertl: no, that means "use IPC::Semaphore; use IPC::SysV 'IPC_PRIVATE','S_IRWXU','IPC_CREAT','SEM_UNDO' "
1140441817 Q * FireEgl Ping timeout: 480 seconds
1140441829 M * Bertl ah, key
1140441888 M * pflanze (eyck: you knever now when it might turn into a problem..)
1140441980 M * eyck (pflanze: maybe, I try to minimize amount of apps on host, it's almost strictly dedicated for disaster recovery entry point for guests)
1140442054 M * pflanze (sure, but i'd love to know if the rest of the security stands, and not being able to scan (for e.g. cleanup) the semaphores of all users in a vserver can be a problem.)
1140442090 M * pflanze btw "will semaphores created by a vserver be removed if a vserver is restarted?"
1140442177 M * pflanze (also replace semaphores with sysv shared mem / message queues of course)
1140442180 M * Bertl good question, btw, is there a way to list _what_ files this simple script requires?
1140442196 M * Bertl have now been adding about 10 different .pm files 'it requested'
1140442197 M * pflanze Bertl: well I guess it needs some .so
1140442207 M * pflanze Bertl: strace?
1140442219 M * pflanze I have a script for that
1140442246 M * eyck it was tricksy IIRC, PAR does this... and it ain't always simple
1140442268 M * pflanze Bertl: http://pflanze.mine.nu/~chris/scripts/utilities/straceopens
1140442297 M * pflanze Bertl: you might be better of rewriting it into C.
1140442341 M * Bertl seems so
1140442411 M * Bertl after adding ~ 45 perl headers, it seems to work :)
1140442472 M * pflanze Those are not headers, those are the implementation
1140442508 M * pflanze (unless you mean .h files for compilation of course)
1140442536 M * Bertl yeah, well those ugly *.pm files :)
1140442586 M * pflanze hehe
1140442592 M * Bertl so, I can answer a few question now
1140442603 M * Bertl first, sems _are_ persistant
1140442634 M * pflanze over vserver restarts?
1140442647 M * Bertl (they will give you a warning on exit when debug is enabled that the sem is still there)
1140442675 M * Bertl second, the sems _are_ properly isolated between contexts
1140442687 M * Bertl i.e. sem in xid=100 is not seen by sem in xid=200
1140442721 M * Bertl third, xid=0 does not see sems from xid!=0
1140442736 M * pflanze huh? why do i see them?
1140442745 A * pflanze checks again
1140442755 M * Bertl now going to test the 'user' stuff
1140442772 M * Bertl ah, btw, how do you 'check' for the sems?
1140442784 M * pflanze I look whether ipcs shows them.
1140442796 M * Bertl hmm, used /proc/sysvipc/sem for now
1140442808 M * Bertl have to get ipcs first :)
1140442810 M * pflanze I'd have to write a little more code to see whether they can be attached to.
1140442817 A * pflanze checks proc on the host
1140442880 M * pflanze /proc/sysvipc/sem is empty on my host.
1140442886 M * pflanze but ipcs still shows them.
1140442898 M * Bertl ah, okay, so one interface virtualized, the other one not
1140442903 M * Bertl probably doing entlink stuff
1140442971 Q * Doener Quit: Leaving
1140443774 M * Bertl yup, seems like semctl_* is missing some virtualization
1140443847 M * Bertl pflanze: are you willing to test stuff there?
1140443906 M * pflanze well, I (still) do not have a test machine, rebooting the live machine is possible but I'd like to make this rare
1140443915 J * matta ~matta@71.224.125.126
1140443938 M * pflanze Bertl: I have a powerpc machine at home on which I could (and probably will) install vserver as well.
1140443945 M * pflanze This machine could be rebooted at will.
1140443985 M * Bertl pflanze: okay, as my test machines are not reachable (for some time now), we delay this until either ebiederm has done his IPC virtualization or we find some time/folks to test this ...
1140443998 M * pflanze yep that's fine.
1140444013 M * pflanze By then I might have my home machine ready as well.
1140444015 M * Bertl it's not just a simple check, it requires getting the numbers right ...
1140444054 M * Bertl (i.e. we also have to define proper semantics, which I'd delay until we do it for mainline)
1140444081 M * pflanze That's fine. Thanks for caring about it.
1140444096 M * Bertl you're welcome! and thanks for the feedback!
1140444106 M * pflanze np:)
1140444176 A * pflanze has to leave
1140444187 Q * pflanze Quit: c ya
1140444537 M * Bertl Vudumen: ping!
1140444636 J * FireEgl Atlantica@2001:5c0:84dc::
1140444654 M * Bertl welcome FireEgl!
1140445067 M * Bertl Hollow: no, the syscall.h seems in sync with my package
1140445090 M * Bertl Hollow: but somehow I remember that we 'fixed' some PIC issues on non x86
1140445237 Q * matta Ping timeout: 480 seconds
1140445857 Q * ntrs Quit: Leaving
1140447062 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1140449071 M * bonbons Bertl: question about parent pid, state-change signal and init-process in guests!
1140449139 M * bonbons Bertl: I have initng in the guest, it starts e.g. forking apache. When apache exits, it expects to get a signal in order to "detect" that apache has terminated though it never gets such one
1140449194 M * bonbons how is the ppid = 1 of such a guest's daemon interpreted, guest's init or host's init? (for the signal to be sent to parent process)
1140449828 M * Bertl details about your versions?
1140449851 M * harry 1.0.0alpha3
1140449860 M * harry ;)
1140449863 M * harry or: hi Bertl :)
1140449876 M * Bertl hi harry!
1140449940 M * harry how are things around here?
1140449956 M * Bertl fine, fine, and how are you?
1140449961 M * harry pretty good
1140449963 M * harry week just started
1140449967 M * harry monday feeling
1140449988 M * harry too much work... so i better get some sleep before i start
1140450006 M * harry haven't done anything yet... :S
1140450142 M * bonbons Bertl: kernel 2.6.15, vs2.1.0.4, vserver-utils 1.0.3
1140450173 A * harry still hates 2.6.15.* kernels...
1140450185 M * harry too many problems with acpi/swap/other mm parts
1140450332 M * Bertl bonbons: for guest init the same rules apply than for real init
1140450344 M * Bertl bonbons: i.e. it doesn't get signals it doesn't handle
1140450529 M * Bertl now checking if the signal sending is done properly
1140450608 M * bonbons Hmm, I gues it's handling that signal, will add some more debug info and test... non-forking daemons are detected, forking ones not (so initng -> daemon is OK, initng -> daemon[fork&exit] -> daemon[forked] does not work)
1140451317 A * Snow-Man suspects there's a few more 'disadvantages' to OpenVZ than Kirill lets on.
1140452060 M * Bertl I'm sure about that ... after all what is discussed on the cannel ...
1140452185 M * Bertl okay, off for dinner .. back later ...
1140452198 N * Bertl Bertl_oO
1140452511 J * mkhl mkhl@200-153-153-39.dsl.telesp.net.br
1140452668 Q * Hollow Remote host closed the connection
1140452831 J * Hollow ~hollow@home.xnull.de
1140453726 J * pflanze ~chris@84-73-52-252.dclient.hispeed.ch
1140453734 Q * mkhl Ping timeout: 480 seconds
1140454127 J * mkhl mkhl@200-153-153-39.dsl.telesp.net.br
1140454264 Q * shedi Quit: Leaving
1140454791 N * Bertl_oO Bertl
1140454793 M * Bertl back now
1140454922 M * matti B.
1140454925 M * matti :>
1140454954 M * bonbons Bertl: not sure if initng gets the signal, though it's registering for it! Is there a way to check it it has a signal handler registered for SIGCHLD?
1140454990 M * bonbons I tried kill -s SIGCHLD 1 inside the guest, but not matching debug info :-(
1140455255 M * Bertl hey matti!
1140455283 M * Bertl bonbons: SIGCHLD might be special
1140455304 M * Bertl bonbons: do you have a test system available?
1140455326 M * bonbons might be :) Yup, test-system is waiting, pre-heated
1140455353 M * Bertl okay, I can provide a patch (in a few minutes) to log some stuff regarding those signals
1140455367 M * Bertl if you are interested, just let me know
1140455433 M * bonbons ok, I'm interested, quite anoying to wait 2 minutes for each guest to shutdown or service inside the guest :)
1140455471 M * Bertl okay, please get a 2.6.16-rc4 kernel and prepare a config for that in the meantime
1140455485 M * Bertl (with the vserver patch of course)
1140455490 M * bonbons maybe I should also upgrade to a more recent vserver-patch? 2.1.1rc7 is the most recent one hollow has put in portage
1140455523 M * Bertl that is also the latest released aptch
1140455917 M * bonbons though I don't know which kernel it's based on... probably 2.6.15...
1140455938 M * Bertl just get vanilla 2.6.16-rc4 and the patch (for the test)
1140455956 M * Bertl and use a kernel config which doesn't include the kitchensink so taht we can recompile it easily
1140456018 M * bonbons the patch on kernel.org for 2.6.16-rc4 is against what?
1140456026 M * Bertl 2.6.15
1140456409 M * bonbons what are the arguments to patch for applying the 2.6.16rc4 and vserver patches?
1140456420 M * Bertl patch -p1
1140456436 M * Bertl (when you are inside the kernel source tree)
1140456613 M * bonbons ok, both patches applied, will make-oldconfig with my current config.
1140456975 M * bonbons what is the "kitchsink" you were speaking above?
1140456999 M * Bertl stuff you do not need in your kernel, drivers you do not have hardware for and such
1140457016 M * Bertl filesystem and features you do not even use ...
1140457106 M * bonbons my config is reduced to what I have/use (except for a few SUB things and network/iptables support)
1140457117 M * Bertl excellent!
1140457242 M * bonbons otherwise it takes long to compile, and is unmanagable on upgrades :) (not speaking about potential conflicts or incorrect detections)
1140457268 M * Bertl yep, that's what I meant with the (metaphorical) kitchen sink :)
1140457300 M * bonbons ok, some special kernel debugging output to enable?
1140457357 M * Bertl http://vserver.13thfloor.at/Experimental/delta-signal-debug01.diff
1140457484 M * bonbons compilation started...
1140457574 M * Bertl will give you kernel log messages whenever signals are sent
1140457574 Q * VxJasonxV Read error: Connection reset by peer
1140457588 M * Bertl so you should keep the process spawning and signaling low
1140457609 M * Bertl so that we can find the right entries
1140457698 M * bonbons I made the kernel message buffer larger, an will do the tests on console (with only required guest running!)
1140457930 J * VxJasonxV ~jason@ip68-110-115-17.ph.ph.cox.net
1140458224 M * bonbons kernel compiled and bootloader updated, rebooting
1140458305 Q * harry Ping timeout: 480 seconds
1140458337 Q * mire Read error: Connection reset by peer
1140458424 M * bonbons Bertl: wow, the gentoo init-scripts for the system produce a gigantic amount of signals!
1140458688 M * bonbons Bertl: can you explain what information each line provides? e.g. sigdel_b: f7af3030[#12,7433] ka=f7d1f6c4;08078e40
1140458717 M * bonbons I guess the 7433 is the PID, #12 the signal number, but for the rest...
1140458774 M * bonbons then there are also lines with _sendsig... xxxxxx[#dd, ddd] xxxxxx(17)
1140458897 M * daniel_hozac bonbons: the delta tells you what it is ;)
1140459001 M * bonbons ah ok (I should have looked inside...)
1140459247 J * mire ~mire@80-166-222-85.COOL.ADSL.VLine.verat.net
1140459333 M * Skram SENTIEN / # emerge -av samba
1140459334 M * Skram These are the packages that I would merge, in order:
1140459334 M * Skram Calculating dependencies \
1140459334 M * Skram !!! All ebuilds that could satisfy ">=sys-apps/baselayout-1.11.14" have been masked.
1140459338 M * Skram what do i do? :(
1140459418 M * daniel_hozac fix the samba ebuild, i guess.
1140459425 M * bonbons the PIDs in there, are they virtualized or not? I assume they are the target of the signal
1140459452 M * daniel_hozac bonbons: i don't think so.
1140459478 M * bonbons Skram: check the deps of samba, but also on it's deps! maybe the cause is in something depending on udev
1140459547 J * brisho ~brians@adsl-66-142-57-54.dsl.kscymo.swbell.net
1140459589 M * Bertl welcome brisho!
1140459613 M * Bertl bonbons: could you uplaod the output of the signals inquestion?
1140459657 M * bonbons Bertl: yep, will also assemble some ps output to it
1140459664 M * Bertl excellent!
1140459760 J * Viper0482 ~Viper0482@p54977D95.dip.t-dialin.net
1140459942 M * bonbons Here they are: http://homepage.internet.lu/brunop/ps.all and http://homepage.internet.lu/brunop/dmesg.kill_7497
1140460095 M * bonbons initng (pid 7398) should get informed about termination of apache2 process(es). I cleaed the dmesg buffer before issuing the kill 7497 in order to have minimal overhead
1140460114 M * Bertl okay
1140460136 M * Bertl sendsig: f7af3030[#12,7433] -> f7bc3a70[#12,7497] f7bdbf34
1140460153 M * Bertl this means pid 7433 is sending a signal to 7497
1140460160 M * Bertl I assume that is your kill
1140460170 M * Bertl the signal is TERM (15)
1140460186 M * bonbons should be the kill
1140460218 M * Bertl 97,98,99,00,01,02,03 seem to be the threads
1140460226 M * Bertl which get the signal too
1140460271 M * bonbons 97 is the master, the other ones are the children (process group I assume)
1140460351 M * Bertl the apache process receives the sigchilds from the terminating threads
1140460385 M * Bertl also host init is informed of some process exits
1140460399 M * Bertl (which would suggest that they did daemonize properly)
1140460409 M * bonbons but guest's init is never informed it seems...
1140460457 M * Bertl hmm, well, it seems to me that this 'just happens' to work on a real system, not by design but by accident
1140460471 M * Bertl doesn't mean that we cannot do some adjustments there
1140460491 N * ebiederm_zZ ebiederm
1140460507 M * Bertl morning ebiederm! you've got mail! :)
1140460518 M * bonbons hmm... so the way initng checks for dying processes is let's say dangerous?
1140460536 M * ebiederm Bertl: So I see. I'm not quite ready to process that pile yet.
1140460565 M * ebiederm Did you see Andrews suggestion on how to avoid the problems with callking kernel_thread?
1140460577 M * Bertl bonbons: well, no, it seems to rely on the fact that everything which is daemonized is reparented to init
1140460610 M * Bertl ebiederm: not yet .. was busy answering kirill's emails :)
1140460628 M * bonbons yep, but here it's reparented to the "wrong" init
1140460669 M * ebiederm Bertl: Basically the idea is to trigger all kernel thread creation from keventd.
1140460691 M * ebiederm Using the kthread API...
1140460769 M * dhansen ebiederm: you might want to skip down to 'Subject: Which of the virtualization approaches is more suitable for kernel?' :)
1140460770 M * bonbons Bertl: I will look how I can make initng survive this more gracefully, could you check if those signals can be redirected to context's init?
1140460807 M * ebiederm dhansen: Thanks.
1140460856 M * Bertl ebiederm: ah, yeah, I read that
1140460864 J * harry ~harry@d515321D1.access.telenet.be
1140460907 M * dhansen Bertl: ebiederm: I'm going to lay off that thread and wait to see if we get a response from the targets of the mail. I trust that they're smart enough to cut through any "inaccuracies" in the mail by themselves.
1140461031 M * Bertl @all: does anybody here know how to contact id23 an Vudumen via email?
1140461158 M * ebiederm dhansen: Has Kirrill publish a proposed container API?
1140461189 M * dhansen ebiederm: not that I know of, other than the OpenVZ patches ;)
1140461217 M * Bertl well, they are well tested so we can savely use them :)
1140461260 M * Bertl but seriously,
1140461292 M * Bertl I guess we will end up with a huge number of syscalls if we want to provide certain functionality
1140461324 M * ebiederm Thanks. Now I know what kind of priority to put on Kirill's emails.
1140461372 M * Bertl dhansen, ebiederm: http://vserver.13thfloor.at/Stuff/Docu/syscall2.8.txt
1140461398 M * Bertl the fields with names there usually contain 1-3 'commands'
1140461411 M * Bertl (ecept for the special columns)
1140461424 J * shedi ~siggi@inferno.lhi.is
1140461458 M * Bertl wb shedi!
1140461472 M * shedi hello Bertl
1140461536 M * ebiederm Bertl: I don't have the context to quickly comprehend that table.
1140461574 M * dhansen Bertl: me neither :(
1140461615 M * Bertl shall I explain?
1140461696 M * ebiederm sure.
1140461713 M * Bertl okay, Linux-Vserver uses a so called syscall switch
1140461731 M * Bertl we basically defined (a long time ago) a kind of ioctl syscall
1140461746 M * Bertl which has a fixed format on all architectures
1140461768 M * Bertl (this was done in sync with the FreeVPS folks)
1140461777 M * dhansen Bertl: ahh, and this keeps you from having to have 50 syscall numbers to fix up for each kernel revision change?
1140461783 M * Bertl the 'switch' part is best descibed here:
1140461788 M * Bertl http://www.13thfloor.at/vserver/d_rel26/v2.1.0/split-2.6.14.4-vs2.1.0/08_2.6.14.4_switch.diff.hl
1140461808 M * Bertl each 'command' for the switch consists of a magic number, which in turn consists of
1140461819 M * Bertl category, command and version
1140461820 M * ebiederm Ok. So this is a summary of what vserver has defined for syscalls so far?
1140461830 M * Bertl yep, precisely
1140461841 M * Bertl for every 'category' there is at least one command
1140461873 M * Bertl so roughly 20 categories with let's say 2 commands each
1140461892 M * Bertl (of course, several versions for each one too, but that is not relevant)
1140461922 M * Bertl mapped to flat syscalls, this would mean roughly 30 syscalls
1140461976 M * Bertl and this doesn't even cover all the things which could be done with the *spaces
1140462115 M * ebiederm Well that is certainly the worst case scenario.
1140462229 M * Bertl you think?
1140462298 M * Bertl I'm pretty certain you will need even more, for monitoring and such stuff (which is done via the spectator context in Linux-VServer, but will require new interfaces for the virtualization approach)
1140462476 M * Bertl bonbons: I'll try something, expect a patch shortly
1140462510 M * ebiederm Bertl: I guess part of this is why I have said I don't want virtualization I just want different namespaces :)
1140462534 M * Bertl and you know I'm fine with that :)
1140462885 M * dhansen Bertl: like we talked about before, there are also some approaches that don't use _new_ syscalls as heavily
1140462897 M * dhansen for instance, CKRM is using configfs
1140462921 M * Bertl yes, and to some extend I can imagine using other interfaces ...
1140462938 M * Bertl (especially as everybody seems to like filesystem interfaces nowadays :)
1140462967 M * Bertl but, how would you use configfs in a hierarchical setup without bending backwards?
1140463052 M * dhansen good question :)
1140463086 M * dhansen I'm just saying that I'm not worried about the complexity of the current system call requirements
1140463086 M * ebiederm This is one of the reasons I am cleaning up procfs.....
1140463103 M * dhansen and I'm still not convinced that anybody _needs_ hierarchical containers
1140463113 M * dhansen it is cool, but CKRM is cool :)
1140463148 M * Bertl dhansen: ad complexity: I'm not really worried too, but I can understand when ebiederm tries to avoid new syscalls :)
1140463162 M * ebiederm dhansen: I think I have finally seen the practical need for hierarchical containers.
1140463195 M * dhansen ebiederm: I'm listenting! :)
1140463204 M * Bertl dhansen: ad hierarchical, well I'm not the one who demands this kind of features, the users are ...
1140463205 M * ebiederm There are two main use cases. Sever virtualization, and application isolation.
1140463280 M * Bertl let me give a simple use-case example to think about:
1140463300 M * ebiederm If you require an application to be run in a container of some form to be migratable, and you are runing a virtual private server...
1140463318 M * ebiederm Bertl: It is interesting that you have users that already need hierarchical containers. I did not know that :)
1140463323 M * Bertl chroot() is something which can be considered a cheap version of private namespaces
1140463351 M * Bertl let's assume we allow a safe chroot() but be restrict the chroot() to one level
1140463366 M * Bertl i.e. make it completely flat
1140463381 M * Bertl now we use that chroot() to create a VPS
1140463405 M * Bertl everything is fine, but some other folks use that chroot() to install/build packages
1140463430 M * Bertl and finally somebody tries to build packages inside a VPS *bang*
1140463476 M * Bertl so, as long as we say, VPS do not need to be hierarchical, the issue is not critical
1140463498 M * Bertl but once we start demanding that the *spaces must not be hierarchical, we are heading for trouble
1140463524 M * Bertl (that's why I tend to arguing for more hierarchy than for less :)
1140463529 M * Bertl *argue
1140463558 M * ebiederm Now. There is another side to it. The implementation does not necessarily need to be hierarchical.
1140463569 M * Bertl I never said that
1140463574 M * ebiederm As chroot is not hierarchical.
1140463602 M * ebiederm But resoruce limits and the process tree benefit from a hierarchy.
1140463630 M * Bertl filesystem does so too and already has (at least to some extend)
1140463682 M * bonbons I'm back, Bertl, just notify me once you have something
1140463693 M * Bertl bonbons: k, will do so ...
1140463756 M * eyck hmm, chroot should be hierarchical
1140463797 M * mugwump moinmoin
1140463830 M * ebiederm eyck: chroot is exactly like chdir. Except it changes the other well known directory.
1140464296 M * Bertl ebiederm: it was just a simplified example ...
1140464300 M * mugwump I've decided I like the term "process families"
1140464340 M * ebiederm Bertl: I understand, and really for application migration and virtual private servers to conicide it is really needed.
1140464390 M * ebiederm dhansen: Does the argument for hierarchical use make sense?
1140465300 Q * brisho Quit: using sirc version 2.211+KSIRC/1.3.11
1140465674 M * Hollow any idea why mount gets EINVAL here? http://phpfi.com/103222
1140465754 Q * Viper0482 Quit: bin raus,
1140465766 J * NikDaPhreak ~NikDaPhre@193.24.241.34
1140465771 M * NikDaPhreak hi all
1140465798 M * Bertl hey NikDaPhreak!
1140465869 M * NikDaPhreak Bertl: :-)
1140465947 M * NikDaPhreak Bertl: remember my problems from yesterday? I just finished compiling util-vserver-0.30.209 and tested it on Linux 2.6.13.5--vs2.0.1-pre2 just to get save_ctxinfo: execv(): No such file or directory
1140466131 M * dhansen ebiederm: it makes sense, I'm just not convinced that it makes enough sense to warrant the complexity
1140466147 M * dhansen for instance, Solaris containers don't support hierarchies
1140466274 M * mugwump True, and after all, we need to respect the design decisions made by Sun engineers, they're smart :-D
1140466298 M * Bertl NikDaPhreak: so, to make it short, whatever version you try, it fails?
1140466321 M * Bertl NikDaPhreak: I can offer you precompiled binaries for testing if you like?
1140466343 M * ebiederm dhansen: So far I have not yet seen any significant complexity.
1140466349 M * Bertl dhansen: if done properly, the complexity should be almost zero
1140466376 M * NikDaPhreak Bertl: well.. I guess I'm to stupid lately... :-( ;-)
1140466394 M * ebiederm The largest complexity I have seen so far is that hierarchicaly containers are incompatible with OpenVZ so Kirill does not like them.
1140466431 M * Bertl well, I do not even think they are incompatible, it just means a little rework on the tool side ...
1140466478 M * Bertl NikDaPhreak: was that a yes, please?
1140466515 M * NikDaPhreak Bertl: yes, please, I'll be glad :-)
1140466553 M * Bertl try to find the installed tools and remove them
1140466732 M * Bertl NikDaPhreak: http://vserver.13thfloor.at/Stuff/QEMU/util-vserver-0.30.210_bin.tar.bz2
1140466740 M * Bertl (unpack it in /)
1140466743 M * NikDaPhreak Bertl: this is the easiest part
1140466800 M * Bertl after that, we can also try with a kernel compile :)
1140466816 M * Bertl (make sure to execute vprocunhide)
1140467008 M * NikDaPhreak Bertl: thanks a million! it worked.
1140467030 M * NikDaPhreak Bertl: I'll have to change that Chivas for sth. stronger
1140467078 M * Bertl just to satisfy my curiosity, what dietlibc version was that? (distro is slackware, yes?)
1140467105 M * NikDaPhreak Bertl: yes, slackware and dietlibc-0.29
1140467127 M * NikDaPhreak Bertl: but I also tried that without dietlibc yesterday
1140467300 M * ebiederm Yeah, my second pass through /proc is done. I now have a fairly reasonable patchset.
1140467339 J * Doener doener@i5387D9A6.versanet.de
1140467467 M * Bertl ebiederm: sounds good!
1140467502 M * Bertl NikDaPhreak: do you have another slackware machine which works fine? otherwise I'd have to assume that slackware is somehow broken
1140467509 M * Bertl welcome Doener!
1140467516 M * Doener evening!
1140467910 M * NikDaPhreak Bertl: i have 3 host systems working fine
1140467933 M * NikDaPhreak bertl it is not impossible, that gcc is different... let me check
1140468308 M * NikDaPhreak Bertl: 3.3.5 - everything works fine vs. 3.4.5 - everything's broken
1140468359 M * Bertl well, then you might want to file a bug report either to the gcc or dietlibc/glibc folks
1140468435 M * NikDaPhreak Bertl: I might think about that.. it's hard to reproduce... but still a bug ;-)
1140468563 J * azazel ~azazel@81-174-46-248.f5.ngi.it
1140468571 M * Bertl welcome azazel!
1140468586 M * azazel hi Bertl !
1140468719 M * azazel do you know if someone tried to connect a pseudo-tty to one vserver guest?
1140468736 M * Bertl connect it to what?
1140468835 M * azazel just a login :)
1140468884 M * Bertl well, folks did that with vts, with pts' it's a little more complicated as they are isolated
1140468908 M * azazel hmmm vts...
1140468958 M * azazel vts?
1140468964 M * bonbons I have such a config running, works fine
1140469004 M * bonbons I have symlinked /dev/console to the appropriate tty and init displays things at right place :)
1140469152 M * Bertl azazel: but if you are interested in working on that, I could help you with the kernel side (pts type of conenctions into the context)
1140469167 M * Bertl bonbons: path is now test compiling
1140469181 M * Skram Hi all.
1140469190 M * Bertl welcome Skram!
1140469210 A * Skram is sick home from school :(
1140469241 M * bonbons ok, what approch does it use to fix the problem? reparenting to context-init or more complete mapping pid=1 in context to it's local init?
1140469283 M * Bertl reparenting to context init if a) there is an initpid, and b) it is still there :)
1140469362 M * bonbons ok, and then virtualizing that ppid to 1?
1140469609 M * Bertl hmm, IMHO no need to do that ...
1140469660 Q * mkhl Quit:
1140469737 M * Bertl bonbons: http://vserver.13thfloor.at/Experimental/delta-vreaper-feat01.diff
1140469774 M * bonbons Bertl: does it apply over the signal-kprint-patch?
1140470230 M * Bertl yep, it should ...
1140470269 M * bonbons it did, and already recompiled
1140470518 J * mkhl mkhl@200-148-41-159.dsl.telesp.net.br
1140470549 P * meandtheshell
1140470673 M * bonbons Ok, SIGCHLD reached the right init process :)
1140470752 M * Bertl so I take it, this kind of works(tm) for you?
1140470805 M * bonbons yep, it passed the first test successfully
1140471019 M * Bertl so please do some more testing, also with killing off the init and such
1140471039 M * Bertl maybe even with purely fake-init guests if possible
1140471058 M * bonbons will do
1140471061 M * Bertl so that we get a feeling if it is devel or experimental stuff
1140471368 M * bonbons killing the guest's init does not work (that's what I expected)
1140471541 M * Bertl use vkill from outside
1140471543 M * Doener Bertl, azazel : IIRC I have some code floating around that does some pty stuff, lemme check
1140471633 M * bonbons I did that, but forgot to try with -s KILL ... with -s KILL it dies
1140471677 M * bonbons hmm, something dies, but the initng is there again...
1140471766 M * Doener azazel: found it. some daemon I started but forgot about... it can create a context and enter a context and comes with a stupid client
1140471781 M * Bertl bonbons: hmm, sounds interesting ... I guess I missed a check :)
1140471783 M * Doener when entering the context, login is started on a pty living inside the context
1140471795 M * Doener if you're interested, I'll upload the code
1140471964 M * bonbons will check if I can still kill the guest as a whole... works, but the kernel's printk reappeared on console... SIGCHLD for the host's bash process
1140472066 M * bonbons and womeone still has to wait() on the two processes left from the guest (two zombies: the bash I had on extra tty and initng itself)
1140472159 M * Bertl bonbons: please change the line:
1140472176 M * Bertl 628: if (init)
1140472180 M * Bertl to
1140472200 M * Bertl 628: if (init && (init != father))
1140472233 M * Bertl (that's in vchild_reaper(), 628 might not be your line)
1140472235 M * bonbons line in the diff?
1140472256 M * Bertl no, just change it in the kernel source, and recompile
1140472273 M * Bertl (just takes a few seconds)
1140472285 M * bonbons at line 628 I land in a comment with no if (init) around
1140472309 M * Bertl look for vchild_reaper(struct task_struct *father)
1140472321 M * Bertl the only if (init) line there
1140472445 M * bonbons ups, was in the wrong kernel sources
1140472526 M * bonbons will that solve the zombies for non-init process in the guest too once the context is killed? (as the context-init has no chance to wait on those)
1140472551 M * Bertl I hope so .. but not sure about that ...
1140472712 J * dothebart ~willi@xdsl-213-196-255-167.netcologne.de
1140472722 M * Bertl Doener: btw, was it you who suggested the Schilly thread for amusement? if so, thanks a lot, it is really fun to read :)
1140472754 M * bonbons rebooting
1140472818 M * Doener well, i did not directly suggest that for amusement, but i guess the author of some messages in that thread (I won't tell the name *g*) just has to be (a bit?) ridiculous ;)
1140472886 M * Doener but lately I get too upset when reading stuff from him, it makes me angry everytime he just stops answering when someone makes a point...
1140473040 Q * tudenbart Read error: Connection reset by peer
1140473136 J * Aiken ~james@tooax6-183.dialup.optusnet.com.au
1140473192 M * bonbons Bertl: "vkill -x 12 -p -s 9" still leaves initng unaffected (I think that's OK), vkill -x 12 kills the context without leaving zombies -> good news
1140473218 M * Bertl try 1 instead of initng pid
1140473275 J * LMS_Guest ~LMS_Guest@adsl-68-94-11-167.dsl.rcsntx.swbell.net
1140473283 M * Bertl welcome LMS_Guest!
1140473284 N * LMS_Guest PotatoBob
1140473298 M * Bertl well, welcome PotatoBob then :)
1140473305 M * PotatoBob heh yep
1140473323 M * PotatoBob I'm having trouble with starting vserver...
1140473338 M * Bertl what kind of trouble?
1140473376 M * PotatoBob How about i past in the output
1140473383 M * PotatoBob [root@PBGateway1 tmp]# vserver PBServer start
1140473391 M * PotatoBob chbind: kernel does not provide network virtualization
1140473399 M * PotatoBob An error occured while executing the vserver startup sequence; when
1140473401 M * bonbons Bertl: that kills it
1140473416 M * PotatoBob there are no other messages, it is very likely that the init-script
1140473423 M * PotatoBob (/sbin/init) failed.
1140473451 M * PotatoBob basically i cant get the vserver to run the init scripts?
1140473458 M * Bertl PotatoBob: okay, let's give the testme.sh script a spin, and upload the output somewhere
1140473469 N * ebiederm ebiederm_oO
1140473475 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh-0.15
1140473486 M * PotatoBob ya I have it
1140473512 M * Bertl okay, run it as root on the host, and upload the output to pastebin.com
1140473516 M * PotatoBob chcontext is working.
1140473520 M * Bertl (or some other pastebin service=
1140473571 M * bonbons Bertl: in the guest processes now show ppid = 1 (a ghost's pid ;)), but no zombies stay around when launching/ending forking daemons (apache2)
1140473613 M * Bertl okay, that sounds good, well the ghost is expected
1140473620 M * Bertl as init is not supposed to die :)
1140473674 M * PotatoBob ok http://pastebin.ca/42365
1140473695 M * Bertl k
1140473726 M * Bertl ah, you are using a very old kernel with very recent tools
1140473750 M * Bertl you have two options there, a) compile in the compatibility code (for the tools)
1140473764 M * Bertl b) upgrade the kernel to something recent
1140473766 M * PotatoBob yep the distibution i am using requires this kernel
1140473781 M * PotatoBob where is the compatibility code?
1140473785 M * Bertl interesting, which distro is that if you don't mind?
1140473798 M * PotatoBob Clarkconnect
1140473804 M * PotatoBob from Clarkconnect.com
1140473869 M * PotatoBob they have a few kernel patches that are needed for their setup
1140473883 M * Bertl okay, so be it ...
1140473927 M * bonbons Hmm... fake-init looks weird with vserver-utils... checking what is wrong
1140473936 M * Bertl PotatoBob: you want to configure the tools with:
1140473947 M * Bertl --enable-apis=NOLEGACY
1140474003 M * PotatoBob ok, now what do i have to do about the chbind problem?
1140474015 M * Bertl it will go away with recompiled tools
1140474019 M * PotatoBob ok
1140474021 M * PotatoBob thanks
1140474046 M * Bertl you're welcome! give it a try, let us know how it goes, feel free to hang around :)
1140474108 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk
1140474114 M * Bertl wb vrwttnmtu!
1140474118 M * vrwttnmtu Hey Bertl
1140474168 M * vrwttnmtu Bertl, I have a question that's not related to vserver at all, but you're a knowledgable chap, and know about internal kernelly things, so can I sling it at you?
1140474192 M * Bertl well, if you must :)
1140474215 M * vrwttnmtu If I have a process that is slowly reading a file, can I use lsof or some other tool to see how far through the file the pointer is?
1140474250 M * Bertl not really, as it could access the file in a random manner
1140474269 M * Bertl every fraction of a second it could be reading somewhere else
1140474276 M * vrwttnmtu Is that likely?
1140474284 M * vrwttnmtu If someone is downloading an ISO from me?
1140474292 M * Bertl for databases it would be very likely :)
1140474300 M * vrwttnmtu :)
1140474334 M * Bertl you could attach strace to that process and check what it is reading/sending
1140474347 M * vrwttnmtu I just want to know how long they have to go, as my net connection is slooooow
1140474348 M * vrwttnmtu :)
1140474371 M * vrwttnmtu fopen has a pointer in the file, doesn't it?
1140474378 M * vrwttnmtu Can I see what byte number it's at?
1140474413 M * Bertl well, the kernel knows _what_ it is reading .. but that is not really exported anywhere
1140474450 M * Bertl userspace should know too, but I guess your httpd doesn't report it either
1140474474 M * vrwttnmtu Nope. Aaah well
1140474475 M * vrwttnmtu :)
1140474497 M * vrwttnmtu I wondered if lsof could dig into the kernel internals
1140474531 M * Bertl nevertheless, if the client downloading the image supports regets, you could just kill the download, and see where it starts the reget
1140474565 M * pflanze vrwttnmtu: I've been told that you should be able to use ptrace(2) to issue an lseek operation from within the process, but never tried.
1140474595 M * vrwttnmtu ptrace(2) is a system call, isn't it?
1140474599 M * pflanze yes
1140474602 M * vrwttnmtu I'd have to write something that did it, no?
1140474607 M * pflanze yes
1140474611 M * vrwttnmtu Eep :)
1140474665 M * vrwttnmtu OK # nclude
1140474717 M * vrwttnmtu OK, so basically there's not already a tool to do it.
1140474745 M * pflanze Maybe someone has already done it.
1140474802 M * vrwttnmtu pflanze, Yeah, possibly. It's not that important, I just thought it might be in lsof
1140474805 M * vrwttnmtu Or something
1140474846 M * bonbons Bertl: sysvinit behaves correctly, though for fake init I have troubles! When I enter the guest /proc inside the guest is not available... looks like processes do not stay in right namespace there... (never tried that out bevore with vserver-utils, so might not be related)
1140474988 M * Bertl bonbons: is there some service which keeps the context running once you started it?
1140475012 M * Bertl (or is the persistant context feature used?)
1140475017 M * bonbons yep, there is the apache2 daemon
1140475046 M * Bertl hmm, could you try with util-vserver too?
1140475056 M * bonbons and now I can't even restart the guest using fake init...
1140475157 Q * wasser Read error: Operation timed out
1140475214 M * bonbons yep, can do that, but really weird, will reboot and do some more vserver-utils test before util-vserver though
1140475252 M * Bertl k
1140475641 M * mef hello
1140475656 M * mef hp blades should be available again.
1140475662 M * Bertl wow, great!
1140475686 M * mef bertl: well, it should be s/blades/blade
1140475692 M * Bertl (but I guess, too good to be true :)
1140475702 M * mef really?!
1140475718 M * Bertl yep, unfortunately
1140475729 M * mef which one is your?
1140475731 M * Bertl ah, the lom just appeared
1140475769 M * mef ok
1140475774 M * mef you can take it from there.
1140475781 M * mef Have to run.
1140475784 M * Bertl okay, tx
1140475786 M * mef Let me know if there are further issues.
1140475798 M * Bertl okay, will do so
1140475976 M * Bertl mef: okay, blade is back too, seems it just rebooted
1140476025 M * PotatoBob do any of you guys get *failed* errors on vserver restart or vserver stop?
1140476029 M * Loki|muh is there a easy way to get the number of files which are open globaly on one host?
1140476033 M * bonbons Bertl: hacked the vserver-utils scripts to start initng as fake init, results are better there, just no process with pid == 1 visible from inside
1140476048 M * mef bertl: too good to be true... :)
1140476069 Q * Aiken Ping timeout: 480 seconds
1140476138 M * mef bertl: just got your email. So is it up or not?
1140476162 M * Bertl yep, email was _before_ you got here :)
1140476181 M * Bertl mef: so it seems to work all fine now
1140476188 M * mef well, I still cannot ping it. it is still booting?
1140476193 M * Bertl yup
1140476201 M * Bertl it's checking disks
1140476207 M * mef which one is your hp-bl25p-2 or hp-bl25p-1?
1140476222 M * Bertl hp-bl25p-1
1140476237 M * Bertl it's now up, and I'm logged on
1140476260 M * mef good
1140476354 Q * Doener Ping timeout: 480 seconds
1140476383 M * Bertl bonbons: maybe it requires the fake init flag?
1140476397 J * Doener doener@i5387DCB2.versanet.de
1140476423 M * Bertl 4 0x00000010 INFO_INIT fakeinit X show a fake init process
1140476438 M * Bertl (context flags)
1140476631 J * Smutje_ ~Smutje@xdsl-87-78-2-132.netcologne.de
1140476695 M * bonbons ok, yep with that flag it's looking better :) and I don't get zombies anymore
1140476720 M * Bertl okay, so it looks like it is working quite fine for you, right?
1140476739 Q * Smutje Ping timeout: 480 seconds
1140476739 N * Smutje_ Smutje
1140476740 M * bonbons one mad thing to try would be killing the running normal init, and replace it by a new one
1140476767 M * Bertl guest init? you will not succeed in doing so, I'd say
1140476768 M * Vudumen hi Bertl
1140476775 M * Bertl hey Vudumen! :)
1140476778 M * Vudumen Bertl: sry i had many works
1140476782 M * Vudumen currently moon is unavailable i know
1140476802 M * Bertl Vudumen: np, just had absolutely no email address ...
1140476822 M * Bertl (otherwise I'd sent an email)
1140476824 M * Vudumen we have power problems so we bought 2 converters/trafos (10kV->400V) but until these will work (approximately 1-1.5 month afaik) it won't be online again :/
1140476855 M * bonbons I will try and see, why shouldn't it succeed? normally start guest, vkill it's init, vexec -cfi newinit inside namespace, shouldn't that do it?
1140476915 M * Bertl Vudumen: okay, so is life, np and thanks for the info!
1140476988 M * Bertl bonbons: you won#t be able to set the initpid for the 'new' init :)
1140477054 M * bonbons kernel only accepts setting the virtual pid=1 once per context-lifetime?
1140477141 M * Bertl well, actually the outside setting could work, the inside wont
1140477232 J * oliwel ~chatzilla@host-62-245-151-178.customer.m-online.net
1140477252 M * Bertl welcome oliwel!
1140477292 J * gerrit ~gerrit@129.33.1.37
1140477321 M * oliwel Bertl: Hi
1140477327 M * oliwel I am in trouble :(
1140477329 M * bonbons yep, it fails on setting (network)context flags
1140477329 M * Bertl wb gerrit!
1140477344 M * Bertl oliwel: hmm?
1140477361 M * oliwel Bertl: I siwtched a guest from my "old" server (309 tools, 2.1.0 patchset) to the new maschine
1140477376 M * oliwel Bertl: now the guest starts. but no process do...
1140477388 M * Bertl 309 means 0.30.209 ?
1140477402 M * oliwel to be more exactly - the init scripts are run, but the process are not started
1140477405 M * oliwel Bertl: yep
1140477411 M * Bertl gentoo guests?
1140477414 M * oliwel seems to be a gentoo prob - so HOLLOW ??
1140477416 M * oliwel Yep
1140477428 M * Bertl you did not stop them properly
1140477436 M * oliwel I updated them from old baselayout hack to new baselayout-vserver...
1140477440 M * Bertl some 'running' files are left in /var whatever
1140477447 M * oliwel I did - and I cleared the init.d tree
1140477450 M * bonbons oliwell, fake init or plain init?
1140477451 M * oliwel no :(
1140477464 M * oliwel had gentoo and swithed to plain
1140477498 M * oliwel The strange thing is - I see that the gentoo rc scripts are started, but the daemons wont come up - even when I run the rc scripts by hand
1140477512 M * oliwel when I copy out the linem that starts the daemon, everythign is finde...
1140477514 M * oliwel fine...
1140477531 M * oliwel so it seems that some of the gentoo stuff its broken
1140477535 M * oliwel but I dont have any idea
1140477555 M * bonbons on one of my boxes it works just fine (util-vserver 0.30.209, 2.6.15-v2.1.0)
1140477603 M * oliwel I have 7 guests running - all migrated fine except this one
1140477631 M * oliwel it seems to be an issue with "start-stop-daemon" helper...if I dont use it, everything works
1140477637 M * bonbons what service should be running on that guest?
1140477661 M * oliwel at least sshd and syslog
1140477661 M * Bertl oliwel: which path is it you cleaned up inside the guest?
1140477670 M * oliwel wait..idea...
1140477720 M * oliwel Ehh - waht ?
1140477735 M * oliwel Ahh - var/lib/init.d
1140477897 M * oliwel Bertl: any ideas
1140477910 M * Bertl vserver --debug start
1140477919 M * Bertl and upload the copious output somewhere
1140477922 M * oliwel mom
1140478098 M * oliwel pastebin.com seems to ne down :(
1140478105 M * Bertl pastebin.ca
1140478210 M * oliwel I think it is useless - the problem starts inside the server - not from the vserver process
1140478236 M * Bertl I think so too, but maybe we get some hints ...
1140478272 M * oliwel http://pastebin.ca/42417
1140478452 M * Bertl okay, yes, it hands over to init
1140478469 M * oliwel yep
1140478493 M * oliwel see - even calling "/etc/init.d/syslog-ng start" inside the running server wont start the syslog
1140478529 M * oliwel calling the syslog-ng directly wqill do - so somewaht in the daemon control seems to be broken
1140478841 M * oliwel weird....giving the daemon control the full binary-path is working...seems that some path issues are mixed
1140479523 M * oliwel leaving guys - gn8
1140479675 M * Bertl k, night!
1140479703 Q * NikDaPhreak Quit: Hybernating my brain....
1140479803 M * bonbons I'm leaving too, night Bertl!
1140479835 M * Bertl good night!
1140479861 Q * bonbons Quit: Leaving
1140479883 Q * oliwel Quit: Chatzilla 0.9.68.5.1 [SUSE 1.0.7-0.1/20050920]