[gaf@gaf ~]$ ps -ef | grep firefox
gaf 2734 2259 8 06:31 tty2 00:03:27 /usr/lib64/firefox/firefox
gaf 3143 2734 0 06:32 tty2 00:00:01
/usr/lib64/firefox/plugin-container
/opt/google/talkplugin/libnpgoogletalk.so -greomni
/usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja
-appdir /usr/lib64/firefox/browser 2734 true plugin
On 06/23/2015 08:48 PM, John Abreau wrote:
I just checked three different machines firefox (Fedora 22, CentOS 6.5, and
MacOS Snow Leopard).
All three have an active firefox browser running, but none show a running
process named "plugin-container", nor any process with a name containing
the string "plug" There are also no processes whose parent PPID is the
firefox process.
All three instances are running a number of plugins.
Shouldn't plugin-container be running if firefox is running?
On Tue, Jun 23, 2015 at 12:17 PM, Steve Litt <sl...@troubleshooters.com>
wrote:
On Tue, 23 Jun 2015 11:38:30 -0400
Matthew Gillen <m...@mattgillen.net> wrote:
On 06/23/2015 10:18 AM, John Abreau wrote:
A bit of googling turned up a page about using cgroups to limit
firefox's memory usage.
http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html
ulimit, and prlimit could do the trick I suppose, but the hard-limits
there would be quite a bit of use-case-specific tuning.
CGroups are much closer to what I want, but not for the rogue
processes: I think making a cgroup for core processes and setting
their swappiness to zero actually gets me closer to what I'm looking
for.
What I really wanted was the rogue process to pay the cost of memory
access, instead of spreading that pain throughout the system. But
CGroups gets me close I think:
According to this:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-memory.html
you can create a group, and set swappiness and oom-killer eligibility
for that group. So ideally I would put certain critical things needed
for recovery (e.g. ssh daemon, agetty, maybe even the window manager;
any process that allows me to find and kill what I need to help the
system recover) in a group that would effectively exempt them from the
thrashing.
HOWEVER, there is still a problem. For instance, my current system
doesn't actually launch an 'agetty' (login) process on the virtual
terminals until you switch to them. That means you need some
'reserved' memory, which my quick reading of cgroups doesn't seem to
allow you to do. I'd be happy if there were just a small amount of
memory reserved, enough to:
- launch agetty and login
- launch root's login shell
- run killall eclipse
Wait a minute. Once upon a time I had a daemon for almost this same use
case, but it was for rogue dbus-daemons instead of rogue eclipses or
rogue firefoxes.
It doesn't even need to be a daemon. You could run it every 5 seconds
with cron, and if twice in a row it shows evidence of a rogue eclipse,
it killalls eclipse. Same with firefox, etc. With firefox, I'd
recommend killall plugin-container first, because that's the usual
subject, and you can keep your windows so you know which to bookmark.
To do this, you need the following:
* A command to define runaway eclipse. Probably some sort of parsed ps
command.
* A file to store the last value of Eclipse's "runaway value", so you
can tell whether it's two in a row.
* A script to combine the preceding with a killall
* Connecting the preceding script to cron. Every 5 seconds ought to do
it.
HTH,
SteveT
Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
--
Jerry Feldman <g...@blu.org>
Boston Linux and Unix
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B 8DC6 24D7 000F B7F1 4F2F
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
