On Wed, Jan 18, 2023 at 9:09 AM <eshwayri(a)gmail.com> wrote:
That is very useful. You are right; I was assuming a non-attached TTY; however, it could
very well be a closed/re-directed stdout. The NetBackup client does fun things with
stdout/stderr for logging and data transfer. I will run some tests tomorrow to check.
The scenario is quite simple. The NetBackup client runs a pre-script on backup. I use
this pre-script with dump-able databases (oVirt, MythTV, Unifi, etc..) like this to create
the backup file, then the backup program scoops up the generated file(s), and finally the
post script cleans up. The pre-script is just calling:
/usr/bin/engine-backup --mode=backup --file=$outf --log=$outl --scope=all
You are right about output being run earlier, so yes it should have caused problems
earlier? I only tested at the very end. From the code:
do${MODE}
ec="$?"
log "EC: ${ec}"
output "Done."
ec="$?"
log "EC: ${ec}"
The exit code was 0 in the first one, but flipped to 1 after the output line. What I
didn't test was what it looks like right after the earlier output lines. It could be
the case that it gets set to 1, but then gets reset to 0 by the actual backup, before
anything tests for it again (or it's time to exit).
And I had tried a "2>&1 >/dev/null" wrap before, and tried to run it
from cron -- none of which I could get to work either. I will play around some more.
Good luck!
No idea if this is relevant, but see this excerpt from the bash(1) man page:
Note that the order of redirections is significant. For example, the
command
ls > dirlist 2>&1
directs both standard output and standard error to the file dirlist,
while the command
ls 2>&1 > dirlist
directs only the standard output to file dirlist, because the standard
error was duplicated from the standard output before the standard out‐
put was redirected to dirlist.
Best regards,
--
Didi