1 |
Frank Steinmetzger wrote: |
2 |
> On Sun, Nov 10, 2013 at 04:07:34PM -0600, Dale wrote: |
3 |
> |
4 |
>>>> I have noticed something that really bugs me. I sometimes have a few |
5 |
>>>> Firefox sessions running. I do this because I have to be logged into a |
6 |
>>>> website with more than one user/password. Here is my issue. If I |
7 |
click |
8 |
>>>> the X box to close a session of Firefox, it doesn't seem to kill the |
9 |
>>>> process. [...] |
10 |
> |
11 |
>>> What version of Firefox? What addons (if any) do you use with Firefox? |
12 |
|
13 |
|
14 |
This has been going on for many versions. I'm on firefox-17.0.9 now. |
15 |
|
16 |
|
17 |
> |
18 |
>> Oh good heavens. I have lots of add ons installed. It would take me a |
19 |
>> while to list them all, heck, just to get a list much list post them |
20 |
>> here. |
21 |
> |
22 |
> There’s an addon for that. ;-) |
23 |
> But if you start like that, I would recommend to thin out the list. You |
24 |
> never know what kind of conflicts and other interactions there might be |
25 |
> between addons. We could discuss this in another thread. ;-) |
26 |
|
27 |
Thing is, it does it on a "profile" that doesn't have but a very few add |
28 |
ons installed. This also happens with Seamonkey and other processes. |
29 |
|
30 |
|
31 |
> |
32 |
>> lol I recall abduction, tab utilities, last pass off the top of |
33 |
>> my head. However, I have a test session that has very very few add ons |
34 |
>> and it does the same way. |
35 |
> |
36 |
> With session you mean firefox profile? I know of no other way of having |
37 |
> different sets of addons simultaneously (short of Walter’s idea of using |
38 |
> different unix users). |
39 |
|
40 |
Yes, I keep getting the two confused. One of these days. ;-) Just |
41 |
when I do get the name of something straight, they change it. :-p |
42 |
|
43 |
|
44 |
> |
45 |
> |
46 |
>> Also, I run into this with other processes as well. It seems to me |
47 |
>> that some package or the kernel is not killing processes as it should. |
48 |
>> I just don't know what that is. |
49 |
> |
50 |
> What processes? If it’s Seamonkey which you mentioned elsewhere, it may |
51 |
> be the same problem/cause. |
52 |
> You could possibly identify the perpetrating process by looking at its |
53 |
> memory footprint. A process that is close to terminating would use much |
54 |
> less memory than a fully running process with tabs. |
55 |
> |
56 |
|
57 |
That is my thinking too. See below. |
58 |
|
59 |
>> It could even be a KDE bug. |
60 |
> |
61 |
> I don’t really think so. You click the X, the window manager notifies |
62 |
> the program in the window to quit. The program destroys its X client, |
63 |
> KWin processes that event and poof. Nothing more KDE can do (IMHO). |
64 |
|
65 |
Thing is, the common thing to all the issues, kdeinit4 process. The |
66 |
tree looks like this. The init process #1, kdeinit4 then other |
67 |
processes that have this issue. Be it Firefox, Seamonkey and the other |
68 |
stuff. |
69 |
|
70 |
|
71 |
> |
72 |
>> I know when I go to boot runlevel, I have to kill quite a few |
73 |
>> processes that are pretty stubborn to kill. kill -15 usually doesn't |
74 |
>> work so I end up using -9 to get it to die. |
75 |
> |
76 |
> If you go to *that* length (switch to boot and kill processes manually), |
77 |
> why not do the *cough* Ubuntu way and simply reboot, since killing X |
78 |
> means killing most of your environment of running applications anyway? |
79 |
|
80 |
I don't reboot to much. Bad experiences with Mandrake. Everything |
81 |
works fine, then reboot and it's busted. You may not really want to |
82 |
ask. ;-) |
83 |
|
84 |
I just finished a complete recompile. It may not help but I wanted to |
85 |
try it anyway, just in case. I have had that fix some pretty weird |
86 |
issues in the past. |
87 |
|
88 |
Thanks. |
89 |
|
90 |
Dale |
91 |
|
92 |
:-) :-) |
93 |
|
94 |
-- |
95 |
I am only responsible for what I said ... Not for what you understood or |
96 |
how you interpreted my words! |