Bug 1311521

Summary:	journald entry shown in systemctl status output show misleading interpretation of skyringd status
Product:	Red Hat Storage Console	Reporter:	Martin Bukatovic <mbukatov>
Component:	unclassified	Assignee:	Timothy Asir <tjeyasin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Kudlej <mkudlej>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	2	CC:	mkudlej, nthomas, sankarshan
Target Milestone:	---
Target Release:	2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rhscon-ceph-0.0.23-1.el7scon.x86_64, rhscon-core-0.0.24-1.el7scon.x86_64, rhscon-ui-0.0.39-1.el7scon.noarch	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-19 05:34:31 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:
Bug Depends On:	1296123
Bug Blocks:

Description Martin Bukatovic 2016-02-24 12:10:09 UTC

Description of problem
======================

Skyring service returns misleading return code when it crashes or systemd
service file is wrong.

Version-Release number of selected component
============================================

rhscon-core-0.0.8-4.el7.x86_64
rhscon-ceph-0.0.6-4.el7.x86_64
rhscon-ui-0.0.14-1.el7.noarch

How reproducible
================

100 % (assuming one reproduces BZ 1305891 crash)

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

1. Install skyring on server
2. Make skyring crash (reproduce BZ 1305891)
3. Run `systemctl status skyringd`

Actual results
==============

~~~
# systemctl status skyringd
● skyringd.service - skyring server
   Loaded: loaded (/usr/lib/systemd/system/skyringd.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2016-02-23 21:09:36 CET; 15h ago
  Process: 31684 ExecStop=/etc/init.d/skyringd stop (code=exited, status=0/SUCCESS)
 Main PID: 4922 (code=exited, status=2)

Feb 22 20:29:01 mbukatov-usm2-server.example.com systemd[1]: Starting skyring server...
Feb 22 20:29:01 mbukatov-usm2-server.example.com skyringd[4916]: Starting skyring:
Feb 22 20:29:01 mbukatov-usm2-server.example.com systemd[1]: Started skyring server.
Feb 22 20:29:20 mbukatov-usm2-server.example.com systemd[1]: Started skyring server.
Feb 23 21:09:36 mbukatov-usm2-server.example.com systemd[1]: skyringd.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 23 21:09:36 mbukatov-usm2-server.example.com systemd[1]: Unit skyringd.service entered failed state.
Feb 23 21:09:36 mbukatov-usm2-server.example.com systemd[1]: skyringd.service failed.
~~~

See the line with `status=2/INVALIDARGUMENT` in this output. That seems to be
misleading as no invalid argument is involved in the crash (as far as I know).

Expected results
================

Journald output from systemctl status doesn't show `status=2/INVALIDARGUMENT`,
but somehting more related to the actual problem here.

Additional info
===============

Why does systemd thinks that? It seems that it's because of a wrong systemd
service file and/or wrong return code from skyringd. Systemd just uses LSB
rules here:

http://refspecs.linuxfoundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Which states:

> In case of an error while processing any init-script action except for
> status, the init script shall print an error message and exit with a non-zero
> status code: 
>
> 1	generic or unspecified error (current practice)
> 2	invalid or excess argument(s)

Comment 2 Nishanth Thomas 2016-04-27 14:54:10 UTC

Since this is an issue with improper systemd unit files, this is fixed along with the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1296123

Comment 3 Martin Kudlej 2016-08-04 10:13:07 UTC

Tested with
ceph-ansible-1.0.5-31.el7scon.noarch
ceph-installer-1.0.14-1.el7scon.noarch
rhscon-ceph-0.0.39-1.el7scon.x86_64
rhscon-core-0.0.39-1.el7scon.x86_64
rhscon-core-selinux-0.0.39-1.el7scon.noarch
rhscon-ui-0.0.51-1.el7scon.noarch
I've tried 4 options how to reproduce this. Skyring service ended with correct meesage in logs and systemd journal. In case of related issue this BZ can be reopen.