[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] Question about /etc/init.d/cman start



> It is actually configurable via /etc/sysconfig/cman (or /etc/defaults/cman on
> debian based systems)
> 
> # CMAN_QUORUM_TIMEOUT -- amount of time to wait for a quorate cluster
> on
> #     startup quorum is needed by many other applications, so we may as
> #     well wait here.  If CMAN_QUORUM_TIMEOUT is zero, quorum will
> #     be ignored.
> [ -z "$CMAN_QUORUM_TIMEOUT" ] && CMAN_QUORUM_TIMEOUT=45
> 
> Setting CMAN_QUORUM_TIMEOUT=0 will simply stop waiting for quorum and
> continue the execution of the init script.

Sure, but I want to wait for quorum.

> Assuming you want to retain the default behavior, once quorum is gained, it is
> enough to execute /etc/init.d/cman start again. The script is clever enough to
> start only what is necessary.
> You have a good point regarding cmannotifyd. In theory it could be used to
> trigger a "/etc/init.d/cman start" once quorum is achieved and notification
> dispatched. I can fix this upstream, but for any RHEL6 changes, I'll need you to

I compile my own packages for debian, so a fix for upstream would be great. I am just unsure
if we should call unfence_self() from cmannotifyd. I guess it is OK if we check that
we got quorum for the first time?

Besides, why do you want that extra complexity running 'cman start' from cmannotifyd? Especially error handling is somehow unclear to me (what if cman start fails there?). So can't we simple make those daemon smart enough so that we can start them at boot time (always)?

- Dietmar
 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]