1343354963 N * Bertl_zZ Bertl 1343354971 M * Bertl back now ... 1343364116 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343366775 J * ghislain ~AQUEOS@adsl1.aqueos.com 1343366798 Q * FireEgl Ping timeout: 480 seconds 1343367094 Q * Wonka Ping timeout: 480 seconds 1343367428 J * FireEgl ~FireEgl@173-25-83-57.client.mchsi.com 1343369019 J * Wonka ~produzier@chaos.in-kiel.de 1343369231 Q * clopez Ping timeout: 480 seconds 1343371601 Q * FireEgl Ping timeout: 480 seconds 1343373746 J * m_ueberall dircproxy4@subjektzentrisch.de 1343374265 J * FireEgl FireEgl@2001:470:e5ad:1:b5c6:b3d3:1f04:fa45 1343374844 Q * ghislain Quit: Leaving. 1343374922 N * BobR_zZ BobR 1343377171 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com 1343377955 M * yang maybe it would be a nice idea to gpg-sign the available patches 1343378361 M * Wonka I wish there was a stable debian vserver kernel with a version of at least 3.1 soon... 1343378387 M * yang yeah me too, there used to be those years back 1343378433 M * yang you can pretty much make util-vserver and kernel a .deb package yourself 1343378496 M * Wonka but I do not want that. 1343378511 M * Wonka rolling kernels myself is too much of a hassle 1343378524 M * Wonka I do that for my personal notebook, and for nothing else. 1343379098 J * kir ~kir@swsoft-msk-nat.sw.ru 1343380059 M * yang well it takes time yes to get everything right, but maybe someone even has a depository of precompiled kernels for DEbian, I just compile my own now 1343380131 M * yang the problem is as it compiles several hours on my HW 1343380199 J * fisted_ ~fisted@xdsl-84-44-147-213.netcologne.de 1343380490 M * Bertl yang: if you need an md5 (or sha2) hash for a patch, just let me know 1343380532 Q * fisted Ping timeout: 480 seconds 1343380541 Q * fisted_ Quit: leaving 1343380542 M * Bertl yang: why several hours? do you compile on arm (and on the target)? 1343380546 J * fisted ~fisted@xdsl-84-44-147-213.netcologne.de 1343380672 M * yang hehe 1343380678 M * yang ATOM, its nearly as bad 1343380704 M * yang well Bertl just tag the patches with gpg signature, that would be best... 1343380744 M * yang i mean I can check the kernel being signed 1343380803 M * yang so yeah whats the MD5SUM of the 2.3.4 ? 1343380996 M * Bertl a5e53c47ddd1fb1013a0e075805c688c patch-3.5-vs2.3.4.diff 1343381062 M * Bertl ATOM isn't that slow, you should consider stripping down the kernel to the actual system requirements, the build should then be done in less than 15 minutes 1343381117 M * Bertl an yes, there are (somewhat) recent kernels prepackaged for debian available 1343381240 M * yang oh 1343381255 M * yang well I am making 3.5 now 1343381288 M * yang I just copied the debian 3.2.1 config and dropped it there 1343381298 M * Bertl that's why it takes ages :) 1343381303 M * yang yeah 1343381317 M * Bertl and in addition gives you a slow kernel :) 1343381348 M * yang oh well...I am not really good in stripping options 1343381371 M * Bertl recent kernels make it somewhat simple actually 1343381413 M * Bertl there is a localmodconfig and localyesconfig build target 1343381414 M * yang last time it took me 4 hours to compile 1343381425 M * Bertl localmodconfig - Update current config disabling modules not loaded 1343381425 M * Bertl localyesconfig - Update current config converting local mods to core 1343381528 P * kir PING 1343381528 1343381592 J * Bl4ckB1rD 4d6f0224@ircip4.mibbit.com 1343381610 M * Bl4ckB1rD hi guys 1343381620 M * yang Bertl: once having a vserver-patched kernel is there an easy step to upgrade to newer kernel versions ? 1343381658 M * Bl4ckB1rD is there any way you can check from host how many file handles each vserver uses ? 1343381674 M * Bl4ckB1rD or maybe total of file handles 1343381687 M * Bl4ckB1rD used in system, since probably it's calculated together ? 1343381742 M * yang Bl4ckB1rD: you could use sth. like "ls -lRa | wc -l" but there are prolly better ways 1343381765 M * Bl4ckB1rD hmm 1343381777 M * yang i mean do you want to count files or ? 1343381785 M * Bl4ckB1rD umm, /proc is the one to be calculated for file handles... 1343381787 M * Bl4ckB1rD nope. 1343381795 M * Bl4ckB1rD file handles used in vserver 1343381836 M * Bl4ckB1rD normally you would get all file handles like this: http://www.pastebin.ca/2175138 1343381965 J * yangchang ~yangchang@175.155.23.73 1343382035 M * Bertl yang: you can patch the diff between the old and the new version (which woul probably reduce the build time for unchanged files) 1343382135 M * yang Bertl: is there a manual for that....an probably I cannot skip 2 or 3 versions of kernel with that ... or can I just apply 3 diffs if the kernel has gone 3 versions up ? 1343382182 M * Bertl well, I doubt there is a manual, but it's rather simple: 1343382221 M * Bertl you create a Linux-VServer patched kernel by unpacking a base kernel version and applying the appropriate Linux-VServer patch 1343382255 M * Bertl if you make a copy of that kernel tree before you start configuring/compiling (can be shallow, e.g. with cp -la) 1343382274 M * Bertl you have something to create a diff against when a new kernel/patch is due 1343382318 M * Bertl i.e. you do the same for the 'new' kernel and then simply run 'diff -NurpP ' 1343382348 M * Bertl as result, you get a patch which is able to convert the into 1343382379 M * Bertl this one you apply on the actual build directory, changing only files modified since 1343382420 M * Bertl assuming the build tree was not cleaned, the kernel will pick up the old config and ask all changed options on 'make oldconfig' 1343382437 M * Bertl after that, the changed files will be recompiled and the kernel/modules linked 1343382571 J * ghislain ~AQUEOS@adsl1.aqueos.com 1343382679 M * yang nice 1343382683 M * yang thanks 1343382774 M * Bertl you're welcome! 1343383302 M * yang yangchang: ! 1343383730 M * Bertl Bl4ckB1rD: there is a file handle accounting in Linux-VServer per guest 1343386475 M * yang would there be a way to trick the system to use /home directory for vserver guests ? The partitioning scheme here is a bit weird 1343386491 M * yang maybe by symlinking /var/lib/vservers into /home ? 1343387133 M * Bertl well, first /var/lib/vservers is not the default location, so it was already changed in your tools (via ./configure) 1343387145 M * Bertl (the default location is /vservers) 1343387180 M * Bertl you can do the same and change the path to /home in general, or set a default, or configure it on a per guest basis 1343387193 M * Bertl (google for 'flower page' to find the config options) 1343387209 M * yang ok 1343387216 M * Bl4ckB1rD anyone heard about kernel runtime switching ? 1343387267 M * Bertl not sure what you're referring to, maybe kexec or ksplice? 1343387339 M * Bl4ckB1rD i was explained that's like when kernel crashes, it crashes but if you use kernel to run kernel, it instantly starts new kernel to continue operation, meaning you dont even have to reboot when kernel panic happens 1343387370 M * Bertl that'd be kexec with a so called 'dump kernel', yes 1343387390 M * Bl4ckB1rD prob 2.4 can do it too, but i dont know if 2.4 support kernel run-time switching 1343387399 M * yang Bertl: Do you know the reason why was vserver-kernel dropped out of debian ? 1343387404 M * Bl4ckB1rD u just make a linux that manage all ur other linuxses 1343387407 M * Bertl usually that is used to write a kernel dump to disc, but of course, you can use it to boot the very same kernel as dump kernel 1343387442 M * Bl4ckB1rD hmm 1343387449 M * Bl4ckB1rD that would be like kernel redundancy ? 1343387460 M * Bertl yang: I presume political reasons and the general bad attitude of the debian Linux-VServer maintainer 1343387486 M * Bertl Bl4ckB1rD: well, it's not redundancy, it is like a quick boot from memory bypassing bios and simila 1343387489 M * Bertl +r 1343387495 M * Bl4ckB1rD true 1343387501 M * Bl4ckB1rD but it actually can help 1343387504 M * Bl4ckB1rD ? 1343387509 M * Bl4ckB1rD would it crash vservers ? 1343387522 M * Bertl yes, they are gone like everyhting else (like on a boot) 1343387552 M * Bl4ckB1rD oh crap 1343387559 M * Bertl but you save a lot of the (re)boot time and you can access the kernel crash dump 1343387561 M * Bl4ckB1rD that's same shit then as if i rebooted the machine 1343387561 M * Bl4ckB1rD -.- 1343387569 M * Bertl basically, yes 1343387570 M * Bl4ckB1rD hmm 1343387574 M * Bl4ckB1rD kernel crash dump ? 1343387578 M * Bl4ckB1rD meaning i can get it 1343387581 M * Bl4ckB1rD if it happens 1343387582 M * Bl4ckB1rD ? 1343387582 M * yang Bertl: there is a so-called failover feature too, like if the first kernel fails to boot, that secondary can boot on second try, however I never managed it working 1343387600 M * Bertl Bl4ckB1rD: yep, that's the primary purpose of kexec and crash dump kernels 1343387601 M * Bl4ckB1rD would i get dmesg too then ? when crash happened ? 1343387609 M * yang I am not sure if hardware recognisez faulty boot if it ends into kernel panic 1343387625 M * Bertl yang: that is usually a bootloader feature (grub and lilo can do that) 1343387631 M * Bl4ckB1rD if i ran dmesg , i would get whole info about the crash right ? 1343387663 M * Bertl not via dmesg, but via a special kernel buffer which is accessible in the kexeced kernel 1343387674 M * Bl4ckB1rD hmm 1343387683 M * Bl4ckB1rD but 1343387688 M * Bl4ckB1rD if it execed new kernel 1343387690 M * Bl4ckB1rD that would mean 1343387696 M * Bl4ckB1rD all boot procedure would be skipped 1343387697 M * Bl4ckB1rD right ? 1343387704 M * Bl4ckB1rD meaning none of the vservers would come back 1343387705 M * Bl4ckB1rD etc... 1343387713 M * Bl4ckB1rD leaving my machine wiped out 1343387714 M * Bl4ckB1rD :D 1343387729 M * Bertl everything the bios does will be skipped, everything the kernel does and of course the init system does is executed normally 1343387747 M * Bertl although most init systems can handle the crashdump case to save the data 1343387853 Q * ensc|w_ Remote host closed the connection 1343387862 J * ensc|w ~ensc@www.sigma-chemnitz.de 1343388028 M * Bl4ckB1rD hmm 1343388139 M * Bertl so, yes, you can consider it like a fast boot with the benefit that you have access to the crashed kernel data 1343388159 M * Bl4ckB1rD okay that's not exactly what i was expecting but still better than nothing 1343388160 M * Bl4ckB1rD ... 1343388214 M * Bl4ckB1rD what about io operations ? 1343388217 M * Bl4ckB1rD for example 1343388241 M * Bl4ckB1rD if kernel crashed, would new kexeced kernel have still info about previous io buffers ? 1343388248 M * Bl4ckB1rD previos kernel's io buffers 1343388251 M * Bertl nope 1343388264 M * Bl4ckB1rD so that mysql databases in replication wouldn't loose part of transaction going on ? 1343388267 M * Bertl well, in theory you coul save/access them of course 1343388271 M * Bertl *could 1343388286 M * Bertl but that's not really something of interest to the kexec folks 1343388301 M * Bl4ckB1rD i'm sure of that :) 1343388308 M * Bl4ckB1rD i'm just trying to figure out 1343388314 M * Bl4ckB1rD why my kernels crash from time to time 1343388319 M * Bl4ckB1rD and it's not like 1343388322 Q * BenG Quit: I Leave 1343388329 M * Bl4ckB1rD some problem with hardware or something 1343388333 M * Bertl for that, you should get a serial console :) 1343388351 M * Bl4ckB1rD yes but that wont help me. even if i get the problem... what then ? 1343388355 M * Bl4ckB1rD if i get the crash 1343388370 M * Bertl you report it here and we have a look at it (for free :) 1343388398 M * Bl4ckB1rD u are too kind. 1343388405 M * Bl4ckB1rD but basically 1343388419 M * Bl4ckB1rD if it's kernel problem, which probably is with kernel panic's right ? 1343388426 M * Bertl yes 1343388436 M * Bl4ckB1rD the only solution to it is, to have new kernel without the "bug" 1343388454 M * Bl4ckB1rD meaning... it's same thing i already done like thousand times 1343388459 M * Bl4ckB1rD putting up new kernel 1343388464 M * Bertl well, no, a hardware problem will immediately lead to a 'kernel problem' as well 1343388466 M * Bl4ckB1rD booting machine with it 1343388478 M * Bl4ckB1rD and same thing in the end. 1343388487 M * Bl4ckB1rD the main problem is, it can't be reproduced 1343388495 M * Bl4ckB1rD you need to wait for let's say 150 days 1343388495 M * Bertl so, of course, the kernel panic is a kernel problem, but it might very well be triggered by hardware 1343388497 M * Bl4ckB1rD then it crashes 1343388505 M * Bl4ckB1rD depending how much system is working 1343388514 M * Bl4ckB1rD sometimes if system works more, crash happens in 100 days 1343388526 M * Bl4ckB1rD but when it's not working that much, this period extends 1343388529 M * Bertl with a crash every 150 days, I'd simply prepare a working/new kernel every week and if the crash happens, simply update 1343388676 M * Bl4ckB1rD u are trying to say to boot every crash new kernel until it stops happening or what ? 1343388696 M * Bertl after 150 days your kernel is not really secure anymore 1343388710 M * Bertl so, the update helps in several ways 1343388719 M * Bl4ckB1rD we are not aiming that much for security more for stability 1343388727 M * Bl4ckB1rD if i had kernel that totally suits our needs 1343388730 M * Bl4ckB1rD and is really stable 1343388734 M * Bl4ckB1rD i would never change it 1343388735 M * Bl4ckB1rD simple 1343388741 M * Bl4ckB1rD unless i needed new feature 1343388749 M * Bl4ckB1rD this is backend servers... 1343388764 M * Bl4ckB1rD they dont need security at all , everything firewalled, no access to it unless vpn 1343388773 M * Bl4ckB1rD security ain't issue at all. 1343388790 M * Bertl did you try 2.6.22.x then? 1343388801 M * Bl4ckB1rD why is that ? 1343388843 M * Bertl well, that was a good kernel IMHO 1343388858 M * Bl4ckB1rD stable ? 1343388878 M * Bl4ckB1rD hmm 1343388915 M * Bertl 13:34:27 up 996 days, 13:49 1343388932 M * Bl4ckB1rD ye that's cool but... is it idling ? 1343388934 M * Bl4ckB1rD show load 1343388935 M * Bl4ckB1rD :D 1343388958 M * Bertl it's a Linux-VServer host with 30 guests 1343388981 M * Bertl load average of each of them is roughly 1.5 1343388993 M * Bl4ckB1rD hmmm 1343388997 M * Bl4ckB1rD i have one 1343388999 M * Bl4ckB1rD really good one 1343389005 M * Bertl but it isn't connected to the internet 1343389007 M * Bl4ckB1rD 13:36:14 up 363 days, 22:23, 1 user, load average: 3.86, 3.66, 2.79 1343389017 M * Bl4ckB1rD Linux vs003 2.6.32-28-vserver #55~ppa1-Ubuntu SMP Fri Feb 4 21:25:09 UTC 2011 x86_64 GNU/Linux 1343389023 M * Bl4ckB1rD it's ubuntu vserver kernel 1343389025 M * Bl4ckB1rD really good one 1343389039 M * Bl4ckB1rD but thing is, i already put the very same kernel to the server that crashes... 1343389044 M * Bl4ckB1rD it still crashes. 1343389045 M * Bl4ckB1rD -.- 1343389058 M * Bertl sounds more like a hardware issue then 1343389071 M * Bl4ckB1rD it's true mainly Dell servers crash 1343389072 M * Bl4ckB1rD -.- 1343389078 M * Bl4ckB1rD let me check 1343389084 M * Bertl but 100-150 days uptime between crashes suggests a power supply issue 1343389098 M * Bl4ckB1rD how do you mean ? 1343389104 M * Bl4ckB1rD they have redundant power supply 1343389121 M * Bl4ckB1rD it's kernel crash 1343389122 M * Bertl well, bad hardware should cause a crash within a week or so 1343389124 M * Bl4ckB1rD not like just wipeout 1343389129 M * Bl4ckB1rD and they respond to ping 1343389131 M * Bl4ckB1rD actually 1343389132 M * Bl4ckB1rD -.- 1343389134 M * Bl4ckB1rD hmm 1343389141 M * Bertl but power fluctuations can be tricky 1343389154 M * Bertl the ping is working as long as the nic interrupt is working 1343389155 M * Bl4ckB1rD hmm but basically... if kernel crash happens 1343389167 M * Bl4ckB1rD it shouldnt ping respond 1343389170 M * Bl4ckB1rD right ? 1343389180 M * Bertl no, in 99% of all cases, the ping still works 1343389188 M * Bl4ckB1rD :( 1343389263 M * Bertl but it's a common misconception that the kernel is fine when ping works 1343389516 M * Bl4ckB1rD okay new info worth remembering :) 1343389631 M * Bl4ckB1rD 0.30.216-pre2982-1 these vserver-utils and libvserver fine for 2.6.22 kernel ? 1343389663 M * Bertl the tools should be backwards compatible if configured properly 1343389664 M * Bl4ckB1rD i actually compiled new kernel 3.0 something 1343389682 M * Bl4ckB1rD and it works fine on one server 1343389684 M * Bl4ckB1rD so far 1343389688 M * Bl4ckB1rD i should try it 1343389690 M * Bl4ckB1rD maybe 1343389702 M * Bl4ckB1rD but i'm really thinking it might be problem with some limit 1343389703 M * Bl4ckB1rD like 1343389711 M * Bl4ckB1rD i have ulimit -n 1million 1343389716 Q * bergerx Remote host closed the connection 1343389723 M * Bl4ckB1rD and if some application is leaking file handles 1343389728 M * Bl4ckB1rD it could hop to it 1343389741 M * Bl4ckB1rD and out of file handles can easy lead to kernel crash 1343389747 M * Bl4ckB1rD for longer period 1343389758 M * Bl4ckB1rD that's why i was asking before if there's any way to monitor that 1343389841 M * Bl4ckB1rD one idea was that server is working becouse ping works, but it's really just nic driver issue... and blocks all new connections 1343389882 M * Bl4ckB1rD not really sure, but i'll try the 3.00 kernel and the 2.6.22 one 1343389885 M * Bl4ckB1rD if they are more stable 1343389890 M * Bl4ckB1rD that's what i need for databases 1343389891 M * Bl4ckB1rD nothing else. 1343390029 M * Bl4ckB1rD Bertl what distro is your 2.6.22 kernel ? 1343390112 M * Bertl mandrake 1343390120 M * Bl4ckB1rD ouch 1343390121 M * Bl4ckB1rD lol 1343390122 M * Bl4ckB1rD :D 1343390129 M * Bertl later mandriva, now mageia :) 1343390131 M * Bl4ckB1rD 2.6.22.19 vs2.3.0.34 is flagged as experimental 1343390132 M * Bl4ckB1rD actually 1343390151 M * Bertl there is a stable vs kernel for that mainline version as well 1343390153 M * Bl4ckB1rD 2.6.22.19 vs2.2.0.7 oh wait 1343390154 M * Bl4ckB1rD here is 1343390155 M * Bl4ckB1rD one 1343390183 M * Bl4ckB1rD this is the one you use ? 1343390314 M * Bertl actually I'm running the experimental branch there 1343390341 M * Bl4ckB1rD vs2.3.0.34 one ? 1343390348 M * Bl4ckB1rD i think i need the 2.3 patch 1343390352 M * Bl4ckB1rD since problem is 1343390356 M * Bl4ckB1rD i use dummy0 interfaces 1343390358 M * yang 2.5 hours and still compiling 1343390360 M * Bl4ckB1rD and as far as i remember 1343390371 M * Bl4ckB1rD 2.2 patch doesnt allow dummy interfaces 1343390380 M * Bl4ckB1rD or should i say it doesn't recognise them 1343390485 M * yang hmmm, /proc/cpuinfo displays this CPU as model name : Intel(R) Celeron(R) CPU 220 @ 1.20GHz 1343390487 M * Bertl Linux-VServer doesn't handle dummy devices differently than mainline ... never has and probably never will :) 1343390498 M * yang But when I placed an order it said "atom" CPU 1343390506 M * yang and it seems to be single core... 1343390534 M * Bertl looks like a celeron to me :) 1343390539 M * Bl4ckB1rD true 1343390540 M * Bl4ckB1rD :P 1343390546 M * yang so they scammed me 1343390556 M * Bl4ckB1rD looks like really slow one too :P 1343390563 M * yang damn 1343390579 M * Bl4ckB1rD and if you dont see many processor id's 1343390588 M * Bl4ckB1rD you dont have more cores 1343390590 M * Bl4ckB1rD :) 1343390608 J * Defaultti defaultti@kapsi.fi 1343390610 M * Bl4ckB1rD cat /proc/cpuinfo | grep processor | wc -l 1343390614 M * Bl4ckB1rD this should give you number 1343390619 M * Bl4ckB1rD of processors/cores you have 1343390637 M * Bertl (if they are activated) 1343390707 M * yang yeah it says 1 1343390718 M * yang afaik ATOMs are dual cored 1343390737 M * Bl4ckB1rD you have 1 core 1343390741 M * Bl4ckB1rD and it's celeron 1343390744 Q * yangchang Ping timeout: 480 seconds 1343390825 M * Bl4ckB1rD Bertl so... you are trying to say it should be a problem ? 1343390833 M * Bertl besides the fact that this is not a conclusion but mere handwaving (logic is flawed) I agree that it is a celeron:) 1343390874 M * Bertl Bl4ckB1rD: I'm saying that Linux-VServer has nothing to do with dummy devices 1343390947 M * Bl4ckB1rD cflags are supported ? and cgroups ? 1343390965 M * Bertl there are no cgroups in those kernels 1343390986 M * Bl4ckB1rD too old ? 1343390987 M * Bl4ckB1rD -.- 1343391014 M * Bertl yeah, cgroups are a relatively recent mainline 'invention' 1343391096 M * Bl4ckB1rD and bcapabilities? 1343391109 M * Bl4ckB1rD like SYS_ADMIN 1343391118 M * Bl4ckB1rD some vservers just need that 1343391130 M * Bl4ckB1rD and it's really poorly documented on 2.3 what's different from 2.2 -.- 1343391138 M * Bl4ckB1rD cant seem to find any information about it 1343391314 M * Bertl a vserver guest which gets SYS_ADMIN is basically able to take over the host 1343391330 M * Bertl in my experience, there is no real case where it is required 1343391357 M * Bertl anyway, bcapabilities are a mainline feature as well and they are present since the 2.4 kernel series 1343391368 M * Bertl (of course, they got refined over time) 1343391860 M * Bl4ckB1rD yup , but for mounting fuse.something types 1343391867 M * Bl4ckB1rD of network file systems 1343391869 M * Bl4ckB1rD you need that 1343391874 M * Bl4ckB1rD and for loading modules 1343391877 M * Bl4ckB1rD into kernel 1343392022 M * Bertl there is no point in loading kernel modules from inside a guest :) 1343396067 Q * ghislain Quit: Leaving. 1343396334 J * yangchang ~yangchang@175.155.23.73 1343396712 M * Wonka for mounting, BINARY_MOUNT SECURE_MOUNT SECURE_REMOUNT is enough 1343396724 M * Wonka I can say that because I tried it 1343397079 M * Bl4ckB1rD btw, happy sysadmin day guys 1343397569 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com 1343400649 Q * Bl4ckB1rD autokilled: Mail support@oftc.net with questions (2012-07-27 14:50:49) 1343402264 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg 1343402763 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343403122 Q * BenG Quit: I Leave 1343403853 Q * yangchang Quit: Leaving 1343404965 J * bonbons ~bonbons@2001:960:7ab:0:bd7b:7ffc:41e3:4ed1 1343405701 N * Bertl Bertl_oO 1343408447 J * ghislain ~AQUEOS@adsl1.aqueos.com 1343409502 Q * ghislain Quit: Leaving. 1343412102 Q * clopez Quit: Leaving 1343412551 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343412641 Q * clopez Remote host closed the connection 1343413079 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343413511 J * sweil ~stefan@p54AD99AC.dip.t-dialin.net 1343413881 Q * clopez Remote host closed the connection 1343413899 Q * hparker Remote host closed the connection 1343413968 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343414281 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1343416510 Q * clopez Remote host closed the connection 1343420064 Q * hijacker_ Quit: Leaving 1343420521 J * clopez ~clopez@131.29.165.83.dynamic.mundo-r.com 1343424129 Q * fisted Ping timeout: 480 seconds 1343424266 J * fisted ~fisted@xdsl-87-78-11-134.netcologne.de 1343426218 Q * hparker Remote host closed the connection 1343426382 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1343427209 Q * sweil Remote host closed the connection 1343427596 J * Hurga nobody@dslb-088-076-243-249.pools.arcor-ip.net 1343427656 M * Hurga Hello world. Just a quick question... what would be the best recent vserver patch/kernel to use for a production system? 1343428197 J * ghislain ~AQUEOS@adsl1.aqueos.com 1343428345 Q * bonbons Quit: Leaving 1343428750 Q * ghislain Quit: Leaving. 1343428784 P * uNIXplumber Verlassend