Date: Wed, 21 Apr 2010 10:34:01 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Kill via Cron... Message-ID: <4BCEC689.4030300@infracaninophile.co.uk> In-Reply-To: <003e01cae12d$b9f2b770$2dd82650$@wakefield.sch.uk> References: <002c01cae05e$7eab3ea0$7c01bbe0$@wakefield.sch.uk> <20100420183859.C52D9BE09@bsd118.wpafb.af.mil> <86r5m9yk0q.fsf@red.stonehenge.com> <003e01cae12d$b9f2b770$2dd82650$@wakefield.sch.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21/04/2010 09:36:24, mcoyles wrote:
> I'm actually trying to kill the following in one swep if they've taken more
> than
> 8 hours to complete... :
>
> 39028 ?? Is 0:00.01 /bin/sh -c sh /root/tools/backup/fullbackup.sh
> 39070 ?? I 0:00.04 /usr/bin/perl /root/tools/backup/backuptodisk.pl
> (perl5.8.9)
> 62219 ?? I 0:00.00 sh -c /sbin/dump -0 -auf - /usr | gzip -q >
> /backup/wednesday/usr.dump.gz
> 62220 ?? I 0:00.33 /sbin/dump -0 -auf - /usr (dump)
> 62221 ?? S 0:27.11 gzip -q
> 62222 ?? S 0:03.07 dump: /dev/da0s1e: pass 4: 3.82% done, finished in
> 1:09 at Wed Apr 21 09:48:59 2010 (dump)
> 62223 ?? DL 0:01.80 /sbin/dump -0 -auf - /usr (dump)
> 62224 ?? DL 0:01.79 /sbin/dump -0 -auf - /usr (dump)
> 62225 ?? DL 0:01.81 /sbin/dump -0 -auf - /usr (dump)
>
> Have tried everything suggested thus far but nothing's done it as
> effectively as the original command run at commandline... just trying to
> automate the process by having cron kill at 8am.
Hmmm.... is that because the system needs the resources for its usual
functions after 8am? Or because if it hasn't finished by that time, it
is clearly hung up and never going to finish?
In the first case, I'd suggest simply running the backup at very low
priority by renicing it to a high value -- it will run at usual speed
*unless* there is anything else that wants a CPU timeslice, when it will
be made to wait.
In the second case, fixing whatever is causing the hang would be a
better idea. (Processes that are hung up trying to do IO may not
respond to signals very promptly which could explain some of your
difficulties.) Unless you've got literally terabytes of content or are
trying to write to a ridiculously slow device, and assuming you start
the backup process at midnight, 8h is more than enough to backup most
hard drives. Is your /backup partition on the *same* disk you're
backing up? Or perhaps /backup is on the slave and /usr is on the
master of the same IDE bus? Either of those could cause significant IO
congestion. Other things to check for are filesystem corruption --
you'll need to take the machine down to single user, unmount the
partitions in question and run fsck(8) on them -- or hardware problems
- -- check the system log for any reports of trouble, try installing
smartd and see if it tells you anything interesting. If your disk is
flaking out, then don't try and coddle it along: replace it ASAP. Once
things have got to the state where errors are affecting the OS, for any
modern drive that indicates complete failure is imminent.
Cheers,
Matthew
PS. You'll get better results if you add "-L -C 32" to the dump(1)
command line. Should speed things up nicely as well.
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvOxokACgkQ8Mjk52CukIzwXACggmDSc35Y+r936agwCuihzghT
tIgAmgLemFna0dbuhRsJau5QAQ1lnvo0
=vKgz
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BCEC689.4030300>