You wrote: > > On 7 June 2018 at 14:03, Steve Blinkhorn <st...@prd.co.uk> wrote: > > I have a remote server (about to be replaced, but still in service and > > needs to stay that way until a replacement is fully commissioned) that > > has just developed a single bad sector. The result has been that > > automatic backups using rsync have failed, and manual intervention is > > needed. > > > > There are also numerous sleeping processes that refuse to be killed, > > almost all in the 'tstile' state (this is i386 7.0). >>snip<< > > How should I proceed? > > First action might be to add a --exclude to the rsync (or move the > affected file to a different location on the filesystem excluded from > rsync). > > You could work out the affected block and dd zeros to it via the raw > device, but if the system is going away I'd probably not worry about > that. > > Other questions which might affect approach include: > - How long before the new system is deployed > - Do you know if the system would reboot cleanly > - Is the root filesystem clean > > David >
The root filesystem is clean, but /var is not. I'm arranging a new colo provider for the replacement servers after shockingly bad service from Easynet/Interoute (now GTT) - they emailed me today to say they have no record of our having colo space with them, but that they are "progressing internally" our request to replace our servers with new ones, two and a half *months* since we had to remove one after it failed. I am calculating the risks associated with a reboot, and contemplating editing /etc/fstab so that /var and /opt (where the bad sector is) are not fsck'd at reboot. If it drops down to single-user mode I have no way of recovering the situation (no remote console), so for the time being I'm nursing the system along - and to be fair to it it is running normally from a user's point of vie. -- Steve Blinkhorn <st...@prd.co.uk>