#2473 Issue `closed`: function has_binary sends misleading “type: foo: not found” messages to the log¶

Labels: support / question, fixed / solved / done

casantos opened issue at 2020-08-06 17:02:¶

ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.4 / Git
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Red Hat Enterprise Linux release 8.1 (Ootpa)
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): KVM Guest
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86_64
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): VirtIO disk
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                                     KNAME      PKNAME    TRAN   TYPE FSTYPE       SIZE MOUNTPOINT
/dev/sr0                                 /dev/sr0             sata   rom  iso9660      7.3G 
/dev/vda                                 /dev/vda                    disk               20G 
|-/dev/vda1                              /dev/vda1  /dev/vda         part vfat          50M /boot/efi
|-/dev/vda2                              /dev/vda2  /dev/vda         part xfs          512M /boot
`-/dev/vda3                              /dev/vda3  /dev/vda         part LVM2_member 19.5G 
  |-/dev/mapper/rootvg-pool00_tmeta      /dev/dm-0  /dev/vda3        lvm                 4M 
  | `-/dev/mapper/rootvg-pool00-tpool    /dev/dm-2  /dev/dm-0        lvm              13.4G 
  |   |-/dev/mapper/rootvg-root          /dev/dm-3  /dev/dm-2        lvm  xfs           48M /
  |   |-/dev/mapper/rootvg-usr           /dev/dm-5  /dev/dm-2        lvm  xfs            4G /usr
  |   |-/dev/mapper/rootvg-pool00        /dev/dm-6  /dev/dm-2        lvm              13.4G 
  |   |-/dev/mapper/rootvg-tmp           /dev/dm-7  /dev/dm-2        lvm  xfs            4G /tmp
  |   |-/dev/mapper/rootvg-opt           /dev/dm-8  /dev/dm-2        lvm  xfs          512M /opt
  |   |-/dev/mapper/rootvg-var_log_audit /dev/dm-9  /dev/dm-2        lvm  xfs          128M /var/log/audit
  |   |-/dev/mapper/rootvg-var_log       /dev/dm-10 /dev/dm-2        lvm  xfs          512M /var/log
  |   |-/dev/mapper/rootvg-home          /dev/dm-11 /dev/dm-2        lvm  xfs          256M /home
  |   `-/dev/mapper/rootvg-var           /dev/dm-12 /dev/dm-2        lvm  xfs            4G /var
  |-/dev/mapper/rootvg-pool00_tdata      /dev/dm-1  /dev/vda3        lvm              13.4G 
  | `-/dev/mapper/rootvg-pool00-tpool    /dev/dm-2  /dev/dm-1        lvm              13.4G 
  |   |-/dev/mapper/rootvg-root          /dev/dm-3  /dev/dm-2        lvm  xfs           48M /
  |   |-/dev/mapper/rootvg-usr           /dev/dm-5  /dev/dm-2        lvm  xfs            4G /usr
  |   |-/dev/mapper/rootvg-pool00        /dev/dm-6  /dev/dm-2        lvm              13.4G 
  |   |-/dev/mapper/rootvg-tmp           /dev/dm-7  /dev/dm-2        lvm  xfs            4G /tmp
  |   |-/dev/mapper/rootvg-opt           /dev/dm-8  /dev/dm-2        lvm  xfs          512M /opt
  |   |-/dev/mapper/rootvg-var_log_audit /dev/dm-9  /dev/dm-2        lvm  xfs          128M /var/log/audit
  |   |-/dev/mapper/rootvg-var_log       /dev/dm-10 /dev/dm-2        lvm  xfs          512M /var/log
  |   |-/dev/mapper/rootvg-home          /dev/dm-11 /dev/dm-2        lvm  xfs          256M /home
  |   `-/dev/mapper/rootvg-var           /dev/dm-12 /dev/dm-2        lvm  xfs            4G /var
  `-/dev/mapper/rootvg-swap              /dev/dm-4  /dev/vda3        lvm  swap         2.1G [SWAP]

Description of the issue (ideally so that others can reproduce it):
The log contains lots of messages like these:

