similar to: ssh after failing fsck?

I have some large filesystems that are only used for rarely used archived data. Is there any way to specify in fstab or elsewhere that if these have passed their 'time to run fsck' that it could be put in the background and the system could go ahead and boot, mounting them whenever the operation finishes? -- Les Mikesell lesmikesell at gmail.com

From: Les Mikesell Sent: April 21, 2015 09:19 > > Why do you care about running them at the same time when it doesn't > take longer to run them all in parallel? Except I think the root > filesystem normally runs first. So you might want to stagger it vs. > everything else. I am trying to avoid running them at the same time in an effort to avoid 70 minute boot times (which is

Hi, we have CentOS ftp server (vsftpd) which has a lot of users who are writing and reading a lot of small files from/into its own accounts (and other servers - using samba client - are reading these files and putting them into outside database). Since this server is under heavy load its availability is important. >From time to time we "crash" this server (don't ask why ...) but

From: Mark Milhollan Sent: April 21, 2015 05:35 > On Mon, 20 Apr 2015, Hugh E Cruickshank wrote: > > >CentOS 6 > > >From ''man fstab'' ... > > The sixth field, (fs_passno), is used by the fsck(8) > program to determine the order > in which filesystem checks are done at reboot time. > The root filesystem should be >

I recently set up a new system to run backuppc on centOS 5 with the archive stored on a raid1 of 750 gig SATA drives created with 3 members with one specified as "missing". Once a week I add the 3rd partition, let it sync, then remove it. I've had a similar system working for a long time using a firewire drive as the 3rd member, so I don't think the raid setup is the cause

Hello, We are running units in the field that are headless. Sometimes we get units returned that we when we boot them up have some type of filesystem inconsistency that the default preen doesn't fix but running fsck -y does. I want to eliminate the -p (preen option) and always do the -y option anyone know where to make this change? Thanks, -- Stephen Clark *NetWolves* Director of

I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that

Hey folks, I searched the list archives and found this : echo "AUTOFSCK_TIMEOUT=5" > /etc/sysconfig/autofsck echo "AUTOFSCK_DEF_CHECK=yes" >> /etc/sysconfig/autofsck http://lists.centos.org/pipermail/centos/2006-November/029837.html http://lists.centos.org/pipermail/centos/2009-September/thread.html#81934 Will this do all disks? I want to do a reboot of a couple

On 01/07/2015 05:53 AM, Les Mikesell wrote: > > Yes - the unattended fsck fails. In that case, there should be logs indicating the cause of the error when it was detected by the kernel. There's probably something wrong with your controller or other hardware. > Personally, I'd prefer for the > default run to use '-y' in the first place. It's not like I'm

On Tue, Apr 21, 2015 at 11:40 AM, Hugh E Cruickshank <hugh at forsoft.com> wrote: > From: Les Mikesell Sent: April 21, 2015 09:19 >> >> Why do you care about running them at the same time when it doesn't >> take longer to run them all in parallel? Except I think the root >> filesystem normally runs first. So you might want to stagger it vs. >>

On 2015-01-07, Gordon Messmer <gordon.messmer at gmail.com> wrote: > > Of course, the other possibility is simply that you've formatted your > own filesystems, and they have a maximum mount count or a check > interval. If Les is having to run fsck manually, as he wrote in his OP, then this is unlikely to be the cause of the issues he described in that post. There must be

On Tue, Apr 21, 2015 at 11:01 AM, Hugh E Cruickshank <hugh at forsoft.com> wrote: > > > Thanks but changing the order of execution or executing them in > parallel does not help with executing them one per reboot. Why do you care about running them at the same time when it doesn't take longer to run them all in parallel? Except I think the root filesystem normally runs

On Wed, January 7, 2015 10:33 am, Les Mikesell wrote: > On Wed, Jan 7, 2015 at 9:52 AM, Gordon Messmer <gordon.messmer at gmail.com> > wrote: >> >> Every regular file's directory entry on your system is a hard link. >> There's >> nothing particular about links (files) that make a filesystem fragile. > > Agreed, although when there are millions, the

My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags). Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if

Hi there, I am newbie and recently started using btrfs. Now facing a weird problem. FWIW, I am on archlinux, kenel v3.8.0, having Btrfs v0.20-rc1. After an abnormal reboot, getting these errors while boot: systemd.fsck[289]: checking extents systemd.fsck[289]: checking fs roots systemd.fsck[289]: checking root refs systemd.fsck[289]: found 23728128 bytes used err is 0 systemd.fsck[289]: total

On rare occasions I want to run a remote X command (like 'meld' to interactively merge changes in files) and normally 'ssh -Y remote_host' from a terminal in an NX/freenx window that is acting as my desktop to start and any X program subsequently started would open in a new window via X-forwarding - at least when the target is a 5.x host. I don't do it often enough to remember

I have some machines that send ssh commands to a load balancer appliance that is really a pair of machines that can fail over to each other. The ssh keys are set up on both targets, but whenever the active target is changed, ssh issues a warning about a "man-in-the-middle" attack also goes to the log and the console which tends to alarm the operators. Setting the strict host check

On Jan 6, 2015, at 4:28 PM, Fran Garcia <franchu.garcia at gmail.com> wrote: > > On Tue, Jan 6, 2015 at 6:12 PM, Les Mikesell <> wrote: >> I've had a few systems with a lot of RAM and very busy filesystems >> come up with filesystem errors that took a manual 'fsck -y' after what >> should have been a clean reboot. This is particularly annoying on

On Wed, Jan 7, 2015 at 12:10 AM, Keith Keller <kkeller at wombat.san-francisco.ca.us> wrote: > On 2015-01-07, Gordon Messmer <gordon.messmer at gmail.com> wrote: >> >> Of course, the other possibility is simply that you've formatted your >> own filesystems, and they have a maximum mount count or a check >> interval. > > If Les is having to run fsck

Less, You are 100% right. Of course I brought up my eth0 - but, like you said, with no IP. Meanwhile, I brought up eth0.48 with 192.168.48.100. However, until I would bring up eth0 with an IP address (any in the network) I would have no connection. Why? That's what I fail to understand. Boris. On Fri, Jan 23, 2015 at 6:45 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On