From: "Laurence Orchard" <laurence@xxxxxxxxxxxxxxx>
Hi all
when trying to access the web through firefox I get an access denyed
error from the proxy server.
I have tried to restart squid as listed below and get the following
errors:-
[root@athlon init.d]# cd /etc/init.d
[root@athlon init.d]# ./squid status
squid dead but pid file exists
squid: ERROR: Could not send signal 0 to process 2828: (3) No such
process
[root@athlon init.d]# ./squid stop
Stopping squid: ./squid: line 84: /var/log/squid/squid.out: Read-only
file system
[FAILED]
[root@athlon init.d]# echo temp > /var/temp
bash: /var/temp: Read-only file system
[root@athlon init.d]# mount
/dev/hda4 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/hdg1 on /usr type ext3 (rw)
/dev/hde3 on /var type ext3 (rw)
/dev/hde1 on /home type ext3 (rw)
/dev/hdf1 on /mnt/hdf type ext3 (rw)
/dev/hdh1 on /tracks type ext3 (rw)
/dev/hda3 on /windows/C type vfat (rw,uid=500,gid=500,umask=000)
/dev/hde2 on /windows/D type ext3 (rw)
/dev/hdg2 on /windows/E type vfat (rw,uid=500,gid=500,umask=000)
/dev/hda5 on /windows/F type vfat (rw,uid=500,gid=500,umask=000)
/dev/hda6 on /windows/G type vfat (rw,uid=500,gid=500,umask=000)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/proc on /var/named/chroot/proc type none (rw,bind)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
//athlon-64/athlon-64(C) on /athlon-64/C type smbfs (0)
automount(pid2195) on /net type autofs
(rw,fd=4,pgrp=2195,minproto=2,maxproto=4)nfsd on /proc/fs/nfsd type nfsd
(rw)
mount obviously sees /var on /dev/hde3 as read-write
on the last reboot I got the following messages in /var/log/messages:-
Feb 17 15:12:31 localhost smartd[2202]: smartd version 5.33
[i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Feb 17 15:12:31 localhost smartd[2202]: Home page is
http://smartmontools.sourceforge.net/
Feb 17 15:12:31 localhost smartd[2202]: Opened configuration
file /etc/smartd.conf
Feb 17 15:12:31 localhost smartd[2202]: Configuration
file /etc/smartd.conf parsed.
Feb 17 15:12:31 localhost smartd[2202]: Device: /dev/hda, opened
Feb 17 15:12:31 localhost smartd[2202]: Device: /dev/hda, not found in
smartd database.
Feb 17 15:12:31 localhost smartd[2202]: Device: /dev/hda, is SMART
capable. Adding to "monitor" list.
Feb 17 15:12:31 localhost smartd[2202]: Device: /dev/hde, opened
Feb 17 15:12:31 localhost smartd[2202]: Device: /dev/hde, found in
smartd database.
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hde, is SMART
capable. Adding to "monitor" list.
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hdf, opened
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hdf, found in
smartd database.
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hdf, is SMART
capable. Adding to "monitor" list.
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hdg, opened
Feb 17 15:12:32 localhost smartd[2202]: Device: /dev/hdg, found in
smartd database.
Feb 17 15:12:33 localhost smartd[2202]: Device: /dev/hdg, is SMART
capable. Adding to "monitor" list.
Feb 17 15:12:33 localhost smartd[2202]: Device: /dev/hdh, opened
Feb 17 15:12:33 localhost smartd[2202]: Device: /dev/hdh, found in
smartd database.
Feb 17 15:12:33 localhost smartd[2202]: Device: /dev/hdh, is SMART
capable. Adding to "monitor" list.
Feb 17 15:12:33 localhost smartd[2202]: Monitoring 5 ATA and 0 SCSI
devices
Feb 17 15:12:33 localhost smartd[2202]: Device: /dev/hde, 1 Currently
unreadable (pending) sectors
Feb 17 15:12:33 localhost smartd[2202]: Sending warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx ...
Feb 17 15:13:36 localhost smartd[2202]: Warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx: successful
Feb 17 15:13:36 localhost smartd[2202]: Device: /dev/hdf, 1 Currently
unreadable (pending) sectors
Feb 17 15:13:36 localhost smartd[2202]: Sending warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx ...
Feb 17 15:14:36 localhost smartd[2202]: Warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx: successful
Feb 17 15:14:36 localhost smartd[2202]: Device: /dev/hdf, 1 Offline
uncorrectable sectors
Feb 17 15:14:36 localhost smartd[2202]: Sending warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx ...
Feb 17 15:15:37 localhost smartd[2202]: Warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx: successful
Feb 17 15:15:37 localhost smartd[2202]: Device: /dev/hdg, 2 Currently
unreadable (pending) sectors
Feb 17 15:15:37 localhost smartd[2202]: Sending warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx ...
Feb 17 15:16:37 localhost smartd[2202]: Warning via mail to
root@xxxxxxxxxxxxxxxxxxxxx: successful
Feb 17 15:16:38 localhost smartd[2621]: smartd has fork()ed into
background mode. New PID=2621.
Feb 17 17:16:38 localhost smartd[2621]: Device: /dev/hde, 1 Currently
unreadable (pending) sectors
Feb 17 17:16:39 localhost smartd[2621]: Device: /dev/hdf, 1 Currently
unreadable (pending) sectors
Feb 17 17:16:39 localhost smartd[2621]: Device: /dev/hdf, 1 Offline
uncorrectable sectors
Feb 17 17:16:39 localhost smartd[2621]: Device: /dev/hdg, 2 Currently
unreadable (pending) sectors
Feb 17 17:46:39 localhost smartd[2621]: Device: /dev/hde, 1 Currently
unreadable (pending) sectors
Feb 17 17:46:39 localhost smartd[2621]: Device: /dev/hdf, 1 Currently
unreadable (pending) sectors
Feb 17 17:46:39 localhost smartd[2621]: Device: /dev/hdf, 1 Offline
uncorrectable sectors
Feb 17 17:46:40 localhost smartd[2621]: Device: /dev/hdg, 2 Currently
unreadable (pending) sectors
My initial suspicion is that you need to hold a decent burial for /dev/hde,
at least. I'd check that cabling is still OK, that the motherboard settings
are still OK. And so forth.
Presuming there are no physical or software changes from your last boot
the above is my best bet. If you changed anything then back off the change.
For example, boot to an earlier known working kernel. If that doesn't work
start checking out the individual disks.
Boot to single user mode. Then see what you can do with an fsck on /dev/hde
through /dev/hdg by hand. If fsck hangs reboot to single user mode and try
something really basic like "fdisk -l /dev/hde". If that fails try the disk
on another machine. It MIGHT be the controller being sick. If you get past
/dev/hde the first time try /dev/hdf and /dev/hdg with this sequence of
actions. If they all pass fsck you might get away with manually mounting
all the disks in your system - one at a time - and performing some strategic
"ls -R" commands to see if the disk can do that much.
However, it surely looks like one of your disks is dead. If I were to bet
on it I'd make a tiny wager it was /dev/hde.
since this last reboot everything seemed to run OK until this morning
the last part of /var/log/messages reads:-
Feb 22 08:01:01 localhost kernel: SMB connection re-established (-5)
Feb 22 08:16:39 localhost smartd[2621]: Device: /dev/hde, 1 Currently
unreadable (pending) sectors
Feb 22 08:16:49 localhost kernel: hdf: irq timeout: status=0xd0 { Busy }
Feb 22 08:16:49 localhost kernel: ide: failed opcode was: 0xb0
Feb 22 08:16:49 localhost smartd[2621]: Device: /dev/hdf, not capable of
SMART self-check
Feb 22 08:17:03 localhost kernel: hdf: irq timeout: status=0xd0 { Busy }
Feb 22 08:17:03 localhost kernel: ide: failed opcode was: 0xb0
Feb 22 08:17:03 localhost smartd[2621]: Device: /dev/hdg, 2 Currently
unreadable (pending) sectors
Feb 22 08:46:38 localhost smartd[2621]: Device: /dev/hde, 1 Currently
unreadable (pending) sectors
Feb 22 08:46:54 localhost kernel: hdf: irq timeout: status=0xd0 { Busy }
Feb 22 08:46:54 localhost kernel: ide: failed opcode was: 0xb0
Feb 22 08:46:55 localhost smartd[2621]: Device: /dev/hdg, 2 Currently
unreadable (pending) sectors
Feb 22 09:01:01 localhost mount.smbfs[2049]:
[2006^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
is it smartd?
That is possible, especially if you can repeat this and smartd was changed
recently.
how can I clear the 'unreadable (pending) sectors'?
I have done a mkfs on /dev/hdf1 &
I have tried running fsck on /dev/hdf1 with the -c -c options but it
finds no errors.
the partition/file system is empty of data.
It seems /dev/hde is the disk that hits problems first. Test it. "mkfs" is
not a particularly smart alternative. Although if that is not an NT based
Windows it might be the right thing to do regardless. Windows 9x is a virus.
Windows ME is a particularly destructive virus. Windows NT variants are
pretty good, until you load "somebody else's software". They are generally
worth keeping if you have good reason, such as "that is where my income is
based." But none of that solves the basic problem. Do /dev/hde and /dev/hdg
successfully fsck to the extent you can? (Boot to Windows to chkdsk the
Windows partitions if you don't simply nuke Windows.) I'd also check the
boot sector ("fdisk -l /dev/hde") for realistic values. Some Windows malware
or crudware may have nastied with the values in the boot sector.
{^_^}
