On Fri, 31 Mar, Philippe De Ryck wrote:
On Thu, 2006-03-30 at 23:19 +0100, N.Pauli wrote:
On Thu, 30 Mar, Philippe De Ryck wrote:
On Thu, 2006-03-30 at 11:45 +0100, N.Pauli wrote:
Dear All,
All of a sudden my machine has become incredibly slow to boot up and to launch anything - boot up took over 5 minutes and launching an app like Mozilla or OpenOffice can take just as long. All the
while
the harddisk drive light is burning constantly. It is as if there is some process that never completes, takes a long time to time out and restarts itself whenever I launch an app. Once I'm in, apps
seem
to run fairly normally. I've looked at 'top' and can't see any culprit there. I had this happen once before and it was solved by making sure that nothing was plugged in to a usb port while booting
up or
even logging on. The last significant things I have done prior to this happening do a normal update and upgrade using Synaptic and install Liferea.
Can anybody give me any clues on where I can start looking to resolve this? The machine is a 1100 Mhz Intel Celeron with 256 Mb RAM so it shouldn't be struggling. I'm running Debian GNU/Linux testing
/ unstable and the 2.6.12-1-386 kernel.
Just an idea, but you might look into HDD-trouble. See what "hdparm
-tT /dev/..." says. See what "smartctl -a /dev/..." says (good
explanation can be found here:
http://www.linuxjournal.com/article/6983).
Maybe a monitor for disk activity can be useful too (gkrellm for example
shows activity and speed).
Good luck
Philippe De Ryck
Philippe,
That article on SMART Control was worth the price of admission alone! I'm going to run the short test over night and see if that brings up anything because all the other signs are healthy - yet the disk
hangs for minutes on end at the slightest provocation. I tried to run the short (2 minute) test during the day but gave up after 40 minutes.
Nigel
Nigel,
I found the article very useful too!
You say your disk hangs but all the attributes indicate a healthy disk.
One way to know this for sure is to put your disk in another machine. If
it works fine, you can exclude the disk. If it still hangs, you probably
know for sure that the disk (or the content) is screwed.
I've had some bad experience with an NVIDIA nforce2 chipset (incredibly
slow) but since you haven't changed anything important on your setup,
that wouldn't be the case. It might be another component that's failing.
What does 'hdparm -tT /dev/hda' say? Are the speeds reasonable?
Thanks for the suggestion, Philippe. Here's the output:
**
debianoak:/home/nbp# hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1192 MB in 2.00 seconds = 595.20 MB/sec
Timing buffered disk reads: 6 MB in 3.24 seconds = 1.85 MB/sec
**
That looks reasonable to me - very fast from the cache and a lot slower when it has to be buffered (on the hard drive, presumably). But, what do I know!?
Following up Listrcv's suggestion I had a good look in /var/logs/syslog and it looks as if it may be something to do with gconf2 being upgraded. This is from my notes:
################################################################################################################
# According to Synaptic's history, at 12:19 on 29/03/06 the following upgrades happened:
# gconf2 (2.12.1-9) to 2.12.1-12
# gconf2-common (2.12.1-9) to 2.12.1-12
# These are the lines from syslog that bracket that time.
################################################################################################################
Mar 29 11:34:01 localhost -- MARK --
Mar 29 11:39:01 localhost /USR/SBIN/CRON[7813]: (root) CMD ( [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Mar 29 11:54:01 localhost -- MARK --
Mar 29 12:09:01 localhost /USR/SBIN/CRON[8549]: (root) CMD ( [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Mar 29 12:17:01 localhost /USR/SBIN/CRON[8753]: (root) CMD ( run-parts --report /etc/cron.hourly)
Mar 29 12:34:01 localhost -- MARK --
Mar 29 12:35:15 localhost gconfd (root-9209): starting (version 2.12.1), pid 9209 user 'root'
Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address "xml:readwrite:/root/.gconf" to a writable configuration source at position 1
Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at position 4
Mar 29 12:35:45 localhost gconfd (root-9209): GConf server is not in use, shutting down.
Mar 29 12:35:45 localhost gconfd (root-9209): Exiting
Mar 29 12:37:28 localhost init: Trying to re-exec init
Mar 29 12:37:39 localhost init: Trying to re-exec init
Mar 29 12:37:57 localhost gconfd (root-9935): starting (version 2.12.1), pid 9935 user 'root'
Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address "xml:readwrite:/root/.gconf" to a writable configuration source at position 1
Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at position 4
Mar 29 12:38:27 localhost gconfd (root-9935): GConf server is not in use, shutting down.
Mar 29 12:38:27 localhost gconfd (root-9935): Exiting
#
#
# Carried on in this vein FOR OVER AN HOUR AND A HALF till...
#
#
Mar 29 14:09:41 localhost gconfd (nbp-16076): GConf server is not in use, shutting down.
Mar 29 14:09:42 localhost gconfd (nbp-16076): Exiting
Mar 29 14:09:46 localhost gconfd (nbp-16156): starting (version 2.12.1), pid 16156 user 'nbp'
Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address "xml:readwrite:/home/nbp/.gconf" to a writable configuration source at position 1
Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at position 4
Mar 29 14:09:53 localhost gconfd (nbp-16156): Resolved address "xml:readwrite:/home/nbp/.gconf" to a writable configuration source at position 0
##################################################
# End of extract from syslog
#################################################
It was after that upgrade that my slowness problems started and gconf began to feature so heavily in syslog.
There seems to be a repeating pattern of resolving an address to do with gconfd first for user root and then user nbp - and making a real meal of it.
Any ideas anyone? I'm going to try and find out more about what gconf does.
Nigel