Hard drive going into sleep mode

[GreyGeek]

Recently I've begun having problems with my desktop momentarily freezing, then increasingly so, and finally becoming unresponsive.

I've tracked it down to my hard drive going into the sleep mode, causing all applications that access it to freeze.

I set the "spindown_time = 0" in /etc/hdparm.conf:

/dev/sda {
     spindown_time = 0
}

That didn't appear to work so I set it in /etc/rc.local ahead of "exit 0"l:

spindown_time = 0

That didn't appear to work, either.

At the first sign of an app hanging I open a Konsole and issue:

sudo hdparm -S 0 /dev/sda

That always worked, if I could get a Konsole open in time to issue it.

With spindown_time set to zero I began watching to see which app had the problem first.
Nepomuk was usually the first but it going into sleep mode didn't seem to cause a hang. The "sleep" word disappeared fast while watching in KSysGuard, which itself caused no problems.
The apps I use the most are KMail and Chromium. I started KMail and watched it. It behaved ok.
I started Chromium-browser (the latest version from Google). That's when the problems began! (I am making this post using FireFox, which has not caused a spin down, yet.)

Chromium-Browser creates multiple threads, and eventually puts each one of them to sleep. FireFox does not. I've also noticed that while running Chromium-Browser a memory leak causes xorg to consume memory. Xorg was up to 3.5GB out of 6GB yesterday, before the last hangup. It looks like I'll be reverting to the version of Chromium in the repository.

As an old programmer it seems to me that Google's Chromium developers are relying on polling to determine the status of hardware and not interrupts. Either that or they are deliberately sending a "-y" or "-Y" hdparm to my hard disk. That requires root. That I don't like.

[GreyGeek]

It's been about 3 hours since I purged the Chromium-Browser downloaded from the Google Chromium website, deleted /opt/Google/Chromium and installed the version of Chromium in the repository.

So far, there has been no DE hanging, or uncontrolled sleeping. (spindown_time = 0).

[kubicle]

An odd bug indeed.

A few notes:

I set the "spindown_time = 0" in /etc/hdparm.conf:

This should work, but it doesn't really prevent "something" (like laptop-mode-tools) from changing the setting or forcing a spindown (it should prevent automatic spindowns, as long as the setting isn't changed)

That didn't appear to work so I set it in /etc/rc.local ahead of "exit 0"l:
Code:

spindown_time = 0

This won't work, 'spindown_time = 0' isn't a command you can run in rc.local...you could run 'hdparm -S 0 /dev/sda' from rc.local, but this should be unnecessary if you have the setting in hdparm.conf.

[GreyGeek]

An odd bug indeed.
......
This won't work, 'spindown_time = 0' isn't a command you can run in rc.local...you could run 'hdparm -S 0 /dev/sda' from rc.local, but this should be unnecessary if you have the setting in hdparm.conf.

mmm... Never used rc.local before, and I was just using the example pattern in the hdparm.conf file. Thanks for the tip!

BTW, After I uninstalled the Google version of Chromium and replaced it with the repository version Chromium worked fine. Then, this afternoon, there was a huge, 245 app update that moved KDE from 4.10.4 to 4.10.5. Sure enough, it included the version of Chromium which gave me the headaches. I forgot to mention that another symptom of the affliction is that for the first time in 200 years I actually had swap activity! Besides showing Xorg taking 3.2GB of RAM it also showed that 95Mb swap file was used as well. All it takes is about 6 or so Chromium threads to lock the KDE DE up tight, including the mouse and keyboard.

It still torques me that Chromium grabs root and puts my HD to sleep. NO app should presume that right without making a setting available to the user to turn it off.

I'm not going to fight with Chromium any more. I'm moving back to FireFox. With all its "sleeping around" Chromium isn't any faster than FireFox.

[kubicle]

It still torques me that Chromium grabs root and puts my HD to sleep.

I don't really believe it does "grab root". More likely there is a bug in Chromium (your experiences and tests seem to point to Chromium) that causes the system to spindown hard disks. Of course the effects are the same, so you'll probably better off using another browser (at least for the time being)

[GreyGeek]

I don't really believe it does "grab root". ...

One cannot change the spindown_time setting using hdparm without using sudo. Is there another app that allows changing the configuration of /dev/sda without root access?

