Solved - perhaps somewhat of an anti-climax. I did follow Volker's
method below, unexpectedly all simple scripts creating tgz files worked
via cron. One thing at a time, reverting back to the contents of my
original script, I have discovered that the point of failure is
including the v switch in the tar command. Looks cool running from the
command line, breaks executing via cron (and not relevant or necessary
in that context).
So I've learnt quite a lot from all this, in particular some options for
useful error logging. Consequently I now know that a file I have
recording various passwords is not being backed up, nor is a credentials
file for connecting to a network drive (owned by root, 0400).
Thanks to everyone for their interest and help with this.
Cheers,
Roger
Volker Kuhlmann wrote:
On Fri 11 Apr 2008 08:08:49 NZST +1200, Steve Holdoway wrote:
The gzip and bzip2 (de)compressions are built into tar itself. If this
Are you sure? They never used to be. You always used to have to install
bzip2 before the j option would work.
A decade ago when I compiled gnu stuff for slowlaris (slow to catch up with
decent shell programs) zlib o.e. was optionally needed for compression
support. bzip2 came later. Seeing that tar is a pretty low-level tool which
system operation to some extend depends on, it makes sense not to add a
reliance on being able to exec other binaries. But here's the pudding:
touch file
strace -e trace=process tar -cjf bla.tar.bz2 file
No exec other than for /bin/tar.
No other binary program file access with trace=file either.
On my tar at least the compressions are built in, I guess it's possible that
other distros do it differently.
It still doesn't explain the truncated tar output - if rudiments of a
tar directory listing exist, the compression must have gone at least that
far.
Other thought: check whether app-armor etc kicks in from/for cron (check
syslog).
Roger, please write a script which produces no output and does your backup.
You want to add at the top:
exec >/tmp/stdout.$$
exec 2>/tmp/stderr.$$
ulimit -a
env
Run from shell. Verify there's no output! Then run from cron. Compare files,
esp the stderr. No matter whether you found a workaround, I'd want to know
why it fails.
Volker