On Fri, Dec 04, 2015 at 08:55:21PM +0100, Elmar Stellnberger wrote:
Hi Remi,
Thanks for your quick response; I should have known. How long are the connections kept open by the kernel after the user program has exited (they acutally kept to be there for several, several minutes until I rebooted*; and Firefox was definitely not killed but closed normally)?
I think, sockets in TIME_WAIT state exist by default about 4min (by the standard), but I not really sure. Read /usr/lib/modules/4.3.0-1-ARCH/build/Documentation/networking/ip-sysctl.txt for parameters that control this behavior (install linux-docs package). But I'd say just get over this "issue". About Firefox opening connection, look at browser.newtabpage.directory.* keys in about:config that contain a set of addresses that FF checks by default on startup to enable that live-tile new tab experience. I'm sure there are other controls there...
Could it be that the connections did not go away for so long because I had unplugged the network cable in response to the enduringly high CPU/FAN activity some time after closing the browser?
No.
There may be an explanation for the high fan activity too as I forgot to disable baloo (KDE autoindexing). I still wonder why no nice load was indicated the respective KDE widget and still about the load since my home directory here is almost empty (just 4x mp4, 1x mkv, 2x txt); or does anyone know whether baloo indexes videos? Or may there have been another cause for the enduringly long FAN activity?
There are tons of reasons why FF or KDE can cause high CPu usage and FAN activity, but non of them are security-related... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D