Bug 1308585 - skyring.pid and .skyring-event files removing
skyring.pid and .skyring-event files removing
Product: Red Hat Storage Console
Classification: Red Hat
Component: core (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 2
Assigned To: Nishanth Thomas
Martin Bukatovic
: TestBlocker
Depends On:
  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:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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):

How reproducible:

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)
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
# systemctl kill -s 15 skyring
# systemctl is-active skyring
# systemctl start skyring
# systemctl is-active skyring

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
# systemctl kill -s 9 skyring
# systemctl is-active skyring
# systemctl start skyring
# systemctl is-active skyring
# 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

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.


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