1114560673 Q * SNy Remote host closed the connection 1114560834 M * Doener_ Bertl: what's the intended use of the options you defined in the killer framework? i guess -x is for xid, but not sure about the rest... 1114560980 M * Bertl they are just left overs ... 1114560993 M * Doener_ ok, so I'll do my own... 1114561000 M * Bertl yup, please do so ... 1114561030 M * Bertl btw, just found this: http://f0rked.com/core/irssi 1114561136 Q * cereal Ping timeout: 480 seconds 1114561461 M * Doener_ thanks! 1114561489 M * Bertl hmm .. hmm, I just found the tips&tricks page on irssi too ;) 1114561493 M * Bertl http://irssi.org/?page=docs&doc=tips 1114561496 J * cereal ~cereal@217.20.124.153 1114561504 M * Doener_ yeah, i've read that an hour ago :) 1114561505 M * Bertl and now I consider adding some 'replaces' 1114561593 M * Doener_ the urls of the util-vserver, proc-security and namespaces wiki pages have proven to be a good idea for a 'replace' 1114561620 M * Bertl well, was more thinking of my 'typical' tpyos ;) 1114561641 M * Doener_ heh ;) 1114561760 J * SNy ~mfr@bmx-chemnitz.de 1114561768 M * Bertl wb SNy! 1114563426 M * Bertl Doener_: http://vserver.13thfloor.at/Experimental/FOR-2.0/delta-fakeinit-feat01.diff 1114563942 M * Bertl Doener_: btw, I agree with your judgement to completely remove the task_[vn]x_info() 1114563951 M * Doener_ ok 1114564139 M * Doener_ patch looks good 1114564289 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-2.0/delta-proc-clean01.diff 1114564300 M * Bertl maybe we should add a test for the fakeinit (to the testme.sh) 1114564363 M * Doener_ looks good, too ;) 1114564501 M * Bertl okay, doing the comp32 stuff now ... 1114565418 M * Doener_ Bertl: hm, in legacy.h we use NB_IPV4ROOT before we define it... 1114565433 M * Bertl hmm, cool! 1114565451 M * Doener_ heh 1114565456 M * Bertl why doesn't the compiler complain? 1114565524 M * Doener_ maybe because it is also defined in network.h and we always include those two together... 1114565541 M * Doener_ but then it should complain about re-definition, shouldn't it? 1114565549 M * Bertl yup 1114565584 M * Bertl I'll investigate ... 1114565609 M * Doener_ i've no idea then... but i discovered it, because the compiler complained when i included legacy.h in the killer ;) 1114565852 J * Doener__ ~doener@p54874DD4.dip.t-dialin.net 1114565872 M * Bertl okay, I lean towards removing the NB_* completely from the legacy.h 1114565917 M * Bertl userspace tools will not use that information, I guess 1114565921 M * Doener__ and move the vcmd_set_ipv4root_v3 to network.h? 1114565950 M * Bertl no, just leave it there and _assume_ that either network.h is included or the compiler will bail out 1114565962 M * Doener__ ok 1114565991 M * Bertl at a later time we will change that to network legacy anyway 1114566063 M * Doener__ hm, guess we should invite gilles... 1114566105 M * Bertl already done so ... 1114566141 M * Doener__ ok, then i just didn't get that mail yet... *aborts his invitation* ;) 1114566271 Q * Doener_ Ping timeout: 480 seconds 1114566505 M * ciphernaut using lvm, it seems using reiserfs is the best choice in that it is the most flexible for resizing, when the need arises 1114566519 M * Bertl hmm, is it? 1114566546 M * DaCa ciphernaut: I share that opinion 1114566560 M * ciphernaut what are other peoples experience with using vservers and lvm? 1114566570 M * hillct Reiser allows for reduction in size 1114566571 M * Bertl lvm and ext3 is quite fine 1114566578 M * hillct which XFS doesn't 1114566591 A * hillct likes XNS on LVM on software RAID 1114566594 M * hillct er XFS 1114566618 M * DaCa ciphernaut: works ok for me :) 1114566654 M * hillct as of 1.9.5 XFS is supported 1114566659 M * Doener__ vserver+lvm+ext3+resizing works fine for me... 1114566688 M * Bertl hillct, DaCa, ciphernaut: except for personal preference, what are the arguments against ext2/3 again? 1114566690 M * hillct Bertl thanks again for that 1114566702 M * hillct resizing 1114566715 M * hillct XFS allows FS expension on yhe fly without unmounting 1114566717 M * ciphernaut Doener: do you need to unmount the filesystem in order to resize it? 1114566745 M * ciphernaut ext2/3 that is 1114566755 M * Doener__ ciphernaut: IIRC expansion can be done on the fly, but I unmount them anyway 1114566795 M * Bertl yup, ext2/3 has online resizing too, you need to activate it on fs creation time 1114566797 A * hillct routinely extends XFS without unmounting on many systems 1114566804 M * hillct NEVER had a problem with it 1114566816 M * hillct really? 1114566821 M * hillct didn't know that 1114566835 M * hillct never thought to look really 1114566842 M * hillct just assumed 1114566926 M * hillct http://ext2resize.sourceforge.net/online.html 1114566947 M * hillct does that mean this patch has made it into the main kernel code now? 1114566970 M * Bertl checking for that right now ... 1114566971 M * ciphernaut tahnks all 1114567001 M * ciphernaut I'll test it with resierfs 1114567018 M * hillct oh 1114567021 M * hillct one other thing 1114567031 M * hillct XFS is optimized for large files 1114567045 M * hillct If memory serves, Reiser is optimized for small files 1114567055 M * Bertl well, I know the XFS code somewhat ... and the reiserfs too ... 1114567057 M * hillct not certain about the latter 1114567080 M * Bertl and telling from the implementation (code) I would stay away from both ;) 1114567086 A * hillct meant it in the department of reasons to go with one vs the other 1114567128 A * hillct doesn't know linux driver ass drom elbow so will leave such judgments to Bertl 1114567138 M * hillct er ass from elbow 1114567182 M * Bertl well, I hope that the developers of both reiser and xfs know their code well, because it is almost unreadable ... 1114567224 M * Bertl xfs because of the many indirections to fit into the linux vfs ... and reiser because of the 'strange' implementation of compatibility layers 1114567250 M * Bertl but that doesn't make either of them bad filesystems ... 1114567437 M * hillct ah 1114567474 M * hillct Is there a verdict as to whether ext/# online resizing is actually in the kernel or not? 1114567497 A * hillct had never heard it so much as mentioned before 1114567504 M * Bertl yup, it seems to be there 1114567507 M * Bertl fs/ext3/resize.c 1114567510 M * Bertl * Support for resizing an ext3 filesystem while it is mounted. 1114567529 M * hillct so it's a switch at creation time? 1114567537 A * hillct looks at the man page 1114567544 M * Bertl it needs a 'resize inode' 1114567733 M * hillct so specify as -O resize inode 1114567771 M * hillct this is why nobody who hasn't looked at the source has figured it out 1114567821 M * hillct it's not in the man page for mkfs.ext3 1114567839 M * hillct is it resize_inode with an underscore or a space? 1114567844 M * Bertl well, some things are reserved for the priviledged ;) 1114567855 M * hillct clearly 1114567876 M * Bertl but maybe the resize inode is created by default (with newer tools) 1114568023 M * Doener__ hm, i better not test unlimited binary forking on my box i guess ;) 1114568066 M * Bertl hmm, well, you have magic-sysrq, or you could make a high prio rt console ... 1114568138 M * Doener__ hm, yeah... using killall/pkill would work... 1114568139 A * Doener__ had thought that he wouldn't manage to be fast enough to kill all those killers... ;) 1114568139 M * Doener__ guess some coffee is needed 1114568315 M * Doener__ qdeb:/home/doener# pkill killer 1114568315 M * Doener__ -su: fork: Resource temporarily unavailable 1114568322 M * Doener__ heh 1114568843 M * Doener__ hmm... just had a load average of 1000+ 1114568853 M * Bertl congrats! 1114568881 M * Doener__ and a lot of: 1114568881 M * Doener__ UseCnt: 3 1114568881 M * Doener__ Tasks: 0 1114568899 M * Bertl going away, I hope ... 1114568985 M * Doener__ ah yeah... the number finally decreases... had too many killers still waiting for a context i guess... 1114569070 M * Doener__ ok, everything back to normal... 1114569078 M * Bertl excellent! 1114569213 M * Bertl sounds like a good choice that 'linux-vserver stuff' ;) 1114569358 M * Doener__ hm, doing a stupid check (ls /proc/virtual | wc -l) the legacy context creation seems to be quite a bit faster than the new one 1114569428 M * Bertl hmm ... how do you deduce one from the other? 1114569499 M * Doener__ i do a 10 level binary fork using both and watch the behaviour of /proc/virtual... i.e. how many contexts are there, how long does it take until all the context are gone again 1114569564 M * Bertl a single syscall for each? 1114569597 M * Bertl dynamic context ids? 1114569607 M * Doener__ dynamic contexts 1114569677 M * Doener__ "single syscall for each" means? 1114569695 M * Bertl well, the 'new' style usually has create, migrate, no? 1114569870 M * hillct cd .. 1114569874 M * hillct d'oh 1114569884 M * Bertl ;) 1114569900 M * Doener__ hm... VCMD_ctx_create includes a call to vx_migrate_task, so why should I call VCMD_ctx_migrate? 1114569972 M * hillct I'm not clear on the use of fstab in the config tree, vs fstab.local 1114569999 M * hillct after reading the flower page and the manespaces wiki page, It's still unclear 1114570004 M * Bertl Doener__: hmm, right, but you are still in setup state then ... 1114570053 M * hillct When the vserver is shut down and init unmounts all filesystems, each of those in the fstab i nthe config tree fails and returns 'must be superuser to unmount' 1114570135 M * Bertl hmm, with 0.30.206 ? 1114570158 M * Bertl guess you should report that as bug then ... 1114570563 M * Doener__ Bertl: how do i get out of setup state? 1114570573 M * Bertl by clearing the setup flag 1114570601 M * Doener__ thought so ;) ... but i can't find anything in the kernel that does it.. 1114570642 M * Doener__ only in the legacy code... 1114570663 M * Bertl vc_set_cflags 1114570708 M * Bertl how does your fork() killer work? 1114570724 M * Bertl because if it 'just' calls create over and over again ... 1114570772 M * Bertl then the legacy call will fail from inside a context, where the new style will succeed 1114570797 M * Bertl but in any case, it might be worth enabling profiling ... 1114571074 M * Doener__ well, i can do a full context setup, but i didn't think that the killer would need it... 1114571101 M * Bertl probably should not ... 1114571118 M * Bertl let's start with a simple, self destructing fork bomb? 1114571136 M * Bertl i.e. some kind of level limit ... fork counter 1114571267 M * Doener__ http://www.13thfloor.at/~doener/vserver/tools/killer-0.02.tar.bz2 1114571281 M * Doener__ that's the latest that is not broken in one or another way... 1114571627 M * Bertl interesting code ... 1114571656 A * Doener__ .oO( is that good or bad? or both? ;) 1114571679 M * Bertl where does it call the new_context() again? 1114571738 M * Bertl and what did you do to my indentation? ;) 1114571742 M * Doener__ after forking (if it does fork, didn't add a check that forces you to select a fork method) 1114571769 M * Doener__ that was a mixed space/tab indentation and it didn't match my tabsize ;) 1114571772 M * Bertl so it forks around a little, and then calls the new_context() once, no? 1114571829 M * Doener__ every child creates a context once... 1114571905 M * Bertl yup ... at the end ... and what does the binary fork do with the local stack variable? 1114571973 M * Doener__ hm, which one? 1114571982 M * Bertl int current = 0; 1114572038 M * Doener__ hm, right... i could use (max == -1 || max--) there 1114572070 M * Bertl hmm, and that would improve things? 1114572087 M * Doener__ the local variable would be gone... 1114572106 M * Bertl yup, now using the implicit local stack variable max ;) 1114572156 M * Bertl what does 'max' mean? 1114572196 M * Doener__ max depth of the binary forking... max=4 == 16 forks 1114572198 M * Bertl I would write the binary_fork (yours as) 1114572208 M * Bertl if (fork()) 1114572208 M * Bertl return 1; 1114572223 M * Bertl linear_fork(max); 1114572246 M * Bertl because that's what you do, no? 1114572301 M * Doener__ hmm... linear_fork(max) does 'max' forks... binary_fork does 2^max forks... 1114572320 M * Bertl does it? 1114572324 M * Doener__ yes it does... 1114572348 M * Bertl okay, we enter the binary_fork() once, right? 1114572354 M * Doener__ yep 1114572371 M * Bertl we then fork, once, leavin two threads, parent and child, right? 1114572381 M * Doener__ yep 1114572412 M * Bertl On success, the PID of the child process 1114572424 M * Bertl and a 0 is returned in the childās thread 1114572444 M * Bertl so the parent returns with 1 (from the fork) 1114572456 M * Bertl while the child continues, no? 1114572468 M * Doener__ yes 1114572520 M * Bertl now current = 0, then current = 1 1114572542 M * Bertl then we fork(), and both parent and child continue 1114572561 M * Doener__ yep 1114572584 M * Bertl hmm, okay, both should have a copy of the current 1114572613 M * Bertl okay, should work then, unless it stops at some point because it can't fork anymore 1114572624 A * Bertl seems tired too :/ 1114572646 M * Doener__ yeah, it's getting morning already... 1114572652 M * Bertl maybe we should add something like: 1114572667 M * Bertl static volatile long fork_count = 0; 1114572682 M * Bertl and inrement that on each thread ... 1114572700 M * Bertl (not necessarily fork_count, maybe task_count ... 1114572759 M * Bertl and then we should also count the 'successful' context creations in a different variable ... 1114573705 M * Doener__ hm, just having it volatile won't be sufficient, would it? didn't do such stuff for a long time... 1114573730 M * Bertl global (i.e. static) and volatile should be sufficient 1114573857 M * Doener__ no, doesn't work 1114573973 M * Bertl hmm, right, those are tasks, not threads ... 1114574122 M * Doener__ guess we should postpone that... we're both too tired... 1114574131 M * Bertl yup .. agreed! 1114575132 Q * ndim Read error: Connection reset by peer 1114575138 J * ndim hun@helena.bawue.de 1114575809 M * Doener__ i'm gone then... time for breakfast... 1114575818 M * Bertl hmm, yeah, good idea ... 1114575818 M * Doener__ sweet dreams Bertl! 1114575823 M * Bertl cya later today ... 1114575838 M * Doener__ hmm... ok, no sweet dreams then ;) 1114575845 M * Doener__ (at least not immediately) 1114575849 M * Doener__ cya 1114575853 M * Bertl well, I'm off to bed _after_ breakfast ... 1114575857 N * Doener__ Doener|gone 1114576856 M * Bertl night folks ... cya all later ... 1114576868 N * Bertl Bertl_zZ 1114578224 Q * Pazzo Quit: .out 1114578243 Q * tchan Ping timeout: 480 seconds 1114578813 J * tchan ~tchan@c-24-13-81-164.hsd1.il.comcast.net 1114582258 J * Pazzo ~Pazzo2@adsl136-175.aknet.it 1114583756 J * jfmrec ~jf.meyer@147-148.245.81.adsl.skynet.be 1114583900 M * jfmrec hello, ifconfig launched in a vserver context displays the virtual IP of other vservers. How to avoid this? 1114585142 Q * jfmrec Quit: 1114585441 N * ciphernaut ciphernaut_zz 1114585769 Q * daniel_hozac Read error: Operation timed out 1114586392 J * daniel_hozac ~daniel@h56n2fls32o829.telia.com 1114588926 J * prae ~prae@ezoffice.mandriva.com 1114594086 Q * DuckMaster Remote host closed the connection 1114599164 J * yarihm ~yarihm@80-218-1-49.dclient.hispeed.ch 1114602202 J * terr ~nobody@ip-213-49-106-244.dsl.scarlet.be 1114602655 J * knoppix_ ~knoppix@dsl-213-023-144-200.arcor-ip.net 1114607923 J * DuckMaster ~duckx@195.75.27.158 1114608087 N * Doener|gone Doener_ 1114608104 M * Doener_ good afternoon... 1114610846 N * Bertl_zZ Bertl 1114610871 M * Bertl morning folks! 1114611204 M * hillct morning Bertl! 1114611218 M * hillct morning Doener_! 1114611234 M * hillct er Afternoonn Doener_ 1114611277 Q * tchan Quit: leaving 1114611567 M * Bertl terr: around? 1114611635 M * Bertl anyway, I'm off for now, but I'll be back later .. 1114611668 N * Bertl Bertl_oO 1114611669 M * terr I'm here !!! 1114611680 N * Bertl_oO Bertl 1114611685 M * Bertl almost too late ;) 1114611697 J * noyan ~xXx@dsl81-215-25067.adsl.ttnet.net.tr 1114611702 P * noyan 1114611721 M * terr Is there any time left? 1114611733 M * Bertl terr: so you're collecting defunct processes, eh? 1114611770 M * terr Yes, 1726 of them at the moment 1114611809 M * Bertl could you switch to a more recent kernel and see if that happens again? 1114611826 M * Bertl just saw that you are using 2.6.11-vs1.9.5-rc1+g1 1114611836 M * Bertl (whatever that g1 might be?) 1114611872 M * terr My first is "Gilles", actually + first config for that kernel version 1114611904 M * Bertl ah, so it is a plain 2.6.11-vs1.9.5-rc1, right? 1114611911 M * terr Yes 1114611931 M * terr Euh: 2.6.11.7 1114611949 M * Bertl there are two options (for newer kernels) 1114611965 M * terr and "vserver 2.0 pre2" 1114611970 M * Bertl either the fixed up 1.9.5 release 1114611980 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.11.7-vs1.9.5.x5.diff.bz2 1114611992 M * Bertl or the new 2.0-pre2 release ... 1114612006 M * terr Yes it *is* that one already! 1114612014 M * Bertl (you might encounter some issues wih the tools on 2.0-pre2 though) 1114612044 M * Bertl hmm, which one? 1114612074 M * terr uname -> 2.6.11.7-vs2.0-pre2+g1 1114612092 M * Bertl you are saying you already updated? and now you are getting the defunct processes with vs2.0-pre2? 1114612116 M * terr Yes! 1114612158 M * Bertl ah, okay, so I misread (or probably mixed) your emails ... 1114612228 M * Bertl okay, which initstyle do you use for your vservers? 1114612263 M * terr "plain" 1114612299 M * Bertl okay, so you are starting an init inside the vserver .. do you know if there are other processes hanging around as defunct except thos init processes? 1114612367 M * terr In fact I don't see defunct "init" 1114612386 M * Bertl okay, you see 'init' in 'D' state and defunct processess, right? 1114612418 M * terr I have: ssh-agent, icewm gconfd-2, gkrellm, xterm, sablevm, mutt, ... etc etc. 1114612433 M * Bertl okay, inside or outside a vserver? 1114612455 M * terr Yes "init" in D state with "[2]" written after it 1114612476 M * terr Outside! The vserver is stopped a long time ago. 1114612527 M * Bertl could you upload the output of 'vps auxwww' and 'ps auxwww' (both on the host) somewhere (e.g. pastebin.com or one of your servers) 1114612717 M * terr I connected to that site but I don't the procedure; could I email it to you instead? 1114612728 J * noyan ~xXx@dsl81-215-25067.adsl.ttnet.net.tr 1114612898 M * Bertl terr: yup 1114613122 M * terr OK, just sent to 1114614086 M * Pazzo hi all! 1114614100 M * noyan hi 1114614124 M * Pazzo vs2.0-pre2+g1? what is g1? 1114614129 M * Pazzo hi noyan! 1114614293 M * terr Just the initial of my first name ;-) 1114614382 M * Bertl okay, looks like your host's init process is simply stuck, writing (or reading) from a device 1114614410 M * Bertl this in turn leaves all processes which exit lingering around as zombies 1114614462 M * terr Do you have a cure for that? 1114614468 M * Bertl now as it is not possible (without kernel modification) to trace the init process (nobody knows why this was decided), the only think you can do is reboot ... 1114614469 M * Pazzo hi Bertl! 1114614493 M * Bertl terr: but I would look into the kernel logs, because init does not 'hang' normally 1114614508 M * Bertl (at least not without good reason, like some hardware failing) 1114614535 M * Bertl hey Pazzo! 1114614570 M * Bertl terr: check dmesg and /var/log/messages (for issues when the first 'zombie' arrived 1114614582 M * DaCa Bertl: isnt that because init cant have a parent? 1114614607 Q * Pazzo Quit: ups.... 1114614619 M * DaCa (that you can't ptrace it) 1114614647 M * Bertl DaCa: well, init has a parent (the real kernel/init thread) but yeah, probably that's why they 'blocked' ptracing it ... 1114614695 M * Bertl terr: should be something around the 25th of april ... 1114614716 M * Bertl okay, leaving now for real (have to do some shopping) back in an hour or two ... 1114614725 N * Bertl Bertl_oO 1114614807 M * terr I won't be here then, but later... 1114614824 M * terr I'll reboot (nothing in /var/log/messages) 1114614852 M * terr Will you be on IRC at around 11 PM? 1114614950 P * terr 1114614950 Q * grecea Read error: Connection reset by peer 1114615085 J * grecea ~grecea@h-195-22-237-74.mdl.net 1114615425 Q * noyan Ping timeout: 480 seconds 1114617888 Q * prae Quit: Client exiting 1114619026 J * Jani GrisLittle@G9cf0.g.pppool.de 1114619029 M * Jani *waves* 1114619244 N * Bertl_oO Bertl 1114619258 M * Bertl greetings! 1114619446 M * Jani *hmms* Little question, I think I have read somewhere it already, but I can't find the location. 1114619459 M * Jani There was something special to setup the lo-device in a vserver, right? 1114619679 M * Bertl well, depends on the branch ... 1114619707 M * Bertl with 1.9.x (2.0) or 1.2 there is nothing to do about lo 1114619733 M * Jani So, it's the normal handling? 1114619733 M * Bertl with ngnet, you have to configure your private lo (for each vserver) 1114619857 M * Bertl yes and no .. maybe you tell me what you want to know or do, then I can answer that ;) 1114619922 M * Jani I just need the loopback network device (127.0.0.1), I have an debian vserver (version: 1.9.5) 1114620248 Q * kevinp|gone Ping timeout: 480 seconds 1114620349 M * Bertl well, I can assure you, it's there ;) 1114620382 J * kevinp ~kevinp@ny.webpipe.net 1114620399 M * Jani It's there? 1114620400 M * Jani *hmms* 1114622535 J * kjo ~krischan@p5484D23B.dip.t-dialin.net 1114623038 J * erwan_taf ~erwan@choeur.l3m.univ-mrs.fr 1114623095 M * Bertl welcome kjo! erwan! 1114623278 M * kjo hi bertl 1114625252 Q * erwan_taf Ping timeout: 480 seconds 1114625453 J * tgunkel_ ~Thorsten@dsl-084-058-010-176.arcor-ip.net 1114625461 M * tgunkel_ Hi * 1114625478 N * tgunkel_ ThorstenG 1114625565 M * Bertl hey ThorstenG! 1114625625 M * ThorstenG Is the debian maintainer of util-vserver here? Is it ola? 1114625645 M * Bertl no and yes ;) 1114625660 M * Bertl (at least I think so .. ) 1114625790 M * ThorstenG Have set up several vservers in last days and it works great! 1114625845 M * Bertl good! 1114625909 M * ThorstenG Now I want to reduce the harddisk space they require. I've read about vhashify 1114625979 M * ThorstenG However it seems the debian util-vserver ship without it 1114625996 M * Bertl yup, successor of the famous vunify ... 1114626011 M * Bertl it's in util-vserver >= 0.30.205 1114626078 M * ThorstenG Sure that it isn't in 0.30.204? 1114626141 M * DaCa sarge has 204, sid has 206 1114626345 M * Bertl any folks around with an amd64 or sparc64 or mips64 or maybe ia64? 1114626464 M * ThorstenG DaCa, thx but even the sid version doesn't have a working vhashify 1114626597 M * DaCa ThorstenG: aparently not, indeed. 1114626621 M * ThorstenG Yes, I've already filled a bug about it, he's missing beecrypt 1114626650 M * ThorstenG Is there any reason why one shouldn't use vhashify? 1114626691 M * Bertl not that we know of ... 1114626713 M * ThorstenG ok, I'll write ola 1114627214 J * Tbery ~tb@pha-84-242-95-4.nat.karneval.cz 1114627220 M * Bertl welcome Tbery! 1114627235 M * Tbery Hi 1114627242 M * Tbery Can i aks 1114627251 M * Tbery I have troble with sudo in vserver 1114627261 M * Bertl let's hear! 1114627261 M * Tbery it doesnot work 1114627281 M * Tbery I have same sudoers on 2 machines 1114627284 M * Tbery same user 1114627285 M * TheSeer now that's what i call a detailed error report... 1114627290 M * TheSeer :-P 1114627298 M * Tbery same aplication 1114627302 M * Bertl TheSeer: seen worse ... 1114627311 M * TheSeer Bertl: sure.. me too ;> 1114627313 M * Tbery but on obe on all commands Aborted 1114627319 M * TheSeer "Help! It doesn't work" 1114627321 M * TheSeer ;> 1114627346 M * Bertl Tbery: so first a view details about kernel patch, user tool version, distro, etc ... 1114627422 M * Tbery 2.6.8 1114627448 M * Tbery 0.30.204-1 1114627511 M * Bertl distro? 1114627566 M * Tbery debian 1114627593 M * Bertl okay, and when you try to sudo, it does tell you what? 1114627604 M * Tbery Aborted 1114627648 M * Bertl any message in the logs? how do you logon the the guest? 1114627655 M * Tbery on root 1114627676 M * daniel_hozac isn't that the netlink problem? 1114627725 M * Bertl most likely ... 1114627807 Q * yarihm Read error: Operation timed out 1114627872 M * Bertl Tbery: still here? did you understand my questions? 1114627901 M * Tbery what I was out on monent 1114627950 M * Bertl np 1114628122 M * Tbery witch log I must look?? 1114628219 M * Bertl for example /var/log/messages (on the guest) 1114628256 M * Tbery any massage about sudo 1114628403 M * Bertl btw, which kernel patch to 2.6.8 ? 1114628424 M * Tbery some old 1.9.2 1114628430 M * Tbery I must upgrade 1114628452 M * Bertl okay, so it's most likely the netlink issue daniel mentioned 1114628477 M * Bertl I would suggest to upgrade to 1.9.5 or later and see if the issue remains 1114628478 M * Tbery I try firt update 1114628505 M * Tbery oki 1114628507 M * Tbery I try,.. 1114628971 J * kalou_ ~kalou@AToulouse-203-1-3-94.w80-14.abo.wanadoo.fr 1114629054 M * Bertl welcome kalou_! 1114629092 Q * kalou Ping timeout: 480 seconds 1114634530 J * prae ~prae@sherpadown.net 1114634552 M * Tbery Im compile new kernel 2.6.11.7 1114634557 M * Tbery with 1.9.5 1114634757 M * Bertl good, maybe you want this patch: http://vserver.13thfloor.at/Experimental/patch-2.6.11.7-vs1.9.5.x5.diff.bz2 1114634781 Q * romke Ping timeout: 480 seconds 1114635127 Q * kjo Ping timeout: 480 seconds 1114635828 J * romke romke@procyon.romke.net 1114636255 Q * Tbery Quit: Ukončuji 1114636615 J * kjo ~krischan@p5484D23B.dip.t-dialin.net 1114636619 Q * kjo Quit: 1114636659 Q * romke Read error: Connection reset by peer 1114636987 J * romke romke@procyon.romke.net 1114638023 J * martijn ~martijn@h141248.upc-h.chello.nl 1114638505 M * Bertl welcome martijn! 1114639152 Q * martijn Ping timeout: 480 seconds 1114639555 J * kjo ~krischan@p5484D23B.dip.t-dialin.net 1114641522 Q * knoppix_ Quit: Verlassend 1114642119 M * Bertl Doener_: you around? 1114642382 J * DuckKing ~Duck@dyn-83-157-191-47.ppp.tiscali.fr 1114642542 Q * duckx Read error: Operation timed out 1114643534 Q * Jani Quit: 1114644400 Q * ThorstenG Quit: Leaving 1114644940 Q * kjo Quit: Verlassend 1114645445 Q * prae Quit: Pwet