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

Reply via email to