1254012327 N * Bertl_oO Bertl
1254012330 M * Bertl back now ...
1254012340 M * Bertl zbyniu: thanks for catching that one!
1254013003 Q * Piet Ping timeout: 480 seconds
1254013648 Q * imcsk8 Quit: This computer has gone to sleep
1254013672 J * Piet ~piet@659AACWOC.tor-irc.dnsbl.oftc.net
1254013743 J * imcsk8 ~ichavero@189.155.65.128
1254016720 Q * imcsk8 Quit: This computer has gone to sleep
1254016844 J * derjohn_foo ~aj@e180193126.adsl.alicedsl.de
1254017257 Q * derjohn_mob Ping timeout: 480 seconds
1254017887 M * Bertl off to bed now ... have a good one everyone!
1254017892 N * Bertl Bertl_zZ
1254019266 Q * FireEgl Quit: Leaving...
1254020416 J * saulus_ ~saulus@c150247.adsl.hansenet.de
1254020827 Q * SauLus Ping timeout: 480 seconds
1254020832 N * saulus_ SauLus
1254025050 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com
1254026334 J * blues ~blues@ccw123.neoplus.adsl.tpnet.pl
1254026453 Q * blues_ Ping timeout: 480 seconds
1254030034 Q * Piet Quit: Piet
1254030322 J * Piet ~piet@659AACWQ7.tor-irc.dnsbl.oftc.net
1254040476 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1254047693 N * vServer_User_sleepy vServer_user
1254048093 Q * bonbons Quit: Leaving
1254048868 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1254052573 J * doener_ ~doener@i59F57968.versanet.de
1254052676 Q * doener Ping timeout: 480 seconds
1254054883 N * Bertl_zZ Bertl
1254066250 Q * FloodServ synthon.oftc.net services.oftc.net
1254068004 J * FloodServ services@services.oftc.net
1254069563 J * kernelmadness ~kernelmad@89.169.96.121
1254069617 M * kernelmadness I got very nasty bug. OOM killer kills processes from any vps when memory limit on one vps is reached
1254069656 M * Bertl not necessarily a bug
1254069674 M * kernelmadness But what?
1254069684 M * Bertl i.e. depends on the configuration
1254069778 M * kernelmadness how it can depend on my configuration? I simply set rlimits on one vps with apache, but it kills not only apache. It kills mysql on another vps, and another apache on third
1254069861 M * Bertl well, if you simply set a limit, then, once the limit is reached, the OOM killer is invoked and decides to kill off the application with the most badness value
1254069864 M * isodude OK, so I figured out that chroot.mount and chroot.caps should be set zero in sysctl if you have grsecurity on.
1254069929 M * Bertl kernelmadness: so, what you probably want is to set a soft and hard limit, so that the guest being the bad one gets a high badness value too
1254069980 Q * derjohn_foo Remote host closed the connection
1254069993 M * kernelmadness I set soft and hard limit both 65536(256M)
1254070004 M * daniel_hozac isodude: as the readme says...
1254070025 M * Bertl kernelmadness: what limit and what kernel/patch are we talking about?
1254070030 M * kernelmadness i think oom killer must kill processes only in corresponding context
1254070063 M * kernelmadness Bertl: 2.3.0.36.14-pre8 kernel 2.6.31
1254070067 M * Bertl the OOM killer is something working globally, on a normal configuration you do not want to see it anyways
1254070144 M * Bertl but I would consider a patch restricting OOM kills to guest local processes, when the kill is triggered from a guest process
1254070160 M * Bertl (based on a flag for example)
1254070225 M * isodude daniel_hozac: which readme?
1254070237 M * isodude daniel_hozac: I've been searching mad for this.
1254070252 M * daniel_hozac http://people.linux-vserver.org/~harry/_README_
1254070309 M * kernelmadness Bertl: wtf, OOM killer always MUST work in guest locally because it is absolutely abnormal to kill other guest processes when one guest reaches IT'S OWN limit
1254070366 M * Bertl nope, I disagree ... take the OOM killer on a vanilla/unpatched kernel
1254070373 M * isodude daniel_hozac: nice. maybe something that should be on the wiki :o
1254070377 J * derjohn_mob ~aj@e180193126.adsl.alicedsl.de
1254070409 M * Bertl kernelmadness: let's say, you hit the global memory limit with a bash script, the OOM killer is invoked .. and kills: apache
1254070451 M * Bertl why? because a situation was reached which should never happen and the kernel kills off the process which has the highest badness
1254070465 M * Bertl now let's map that to the guest case:
1254070533 M * kernelmadness ok, look. We have ability to limit guest resources. Guest reached its own resource limit. Why we must kill another guest when he is not guilty?
1254070546 M * Bertl assume we have a guest A being large over the soft limit (because memory was available), now guest B uses some memory (and goes slightly over memory) .. now should we kill off guest B processes or guest A?
1254070595 M * kernelmadness guest A
1254070633 M * Bertl see, but B was the one causing the OOM
1254070660 M * Bertl so, I'm fine with doing what you consider 'expected behaviour' but not unconditionally
1254070745 M * isodude hm
1254070754 M * kernelmadness it is different types of OOM. In my case only 25% of global memory was used, one guest limited to 256M reached its own limit and processes from another guests were killed, but they had no rlimits at all!
1254070809 M * Bertl do you want processes inside the guest to be killed even if enough 'global' memory is available?
1254070966 M * kernelmadness yes. I limited one guest because of buggy rails application. Expected behaviour: local guest processes are killed on reaching memory limit and respawned. Real behaviour: local guest processes killed and respawned but processes from other guests also killed
1254071025 M * isodude daniel_hozac: I'm putting that plus my sysctl-conf on the wiki, is there some reason this havn't been done?
1254071129 M * daniel_hozac you would have to ask harry.
1254071156 M * Bertl kernelmadness: okay, so this is a feature request then (kind of kill off at memory limit), as we usually design for 'overall' optimizations, which is not (yet) implemented ...
1254071175 M * kernelmadness i always thinked that local guest problems must not interfere other guests, because it is one of reasons why virtualization technologies appeared
1254071175 M * Bertl kernelmadness: nevertheless, you could set a ulimit for that process, which would do the very same
1254071193 M * Bertl kernelmadness: Linux-VServer is an isolation technologu
1254071197 M * Bertl *technology
1254071229 M * Bertl on the host, and across the guests its strength is the resource sharing and optimization
1254071252 M * Bertl if you want a virtual machine, KVM is a better choice
1254071269 M * isodude daniel_hozac: I'm guessing that's harry in this channel, am I correct?
1254071298 M * kernelmadness yes, isolation ;) in this case we have no isolation and ability to crash a half of server
1254071315 M * Bertl only with your specific config :)
1254071357 M * Bertl making your hard limit a soft limit, and setting the hard limit to a global 'working' maximum would probably do what you want already
1254071391 M * Bertl except that it would only start killing your guest processes, when the global limit is reached
1254071463 M * Bertl but as I said, sounds to me like something we could add based on a flag or similar, but which requires that this feature is of some interest to the community or alternatively is sponsored (the development)
1254072910 P * vServer_user 
1254073014 M * fback good evening :-)
1254073270 Q * uva Quit: Leaving
1254074644 M * kernelmadness Bertl: in my opinion this is not feature, this is a bug. Reaching limit of guest resources is a local problem, it must not invoke global OOM-killer because the only mission of OOM-killer is to support life of the machine in critical situation when we have no free memory at all
1254074886 M * Bertl well, there is no 'local' OOM killer
1254074968 M * Bertl if you want hard, per guest limits, you have to disable the overcommitment anyways, and then, the limits will apply properly on the allocation
1254075106 M * Bertl but feel free to consider it a bug, and submit a patch to 'fix' it ... as I already said, I'd probably include it with minor modifications as 'feature'
1254075107 M * kernelmadness hmm. I dont understand what means 'disable overcommitment'
1254075139 M * Bertl by default, linux is in overcommit mode, i.e. it operates as if it has unlimmited memory
1254075165 M * Bertl it simply gives out memory to any process asking for it, regardless of the actual availability
1254075184 M * MooingLemur like a modern financial institution :)
1254075191 M * Bertl once that 'virtual' memory is instantiated, it can happen that the memory is not available :)
1254075205 M * Bertl this is the moment where the OOM killer is invoked
1254075300 M * kernelmadness ok..
1254075364 M * fback kernelmadness: it's some kind of memory leak, this RoR application?
1254075439 M * fback Bertl: he should be able to limit memory available for a guest, no?
1254075463 M * kernelmadness fback: yes, RoR. We can't find this f**king leak and only solution we had is to limit guest
1254075482 M * Bertl it would be better to use ulimits for that
1254075514 M * fback I think it's the way our OS guys solved similar problem with leaking java app
1254075545 M * fback they simply limited memory available for that particular guest
1254075683 M * fback I'm not goung to argue if it was best they could do, but it worked :-)
1254076317 M * arekm Bertl: 4 days and still running (2.6.27+vserver without kernel/sched* changes)
1254076496 M * Bertl good, blues didn't try without the 'other' patches, no?
1254076626 M * arekm I use other patches. The only difference is lack of kernel/sched* vserver changes and no grsecurity (note that without grsecurity but with complete vserver patch it did crash)
1254076663 M * Bertl yes, I remember
1254077577 J * geb ~geb@earth.gebura.eu.org
1254077607 J * imcsk8 ~ichavero@189.155.65.128
1254078208 Q * geb Read error: No route to host
1254078211 J * geb ~geb@earth.gebura.eu.org
1254080078 Q * Chlorek Quit: -
1254081059 J * Chlorek ~cokolwiek@c.sed.pl
1254082254 M * kernelmadness tried to use ulimit. Not works because of rails is not using pam
1254082276 M * Bertl  so? maybe use it explicitely then?
1254082314 M * kernelmadness how?
1254082425 M * Bertl just execute ulimit before starting whatever process you want (e.g. in a script)
1254082498 M * Bertl you could also set it for the guest (as upper limit)
1254082508 M * Bertl note: ulimit not rlimit
1254082556 M * kernelmadness hm. How to set it for guest?
1254082626 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html
1254082656 M * Bertl grep for ulimits
1254082714 M * kernelmadness wow. so, why to have rlimits when we have ulimit?
1254082734 M * Bertl because ulimits are per process, while the rlimits are per guest
1254082772 M * Bertl i.e. take the number of file handles: with ulimit at 64, each process can open 64 files
1254082789 M * Bertl while an rlimit of 64, allows all processes in a guest to open 64 in total
1254082838 M * kernelmadness forks are treated without parenting?
1254082856 M * Bertl hmm?
1254082948 M * kernelmadness if we ulimit rss at 64M and one process will consume 60 and its form another 60, fork will be terminated because of sum(60+60=120 > 64) or not?
1254082975 M * Bertl nope, ulimits are per process, so each process is a new game
1254082984 M * kernelmadness ok, thanks
1254083383 M * Bertl np
1254084637 Q * ghislainocfs2 Quit: Leaving.
1254084825 Q * bonbons Quit: Leaving
1254084837 Q * kernelmadness Quit: kernelmadness
1254085543 Q * imcsk8 Quit: This computer has gone to sleep
1254086012 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk
1254086962 Q * larsivi Ping timeout: 480 seconds
1254087124 Q * BenG Quit: I Leave
1254087611 J * superbaloo ~superbalo@LLagny-156-36-2-84.w80-14.abo.wanadoo.fr
1254087614 M * superbaloo Hi there
1254087632 M * superbaloo is it possible to have the /vservers mounted on nfs ?
1254087664 M * superbaloo i'm currently having problems with permissions (or i think so)
1254088644 M * Bertl sure it is possible ... what problems do you see? (and what kernel/patch versions)
1254089268 Q * superbaloo Remote host closed the connection