# grep 'type: .*: not found' /var/log/rear/rear-$(hostname -s).log
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: getty: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: dhcpcd: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: dhcp6c: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: dhclient6: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: grub-probe: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: sedutil-cli: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: sedutil-cli: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: cryptsetup: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: hpacucli: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: hpssacli: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: ssacli: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: multipath: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: grub-mkstandalone: not found
/usr/share/rear/lib/_input-output-functions.sh: line 331: type: grub-probe: not found

The messages induce the user to think that there is an error when in fact there is nothing wrong.

Workaround, if any:
Edit /usr/share/rear/lib/_input-output-functions.shand in function has_binary replace

type $bin 1>/dev/null && return 0

by

type -t $bin 1>/dev/null && return 0

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files): not required

jsmeix commented at 2020-08-07 10:20:¶

This issue is an example case of our general issue
https://github.com/rear/rear/issues/2416

The proposed change from plain type to type -t
conflicts with what is descibed in the comment
of the has_binary function which reads

# Suppress success output via stdout which is crucial when has_binary is called
# in other functions that provide their intended function results via stdout
# to not pollute intended function results with intermixed has_binary stdout
# (e.g. the RequiredSharedObjects function) but keep failure output via stderr:
type $bin 1>/dev/null && return 0

because - as far as I see - essentially the proposed change results the same
as if both stdout and stderr were suppressed like

type $bin &>/dev/null && return 0

But stderr is intentionaly not suppressed because
filtering stdout or stderr directly in the program call is in general not wanted,
cf. the section "What to do with stdin, stdout, and stderr" in
https://github.com/rear/rear/wiki/Coding-Style
that reads (excerpt):

All what could be useful for later debugging in case of issues
must appear in ReaR's log file. Usually command output
should not appear on the user's terminal but in ReaR's log file.
Because stdout and stderr are redirected into ReaR's log file
you should omit things like '1>/dev/null' or '2>/dev/null'
or '&>/dev/null' to have all messages in the log file
where they help to identify the root cause of a problem.
On the other hand if a program is needlessly verbose
you may use '1>/dev/null' or '2>/dev/null' or '&>/dev/null'
as appropriate to avoid that the log file is "polluted" with
useless messages ...

cf. https://github.com/rear/rear/pull/2466#discussion_r466410087

casantos commented at 2020-08-07 12:04:¶

The genera approach is reasonable but in this case the failure is not an error. Compare with the test for the existence of pidofin /usr/sbin/rear, for instance. A possible alternative would be to make has_binary show the messages only in debug mode.

jsmeix commented at 2020-08-07 12:11:¶

That type: COMMAND: not found is not an error is visible to the user
because that message does not contain a word like "error" or "failure"
so the particular user misunderstands the meaning of the message.

The "possible alternative" is
what https://github.com/rear/rear/issues/2416 is about.

jsmeix commented at 2020-08-07 12:18:¶

The test for the existence of pidof in /usr/sbin/rear
behaves even "worse" compared to the has_binary function
because type pidof 1>/dev/null runs before stdout and stderr
are redirected into the log file so that without pidof one gets on the terminal

# usr/sbin/rear -s mkrescue
usr/sbin/rear: line 366: type: pidof: not found
ERROR: Required program 'pidof' missing, please check your PATH

jsmeix commented at 2020-09-30 13:42:¶

@casantos
could you please test if the changes in
https://github.com/rear/rear/pull/2498
solve this issue sufficiently for you?

jsmeix commented at 2020-10-01 14:44:¶

@casantos
I changed https://github.com/rear/rear/pull/2498 noticeably,
cf. https://github.com/rear/rear/issues/2416#issuecomment-702142588
and https://github.com/rear/rear/issues/2416#issuecomment-702159687

Could you please test if the current changes in
https://github.com/rear/rear/pull/2498
i.e. if this changes
https://github.com/rear/rear/pull/2498/files
solve this issue sufficiently for you?

jsmeix commented at 2020-10-12 12:45:¶

Because no news is good news I assume this issue is done
since https://github.com/rear/rear/pull/2498 is merged.

[Export of Github issue for rear/rear.]

#2473 Issue closed: function has_binary sends misleading “type: foo: not found” messages to the log¶