Bug 1308585 - skyring.pid and .skyring-event files removing
skyring.pid and .skyring-event files removing
Status: VERIFIED
Product: Red Hat Storage Console
Classification: Red Hat
Component: core (Show other bugs)
2
Unspecified Unspecified
unspecified Severity medium
: ---
: 2
Assigned To: Nishanth Thomas
Martin Bukatovic
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-15 09:48 EST by Lubos Trilety
Modified: 2016-08-08 14:59 EDT (History)
3 users (show)

See Also:
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:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lubos Trilety 2016-02-15 09:48:11 EST
Description of problem:
skyring.pid file is created  and remains on the machine when skyring fails to start. Similar when skyring is stopped because of some error (not fatal crash) skyring.pid file and .skyring-event socket remain on the machine.

Version-Release number of selected component (if applicable):
rhscon-core-0.0.8-2.el7.x86_64
rhscon-ceph-0.0.6-2.el7.x86_64
rhscon-ui-0.0.12-1.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Stop mongod and tries to start skyringd.service

Actual results:
skyring fails to start due to DB is not available. However skyring.pid file in /var/run is not removed. Because of that skyring cannot be started even when mongod is running.

Expected results:
skyring.pid file should be removed.

Additional info:
Note that presence of .skyring-event cause the same issue. Skyring cannot be started whilst the file is there.
Comment 1 Martin Bukatovic 2016-02-16 04:11:36 EST
Fixing BZ 1296123 (providing proper config files for systemd) will resolve this issue.
Comment 3 Martin Bukatovic 2016-03-10 11:06:30 EST
I don't understand this operation:

Depends On: 1298096
No longer depends On: 1296123

Why do you think that this BZ no longer depends on BZ 1296123 (skyring systemd
service issue) and that it depends on BZ 1298096 (firewall configuration)
instead?
Comment 4 Martin Bukatovic 2016-03-22 06:12:12 EDT
Question from comment 3 remains unanswered.
Comment 5 Martin Bukatovic 2016-08-08 13:37:04 EDT
Dropping misleading dependency (there was no feedback).
Comment 6 Martin Bukatovic 2016-08-08 13:37:59 EDT
And based on the previous comment 5, dropping needinfo flag.
Comment 7 Martin Bukatovic 2016-08-08 14:59:04 EDT
Checking rhscon-core-0.0.41-1.el7scon.x86_64

PID file
--------

PID file of skyring service is managed by systemd and is no longer a problem.

unix domain socket file
-----------------------

When skyring is killed so that the service can shutdown itself properly, the
socket file is removed and the service can be started again outright:

~~~
# systemctl is-active skyring
active
# systemctl kill -s 15 skyring
# systemctl is-active skyring
inactive
# systemctl start skyring
# systemctl is-active skyring
active
~~~

But when the serice is killed by force preventing a proper shutdown (SIGKILL),
the socket file remains there (as if the service crashed):

~~~
# systemctl is-active skyring
active
# systemctl kill -s 9 skyring
# systemctl is-active skyring
failed
# systemctl start skyring
# systemctl is-active skyring
failed
# ls -l /var/run/.skyring-event 
srwxr-xr-x. 1 root root 0 Aug  8 20:51 /var/run/.skyring-event
~~~

Removing the socket file allows skyring service to be started again:

~~~
# rm -f /var/run/.skyring-event
# systemctl start skyring
# systemctl is-active skyring
active
~~~

I consider this ok: one can't expect that unix daemon would do a proper
shutdown including cleanup when killed by SIGKILL or during crash.

>>> VERIFIED

Note You need to log in before you can comment on or make changes to this bug.