| Summary: | skyring.pid and .skyring-event files removing | ||
|---|---|---|---|
| Product: | Red Hat Storage Console | Reporter: | Lubos Trilety <ltrilety> |
| Component: | core | Assignee: | Nishanth Thomas <nthomas> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Bukatovic <mbukatov> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2 | CC: | mbukatov, mkudlej, sankarshan |
| Target Milestone: | --- | Keywords: | TestBlocker |
| 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:30:17 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
Lubos Trilety
2016-02-15 14:48:11 UTC
Fixing BZ 1296123 (providing proper config files for systemd) will resolve this issue. 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? Dropping misleading dependency (there was no feedback). And based on the previous comment 5, dropping needinfo flag. 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
|