On Jul 12, 2005, at 2:18 PM, Greg Troxel wrote:

>
> when doing this, make sure not to mess up /var/chroot/sshd.  I just
> had a machine fail to start ssh since /var/chroot/sshd was owned by me
> instead of root.  So perhaps rsync what you can from /var first to
> /var.new and put something in rc to mv it to /var on startup.
>

good point about the sshd.

And there is IMO an outside chance that doing the fsck won't be a  
permanent fix.  I just put a new drive in my little netbsd server as  
I kept (eventually) getting the same bad set of blocks in /tmp, which  
needed a console user fsck to clean them up each time.  You'd think  
they'd get remapped but either the drive is out of spares(!), or  
something.  I tried a few tricks to write directly to them to try and  
force a drive-level remap, some here may recall this from a few  
months back, but it never really lasted.  Back when I was a student,  
HDs were expensive, and I was using MFM drives, I'd just park a huge  
file on bad spots like this and leave it :)  but that was then.

Anyway for a remote machine that would be hard to have local people  
adjust for you, I like the suggestion about setting up the symlinks  
best so far.

Not that I really know what I'm doing :)  but based on my experience  
getting a fsck run locally might not be as permanent a fix as you  
would hope.  And /var seem probably pretty safe to point somewhere  
that you know is good for writing, unless you are generating  
incredibly huge logfiles.

B