Re: Running unattended (ifo FFS thread)
Kevin Day [EMAIL PROTECTED] writes: The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. 'fsck -p || fsck -y' should do the trick. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On Sun, Nov 07, 1999 at 04:57:54PM +0100, Dag-Erling Smorgrav wrote: Kevin Day [EMAIL PROTECTED] writes: The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. 'fsck -p || fsck -y' should do the trick. What about at rc.conf knob, that make /etc/rc use this instead of the normal fsck -p ?? This could be useful for servers at remote sites. Should I submit a PR with a diff ? /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
Quoth [EMAIL PROTECTED]: : : The problem is that 'fsck -py' ignores the 'p' and will fsck every time, : even if it's unneeded. This takes ages for me. I believe I submitted a PR : with a 'fix' to fsck. : : According to the man page, fsck -y and fsck -p are two distincts commands. Here's a patch to fix the man page as well then: *** fsck.8.~1~ Fri Oct 29 11:42:04 1999 --- fsck.8 Fri Oct 29 11:43:30 1999 *** *** 109,115 .Nm with the .Fl p ! option will correct; if it encounters other inconsistencies, it exits with an abnormal return status and an automatic reboot will then fail. For each corrected inconsistency one or more lines will be printed identifying the filesystem on which the correction will take place, --- 109,117 .Nm with the .Fl p ! option will correct, in the absence of the ! .Fl y ! option; if it encounters other inconsistencies, it exits with an abnormal return status and an automatic reboot will then fail. For each corrected inconsistency one or more lines will be printed identifying the filesystem on which the correction will take place, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Running unattended (ifo FFS thread)
On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Running unattended (ifo FFS thread)
On 28-Oct-99 Kevin Day wrote: This means that it generally always gets through the fsck.. Of course if had to delete files then they're gone, but if you value its ability to stay without human intervention its handy. The problem is that 'fsck -py' ignores the 'p' and will fsck every time, even if it's unneeded. This takes ages for me. I believe I submitted a PR with a 'fix' to fsck. Yeah, the machines we have don't get shutdown except for a power failure so that wasn't a problem :) I'll have a look for your PR tho. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Running unattended (ifo FFS thread)
On Thu, 28 Oct 1999, Daniel O'Connor wrote: On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. we do fsck -p || fsck -y This means that it generally always gets through the fsck.. Of course if fsck had to delete files then they're gone, but if you value its ability to stay up without human intervention its handy. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Running unattended (ifo FFS thread)
On Thu, 28 Oct 1999, Daniel O'Connor wrote: On 27-Oct-99 Remy Nonnenmacher wrote: In followup of the FFS thread, I would like to know if there are some recommendations for running unattended machines. For exemple, avoiding the 'run fsck manually' (for exemple, when co-locating a machine far away where it is not possible to get a console login). Well.. (and I know lots of people would say this is stupid) If you are going to run it in isolation, then you can change the inital fsck so that it just assumes yes for all user input in an error condition.. It isn't really clear what else you would do, though. Most people don't know enough to fix things that fsck can't. If it hoses the box, restore from backup. It is what they are for! David scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