[GreyGeek]

BTW, another "feature" of that 245 app upgrade of KDE to 10.4.5 is that KDE doesn't read time properly and gives errors when attempting to change it using systemsettings, even if systemsettings is run using kdesudo. KDE now prefers the Eastern Time setting and ignores the time zone settings. (i.e. "Chicago")
When I run Stellarium, for example, I have to go into the configuration and move the time back 5 hours.

IF I use a Konsole and issue

sudo ntpdate north-america.pool.ntp.org

the time displayed in the system tray returns to what it should be in a few moments. But, Stellarium ignores the new setting and stays with the Eastern Time Zone.

Hardware time, as shown by

hwclock -r

is always correct.

KDE 4.10.4 and previous versions NEVER had this problem with the time, and all apps displayed the correct time.

[kubicle]

BTW, another "feature" of that 245 app upgrade of KDE to 10.4.5 is that KDE doesn't read time properly.

You might be suffering from the zic bug ("/etc/localtime is a broken link") which can be worked around until it's fixed. You can check whether the cause is this bug by running 'ls -l /etc/localtime' and posting the output here.

One cannot change the spindown_time setting using hdparm without using sudo. Is there another app that allows changing the configuration of /dev/sda without root access?

Spinning down hard disks requires root access by default, but I don't believe Chromium directly does that (Chromium doesn't have root access unless you start if with them, that's why I don't think it does it directly)...instead there might be a weird bug in Chromium that causes the system (kernel or udev, for example, that do have root access) to spin down hard disks for some reason. This is just speculation, though, I've never used chromium.

[GreyGeek]

You might be suffering from the zic bug ("/etc/localtime is a broken link") which can be worked around until it's fixed. You can check whether the cause is this bug by running 'ls -l /etc/localtime' and posting the output here.

-rw-r--r-- 1 root root 3543 Jul 14 03:49 /etc/localtime

In another thread I documented my timekeeping problem and temporary solution by using
sudo dpkg-reconfigure tzdata

My KDE system tray time is correct, my files have the correct timestamp on them, but what "date -u" and "sudo hwclock -r" shows are five hours on either side of what the system tray shows.

[kubicle]

In another thread I documented my timekeeping problem and temporary solution by using
sudo dpkg-reconfigure tzdata

There are about a dozen threads with this problem, so you were not alone. And reconfiguring tzdata should fix it, to work around issues with the systemsettings time module (making changes may cause the issue to reappear, as the module uses zic) one should choose a timezone that's not a link (choosing US/Central instead of America/Chicago, for example)

My KDE system tray time is correct, my files have the correct timestamp on them, but what "date -u" and "sudo hwclock -r" shows are five hours on either side of what the system tray shows.

date -u will show UTC time, so it should be off by hours equal to your timezone, about hwclock...have you saved system time to hwclock, there's an upstart script in /etc/init/hwclock-save.conf that should run on runlevels 0 and 6 (shutdown and reboot, respectively)

[GreyGeek]

The "date -u" command does indeed show that the clock time is UTC. The "hwclock -r" shows the clock at 5 hours into the future, thus the two command straddle the date shown in the system try, which I am assuming it made by taking the UTC time and subtracting the 5 hours to get CDST. I ran "sudo hwclock -w" and wrote the system time to the hardware clock, which now shows local time. "date -u" still shows UTC time.

[kubicle]

Just for clarification, whether the bios clock is set to UTC or localtime is controlled by the UTC=yes/no variable in /etc/default/rcS. UTC is the recommended default, and you generally don't need to worry about it (the system should be able to handle either setting transparently), basically the only reason to change the default is when you're dual booting with (at least some versions of) windows, which doesn't understand UTC system clock.

'date -u' will always print (what the system thinks is) the UTC time, regardless of what the hardware clock is set at, just like 'date' will print what the system thinks is localtime.

There is/was a bug in KDE systemsettings (the bug is actually in the CLI tool 'zic' that the setting module uses) that affected localtime setup (more details can be found here http://www.kubuntuforums.net/showthr...s-create-a-fix) messing up the KDE tray clock (among other things) into thinking localtime == UTC, because /etc/localtime isn't correctly set up....yours should be good now.