[FEATURE] Flush on daemon shutdown #3

New Issue

2018-06-21T22:34:47-04:00

JoshuaBoniface commented

2018-06-21 22:34:47 -04:00

(Migrated from git.bonifacelabs.ca)

Flush node on daemon shutdown, however also have a separate "restart" signal from Systemd trapped to do a graceful restart without flushing.

Suggested by @michal

Flush node on daemon shutdown, however also have a separate "restart" signal from Systemd trapped to do a graceful restart without flushing. Suggested by @michal

JoshuaBoniface commented

2018-06-21 22:35:05 -04:00

(Migrated from git.bonifacelabs.ca)

changed the description

JoshuaBoniface commented

2018-06-25 23:05:51 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit d0dc923d92

mentioned in commit d0dc923d9201151b68e23c8b5210cb98a74b5ab1

JoshuaBoniface commented

2018-06-25 23:13:17 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit ac2b3c464c

mentioned in commit ac2b3c464cff4643b1078b02c7024bc1d15e2a6c

JoshuaBoniface commented

2018-06-25 23:17:16 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit c5a7ac0738

mentioned in commit c5a7ac073849d580c9adb71aa00d9302fb30d5aa

JoshuaBoniface commented

2018-06-26 12:09:16 -04:00

(Migrated from git.bonifacelabs.ca)

I did some testing and based on how Systemd works, there is no way to selectively flush only on a stop - the restart does a stop + start unconditionally so there's no way to differentiate the two. Trying to do this with SIGHUP/reload also does not work since that doesn't respawn.

Won't add; admin is always responsible for flushing first.

cc: @MichalKozanecki

I did some testing and based on how Systemd works, there is no way to selectively flush only on a `stop` - the `restart` does a `stop` + `start` unconditionally so there's no way to differentiate the two. Trying to do this with `SIGHUP`/`reload` also does not work since that doesn't respawn. Won't add; admin is always responsible for flushing first. cc: @MichalKozanecki

JoshuaBoniface commented

2018-06-26 12:09:17 -04:00

(Migrated from git.bonifacelabs.ca)

closed

JoshuaBoniface commented

2018-06-26 12:10:40 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit 9eb1855add

mentioned in commit 9eb1855add1cf1e988f48233cb161cc0ecd1708a

JoshuaBoniface commented

2018-06-26 12:10:40 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit 75ed61908a

mentioned in commit 75ed61908a3315cabee1411818f97afd4f145298

JoshuaBoniface commented

2018-06-26 12:10:40 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in commit f27cdb024c

mentioned in commit f27cdb024c9f83f2cf68029edcd91ac386b14380

MichalKozanecki commented

2018-06-26 21:38:45 -04:00

(Migrated from git.bonifacelabs.ca)

How do the other nodes know the difference between a node being down because an admin gracefully shut pvc down, and pvc(or zookeeper) crashed?

How do the other nodes know the difference between a node being down because an admin gracefully shut `pvc` down, and `pvc`(or `zookeeper`) crashed?

MichalKozanecki commented

2018-06-26 21:38:45 -04:00

(Migrated from git.bonifacelabs.ca)

reopened

JoshuaBoniface commented

2018-06-26 21:40:08 -04:00

(Migrated from git.bonifacelabs.ca)

If pvc crashes, it never sets its daemon state to stop, and hence gets fenced. If Zookeeper crashes, the node stops sending keepalives, and hence gets fenced.

If `pvc` crashes, it never sets its daemon state to `stop`, and hence gets fenced. If Zookeeper crashes, the node stops sending keepalives, and hence gets fenced.

MichalKozanecki commented

2018-06-26 21:54:13 -04:00

(Migrated from git.bonifacelabs.ca)

💯 👍

:100: :+1:

MichalKozanecki commented

2018-06-26 21:54:14 -04:00

(Migrated from git.bonifacelabs.ca)

closed

Sign in to join this conversation.