Bug 1368106
| Summary: | qnetd is not checked for usage when killed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Roman Bednář <rbednar> |
| Component: | pcs | Assignee: | Tomas Jelinek <tojeline> |
| Status: | CLOSED DUPLICATE | QA Contact: | cluster-qe <cluster-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | cfeist, cluster-maint, idevat, omular, rbednar, tojeline |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-09-13 07:42:13 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: | |
| Embargoed: | |||
That is how it was designed. Is it wrong? What behavior do you expect? We could check if qdevice is in use in "pcs qdevice kill" based on "pcs qdevice status" output. But the kill command is expected to be used when things go terribly wrong and the user needs to forcefully stop the qdevice. In that case we cannot rely on "pcs qdevice status" to be working. Moreover qdevice can be killed by the "kill" and "killall" commands at any time without any prompt or warning. So far this looks like NOTABUG for me. Alright, can't argue with that logic. So how about the stop command? Is it also intended for that one not to check the status/usage?
You're right that kill command is a forcefull way and should be a last resort, but a stopping action seems reasonable to have a check/prompt there.
Keeping in mind that user can stop the service anytime using other tools anyway, same as killing it as you mentioned, but that's why we have pcs right? To make things easier, faster and help users avoid mistakes.
Also with latest build the kill command does not seem to work at all, do we need a separate BZ to track this?
# pcs qdevice kill net
quorum device killed
# systemctl is-active corosync-qnetd.service
active
# pcs qdevice status net
QNetd address: *:5403
TLS: Supported (client certificate required)
Connected clients: 4
Connected clusters: 1
Cluster "STSRHTS16137":
Algorithm: LMS
Tie-breaker: Node with lowest node ID
Node ID 1:
Client address: ::ffff:192.168.0.35:40572
Configured node list: 1, 2, 3, 4
Membership node list: 1, 2, 3, 4
Vote: ACK (ACK)
Node ID 4:
Client address: ::ffff:192.168.0.43:40480
Configured node list: 1, 2, 3, 4
Membership node list: 1, 2, 3, 4
Vote: ACK (ACK)
Node ID 2:
Client address: ::ffff:192.168.0.36:42636
Configured node list: 1, 2, 3, 4
Membership node list: 1, 2, 3, 4
Vote: ACK (ACK)
Node ID 3:
Client address: ::ffff:192.168.0.42:46054
Configured node list: 1, 2, 3, 4
Membership node list: 1, 2, 3, 4
Vote: ACK (ACK)
=================================
corosynclib-2.4.0-4.el7.x86_64
corosync-2.4.0-4.el7.x86_64
corosync-qdevice-2.4.0-4.el7.x86_64
corosync-qnetd-2.4.0-4.el7.x86_64
pcs-0.9.152-8.el7.x86_64
Fair enough, we can add the check when stopping a qdevice. Are you sure the killing does not work? I suspect that another instance of qnetd was started by systemd just after you killed it. Can you check that? >Are you sure the killing does not work? I suspect that another instance of >qnetd was started by systemd just after you killed it. Can you check that?
Checked that, it's exactly the case.
This has been reported and fixed in the original pcs qdevice bz. *** This bug has been marked as a duplicate of bug 1158805 *** |
There is no check that qdevice is actually used by a cluster. It is possible to kill it any time without any warning or prompt. # pcs qdevice status net QNetd address: *:5403 TLS: Supported (client certificate required) Connected clients: 4 Connected clusters: 1 Cluster "STSRHTS10485": Algorithm: LMS Tie-breaker: Node with lowest node ID Node ID 1: Client address: ::ffff:192.168.0.137:35018 Configured node list: 1, 2, 3, 4 Membership node list: 1, 2, 3, 4 Vote: ACK (ACK) Node ID 2: Client address: ::ffff:192.168.0.140:59852 Configured node list: 1, 2, 3, 4 Membership node list: 1, 2, 3, 4 Vote: ACK (ACK) Node ID 3: Client address: ::ffff:192.168.0.141:35462 Configured node list: 1, 2, 3, 4 Membership node list: 1, 2, 3, 4 Vote: ACK (ACK) Node ID 4: Client address: ::ffff:192.168.0.142:52374 Configured node list: 1, 2, 3, 4 Membership node list: 1, 2, 3, 4 Vote: ACK (ACK) # pcs qdevice kill net quorum device killed # pcs qdevice status net QNetd address: *:5403 TLS: Supported (client certificate required) Connected clients: 0 Connected clusters: 0 corosync-qnetd-2.4.0-3.el7.x86_64 corosynclib-2.4.0-3.el7.x86_64 corosync-qdevice-2.4.0-3.el7.x86_64 corosync-2.4.0-3.el7.x86_64 pcs-0.9.152-6.el7.x86_64