Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Jan 24, 2013 at 10:09:30AM +0100, Helmut Wollmersdorfer wrote: > > Am 23.01.2013 um 19:01 schrieb Dan Barker: > > >If those time stamps are believable, then the problem occurred > >before you started! > > > >I don't know of drbd accessing the config decks before a drbdadm > >command, but it looks like you have proved that it happens. You > >copied, it activated! Very strange result. I'll let the drbd > >authors chime in on what new files in the config directory can > >cause before you request something using them, but it looks like > >the way to do this is to do the edit elsewhere, or "Save As" (:w > ><filename>). > > So we learned from this (again): Never configure on the fly. > > Edit your new resource-config in another place and then move it into > /etc/drbd.d/. > > > > >Actually, you have pacemaker and heartbeat in the mix. I imagine > >they do watch directories for changes. It may not be drbd at all, > >but drbdadm commands requested by those tools. > > The error-message comes from drbd/user/drbdadm_parser.c -> > vcheck_uniq(). It checks if certain keys like resource-name in the > config are unique. For some reasons this check seems to be activated > via pacemaker/crm -> ocf:linbit:drbd -> monitor(?) -- as far as I > understand the code. Right. pacemaker monitor for some resource (maybe drbd8_1) was executed, but found two definitions of that resource. Did not know what to do, was confused, errors out with "generic error". Pacemaker recovery for "generic error" is -> stop. If that had still found an invalid config, it would have been a stop failure, which would escalate to node fencing (stonith)... D'uh. So before you touch anything "critical", put pacemaker in maintenance mode, and double check before you take it out again. BTW, you may change the default behaviour (each drbd resource defined within the "same" config file, or included from there) by adding an explicit config file to each resource, possibly including "global_common" from each of them. Benefit: it would not explode in this situation. Drawback: it cannot help you if you mistype something, and try to re-use the same port or similar in several such "independend" config files. Depending on exact setup, you need to always remember to specify the specifig config file, or things won't work, and potentially handlers sometime will be confused because they don't find "their" config file... If you still want to try that setup, best to experiment a bit with it first, before you decide to actually use 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