Just to add my 2-cents worth: Linux in general will halt the boot process when it finds an error on the filesystem...ANY of them that are in the fstab & set to auto-mount at boot-time.
For example: I implement backup to disk on most of my servers, but don't want a re-boot halted due to an error on the backup drive, so I don't list the drive as auto-mounted in fstab... instead,I run fsck & mount the drive at the END of the boot process - well after the main services have been started. That way the server can re boot even without a backup drive! But you indicated that fsck fixed items on your root fs... No way around that--that definitely requires admin intervention to continue...boots on the ground, so to speak. Dan IT4SOHO Sergio M <sergio...@gmail.com> wrote: >El -10/01/37 16:59, Jake Vickers escribió: >> On 07/07/2011 11:47 AM, Sergio M wrote: >>> Hi there list. >>> Yesterday I had this weird problem with my QMT box. First, the SMTP and >>> POP3 >>> services stopped to answer. So I ssh'ed in and made a qmailctl stat. >>> Every service looked like this: >>> supervise: fatal: unable to acquire log/supervise/lock: read-only file >>> system >>> >>> So I tried to qmailctl stop and start, but neither of them worked. I >>> decided >>> to reboot. And then I lost connection to the box. >>> After I made it to the datacenter, i found out that it was stuck in the >>> boot >>> sequence, waiting for the root password to be entered to make a manual fsck. >>> I entered passwd, ran 'fsck /' and it fixed some inodes and stuff. It >>> finished booted and everything went to normal. I forced a fsck with >>> 'shutdown >>> -Fr now' and found nothing. >>> >>> So the questions: >>> 1. I found nothing about thise read-only error on the archives. Anyone has >>> any ideas of what might have happened or where to look for possible causes? >>> 2. Is there a way to configure CentOS to do this fsck on boot completely >>> unattended? So that it it reboots again there is no need to go to the NOC >>> to >>> enter root password and run the fsck manually? >>> >> >> This is not QMT specific. >> Look in your messages file for for medium errors - what most likely happened >> is that there were some bad sectors on the disk, which ended up timing out >> and >> causing the system to mount it read only. >> As far as automtically doing this on a boot (when needed), yes and no. Yes >> if >> the system is not in too bad of shape - no if the system is bricked. >> In your /etc/fstab file, the fifth column is your dump options, and the >> sixth >> column your filesystem check options. Dump is for backups, so you can >> ignore. >> The sixth column for the filesystem check - that's the one you want. When >> the >> system boots up, it determines what order to do a filesystem check (if >> neede) >> by the number in the sixth column. If it's a zero, it is not checked, and if >> there was an error on that system is will be unmounted or read only when the >> system boots up. I normally use a "1" for my root filesystem to get that >> checked first, but that's my option. >> >Ok, thank you Jake. > >I will clone the HDD in a new one just to be sure and leave the old one aside. > >Thanks! >-Sergio > > >--------------------------------------------------------------------------------- >Qmailtoaster is sponsored by Vickers Consulting Group >(www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! >--------------------------------------------------------------------------------- > Please visit qmailtoaster.com for the latest news, updates, and packages. > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
