Certain applications become unresponsive when a file is saved to the hard drive

For a long time I’m experiencing a very bizarre issue on my system, primarily involving three applications. The problem affects Firefox, Thunderbird, and Pidgin. What happens is that, after any of those programs are left running for a while, they become unresponsive for 5 - 30 seconds whenever a file is created or saved on my hard drive by some programs. I initially noticed that those 3 applications become unresponsive when I save an image from Firefox… but later I saw that saving a file in Kwrite for the first time also causes it. Closing and restarting either of the programs makes the issue stop happening to it… until a few hour(s) later when it begins again. An important clue I noticed in the System Monitor is that while unresponsive, both Firefox Thunderbird and Pidgin use 13% CPU, and after they become responsive again they go back to normal. Their icons in the system tray (KDE) also become invisible while they’re unresponsive.

How can saving an image from Firefox or a text file in Kwrite cause those specific applications to become stuck for nearly half a minute each time? What could possibly trigger it and how can they relate? Is this due to a known bug or some hard drive / memory problem, and is there a solution?

I haven’t experienced this, but a good place to start might be to consider the advice given here

Firefox hangs or is not responding - How to fix | Firefox Help

and also examine

Help>Troubleshooting Information

On 2013-01-05 12:26, MirceaKitsune wrote:
> How can saving an image from Firefox or a text file in Kwrite cause
> those specific applications to become stuck for nearly half a minute
> each time? What could possibly trigger it and how can they relate? Is
> this due to a known bug or some hard drive / memory problem, and is
> there a solution?

Is your system using swap?

Is your disk going to sleep?

Check your disk for errors (use smartctl). They would show in the
messages log, too, while you try to write.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

I have 9GB of triple-channel RAM and a 2GB swap partition. SMART doesn’t report any errors on the drive at boot, nor did I ever experience file read / write errors in any other form.

Something else that’s important which I foolishly forgot to mention: This happens both on my main PC and laptop, which means it’s certainly not a hardware issue. I did however port many configuration settings from one to the other.

Open a terminal and login as root with su -. What is the output of the commands below? Please be careful to type them correctly.


cat /sys/block/sda/queue/read_ahead_kb
cat /proc/sys/vm/dirty_writeback_centisecs
hdparm -B /dev/sda

Then log out using exit. Expected values are:
read_ahead_kb 128
dirty_writeback_centisecs 500
hdparm 254

If these values are correct then it might just be an issue with firefox. I think it is possible if the hdparm value is low, your disk is spinning down and upon saving a file it needs to spin up again and commit i/o.

On 01/05/2013 03:56 PM, MirceaKitsune wrote:
> I did however port many configuration settings
> from one to the other.

try using yast to add a new test user…and see if the same problems
show up “after any of those programs are left running for a while”

so, you will need to commit to using that test user in the same kind
of ways you now use your own user…i’m not exactly sure how to do that
with all three of the named problem programs: firefox and pigdin
shouldn’t be too hard, but TB might be…


dd

On 2013-01-05 15:56, MirceaKitsune wrote:

> I have 9GB of triple-channel RAM and a 2GB swap partition. SMART
> doesn’t report any errors on the drive at boot, nor did I ever
> experience file read / write errors in any other form.

No, you have to run the long smart test to be sure.
If there are currently known errors they would be in the log.

> Something else that’s important which I foolishly forgot to mention:
> This happens both on my main PC and laptop, which means it’s certainly
> not a hardware issue. I did however port many configuration settings
> from one to the other.

I can not imagine what.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

Thought to let everyone know I fixed this problem a few weeks ago. It was caused by another issue with the eSATA chip messing up hard drive functionality, see this thread for more information. I also switched my remaining Windows partitions from NTFS to ext4 which might have contributed as well.

On 01/29/2013 01:36 PM, MirceaKitsune wrote:
>
> Thought to let everyone know I fixed this problem

happy to hear! good on ya!
yep, when using Linux you will get the best service, stability, speed
etc from Linux file systems…


dd
openSUSE®, the “German Engineered Automobile” of operating systems!

Indeed. I used NTFS on data partitions cuz I was switching from Windows. Once I got rid of Win I could change all to ext4, and they started working faster. NTFS worked too but much slower, and of course had no file / folder permissions. The main problem still was likely the eSATA chip.

On 2013-01-29 16:16, MirceaKitsune wrote:

> Indeed. I used NTFS on data partitions cuz I was switching from
> Windows. Once I got rid of Win I could change all to ext4, and they
> started working faster. NTFS worked too but much slower, and of course
> had no file / folder permissions. The main problem still was likely the
> eSATA chip.

Yes, NTFS is very much CPU intensive in Linux, thus slower.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)