1306806100 M * Bertl_oO off to bed now ... have a good one everyone! 1306806105 N * Bertl_oO Bertl_zZ 1306807257 Q * FireEgl Read error: Connection reset by peer 1306807290 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com 1306814594 J * thierryp ~thierry@home.parmentelat.net 1306816431 J * sannes ~ace@cm-84.209.81.224.getinternet.no 1306819824 Q * thierryp Remote host closed the connection 1306820035 Q * Piet Ping timeout: 480 seconds 1306820269 J * Piet ~Piet__@28IAABWWY.tor-irc.dnsbl.oftc.net 1306822109 J * thierryp ~thierry@home.parmentelat.net 1306822511 Q * thierryp Remote host closed the connection 1306822871 Q * pmjdebru1jn Remote host closed the connection 1306822902 J * ghislain ~AQUEOS@adsl2.aqueos.com 1306823194 Q * Milenco_ Ping timeout: 480 seconds 1306823201 J * pmjdebruijn ~pascal@overlord.pcode.nl 1306824415 M * arekm daniel_hozac: hi, what do you think about adding arping calls to util-vserver, so arps to update neighbour cache will be send for every ip added to guest? 1306824810 M * ard bad idea 1306824817 M * ard better use a hook for that 1306824869 M * ard if you really need the arping, the chances are high that you are doing things a little bit from the main road... 1306824929 M * ard In a hook you can fix it yourself. Actually I would love to have a hook that gets run on interface creation time when f.i. the network namespace already exists. 1306824936 M * arekm bad because? (init script for distros like FC do exactly that for configure IPs) 1306824966 M * ard if you are doing things like l2 failover, any arp is a bad arp 1306825032 M * ard in some of my cases the vservers have fixed mac-addresses... the arp would be send from the wrong network namespace and stuff like that. 1306825064 M * ard It's not bad to send the arp, it's bad to make it a default thing 1306825093 M * ard at the point you do the arp, I would love to do the arp, but just a tiny little bit different :-) 1306825141 M * ard and if you are doing large datacenter setups, you probably want a regular arp to prevent flooding. 1306825156 M * ard I mean a timed arp as well 1306825331 M * ard http://217.196.41.9/public_html/vlarp/ has helped us a lot against flooding 1306826536 J * thierryp ~thierry@zanzibar.inria.fr 1306826966 J * kir ~kir@swsoft-msk-nat.sw.ru 1306827992 M * daniel_hozac Bertl_zZ: http://people.linux-vserver.org/~dhozac/p/k/delta-ipv4src-fix02.diff 1306828226 M * daniel_hozac arekm: sounds sane to me. 1306828572 M * sannes1 daniel_hozac: Does vserver-start directory in util-vserver do anything? Should I implement support for umask in that aswell? 1306828646 M * daniel_hozac no 1306828717 M * daniel_hozac it's unused and hasn't been touched for a long, long time. 1306828761 M * daniel_hozac 6 years to be exact... 1306828766 M * sannes1 Maybe just delete it then :P 1306828779 P * kir Leaving. 1306828782 M * sannes1 but, I should still update configuration.xml ? 1306828789 M * daniel_hozac yes, always. 1306829082 M * sannes1 daniel_hozac: http://www.sannes.org/misc/add_umask_configuration_docs.patch 1306829682 J * petzsch ~markus@dslb-088-075-161-022.pools.arcor-ip.net 1306829771 Q * FireEgl Quit: Leaving... 1306831866 J * FireEgl ~FireEgl@173-16-9-3.client.mchsi.com 1306834580 N * Bertl_zZ Bertl 1306834590 M * Bertl morning folks! 1306834657 M * daniel_hozac morning Bertl 1306834729 M * Bertl regarding the patch, what is the reason behind that? 1306834774 M * daniel_hozac see the mailing list 1306834785 M * daniel_hozac we use the mask to pick the most appropriate source address 1306834799 M * daniel_hozac with a mask of 32, we'll just always use the first IP 1306834908 M * Bertl hmm, so we broke that not too long ago I guess ... okay, will revert that change 1306834931 M * Bertl (i.e. most likely simply apply that patch) 1306835030 M * daniel_hozac yeah, it apparently works fine in 2.6.37 1306835542 M * sannes1 Bertl: This also exposes umask in proc.. http://www.sannes.org/misc/expose_umask_in_proc.patch 1306835966 M * Bertl okay, but what is the idea behind the long long? 1306836308 M * sannes1 Uhm, heh, good question, that was me copy pasting stuff, of course, it should not have a cast, and it should be only one l 1306836352 M * Bertl okay :) 1306836403 M * sannes1 updated the patch 1306836420 M * sannes1 I'll go see if I can find a brownpaper bag to have over my for the rest of the day :P 1306836439 M * Bertl first change the 016 to 08 :) 1306836445 M * sannes1 doh 1306836461 M * sannes1 but, then the formatting will not be like the others? 1306836467 M * sannes1 not that it matters.. *fixing* 1306836479 M * Bertl it will be like the spaces 1306836492 M * Bertl which is more appropriate anyway 1306836544 M * sannes1 :) okay, done 1306837021 M * arekm Bertl: 2.6.38.6, patch-2.6.38.6-vs2.3.0.37-rc15.diff, are you aware of any problems with processes in guest in R state, eating CPU but unkillable? 1306837089 M * Bertl nope 1306837119 M * Bertl can you get a stack trace from those? 1306837250 M * arekm no, these don't show in sysrq-t (I'm looking for process pid in guest in sysrq-t output) 1306837265 M * arekm let me see if gdb can attach to these 1306837285 M * arekm /proc/pid/wchan i 0 1306837315 M * arekm Memory cgroup out of memory: Kill process 22695:#333 (httpd.prefork) score 255 or sacrifice child 1306837320 M * arekm Killed process 22695:#333 (httpd.prefork) total-vm:379016kB, anon-rss:42796kB, file-rss:284kB 1306837360 M * arekm but it still exists in ps aux... (we tried to lower guest memory via cgroup, so OOM would kill the processes for us ... but that failed - process is still there) 1306837401 M * Bertl and you cannot make it dump? 1306837525 M * arekm dump core via SIGSEGV? no 1306837575 M * arekm gdb "Attaching to program: /usr/sbin/httpd.prefork, process 29172 1306837599 M * Bertl what about 'cat /proc/22695/stack' ? 1306837626 M * arekm # cat /proc/22695/stack 1306837627 M * arekm [] 0xffffffffffffffff 1306837664 M * Bertl so it seems that process is already dead 1306837680 M * Bertl does it really consume resources or just hang around? 1306837681 M * arekm http 29172 52.0 1.6 368780 34880 ? RN 10:43 54:08 /usr/sbin/httpd.prefork 1306837730 M * arekm according to few tools it eats resources (cpu usage for it changes for example, 80-99%) 1306837734 M * Bertl does that guest have an init? 1306837761 M * arekm no 1306837787 M * arekm I mean there is "virtual" init, root 1 0.0 0.0 8332 728 ? Ss 08:38 0:04 init [3] 1306837800 M * Bertl so it uses the blend through init, yes? 1306837805 M * arekm but no real init 1306837825 M * Bertl does that init log anything about that process? 1306837844 M * arekm this is fake vserver init, so it doesn't log anything 1306837869 M * Bertl it still will have to reap the processes I guess 1306837978 M * arekm http://pastebin.com/PshzVbqM - pstree shows like this 1306838217 M * Bertl and vkill doesn't affect that process at all? 1306838309 M * arekm vkill - no effect 1306838350 M * Bertl Linux-VServer debugging enabled by any chance? 1306838359 M * arekm netstat shows that this process is still listening on socket 1306838382 M * arekm unfortunately debugging is disabled 1306838438 M * arekm is VSERVER_DEBUG affecting performance or security in any way? (if not then I would enable it by default in distro kernel then) 1306838464 M * arekm hm, help says it is 1306838471 M * Bertl well, as any debugging, there is some overhead involved 1306838749 M * arekm rebooting machine, no other way 1306838810 M * Bertl definitely strange 1306838865 M * arekm this is second server where this problem occured, the other one was a machine with java apps running inside of guests 1306838898 M * Bertl it might make sense to do a test setup then, with debugging enabled 1306838920 M * arekm trying with init style == plain now, will see if that matters 1306839049 M * daniel_hozac sannes1: Bertl: hmm, umask is only 32-bit? 1306839100 M * Bertl it's a long, so it will depend on the arch 1306839101 M * daniel_hozac i thought the kernel was already using 64-bit for the clone flags. 1306839108 M * daniel_hozac regardless of arch :) 1306839131 M * Bertl well, then we should adapt that 1306839257 J * ffrank ~ffrank@g230122085.adsl.alicedsl.de 1306839373 M * ffrank hi. I'm using vserver utils 0.30.216-pre2864-2+b1 and my servers don't seem to use the limit defined in /etc/vservers/$name/rlimits/nofile (set to 8192). instad, all processes in the guest have a hard limit of 1024. how can I debug this? 1306839396 M * daniel_hozac rlimits has nothing to do with ulimits. 1306839411 M * daniel_hozac if you want to change your ulimit, use the ulimits directory instead. 1306839421 M * daniel_hozac (and make sure your guest's configuration won't reset it) 1306839423 M * sannes1 Bertl: Want a patch with that change? 1306839443 M * Bertl ffrank: the rlimits are a total per guest 1306839468 M * Bertl sannes1: if you want to give it a try, why not 1306839477 M * sannes1 Both space and umask then? 1306839489 M * ffrank daniel_hozac: i see, thanks. I was following http://linux-vserver.org/Resource_Limits 1306839510 M * Bertl sannes1: hmm? 1306839522 M * ffrank Bertl: oops - thanks for the hint 1306839582 J * vasko ~vasko@unreal.rainside.sk 1306840695 M * sannes1 Bertl: The vx_umask is just to change output in proc and in the struct vx_info. Then it is uint64_t (since the struct vmc_umask is already uint64_t). All umask related changes are in http://www.sannes.org/misc/vserver_umask_changes.patch 1306840776 M * Bertl yep, looks fine, thanks! 1306842305 M * arekm Bertl: plain style didn't help :/ 1306842343 M * Bertl so if that is easily reproduceable, please enable debugging and see what happens when you send a signal 1306842452 Q * ensc|w Quit: Lost terminal 1306842468 J * ensc|w ~ensc@www.sigma-chemnitz.de 1306842798 M * daniel_hozac arekm: you did try SIGKILL, right? 1306842839 M * arekm daniel_hozac: I did, didn't work. We lowered memory via cgroup for this guest and even OOM told me that it killed this probess but that also didn't work. Process was still there 1306842846 M * arekm in some weird state 1306842962 M * arekm Bertl: debugging is a bit hard, this is production machine 1306842984 M * daniel_hozac was it weird before you used the OOM-trick, or did that make it weird? 1306843016 M * arekm daniel_hozac: it was weird initially and we here tried various ways to kill hanging processes and stop guest - all failed. Ended with machine reboot 1306843076 M * daniel_hozac did you check the scheduler settings for it? /proc//sched? 1306843134 M * daniel_hozac particularly the policy. 1306843172 M * arekm daniel_hozac: no, will do next time 1306845064 M * Bertl arekm: also, is it plain vanilla + Linux-VServer patch or do you incorporate other patches related to scheduling or security? 1306845189 Q * ffrank Quit: Leaving 1306845545 Q * matti Quit: Lost terminal 1306846333 M * arekm Bertl: grsec is there + few smaller patches 1306846355 M * arekm Bertl: but friend says he tested without grsec on other machine and also got the problem 1306847008 M * ghislain re 1306847012 M * ghislain oups sorry 1306849405 M * ghislain i look for a tricky thing. If i share the / partition between all vserver's and hashify it 1306849421 M * ghislain i then want to limit each user so it cannot fill the / partition alone 1306849445 M * ghislain but then i do not want that system files upgraded by packages count in the user's disk limit 1306849466 M * ghislain seems impossible to me, anyone know of a solution to this issue ? 1306849521 M * daniel_hozac that seems impossible, yes. 1306849582 M * ghislain dam it i hit the impossible wall again ^^ 1306849650 M * ghislain i wonder if i can ask the system the list of the files included in packages then remove it from the vseerver xid. seems possible but heavy on ressources 1306849675 M * daniel_hozac well 1306849686 M * daniel_hozac someone could just make a package of large files and circumvent your limit then? 1306849743 M * ghislain yes but i will simply forget about evil genius to cover the basic case of someone installing big JAVA BLOB(tm) in /usr :) 1306849759 M * Bertl ghislain: you would simply need to verify the hash signature of all installed files (on a regular basis) and remove those you know from accounting 1306849788 M * ghislain but you are right this system is easely evaded by creating fake packages 1306849799 M * Bertl (where knowing means that they are certified packages and proper files) 1306849814 M * ghislain bertl: yes certified by the debian key 1306849821 M * Bertl for example 1306849841 M * ghislain interesting challenge for a week end 1306849871 M * ghislain i have right know some problem with disk limits so i am browsing http://linux-vserver.org/Disk_Limits_and_Quota :) 1306849878 M * Bertl well, nowadays I'm not sure it is even worth the time we spent on thinking about that so far ... because disk space is really cheap 1306849911 M * daniel_hozac limits are still good to have. 1306849915 M * Bertl i.e. it is probably a lot easier to give everybody +1G and simply account all the system files as well 1306849945 M * Bertl correct, but not based on allowed and unallowed packages :) 1306850633 M * ghislain right now i give 2gb but yes perhaps i should accoutn the system usage and see if it's worth the trouble 1306850674 M * ghislain they have /var and /home fo the data anyway 1306851596 M * ghislain if i chxid a file does it un-hashify it ? 1306851626 M * daniel_hozac no. 1306851699 M * ghislain ok good knews thx 1306853136 Q * thierryp Remote host closed the connection 1306853190 J * ryker ~Adium@c-76-16-115-27.hsd1.in.comcast.net 1306853251 J * dowdle ~dowdle@scott.coe.montana.edu 1306854253 M * sannes1 hm cgroup + umask is no good it seems .. hm 1306854339 M * sannes1 or, no, no relation, .. okay now I'm confused 1306854465 M * sannes1 aha 1306855322 M * sannes1 Fikk siste brikke på curby! 1306855328 M * sannes1 ops 1306855335 M * sannes1 wrong window :P 1306857861 J * bonbons ~bonbons@2001:960:7ab:0:e9df:886a:9431:2341 1306860594 Q * sannes Ping timeout: 480 seconds 1306860621 J * imcsk8 ~ichavero@148.229.1.11 1306861206 J * DelTree_ ~deplagne@alcorak1.eric.deplagne.name 1306861241 Q * DelTree Read error: Connection reset by peer 1306861659 J * sannes ~ace@cm-84.209.81.224.getinternet.no 1306862926 Q * ncopa Remote host closed the connection 1306863071 M * Bertl time for a nap ... bbl 1306863077 N * Bertl Bertl_zZ 1306866580 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com 1306868320 J * Piet_ ~Piet__@28IAABW6S.tor-irc.dnsbl.oftc.net 1306868661 N * Bertl_zZ Bertl 1306868668 M * Bertl back now ... 1306868716 Q * Piet Ping timeout: 480 seconds 1306872141 Q * MooingLemur Ping timeout: 480 seconds 1306872514 J * MooingLemur ~troy@ipv4.pinchaser.com 1306873232 J * thierryp ~thierry@home.parmentelat.net 1306873271 Q * sannes Remote host closed the connection 1306873780 Q * thierryp Remote host closed the connection 1306874178 Q * bonbons Quit: Leaving 1306877793 Q * BenG Quit: I Leave 1306878277 Q * petzsch Quit: Leaving. 1306879038 J * derjohn_mob aj@88.128.240.18 1306879616 Q * ghislain Quit: Leaving. 1306880101 Q * Piet_ Ping timeout: 480 seconds 1306880688 J * Piet_ ~Piet__@659AABX5O.tor-irc.dnsbl.oftc.net 1306882269 Q * derjohn_mob Ping timeout: 480 seconds 1306882499 J * ksn ~ksn@41.146.192.32 1306882868 Q * dowdle Remote host closed the connection 1306884491 N * ensc Guest2992 1306884501 J * ensc ~irc-ensc@p5DF2F3D6.dip.t-dialin.net 1306884912 Q * Guest2992 Ping timeout: 480 seconds 1306886161 Q * neofutur Remote host closed the connection 1306886163 J * neofutur ~neofutur@xena.ww7.be 1306886165 Q * PowerKe Remote host closed the connection 1306886177 J * PowerKe ~tom@94-226-105-27.access.telenet.be 1306886212 Q * ensc Remote host closed the connection 1306886222 J * ensc ~irc-ensc@p5DF2F3D6.dip.t-dialin.net