Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Aug 25, 2010 at 02:10:55PM +0900, Junko IKEDA wrote: > Hi, > sorry for covering old ground. > > http://www.gossamer-threads.com/lists/drbd/users/19746 > > We should catch that one, probably, and irgnore it at least for monitor > > (role, status, dstate, etc.) and "down" related commands (secondary, > > disconnect, detach), or handle it more gracefully in some yet to be > > > Maybe we should add such a loop to drbddisk as well. > > Or somehow set it up as a wrapper around the ocf agent (though that may > > not be easily possible). > > > > Yes, your patch is ok. > > Still I'm not taking it as such, but probably make drbdsetup more robust > > in face of file system problems on /var/lock/, and add a monitoring loop > > to drbddisk instead. > > Do you have any good idea for handling /var/lock? For the EROFS on open(/var/lock/*), just put /var/lock on tmpfs and be happy. For the drbddisk script, yes, we probably should stop lying # other error, may be syntax error in config file, # anything else: to not confuse heartbeat further, # and avoid reboot due so "failed stop recovery", # pretend that we succeeded in stopping this. As you seem to rather have the reboot due to failed stop recovery in any case, yep, lets have it. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed