Open jimklimov opened 1 month ago
Seems limited to USB scans:
:; grep fatal nut/tools/nut-scanner/scan_*
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Failed to init libusb 1.0");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "No USB device found");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_xml_http.c: "%s: Had to abort scan for %s, see fatal details above",
Note that malloc()==NULL
handling is also not fatal in other scanners (and once even in USB), where they break
off a loop iteration to try going into next cycle:
nut/tools/nut-scanner/scan_ipmi.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_ipmi.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_nut.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_snmp.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_snmp.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: fatal_with_errno(EXIT_FAILURE, "Out of memory");
nut/tools/nut-scanner/scan_usb.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_xml_http.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_xml_http.c: upsdebugx(0, "%s: Memory allocation error", __func__);
nut/tools/nut-scanner/scan_xml_http.c: upsdebugx(0, "%s: Memory allocation error", __func__);
Partial solution posted: the single-commit PR #2577 addresses the acute problem from this issue, to not abort other scan types if there are problems with USB (other scanners do not seem to indulge in fatal behaviors).
It does not (yet?) address the ideas about returning or not an error exit code based on explicitly requested scan type failures (and/or them all or any not-returning any findings?) Probably there should be explicit CLI options about what we want to see as an error, for scripting.
Perhaps separately from that, memory errors that were not retried and recovered from should end up in an erroneous exit-code regardless, as we did not ATTEMPT scanning some of the items we otherwise could (so the lack of findings may be a false-positive)?
...or
On one hand, this is a bit inconsistent vs. the situation where a missing library causes a scan to be overlooked and skipped. On the other, if it was requested and could not be fulfilled, it should be an error.
Maybe the explicit settings
-O
,-U
, etc. should be treated as "required to succeed", while automatic enablement via no flag at all should be best-effort (require any one to succeed or hold no expectations at all?), and via-C
is most questionable (require all to succeed or at least one)?In any case, returning an error or success as exit code should be deferred to until all possible scans were completed (barring
malloc
,ulimit
orpthreads
errors, etc. - and better step back there too). Here the other scans (netxml, snmp, oldnut) were started, passed 1-2 IP addresses, and were not allowed to finish.