RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1434236 - ethtool returns incorrect exit code for error (stderr)
Summary: ethtool returns incorrect exit code for error (stderr)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ethtool
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ivan Vecera
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-21 03:28 UTC by Vikram Hosakote
Modified: 2017-11-03 18:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-03 18:48:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Vikram Hosakote 2017-03-21 03:28:15 UTC 
Description of problem:
=======================

ethtool returns an incorrect exit code (0 which is success) when it fails with an error (stderr). When ethtool fails with an error (stderr), it must return a non-zero exit code instead of 0.

Since orchestration tools like Ansible takes action based on the value of the exit code return by a command, due to this bug, Ansible thinks that ethtool worked/passed when ethtool actually fails with an error (stderr). Fixing this bug will make orchestration tools like Ansible to take proper action based on the correct non-zero exit code returned for an error (stderr).

Version-Release number of selected component (if applicable):
=============================================================

# ethtool --version
ethtool version 3.15

How reproducible:
=================

Always.

Steps to Reproduce:
===================

# /usr/sbin/ethtool -K eth0 lro off > output
Cannot change large-receive-offload

# cat output
#

# /usr/sbin/ethtool -K eth0 lro off 2> output

# cat output 
Cannot change large-receive-offload

# /usr/sbin/ethtool -K eth0 lro off
Cannot change large-receive-offload

# echo $?
0

Actual results:
===============

# /usr/sbin/ethtool -K eth0 lro off
Cannot change large-receive-offload

# echo $?
0

Expected results:
=================

ethtool must return a non-zero exit code for an error (stderr) instead of 0.

# /usr/sbin/ethtool -K eth0 lro off
Cannot change large-receive-offload

# echo $?
127 (or any other non-zero exit code)

Additional info:
================

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.2 (Maipo)

# uname -r
3.10.0-327.el7.x86_64

# uname -a
Linux testnode.in 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/system-release-cpe 
cpe:/o:redhat:enterprise_linux:7.2:ga:server
Comment 2 Ivan Vecera 2017-05-22 14:36:06 UTC 
Could you please provide an output from 'ethtool -k eth0' ? You are probably trying to change fixed (non-changeable) offloaded feature.
Comment 3 Vikram Hosakote 2017-05-22 17:53:50 UTC 
Below is the output of "ethtool -k eth0".

# ethtool -k eth0
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
	tx-checksum-ipv4: off [fixed]
	tx-checksum-ip-generic: on
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
scatter-gather: on
	tx-scatter-gather: on
	tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: on
	tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
busy-poll: off [fixed]
Comment 4 Ivan Vecera 2017-05-23 07:12:51 UTC 
(In reply to Vikram Hosakote from comment #3)
> Below is the output of "ethtool -k eth0".
> 
> # ethtool -k eth0
> ...
> large-receive-offload: off [fixed]
> ...

So you are trying to enable fixed feature (LRO in your case)... It is not possible to change such features so ethtool just informs about it... This is not an error.
Comment 5 Vikram Hosakote 2017-05-23 18:51:42 UTC 
Then, why does ethtool print the output in stderr and return 0 (which is success)?
Comment 7 Ivan Vecera 2017-11-03 18:48:14 UTC 
(In reply to Vikram Hosakote from comment #5)
> Then, why does ethtool print the output in stderr and return 0 (which is
> success)?

It's upstream behavior... please see commit like 5954d26 ("ethtool: Do not return error code if no changes were attempted"). This commit changes the return code when channel parameters were not changed... it returned non-zero but now zero although prints the message to stderr.

If we change this behavior we could break existing scripts that assumes such messages on stderr output.

...and return zero is valid because an attempt to change fixed parameter is not an error state but a mistake of the user.
Note You need to log in before you can comment on or make changes to this bug.