Skip to content

fru print exit status depends on the last processed item #326

Open
scop opened this issue Feb 15, 2022 · 2 comments · May be fixed by #327
Open

fru print exit status depends on the last processed item #326

scop opened this issue Feb 15, 2022 · 2 comments · May be fixed by #327

Comments

@scop
Copy link

scop commented Feb 15, 2022

The exit status of ipmitool fru print appears to depend on what happens with the last processed item. If there is an error related to it, the exit status is non-zero, whereas if this item is followed by a successfully processed item, or in general if the last item is processed successfully, it is zero.

We think a more consistent exit status would be in order: either always return with non-zero if there are failures processing any of the items, or alternatively with zero if any of the items is processed successfully, no matter the position of the failed item(s). Perhaps the latter would be better in terms of backwards compatibility/assumptions.

Let us know if you'd like to see a PR along these lines, and which would be your preferred approach.

Cc @macronet

@AlexanderAmelkin
Copy link
Contributor

@scop I'd say that ipmitool is generally very inconsistent about exit codes, and needs major refactoring regarding that.

as for multi-entity operations like print, I think it would be useful to have both behaviors switchable with a command line option, default being the latter (always 0 if at least one item was a success)

@scop
Copy link
Author

scop commented Feb 15, 2022

Thanks for considering. I cannot say I personally agree with having such an option, I don't recall ever seeing such a thing anywhere. While I can see it could theoretically be useful for some cases, to me there is larger value in well chosen and documented command behavior, and not having too many options to cater all conceivable scenarios.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants