I hosed my main desktop pretty badly a couple days ago, have reconciled myself to bad news and would appreciate some advice. (CentOS 5.3 fully updated but now backed down from kernel 2.6.18-128.7.1.el5 to 2.6.18-128.4.1.el5 just to try that.) The whole debacle began when I was investigating my formerly-weekly backup script to run to completion. The backup is kept on an external USB-connected drive that is mounted and unmounted by the backup script. I have manually mounted it to retrieve a file but it has been months since I did that. I deleted one copy of the backup, as I've done in the past and made a new crontab entry to try the backup again 2 or 3 minutes later. It was still running several hours later, which couldn't possibly be right. Next, I tried clearing the backup on the backup drive and manually copying directories to it. That didn't work too well, either. At some point, I tried to send an email using SeaMonkey and couldn't, because it was unable "to write a temporary copy". I quickly found that that wasn't all it couldn't write, too. I tried restarting KDE, which got nowhere. Almost everything worked O.K. from the command line, the most obvious exception being that I was unable to read any man pages as a non-privileged user until after I had accessed that man page as root. I did an rpm -Va with output redirected to a USB memory dongle. There is stuff missing and mangled but nothing that raised my suspicion. Finally, here is my selinux configuration. [rj at mavis ~]$ ls -l /etc/selinux/config -rw-r--r-- 1 root root 511 Dec 5 2007 /etc/selinux/config [rj at mavis ~]$ cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0 [rj at mavis ~]$ Does anyone have any ideas how I might attack this thing? An epiphany has not been forthcoming. :-(
> I deleted one copy of the backup, as I've done in the past and made a > new crontab entry to try the backup again 2 or 3 minutes later. It was > still running several hours later, which couldn't possibly be right. > Next, I tried clearing the backup on the backup drive and manually > copying directories to it. That didn't work too well, either. At some > point, I tried to send an email using SeaMonkey and couldn't, because it > was unable "to write a temporary copy". I quickly found that that > wasn't all it couldn't write, too.Run df and check the size of /dev. --------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On Fri, Sep 04, 2009 at 11:24:16AM -0500, Robert wrote:> I deleted one copy of the backup, as I've done in the past and made a > new crontab entry to try the backup again 2 or 3 minutes later. It was > still running several hours later, which couldn't possibly be right. > Next, I tried clearing the backup on the backup drive and manually > copying directories to it. That didn't work too well, either. At some > point, I tried to send an email using SeaMonkey and couldn't, because it > was unable "to write a temporary copy". I quickly found that that > wasn't all it couldn't write, too. > > I tried restarting KDE, which got nowhere. Almost everything worked > O.K. from the command line, the most obvious exception being that I was > unable to read any man pages as a non-privileged user until after I had > accessed that man page as root.All symptoms that you've run out of space. Your backup has probably gone to the root disk, not the backup one, and it ended backing up the backup of the backup of the .... Free some space and everything should work OK. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20090904/3142e008/attachment.sig>
Luciano Rocha wrote:> On Fri, Sep 04, 2009 at 11:24:16AM -0500, Robert wrote: > >> I deleted one copy of the backup, as I've done in the past and made a >> new crontab entry to try the backup again 2 or 3 minutes later. It was >> still running several hours later, which couldn't possibly be right. >> Next, I tried clearing the backup on the backup drive and manually >> copying directories to it. That didn't work too well, either. At some >> point, I tried to send an email using SeaMonkey and couldn't, because it >> was unable "to write a temporary copy". I quickly found that that >> wasn't all it couldn't write, too. >> >> I tried restarting KDE, which got nowhere. Almost everything worked >> O.K. from the command line, the most obvious exception being that I was >> unable to read any man pages as a non-privileged user until after I had >> accessed that man page as root. >> > > All symptoms that you've run out of space. Your backup has probably gone > to the root disk, not the backup one, and it ended backing up the backup > of the backup of the .... > > Free some space and everything should work OK. >BINGO! I feel especially bad because I have seen the "out of disk space" problem before but not while trying to nudge a backup. It's nice to sit in front of an old friend rather than this stranger but serious use will come only after I liberate a lot more space. Thanks for your help and the clue by lhecking! Regards, Robert