Bug 1372716

Summary:	firewall-cmd --query-* cmds should return valid exit code
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Dolezal <todoleza>
Component:	firewalld	Assignee:	Phil Sutter <psutter>
Status:	CLOSED ERRATA	QA Contact:	Tomas Dolezal <todoleza>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	atragler, egarver, rkhan, sukulkar, todoleza
Target Milestone:	rc	Keywords:	Documentation
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	firewalld-0.4.4.4-11.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-10 10:30:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Tomas Dolezal 2016-09-02 13:06:30 UTC

Description of problem:
when the result of a query is negative, exitcode 1 is used. this code is undefined as per man:firewall-cmd(1). While the code is correctly zero/non-zero, 1 is usually result of Traceback, not a valid operation in firewalld.

Version-Release number of selected component (if applicable):
firewalld-0.4.3.2-6.el7.noarch

How reproducible:
always

Steps to Reproduce:
firewall-cmd --query-service ssh ; echo ec=$?
firewall-cmd --query-service dns ; echo ec=$?
firewall-cmd --query-panic ; echo ec=$?

Actual results:
yes
ec=0
no
ec=1
no
ec=1

Expected results:
yes
ec=0
no
ec=12 <--- CHANGED to NOT_ENABLED
no
ec=12 <--- CHANGED to NOT_ENABLED

Additional info:

Comment 2 Thomas Woerner 2016-09-02 13:59:36 UTC

All query methods either return 0 or 1 for a long time already. I do not know if it will be simply possible to change the values without breaking scripts using the current exit codes.

Comment 3 Eric Garver 2017-06-23 17:22:53 UTC

Tomas,

The man page sections for --query-* commands indicates that it may return 1. The 'EXIT CODES' section could be updated to indicate that for --query-* 1 means negative status, otherwise it's due to a traceback.

I agree with Thomas in comment 2 that changing the return code would be problematic. Best we can do is improve the man page. Do you agree?

Comment 4 Tomas Dolezal 2017-06-26 12:15:20 UTC

Hello Eric,
(In reply to Eric Garver from comment #3)
> I agree with Thomas in comment 2 that changing the return code would be
> problematic. Best we can do is improve the man page. Do you agree?
Yes, I agree. the possible change should be done in both downstream and upstream.

Comment 9 errata-xmlrpc 2018-04-10 10:30:16 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0702