1104711005 A * Bertl .oO( MODPOST with allmodconfig takes ages ) 1104711500 Q * mboman Quit: One day I'll get that peer and reset HIS connection! 1104711523 M * Bertl Doener: http://vserver.13thfloor.at/Experimental/patch-2.6.10-vs1.9.3.16-pre1.diff 1104711541 M * Bertl it has a small issue with the includes but it should work for you ... 1104711585 M * Bertl (means, it should not affect your patches) 1104711952 M * Doener 8352 doener 16 0 1025m 742m 600 S 0.0 84.0 0:15.26 diff --> 84% memory usage... this is what happens when you do diff ... | less on directories with cscope databases... ;) 1104711963 J * click click@dsl-84-161.aal.tiscali.no 1104711968 M * Bertl welcome click! 1104711974 M * Bertl Doener: yeah, I know that ... 1104712009 M * Bertl but I have something which is double the fun, just copy a kernel tree into another, then diff that ;) 1104712055 M * click re re, another powersurge hit the town today :/ got to invest in a friggin' UPS for my home as well now I think. 1104712092 M * Bertl considering that too for some time now (so much for western civilisation) 1104712179 M * click well, i know what caused the outage so... thunder and lightning hit one of the power-systems near here 1104712354 M * Doener Bertl: great, managed to do that now ;) 1104712372 M * Doener forgot to delete temp. directories.. 1104712387 A * Bertl .oO( hmm, looks like you have to try everything ;) 1104712407 M * Doener if it only way intentional ... 1104712413 M * Doener s/way/was/ 1104713142 M * Bertl okay, this should be fine ... http://vserver.13thfloor.at/Experimental/patch-2.6.10-vs1.9.3.16.diff 1104714552 M * we2byy enough for today 1104714555 M * we2byy nite 1104714577 M * Bertl night! 1104714727 M * Doener night we2byy ! 1104714827 Q * yarihm Quit: Leaving 1104714961 M * Bertl Doener: sshd[5915]: fatal: daemon() failed: Success (what was the answer to that?) 1104714971 M * Doener broken /dev/null 1104714981 M * Bertl ah, why isn't that in the FAQ yet? 1104714999 M * Doener didn't I add that? 1104715014 M * Bertl thought so ... but couldn't find it ... 1104715032 M * Doener hm, i'll add it then 1104715038 M * Bertl thanks a lot! 1104715053 M * ntrs Doener, how do I fix the broken /dev/null? 1104715074 M * Doener copy/create a real /dev/null 1104715076 M * Bertl first, check if it is broken (i.e. not the device but a file) 1104715077 M * albeiro put black hole inside ;p 1104715086 M * Doener broken means 'someone put a plain file there' 1104715087 M * albeiro and it will suck in everything :) 1104715106 M * ntrs yes, it is a file 1104715110 M * Bertl then just do cp -va /dev/null /vservers//dev/null 1104715226 M * ntrs Yep, that worked fine. Thanks. 1104715479 M * Doener hm, wiki ate my quoted changelog... 1104715560 M * Bertl hmm, it did? 1104715598 M * Bertl looks fine to me (it's there now) 1104715626 M * Doener the summary of change was a little longer than it is now 1104715634 M * Doener it's a bug in the preview function 1104715642 M * Doener 1104715675 M * Bertl hmm, that should be escaped ... 1104715709 M * Bertl (I'll investigate) 1104715724 M * Doener actually it read: test "some" thing 1104715737 M * Doener so it seems to be more than just missing escaping 1104715860 M * Bertl ah, okay, I understand, you mean the "Added entry about the infamous" ;) 1104715867 M * Doener yep 1104715886 M * Bertl yeah, probably the comment isn't escaped, will fix that ... 1104715897 M * Doener ok, great 1104715912 A * Bertl thought the page itself messed up ... 1104716401 M * Bertl k, should be fixed now ... 1104716467 M * Bertl (http://linux-vserver.org/Hacker+Page?action=history) 1104717581 M * Doener hm, what's the VXS_HASHED flag for? 1104717624 M * Bertl a flag stating that the entry is hashed ... 1104717693 M * Bertl (rcu doesn't prevent that we 'find' an already unhashed entry) 1104718107 M * Doener and it doesn't prevent the test for that flag to happen immediately before the flag is cleared... 1104718511 M * Bertl hmm, yeah, we should check it _after_ we get the vx_info 1104718599 M * Bertl or we take the hashlock there ... which renders the rcu useless once again ... 1104718664 M * Doener in which cases do we need to get a vx_info that is currently hashed? 1104718706 M * Bertl whenever we use the vx_info for a reference (task, sk, mm) it _must_ be hashed 1104718751 M * Bertl (once the refcount reaches 0, there should be _no_ way back) 1104718757 M * Doener ok, sk and mm can only happen when a task is holding a reference anyway, right? 1104718784 M * Bertl in theory, yes ... 1104718791 M * Doener and in practice? 1104718802 M * Bertl no idea ;) 1104718805 M * Doener hehe 1104718873 M * Doener ok, if we stick to theory, the only(?) critical function would be vx_migrate_task i guess 1104719049 M * Bertl well, and the __loc_vx_info() stuff ... 1104719140 M * Bertl why not take the hash lock when we hit __lookup_vx_info()/found 1104719164 M * Bertl then validate vx_info_state(vxi, VXS_HASHED) and if not positive, return NULL 1104719168 M * Doener _loc_vx_info always leads to vx_migrate_task 1104719393 M * Bertl yes, but I do not want the 'checks' to be done somewhere else than in __loc_vx_info() or better __locate_vx_info() 1104719404 M * Doener ok 1104719477 M * Bertl OTOH it would be nice to avoid taking the spinlock, even for short amounts of time .. maybe we should use a context lock for that? 1104719539 M * Doener hm... 03:19:11 Bertl (once the refcount reaches 0, there should be _no_ way back) 1104719552 M * Doener so why not check for the refcnt instead? 1104719565 M * Bertl would that buy us anything? 1104719594 M * Bertl (nobody guarantees that the refcnt isn't decremented just after we found that vx_info :/) 1104719650 M * Bertl we could move the unhashing into some rcu callback too ... 1104719667 M * Bertl but I do not have a good feeling with double rcu stuff 1104719817 M * Doener hm, no.. that would even need to go into set_vx_info ... 1104720204 M * Bertl okay, what about the following: 1104720227 M * Bertl we use a vx_info lock, and take that on set/clr 1104720289 M * Bertl after we have the lock (in set) we check the refcnt first, if it is zero, we return some error to the caller, which does a cleanup? 1104720309 M * Bertl (hmm, doesn't sound too good) 1104720330 M * Bertl maybe we should return the vx_info locked if found 1104720354 M * Bertl then unlock it after a set_ or whatever happens with it 1104720382 M * Bertl of course the clr would take the lock too ... 1104720431 M * Doener hm, if we do a check in set_vx_info anyway, we could get away with atomic_add_and_return 1104720470 M * Doener hm, no... that could blow up if two set_vx_info are running on the same vx_info 1104720472 M * Bertl okay, we do atomic_inc_return() and check for 1? 1104720492 M * Bertl then eject the core ;) 1104720894 M * Bertl what about doing two calls __locate_vx_info()/locate_vx_info() 1104720936 M * Bertl or better __locate_vx_info_locked() 1104720998 M * Bertl the lock is already there (vx_lock) 1104721179 M * Doener hm, we got vx_info_is_hashed or something... we could move the check there and also acquire the lock there 1104721221 M * Bertl doing any locking there (locally) doesn't buy us anything either ... 1104721221 M * Doener hm, still wouldn't buy us anything... 1104721238 M * Bertl the only way I see atm is to 'lock 1104721248 M * Bertl +' the vx_info and return it locked 1104721260 M * Doener ok, guess i really need a coffee... 1104721299 M * Doener yep, would work... but looks a little ugly, doesn't it? 1104721311 M * Doener (got no better idea though) 1104721328 M * Bertl well, looks like dentries are doing it the same ugly way ... 1104721375 M * Doener really? hmm... got a file+line for me? 1104721499 M * Doener got it 1104721506 M * Bertl k 1104721587 M * Bertl it's not that critical if we do it per context 1104721597 M * Bertl because a) the vx_info is already referenced 1104721617 M * Bertl and b) the lock will not be held in the typeical path 1104721672 M * Bertl but I'm really not sure that RCU is the optimal way to go ... 1104721704 M * Bertl guess it requires some real benchmarking to decide for the one or other ... 1104721903 M * Doener the difference between dcache and ours is that we got 2 counters, while dcache can increment the counter in the lookup function (as we do with usecnt), our "main counter" is updated somewhere else... 1104721935 M * Bertl well, no problem with using just one ;) 1104721972 J * lhguest-02939 ~e63548@200-122-0-45.prima.net.ar 1104721980 M * Bertl welcome lhguest-02939! 1104721990 M * lhguest-02939 hi 1104722002 M * Doener would mean that we change semantics, so that a context's lifetime is no longer controlled by the processes living in it, but by anything using the context 1104722041 M * lhguest-02939 i dont have any clew where i am 1104722054 M * Doener where 'lifetime' means the time while the context info is hashed 1104722080 P * lhguest-02939 1104722144 M * Doener hm, would that cause any problems? (i can't see any atm) 1104722151 M * Bertl yes, it would ... 1104722171 M * Bertl thing is, sockets for example might exist and _hold_ the context for minutes 1104722196 M * Bertl but folks want to start the context right after a stop ... 1104722207 M * Doener good point 1104722350 M * Bertl what if we simply get rid of the rcu stuff and use an rwlock for the hash? 1104722401 M * Bertl reads won't be affected, and whenever we change something (e.g. unhash or hash) it is synchronized 1104722457 M * Bertl (of course, requires a separate lookup which increments the refcnt) 1104722733 M * Doener something like __loc_vx_info_and_use? 1104722762 M * Doener or __loc_vx_info_and_ref or whatever 1104722769 M * Bertl well, actually the __loc is probably specific and will always return a 'ref' 1104722785 M * Bertl but __locate_vx_info_* would be useful 1104722817 M * Bertl but I'm still not sure if it would not be _much_ better and easier to return a _locked_ vx_info 1104722845 M * Bertl you can then get/pu/set/clr it as much as you like ... and after that unlock it 1104722886 M * Bertl IMHO that might simplify a lot of things we do right now ... 1104722950 M * Doener guess it's the best we can do 1104722954 M * Bertl so that would make two __lookup..() then one which does nothing (no locking or whatsoever) and one which returns a locked vx_info 1104722961 A * Doener officially hates locking from now on... ;) 1104723350 M * ntrs Does anyone have BIND rpms for MDK 10.0 that work in a vserver? 1104723866 M * ntrs anyone? 1104723898 M * Bertl latest linux-vserver allows bind to run unmodified (but it's a little trickier) 1104724015 M * Doener hm, the spinlock in __loc_vx_info is not only needed for unique dynamic xids but also to avoid duplicate xids in general... without it, in two calls to __loc_vx_info, the lookup may return NULL each time and both would hash the vxi, right? 1104724056 M * Bertl yep 1104724058 M * ntrs Ok, but until then do you have BIND rpms? 1104724070 M * ntrs And how is it trickier? 1104724092 M * Bertl nope, I'm avoiding 10.x MDK like hell, it seems they managed to break every single package ... 1104724170 M * ntrs Ok. How is it trickier using the new patch? 1104724176 M * Bertl but why not just download the src rpm (ftp://mandrake.contactel.cz/Mandrakelinux/devel/10.1/SRPMS/main/bind-9.3.0-3mdk.src.rpm) add the option in the spec file and recompile it 1104724193 M * ntrs Ok, will try that. 1104724232 M * Bertl (it is trickier because the required flags are not known to the tools yet) 1104724250 M * ntrs oh, that's nothing. I am already using ^19 1104724254 M * ntrs :) 1104724279 M * ntrs So, what is the latest vserver version and for which kernel? 1104724298 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.10-vs1.9.3.16.diff 1104724454 Q * sannes Read error: Connection reset by peer 1104724752 M * ntrs What's been changed between 1.9.3.12 and 1.9.3.16? How stable is .16? 1104724866 M * Bertl several fixes and cleanups, some restructuring 1104724877 M * Bertl a new history debug system 1104724924 M * Bertl we hope that it is _more_ stable than 1.9.3.12 ;) 1104724946 M * ntrs There is no detailed changelog I assume? 1104724956 M * Bertl no, but you can get a diff ;) 1104724962 M * ntrs Yes, sure. Thanks. 1104724962 M * Doener hehe 1104724969 M * ntrs :) 1104725525 M * Doener Bertl: did you do a patch to reactivate the openfd stuff? 1104725532 M * Bertl not yet ... 1104725550 M * Doener ok 1104725589 M * Doener shouldn't be too hard to figure out what to uncomment... 1104725619 M * Doener Bertl: is it the openfd or the nofiles stuff or both? 1104725652 M * Bertl nofiles is working fine (and is active) 1104725754 M * Doener hm, well, it is called in vx_migrate_task, but the result is not used... 1104725768 M * Bertl which is fine, as it is now ;) 1104726862 M * Doener ok, i'm screwed now... OPENFD appears twice in the whole source, both in vx_migrate_task, and the commented vx_openfd_inc is not included, so i guess i can't continue there, as i got nothing to uncomment ;) 1104727136 M * Bertl well, make a copy of those vx_files_inc/dec macros 1104727150 M * Bertl and place them where you consider it appropriate ... 1104727189 M * Doener calls to vx_openfd_* seem to be in-place 1104727231 M * Bertl well the macros are simple now ... 1104727238 M * Bertl #define vx_files_inc(f) \ 1104727239 M * Bertl vx_acc_cres_cond((f)->f_xid, 1, (f), RLIMIT_NOFILE) 1104727251 M * Bertl similar for openfd ... 1104731397 M * Doener test compiling now... 1104731516 J * sannes ~ace@home.skarby.no 1104731528 M * Bertl welcome sannes! 1104731757 Q * t____ Quit: BitchX: it won't get you laid 1104732090 J * grecea ~grecea@h-195-22-237-74.mdl.net 1104732493 M * Bertl welcome grecea! 1104732862 M * Bertl okay, I'm off to bed now ... 1104732880 M * Bertl have a good whatever everyone! 1104732886 N * Bertl Bertl_zZ 1104733109 M * Doener night! 1104734915 M * Doener Bertl_zZ: hm, openfd accounting works for me. IIRC didn't change anything significant compared to the openfd code in 1.9.2.3 ... 1104734937 M * Doener f.e. this seems to work just fine: ls | chcontext --ctx 100 ls `chcontext --ctx 200 ls` 1104734957 M * Doener both contexts never go below zero and reach zero at the end 1104736959 J * [CIA] ~amsam@62.139.206.104 1104737025 P * [CIA] 1104740681 J * BWare ~bware@212.26.196.41 1104740975 Q * serving Read error: Connection reset by peer 1104742462 Q * are|afk Quit: Disconnecting 1104744229 J * rs rs@ice.aspic.com 1104744246 M * rs hi there 1104744250 M * Doener hi rs 1104744305 J * sirius ~sirius@212.37.49.38 1104744307 M * sirius hi^^ 1104744412 M * sirius I've some problems in order to compile the util-vserver (devel) i'm using the 0.30.196 tools and the vs 1.9.3.16, i've copied the kernel header files to /usr/include -> on compiling the tool ive got: 1104744415 M * sirius In file included from /usr/include/linux/fs.h:19, 1104744415 M * sirius from src/rpm-fake.c:43: 1104744415 M * sirius /usr/include/linux/prio_tree.h:22: error: parse error before "pgoff_t" 1104744415 M * sirius /usr/include/linux/prio_tree.h:23: error: ISO C forbids data definition with no type or storage class 1104744421 M * sirius can someone help me ? 1104744458 M * Doener you should not copy the headers to /usr/include... 1104744482 M * sirius i'm using debian, debain's default kernel headers are from 2.4.18 ... 1104744487 M * sirius its old 1104744555 M * Doener go for sarge or sid, but never copy your kernel's headers to /usr/include, IIRC your glibc should provide those headers... 1104744584 M * Doener and there should also be no problem with the 2.4.18 AFAICT 1104744596 M * Doener s/.18/.18 headers/ 1104744602 M * sirius kk 1104744636 M * Doener the tools will use the needed kernel headers from the source tree of the installed kernel 1104744947 Q * sirius Quit: 1104745825 J * _are_ ~are@gateway-dsl.lihas.de 1104746742 M * _are_ hi 1104747404 M * _are_ hmm, now the server froze again, but it froze as I put big writeload on a reiserfs 1104747423 M * _are_ did writeloads before, but not always reiserfs 1104747938 J * serving ~serving@213.186.171.95 1104749026 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104749026 Q * we2byy Read error: Connection reset by peer 1104750636 M * sannes :) 1104750933 M * sannes _are_ : that is exactly the same thing that triggers it for me.. 1104750965 M * sannes _are_ : freezes or random panics/ooopses 1104751040 M * sannes _are_ : if with writeload you mean something like this : cp -a somereallybigdir someotherdir & sleep 30 ; cp -a somereallybigdir someotherdir2 and then just do whatever I usually do .. 1104751476 M * _are_ in this case actually a rsync via rsh (Gigabit network, fast disks) 1104752894 M * sannes ah, well, seems that that it could be ACPI bug for my part on my laptop.. that could be half of the oopses/panics .. now I have to find out if it could be the same thing on the server.. 1104752926 M * _are_ I get no screen output at all, not on local cnsole, not via network syslog 1104753274 M * sannes heh, probably (and now I'm guessing) the complete freezes are due to some other bug and the oopses can be contributed to ACPI .. 1104753310 M * sannes (for my part) and the complete freezes occur when I do a lot of writing to reiserfs.. 1104753311 M * _are_ well, keep in mind I run opterons with 64bit, might encounter a few extra bugs compared to i386 1104753380 M * _are_ smp: dangerous, non-i386: dangerous, reiserfs: dangerous, extra patches (aka vserver): dangerous. And I use all of them :-> 1104753422 M * Loki|muh reiserfs = dangerous? 1104753426 M * _are_ but might as well be the intel gbit driver 1104753446 M * _are_ Loki|muh: all filesystems that are not pure, plain old ext2 are dangerous. I had data loss with all of them 1104753500 M * albeiro reiserfs is dangerous, indeed 1104753501 M * _are_ though I think reiserfs and ext3 are the most stable journalling fs for liux atm 1104753529 A * albeiro is using only xfs and have not problems so far 1104753560 M * _are_ albeiro: wel, at some point some directories claimed to be empty. xfs_repairfs claimed no errors, but afterwards they had been there again 1104753580 M * albeiro strange it is. 1104753592 M * albeiro but anyway, i would not trust reiserfs even on /tmp 1104753613 M * _are_ jfs had been the worst, the data never made it to disk, even, not even corrupted :-> 1104753637 M * albeiro jfs is always in devel... 1104753651 M * _are_ xfs I used for quite a bit, the siste machine ran reiserfs same time. 1104753663 M * albeiro xfs is best designed, read some documentation about it and you will get amazed 1104753668 M * _are_ xfs had the described corruptions 1104753697 M * albeiro as every fs have 1104753699 M * _are_ and I heard speeches of Hans Reiser, by the structure of the speeches it is amazing the filesystem works at all. 1104753721 M * _are_ jumping to and fro all the time. 1104753734 M * albeiro it lacks many features xfs has 1104753743 M * albeiro hans reiser is talking in such a way to get money from goverment agencies 1104753760 M * albeiro and reiserfs4 is even more shame 1104753773 M * _are_ well, atm ext3, xfs and reiserfs are the choices I have 1104753787 M * _are_ ext3 I like for being able to at least recover it using ext2 tools 1104753818 M * _are_ reiserfs man use in the wild, so probably stll decent debugging and it can be grown online without a kernel patch like ext3 needs 1104753839 M * albeiro xfs grows easily ;p 1104753846 M * _are_ xfs would be fine, but I heard numerous rumours sgi won't devel any further there. had been some time ago, though. 1104753885 M * _are_ and no active maintainer is a deathly situation with me using new achitectures same time 1104753926 M * albeiro is ext2 developed ? no ;p 1104753953 M * _are_ well, ext2 has the advantage to e used for many years now 1104753960 M * albeiro well, from what i heard sgi will be maitaining xfs and what's more completly new version is beeing developed 1104753970 M * albeiro with many ew features 1104753971 M * albeiro s/ew/new/ 1104753982 M * _are_ sounds intresting, do you have any links? 1104754026 M * albeiro not yet, will ask friend who has told me it 1104754026 M * _are_ I can't state my search for a stable journalling, online growable (and possible shrinkable), acl-permitting filesystem as over, yet. 1104754078 M * albeiro for what i know they are going to have fetures like dynamically allocated space in blocks 1104754096 M * albeiro so you would no more waste space with many small files 1104754256 M * albeiro hm, friends says he is at work and will give links later when at home 1104754385 M * _are_ ok 1104754403 M * _are_ well, the claimed features and the actually used features are 2 things. 1104754431 M * _are_ I always remember raid-1, should be twice as fast in reading. at least most hardware raid controllers don't support alternate reading :-/ 1104754433 M * sannes I have had no problems with reiserfs .. 1104754434 M * albeiro we will see how it goes :) 1104754445 M * sannes I might have now, but who knows .. 1104754449 M * _are_ :-> 1104754460 M * albeiro twice fast raid should be raid0 1104754473 M * _are_ albeiro: reading, not writing and reading 1104754495 M * albeiro ah, ok 1104754545 M * _are_ I somewhat miss the old irix/aix/hpux stuff where you had been able to give interleave factirs, spindles and other info about the disks data structure to the OS to do the best of it. However, today I'd expect that to be done ... 1104754545 M * _are_ automaticlaly anyway 1104754573 M * _are_ and I still wait for the logical block relocator for lvm 1104754612 M * albeiro code it ;] 1104754623 M * _are_ we want to have it stable :-> 1104754651 M * _are_ I am somewhat good in scripting bash, but I doubt it would be acepted as a bash script :-> 1104754789 M * _are_ btw: I still look for decent info on how unifying works and what should never be unified and especially how you set up unification with the newstyle tools 1104756933 Q * TheSeer Ping timeout: 480 seconds 1104757052 J * TheSeer ~theseer@border.office.salesemotion.net 1104757627 M * sannes _are_ : I have a really good solution for that, especially since you are using 64bit architecture.. BUY LOTS AND LOTS OF RAM AND HD :) *lol* 1104757683 M * ndim Bertl_zZ: I'm now running the 2.6.10-vs1.9.3.14 which crashed so horribly last time. So far, not a single Oops. 1104757924 M * _are_ sannes: it is the small machine, it runs with 2*Opteron 246, 8GB RAM, 2TB SCSI Raid, the big one will most likely have 4*Opteron 246 and 16GB RAM. 1104757949 M * _are_ so far I have not been able to find a somewhat affordable solution for 2TB RAM :-> 1104758120 Q * hesus Ping timeout: 480 seconds 1104758320 J * hesus darksoul@pingu.ii.uj.edu.pl 1104758468 M * sannes _are_ : heh, wish I had that kind of luxery.. 8GB RAM.. mmmmm.. :> 1104758501 M * _are_ well, not my own machine 1104758517 M * _are_ and ram is not *that* expensive anymore, the disks are the expensive part here 1104758606 M * _are_ Hmm, why is it not possible to take a ready compiled kernel source, add xfs as a module and just do 'make modules'? afair this worked with other modules 1104758682 M * _are_ hmm, seems to be a compiler problem. 1104758817 M * we2by helo 1104759074 M * _are_ hi we2by 1104759335 M * _are_ albeiro: xfs: no version for "struct_module" found: kernel tainted. <-- this again is a major reason not to use xfs 1104759375 M * albeiro not even minor one 1104759392 M * albeiro and i have not seen it here 1104759516 M * _are_ probably for hving it static in kernel 1104760619 M * albeiro yeah 1104760622 M * albeiro it's trivial fix anyway 1104761098 Q * grecea Read error: Connection reset by peer 1104761378 J * grecea ~grecea@h-195-22-237-74.mdl.net 1104761866 M * meebey I had/have a big securityhole in my vserver 1104761898 M * meebey my base system is a boostrapped woody 1104761908 M * meebey and I didnt remove any /dev/* 1104761932 M * meebey so with root rights you can access the harddisk and change data if you want 1104761954 M * meebey I should remove all /dev/* and add the ones I really need :_P 1104761970 M * meebey like /dev/pts or /dev/null 1104763229 M * _are_ you can't mount it without the necessary capability and afaik you canm't access the raw device without the necessary capability, either. 1104764248 N * Bertl_zZ Bertl 1104764298 M * Bertl evening folks! 1104764305 M * _are_ hi Bertl 1104764352 M * Bertl hey _are_, you are wrong regarding the raw access ;) 1104764409 M * _are_ feared so. 1104764442 M * _are_ this is why i state all stuff in public, hopefully someone will correct me whenevr I get something wrong 1104764462 M * _are_ and if it is correct what I write, it might have saved some work to others ;) 1104764482 M * Bertl actually I tried several times to 'block' unwanted raw access, but it doesn't work without affecting normal operations ... 1104764492 M * Bertl (so you have to keep a clean /dev ;) 1104764589 M * _are_ so basically as soon as I have the /dev and have r/w rights, I can do my own little tool to just access it, e.g. like smbtar does for acess ing samba shares without mounting them. 1104764615 M * _are_ (and probably such a toolalready exists for some debugging/recovery reason) 1104764626 M * Bertl well, don't know about smbtar, but yes, you can do funny stuff with the raw device ... 1104764653 M * Bertl and one of the worst mistakes is to believe that 'allowing' just one partition is fine ... 1104764682 M * Bertl because with raw access to the device, you can create your own special nodes (i.e. other devices) yourself ... 1104764690 M * _are_ :-> 1104764722 M * Bertl (this is at least somewhat blocked by the secure mount stuff in 1.9.x, which allows loopback mounts but only with nodev set 1104764723 M * _are_ so basically if you have a populated /dev in any vserver, the security concept is overwritten already 1104764761 M * Bertl yes, that is why the tools 'usually' take care of that ... 1104764772 M * _are_ :-> 1104764780 M * Bertl (I hope we'll bring that to the debian tools too ;) 1104764799 M * _are_ true, the debootstrapped vserver has a clean /dev 1104764816 M * _are_ I definitly have not depeted anything manually there 1104764850 M * _are_ # ls /dev/ 1104764850 M * _are_ fd full log null ptmx pts random reboot shm stderr stdin stdout tty urandom xconsole zero 1104764875 M * Bertl hmm, still there are things I would not expect there ... 1104764876 M * _are_ hmpf, I need to learn to type. 1104764898 M * _are_ e.h.? 1104764900 M * Bertl the reboot looks at least suspect to me 1104764917 M * Bertl what the xconsole might be, I don't know ... 1104764927 M * _are_ it is a named pipe 1104764932 M * _are_ reboot is a socket 1104764939 M * Bertl yeah, and where does it lead? 1104764954 M * Bertl on the host, maybe to initd? 1104764962 M * _are_ # fuser /dev/reboot 1104764962 M * _are_ # 1104764983 M * _are_ same for the xconsole 1104764994 M * _are_ seems nothing connected there, at leats nothing from that context 1104765418 M * Bertl btw, still issues with your server? 1104765423 M * _are_ :-( 1104765431 M * _are_ yes, crashed today during a copy action 1104765437 M * Bertl and which kernel/patch/config? 1104765473 M * _are_ however, I assume reiserfs (likely) or the network adapter (e1000) to be the problem 1104765495 M * _are_ 2.6.10-vs1.9.3.14 1104765510 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.10-vs1.9.3.16.diff 1104765525 M * Bertl (some 'unlikely' issues where fixed there) 1104765542 M * Bertl do you have a link/url to your kernel config? 1104765772 M * _are_ it is same as last time 1104765782 M * Bertl url? 1104765918 J * infowolfe infowolfe@209-112-147-196-cdsl-rb1.nwc.acsalaska.net 1104765924 M * _are_ http://vgn.lihas.de/config.gz 1104765925 M * Bertl welcome infowolfe! 1104765940 M * infowolfe hi berni 1104765943 M * infowolfe Bertl, 1104765948 A * infowolfe cusses at tab completion 1104765952 M * Bertl ;) 1104765994 J * mboman ~michael@cm48.sigma230.maxonline.com.sg 1104766056 M * Bertl welcome mboman! 1104766064 M * Bertl _are_: disable CONFIG_NETPOLL=y 1104766071 M * mboman Hi Bertl 1104766078 M * Bertl _are_: same for CONFIG_NET_POLL_CONTROLLER=y 1104766092 M * Bertl and CONFIG_E1000_NAPI=y 1104766104 M * Bertl and CONFIG_IXGB_NAPI=y 1104766154 M * Bertl unfortunately the GBit nic drivers do strange things with netpoll api 1104766163 M * Bertl (i.e. crash the machine :/) 1104766169 M * _are_ umpf 1104766218 M * _are_ guess I build a new kernel then with the new patch and install it somewhere tonight 1104766335 M * infowolfe Bertl, 2.6.10-vs1.9.3.14.diff, how recent? any major bugs? 1104766485 M * Bertl recent, but 1.9.3.16 is better ;) 1104766508 M * infowolfe thanks ;-) 1104766516 M * infowolfe do you have deltas for it? 1104766539 M * Bertl not yet, but I do one if it helps you ... 1104766578 M * infowolfe nah, don't need it ;-) 1104766581 M * infowolfe thanks though 1104766585 M * Bertl k 1104766603 M * infowolfe do you know the latest version of enrico's tools? 1104766622 M * Bertl 0.30.196 and there is a cvs version 1104766650 M * infowolfe hrm, i'm thinking i'll be trying cvs out then ;-) 1104766692 M * infowolfe does vs1.9.3.16 have ngnet support? 1104766714 M * Bertl nope 1104766736 M * infowolfe how close are they in configuration? 1104766744 M * infowolfe or rather, is it even ready yet? 1104766745 M * infowolfe lol 1104766765 M * Bertl ngnet? no it's highly experimental (and not many do experiment atm) 1104766796 M * Bertl probably because you need some decent knowledge to get it to work ... 1104766834 M * infowolfe hrm... alright... knowledge of what ;-) 1104766858 J * monrad ~monrad@213083190130.sonofon.dk 1104766866 M * Bertl basically of what you are doing .. I can walk you through if you like to test ... 1104766875 M * Bertl welcome monrad! 1104766877 M * infowolfe wouldn't hurt to try 1104766878 M * monrad evening 1104766886 M * infowolfe hey monrad 1104766934 M * Bertl well, I guess I can't convice you to use 2.6.10-rc3 for that, so I have to update the patches for ngnet ;) 1104766962 M * we2by I wanna do a share for vservers 1104766966 M * we2by is that posible? 1104766978 M * Bertl with whom do you want to share? 1104766983 M * infowolfe Bertl, thanks ;-) 1104766990 M * infowolfe Bertl, i think i can help ;-) 1104766997 M * we2by I wanna share /vservers/share to /vservers/server-n 1104766997 M * infowolfe we2by, do you want to share between vservers? 1104767003 M * we2by infowolfe, yep 1104767007 M * infowolfe we2by, pretty easy actually 1104767013 M * _are_ Bertl: I don't need the legacy Kernel API when I use the 0.30.196 tools, right? 1104767014 M * infowolfe do you want read only access or read-write? 1104767020 M * we2by read write 1104767027 M * infowolfe _are_, you always want legacy at this point ;-) 1104767051 M * _are_ infowolfe: my config is directory based already. 1104767057 J * Rusty` ~rusty@rev.193.226.233.94.euroweb.hu 1104767061 M * Rusty` hy guys 1104767062 M * Bertl welcome Rusty`! 1104767073 M * Rusty` hey Bertl! what's up? :) 1104767096 J * v00dY v00dy@62.241.52.143 1104767099 M * infowolfe _are_, doesn't matter 1104767117 M * infowolfe we2by, mount -o bind,rw /path/to/share /path/to/vserver/share/place 1104767118 M * _are_ ok :-> 1104767135 M * infowolfe we2by, ensc isn't using the non-legacy api yet, afaik 1104767171 M * infowolfe brb, restarting X 1104767194 Q * infowolfe Quit: (restarting X) 1104767652 J * infowolfe infowolfe@209-112-147-196-cdsl-rb1.nwc.acsalaska.net 1104767691 M * infowolfe okie, i'm bakc 1104767693 M * infowolfe back* 1104767721 M * we2by I;m gonna need a few vservers 1104767722 M * we2by brb 1104767744 M * ndim I need an extra box to test vservers on. 1104767821 M * Bertl hey ndim! 1104767826 M * ndim Hi Bertl. 1104767839 M * Bertl seems like linus found the issue you had ... 1104767853 M * ndim I'm currently running the kernel which oopsed and panicked the last time. 1104767860 M * ndim Without any problems so far. 1104768058 M * infowolfe Bertl, let me know when you have a 2.6.10 patch for me ;-) 1104768087 M * we2by the S_CONTEXT value must be unique? 1104768091 M * Bertl ndim: yep, that _is_ expected ... I'll dig out the reference ... 1104768341 Q * infowolfe Read error: Connection reset by peer 1104768633 M * we2by my second vserver can not resolve hostname 1104768634 M * we2by :\ 1104768653 M * TheSeer vi /etc/resolv.conf 1104768657 M * TheSeer ;) 1104768696 M * _are_ we2by: if it is same setup as yesterday, try 'nameserver 10.0.0.26' added to resolv.conf 1104768704 M * we2by I added it 1104768725 M * _are_ and it doesn't work out? 1104768734 M * we2by nope 1104768735 J * infowolfe ~infowolfe@209-193-10-181-cdsl-rb1.nwc.acsalaska.net 1104768736 M * _are_ but both vservers have 10.0.0.x? 1104768743 M * we2by ~# ping google.com 1104768743 M * we2by ping: unknown host google.com 1104768749 M * we2by yea, both has that 1104768754 M * we2by I can ping the ip of google 1104768762 M * we2by and I can ping the vserver running named 1104768789 M * _are_ hmm, the dns works from external at least 1104768794 M * we2by yep 1104768799 M * we2by it also work for my win 1104768802 M * we2by I am using it right now 1104768805 M * infowolfe we2by, you want to copy your resolv.conf over ;-) 1104768828 M * we2by a type error 1104768830 M * we2by :) 1104768841 M * _are_ :-> 1104768919 M * Bertl fascinating ;) 1104768951 M * _are_ Bertl: how many of the problems in this channel are really vserver related and how many are generic bugs? ;) 1104768975 M * Bertl I'd say roughly about 2% are vserver issues ... 1104768985 Q * infowolfe Quit: 1104768991 J * infowolfe ~infowolfe@209-193-10-181-cdsl-rb1.nwc.acsalaska.net 1104768991 M * _are_ could be worse :) 1104769014 M * Bertl yeah, actually I'm happy with any non-vserver issue ;) 1104769165 M * Rusty` :) 1104769346 M * we2by how hard is it to break the vserver and get to the host OS? 1104769364 M * Bertl depends on the host administrator ... 1104769411 M * we2by berni, can u tell a litle bit about it? 1104769424 M * Bertl yeah berni! tell us about it *G* 1104769435 M * we2by what config is recomended withough applying sec patches to get the best out of it 1104769443 M * we2by ;) 1104769532 M * Bertl basically the vserver system has no known weakness, except for the host system administrator ;) 1104769620 M * we2by u can;t change the hostname inside the vserver? 1104769653 M * Bertl you can, but only 'your' hostname ;) 1104769677 M * we2by jc:~# hostname mysql.jc.humpmeg.net 1104769677 M * we2by hostname: you must be root to change the host name 1104769725 M * Bertl 'grep Cap /proc/self/status' ? 1104769786 M * infowolfe Bertl, no rush on ngnet... turns out they dont' want it after all *sigh* 1104769800 M * Bertl well, I'm basically ready ;) 1104769815 M * Bertl (i.e. it is test compiling ;) 1104769826 M * _are_ some day I will look into what ngnet is :-) 1104769834 M * we2by jc:~# grep Cap /proc/self/status 1104769835 M * we2by CapInh: 0000000000000000 1104769835 M * we2by CapPrm: 00000000dc0c24ff 1104769835 M * we2by CapEff: 00000000dc0c24ff 1104769835 M * we2by CapBset: 00000000dc0c24ff 1104769836 M * we2by jc:~# 1104769874 M * _are_ who thinks it is a bad idea to do the normal intranet vservers (file, print, mail, ...) together on the same box with a firewall-vserver? 1104769923 M * Bertl we2by: you need VXC_SET_UTSNAME to allow this ... 1104770024 M * Bertl http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/lib/ccaps-v13.c?rev=HEAD 1104770042 M * Bertl http://www-user.tu-chemnitz.de/~ensc/util-vserver/doc/conf/configuration.html (section about ccaps) 1104770058 M * we2by Bertl, add VXC_SET_UTSNAME=yes in the config file? 1104770093 M * Bertl nope, you need alpha util-vserver (and 1.9.x) for that 1104770107 M * we2by so how do I change the hostname then? 1104770111 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1104770117 M * we2by what do I add to the config file?? 1104770123 M * Bertl happy new year ensc! 1104770144 M * Bertl we2by: what config style/tools/patches do you use atm? 1104770147 M * ensc Bertl: thx, same for you 1104770152 M * we2by 0.30 1104770157 M * we2by kernel 2.4.x 1104770171 M * Bertl ensc: Doener said, this shall be the year of linux-vserver! ;) 1104770277 M * Bertl we2by: in the config file you specify S_HOSTNAME="mysql.jc.humpmeg.net" 1104770469 M * Bertl ensc: how is your thesis? 1104770603 M * ensc Bertl: there is still much work and only 3 weeks remaining :( 1104770629 M * Bertl well, I'm absolutely sure you will make it ... 1104770630 M * ndim Bertl: I found the thread on LKML. 1104770639 M * Bertl ndim: excellent! 1104770679 M * Bertl ensc: if you need somebody to proofread, just let me know ... 1104770707 M * ensc Bertl: thx; I will contact you 1104770818 M * _are_ ensc: you do a thesis on linux-vserver? 1104770877 M * Loki|muh ensc: whats the title of your thesis? 1104770971 M * ensc _are_: no; about a QA- and buildsystem for the Fedora project. I hoped to make the buildsystem vserver-based but there is not enough functionality in 2.6 yet :( 1104771001 M * _are_ oh, they have no buildsystem, yet, or just no good one? 1104771012 M * ensc for 2.4 only 1104771023 M * ensc but this does not really work well with FC3 1104771031 M * ensc (especially NPTL issues) 1104771053 M * _are_ NPTL is unknown to me (at least as a shortcut) 1104771073 M * ensc some notes about the old one: http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ 1104771109 M * ensc http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ar01s03.html 1104771113 M * ensc is the vserver part 1104771114 M * ndim native posix thread library 1104771122 M * _are_ ah, ok 1104771493 Q * mboman Quit: One day I'll get that peer and reset HIS connection! 1104771586 M * we2by can u reboot a vserver inside it? 1104771608 M * Loki|muh reboot -f with the alpha tools 1104771865 Q * Rusty` Quit: Leaving 1104772284 M * we2by I mean when you are inside it 1104772288 M * we2by and u type in reboot 1104772398 M * Bertl depends on your 'reboot' command 1104772406 M * Bertl (and your setup of course) 1104772426 M * we2by ok.... 1104772436 M * Bertl with alpha tools, the vshelper will be called (typically after reboot -f) which will restart the context 1104772444 M * we2by I want to have the posibility to reboot the vserver when I am inside it 1104772463 M * we2by unfurtunatelly this is 0.3 not the alpha 1104772479 M * Bertl ensc: does 0.30 provide vshelper reboot functionality? 1104772525 M * ensc Bertl: no 1104772543 M * Bertl we2by: then you have to write your own /sbin/vshelper script 1104772545 M * we2by do u think I can run 10 vserver on a celeron 2.4 with 512 ram? 1104772560 M * we2by Bertl, ok.. 1104772563 M * Bertl again depends on the config and usage pattern ... 1104772567 M * we2by sounds hard 1104772602 M * Bertl lycos had about 100-150 vservers running on a dual PIII (with 2GB of ram) for a short amount of time ... 1104772653 M * Bertl OTOH, I know some folks providing game servers (on linux-vserver) which told me that more than 6 servers are not easy to do ... 1104772696 M * we2by more than 6 vservers? 1104772702 M * we2by depends what each one does 1104772732 M * Bertl exactly ... 1104772733 M * we2by each all of those is running apache only and do not get alot hits per day. I think u can just 10+ vservers on a celeron 1104772746 M * we2by for a gameserver, those will eat all ur cpu 1104772818 M * Loki|muh my boss runs 7vservers on a single box with 1GB Ram and with a load of 0.00 most of the time ;) 1104772886 M * _are_ apache should be possible, unless they serve big sites with 1000s of hits and active pages/databases everywhere 1104772900 M * Bertl the typical usage pattern with web server, mail, maybe database, on a 2.6 kernel typically needs 64MB memory and 100Mhz cpu at most ... 1104772952 M * we2by Bertl, is that true? 1104772991 M * Bertl (for each context, that is) 1104773617 M * infowolfe Bertl: getting segfaults on 2.6.10-vs1.9.3.16 in /usr/bin/vserver :-\ 1104773646 M * infowolfe /usr/sbin/vserver: line 84: 7205 Segmentation fault "$@" $_SECURE_MOUNT -a --chroot --fstab "$fstab" 1104773658 M * infowolfe /usr/sbin/vserver: line 131: 7211 Segmentation fault ${NICE_CMD[@]} $_CHBIND "${CHBIND_OPTS 1104773708 M * Bertl interesting ... arch/tools/strace/gdb ? 1104773809 M * infowolfe attempting to get the guy with actual access to the box into here 1104773843 Q * ensc Read error: Connection reset by peer 1104773855 J * bonsaikitten ~pal@dsl-082-082-236-074.arcor-ip.net 1104773864 M * Bertl welcome bonsaikitten! ;) 1104773874 J * DuckKing ~Duck@dyn-83-157-178-98.ppp.tiscali.fr 1104773875 M * bonsaikitten hello Bertl 1104773876 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1104773904 M * infowolfe Bertl: bonsaikitten is the owner of those segfaults 1104773912 M * bonsaikitten "owner" ?? :-) 1104773919 M * Bertl thought so ;) 1104773919 M * infowolfe he's got access to the box and would like you to help him fix it ;-) 1104773930 M * infowolfe thanks 1104773940 M * Bertl first get me the details ;) 1104773941 A * infowolfe wanders off to finish tuning his new kernel 1104773961 M * bonsaikitten Bertl: SMP box, kernel 2.6.10 + vserver 1.9.3.16 patch 1104773970 M * Bertl k, what arch? 1104773973 M * infowolfe x86 1104773980 M * bonsaikitten kernel is up, machine works, vservers not yet :-) 1104773994 M * infowolfe quad p3 500 ;-) 1104773996 M * Bertl okay, you did the testme.sh? 1104774038 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh 1104774079 J * keanu ~keanu@D5763ABA.kabel.telenet.be 1104774085 M * Bertl welcome keanu! 1104774088 M * bonsaikitten chcontext is working. 1104774089 M * bonsaikitten chbind failed! 1104774106 M * infowolfe Bertl: keanu is the guy who compiled that kernel. 1104774117 M * Bertl in this case something went wrong (either with the kernel or the tools) 1104774146 M * Bertl let's start with the kernel, could you upload the .config please? 1104774156 M * infowolfe Bertl: i'm thinking it's kernel, the tools were working ok with 2.6.9-vs1.9.2 (iirc) 1104774282 M * bonsaikitten Bertl: http://dev.gentoo.org/~patrick/config 1104774292 M * Bertl tx 1104774303 Q * DuckMaster Ping timeout: 480 seconds 1104774381 M * Bertl okay, config looks fine, which gcc/binutils? 1104774432 M * bonsaikitten Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 1104774440 M * Loki|muh bonsaikitten: you are gentoo-developer? 1104774450 M * bonsaikitten Thread model: posix 1104774451 M * bonsaikitten gcc version 3.3.4 20040623 1104774458 M * bonsaikitten Loki|muh: yes 1104774503 M * Bertl k, looks fine too ... 1104774542 M * Bertl # ./testme.sh 1104774542 M * Bertl Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl 1104774542 M * Bertl chcontext is working. 1104774542 M * Bertl chbind is working. 1104774542 M * Bertl Linux 2.6.10-vs1.9.3.16 i686/0.30.196/0.30.196 [Ea] 1104774544 M * Bertl --- 1104774547 M * Bertl [001]# succeeded. 1104774549 M * Bertl [011]# succeeded. 1104774552 M * Bertl [031]# succeeded. 1104774554 M * Bertl [101]# succeeded. 1104774557 M * Bertl [102]# succeeded. 1104774559 M * Bertl [201]# succeeded. 1104774562 M * Bertl [202]# succeeded. 1104774564 M * Bertl (this is on a quad PIII) 1104774580 M * Bertl you said chbind is failing, right? 1104774585 M * bonsaikitten yes 1104774634 M * Bertl please do 'grep ipv4 /proc/self/status' 1104774657 M * keanu 1~ipv4root: 0 1104774657 M * keanu ipv4root_bcast: 0 1104774665 M * keanu s/1~// 1104774675 M * Bertl okay, how where the tools compiled? 1104774676 M * bonsaikitten ipv4root: 0 1104774678 M * bonsaikitten ipv4root_bcast: 0 1104774691 A * bonsaikitten is lagging :-) 1104774693 M * keanu its util-vserver-0.30.196 1104774706 M * Bertl with dietlibc? 1104774715 A * keanu looks at infowolfe 1104774759 M * bonsaikitten unlikely 1104774769 M * keanu dietlibc is installed 1104774792 M * Bertl well, the tools prefer dietlibc ... 1104774812 M * bonsaikitten any easy way of finding out? 1104774821 M * Bertl yep, vserver-info 1104774834 M * bonsaikitten Use dietlibc: yes (0.25) 1104774840 M * infowolfe Bertl: should be dietlibc 1104774855 M * Bertl k, using 0.27 here ... but well ... 1104774870 M * Bertl what does Available APIs say? 1104774873 M * infowolfe Bertl: it was the version available "stable" in the gentoo tree at the time i built the tools 1104774904 M * keanu Available APIs: compat,v11,v13,fscompat,net,oldproc,olduts 1104775001 M * Bertl okay, what does 'chbind --ip 127.0.0.1 true' return? 1104775019 M * keanu ipv4root is now 127.0.0.1 1104775019 M * keanu Segmentation fault (core dumped) 1104775036 M * Bertl k, let's look at the core dump with gdb then ... 1104775053 M * keanu gdb isn't installed :\ sec 1104775066 M * Bertl (gdb `which chbind` core. ) 1104775147 M * bonsaikitten Bertl: thanks for your help 1104775222 M * Bertl you're welcome ;) 1104775265 M * Loki|muh bonsaikitten: maybe you wanna look at: http://bugs.gentoo.org/show_bug.cgi?id=55973 1104775282 M * Loki|muh bonsaikitten: its regarding using gentoo as vserver 1104775296 M * Loki|muh ;) 1104775330 M * bonsaikitten Loki|muh: I've inherited blackbox yesterday, I can't do everything myself :-) 1104775378 M * Loki|muh yeah, sure ;) 1104775383 M * bonsaikitten but maybe getting vserver integrated won't be that much work 1104775432 M * Loki|muh yes, it is not much work, but it would be great if it would be per default in the baselayout ;) 1104775460 M * bonsaikitten Loki|muh: it also needs a special kernel, so that will be a bit more difficult 1104775461 M * Bertl bonsaikitten: any progress with the gdb? ah, you are compiling it ;) 1104775548 M * bonsaikitten it's only a quad processor baby ... :-) 1104775831 Q * infowolfe Read error: Connection reset by peer 1104775919 M * bonsaikitten as soon as the compile farm software exists that shouldn't be a problem, but for now gentoo needs everything compiled :-\ 1104775937 M * bonsaikitten and most software won't parallelize during compile 1104776075 M * keanu finaly gdb is done 1104776093 M * Bertl congrats! 1104776278 M * bonsaikitten I see keanu is compiling util-vserver-0.30.196 1104776283 M * bonsaikitten maybe that fixes it already 1104776303 M * keanu i allready recompiled it b4 1104776327 M * bonsaikitten heisenbug :-) 1104776336 M * bonsaikitten if you look long enough it might go away 1104776387 M * keanu Bertl: what info do you want from gdb 1104776415 M * Bertl basically `where` 1104776432 M * keanu this is probably where -fomit-frame-pointer bites us in the ass 1104776469 M * Bertl (well, more the missing debug info) 1104776481 M * Bertl but you can use the chbind from the build tree ... 1104777089 M * keanu #0 0x08048c21 in execvp () 1104777117 A * keanu updates dietlibc 1104777137 M * Bertl excellent, please upgrade the dietlibc to a working version ;) 1104777142 M * bonsaikitten haha 1104777169 M * Bertl but the tools worked with the previous kernel release, right? ;) 1104777176 M * bonsaikitten we need yes 1104777182 M * bonsaikitten aargh :-) 1104777184 M * bonsaikitten yes 1104777460 M * keanu that didn't help 1104777548 M * Bertl still getting segfaults in execvp? 1104777552 J * infowolfe ~infowolfe@209-112-197-65-cdsl-rb1.nwc.acsalaska.net 1104777557 J * _Plug ~plug@datadot.net 1104777558 M * keanu yeah 1104777564 Q * Plug Quit: changing servers 1104777647 M * Bertl well, I can upload my tools (or build static ones for you to test)? 1104777730 M * bonsaikitten keanu: what do you think? static build? 1104777756 M * Bertl http://vserver.13thfloor.at/Experimental/TOOLS/chbind 1104777821 M * keanu dumped 1104777999 M * Bertl very strange ... 1104778077 M * Bertl could you strace it (with the chbind --ip 127.0.0.1 true) and upload that somewhere? (strace -fF pls) 1104778079 M * keanu --disable-dietlibc segfaults too 1104778280 Q * _Plug Ping timeout: 480 seconds 1104778291 M * keanu Bertl: http://dev.gentoo.org/~axxo/strace 1104778526 M * Bertl tx 1104778706 M * Bertl hmm, that looks identical (up to the execve which fails for you) 1104778720 M * bonsaikitten so most likely kernel bug? 1104778730 M * Bertl nope, this is purely userspace 1104778746 M * bonsaikitten cool 1104778752 M * Bertl the syscall succeeded .. then the execve fails ... 1104778759 M * bonsaikitten so there is a chance of fixing it without reb00ting 1104778780 M * Bertl but I remember that we had similar issues ... let's see if I can find anything ... 1104778796 M * keanu thanks 1104779415 J * Plug ~plug@datadot.net 1104779551 M * Bertl keanu: does 'chbind --ip 127.0.0.1 -- true' segfault too? 1104779630 M * keanu yes 1104780161 M * Bertl keanu: please reload http://vserver.13thfloor.at/Experimental/TOOLS/chbind 1104780176 M * Bertl and segfault it with 'chbind --ip 127.0.0.1 -- true' 1104780191 M * Bertl then upload the coredump somewhere where I can reach it ... 1104780216 M * Bertl okay, off for dinner now, back in 30 ... 1104780221 N * Bertl Bertl_oO 1104780446 M * keanu Bertl_oO: http://dev.gentoo.org/~axxo/core 1104780725 Q * sannes Read error: Connection reset by peer 1104781757 Q * _are_ Quit: Disconnecting 1104782372 N * Bertl_oO Bertl 1104782688 M * Bertl keanu: is it possible that some security stuff (like stack protection or whatever) is interfering here? 1104782722 M * keanu don't think so 1104782734 M * Bertl Program terminated with signal 11, Segmentation fault. 1104782735 M * Bertl #0 0x080489e9 in execvp () 1104782750 M * Bertl 0x080489e9 :push $0x804ae75 1104782750 M * Bertl 0x080489ee :call 0x8048b64 1104782800 M * keanu hmm 1104783178 M * keanu notting hardneded or things like that 1104783481 M * Bertl well, I don't see anything bad in calling 1104783487 M * Bertl execvp(path,argv); 1104783513 M * Bertl with path=argv'[optind] and argv=argv'+optind 1104783589 M * Bertl keanu: what if you do 'chbind --ip 127.0.0.1 -- true true' 1104783644 M * keanu same 1104783689 M * keanu :( 1104783993 M * Bertl well, the only thing I can suggest is to single step the execvp with gdb ... 1104784025 M * Bertl and try to figure where/why it fails ... 1104784530 M * Bertl ah, idea! the execvp does path searching ... 1104784545 M * Bertl keanu: what does your PATH env var contain? 1104784561 M * keanu /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3 1104784600 Q * flock Ping timeout: 480 seconds 1104784865 M * Bertl 'env -i /bin/true' does work as expected I presume? 1104784885 M * keanu yup 1104784905 M * Bertl what about 'env -i chbind --ip 127.0.0.1 true' ? 1104784935 M * keanu with full path to chbind seg faults too 1104785030 M * keanu Program received signal SIGSEGV, Segmentation fault. 1104785030 M * keanu execvp (file=0xbffffccf "true", argv=0xbffffb54) at lib/execvp.c:10 1104785030 M * keanu 10 const char *path=getenv("PATH"); 1104785033 M * keanu hmm 1104785051 M * keanu compiled dietlibc with debug 1104785136 M * Bertl # env -i PATH=":" `which chbind` --ip 127.0.0.1 /bin/true && echo $? 1104785136 M * Bertl ipv4root is now 127.0.0.1 1104785136 M * Bertl 0 1104785269 M * Bertl (1998) It looks like the execvp() function invokes execve() with a null 1104785270 M * Bertl pointer when an attempt is made to execute a file that does not exist. 1104785340 M * keanu seg faults too, core by true? 1104785392 M * Bertl hmm, I'm inclined to believe that it _is_ a kernel issue ... 1104785415 M * Bertl http://dev.gentoo.org/~patrick/config <-- still valid? 1104785431 M * Bertl (if so, I'll compile the kernel here) 1104785450 M * keanu yes 1104785564 J * _are_ ~are@84.56.128.56 1104785581 M * Bertl wb _are_! 1104785597 M * _are_ hi 1104785616 M * _are_ Bertl: server hangs again, but I have not come around to boot the new kernel, yet 1104785655 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1104785692 M * Bertl wb flock! 1104785701 M * flock 'lo 1104785705 M * Bertl _are_: well, then update it now! 1104785726 M * _are_ hehe, it is already installed, just someone needs to get there and hit the reset button 1104785741 M * _are_ I guess tomorrow 6:05am I will get a call :-> 1104785895 M * Bertl keanu: do you need any of the modules? 1104785903 M * Bertl (I mean to boot and test?) 1104785907 M * keanu Bertl: no 1104785913 M * keanu Bertl: none are loaded 1104785945 M * Bertl k 1104786187 M * Bertl http://vserver.13thfloor.at/Experimental/KEANU/ 1104786395 Q * serving Ping timeout: 480 seconds 1104786625 M * keanu can't reboot :\ 1104786672 M * Bertl button is stuck, I guess ;) 1104786696 M * Bertl np, I'm off to bed now, but I'll be back tomorrow morning ... 1104786740 M * keanu stupid bios needs a keyboard, and its got none, and its a few hundrek km away from me 1104786849 M * Bertl that must be a really stupid bios ... does it ask: "no keyboard found! press F1 to continue!" 1104786881 M * Bertl s/ask/prompt/ 1104786896 M * keanu something like that :) 1104786917 M * Bertl k, so we'll see tomorrow I guess .. have a nice whatever! 1104786929 M * keanu you too, thanks for the help 1104786932 M * Bertl night everyone! 1104786940 N * Bertl Bertl_zZ 1104787926 J * sannes ~ace@home.skarby.no 1104793120 J * serving ~serving@213.186.191.24 1104793926 J * berni_ ~berni@2001:1b18:202::2 1104793965 Q * berni Quit: fixing my ugly cabling 1104794025 M * we2by I have a weird problem 1104794034 M * we2by vserver-stat does not give a list of all vservers 1104794166 Q * monrad Quit: Leaving 1104794852 Q * keanu Quit: leaving 1104794890 J * keanu ~keanu@D5763ABA.kabel.telenet.be 1104795507 M * we2by vserver-stat does not give a list of all vservers 1104796596 Q * bonsaikitten Quit: leaving