3:36 p.m.
The output() function. This line:
printf "%s\n" "${m}"
It will fail if there is no attached TTY, which will set the exit code to 1, which in turn
will trigger the cleanup() function notifying the engine that the backup failed. This
ironically happens when it should be writing "Done." and exiting after a
successful backup. Fix I used was to change it to:
printf "%s\n" "${m}" >> "${LOG}"
You can't assume attached TTY since a lot of people like me want to run this as part
of a pre/post script to an automated backup program.
12:29 a.m.
New subject: Bug in the engine-backup script when no attached TTY -- Easy fix
On Tue, Jan 17, 2023 at 11:37 PM <eshwayri(a)gmail.com> wrote:
The output() function. This line:
printf "%s\n" "${m}"
It will fail if there is no attached TTY,
Are you sure it requires an attached _TTY_? Not merely stdout?
It indeed requires a TTY in certain cases (see readdbpassword) but not
in the common ones.
which will set the exit code to 1, which in turn will trigger the
cleanup() function notifying the engine that the backup failed.
This ironically happens when it should be writing "Done."
Doesn't it use 'output' much earlier, thus failing much earlier? E.g. here:
output "Start of engine-backup with mode '${MODE}'"
and exiting after a successful backup. Fix I used was to change it
to:
printf "%s\n" "${m}" >> "${LOG}"
This is redundant - 'output' already writes to the log.
You can't assume attached TTY
Well, if we want to be able to input passwords safely, we need a tty.
For common cases, we indeed do not, and do not assume it.
We do indeed assume stdout. Almost all 'normal' programs do. E.g.:
$ date >&-
date: write error: Bad file descriptor
$ echo $?
1
When needing to run such programs without stdout, you usually wrap them, e.g.:
$ (date > /dev/null) >&-
$ echo $?
0
since a lot of people like me want to run this as part of a pre/post
script to an automated backup program.
Please clarify your case. If it's a shell script that's calling
engine-backup, can't this script redirect the output? E.g. to
/dev/null, if you never look at it?
If you provide this script directly to some backup program that does
not provide an stdout (meaning, executes it with FD 1 closed), you
indeed have to handle this somehow. I'd personally do this by creating
a trivial one-line wrapper script and point the backup program to the
wrapper.
That said, I'd consider such behavior a bug in the calling backup
program. I'd expect such a program to provide an stdout to the
pre-/post- programs it calls, keep the output sent there, and log it
to its own logs. When things fail, it will be so much easier for the
user to investigate stuff if you can see the engine-backup output in
the caller's log.
(But admit that when I was a sysadmin and used such programs, I always
wrote my own wrappers around them, and not vice-versa. I realize this
isn't always the best choice or even possible).
Hope this helps. If you still think there is a real bug, please
provide more details.
Thanks and best regards,
--
Didi
1:08 a.m.
New subject: Bug in the engine-backup script when no attached TTY -- Easy fix
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.
-Edmond
1:19 a.m.
New subject: Bug in the engine-backup script when no attached TTY -- Easy fix
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
473
days inactive
474
days old
3 comments
2 participants
participants (2)
-
eshwayri＠gmail.com -
Yedidyah Bar David