Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 05/31/2011 04:03 PM, Whit Blauvelt wrote: > On Mon, May 30, 2011 at 09:51:15AM +0200, Felix Frank wrote: >>> Does "X-Start-Before" mean start this before these, or start these before >>> this? Ubuntu as a Debian should obey this LSB stuff. But >> >> Careful - you're agitating the Debian crowd ;-) >> >> I wouldn't be so quick to assume that Ubuntu does these things in the >> exact Debian way. > > Sure, wouldn't be surprised if it's Ubuntu breakage. My question is real > though. Does "X-Start-Before" mean "start before," so that DRBD's init.d > file is insisting it be started before heartbeat? Or does the "X" negate the > meaning, so that "X-Start-Before" means start after? On the one hand, yes AFAIK, there is no such thing as "Start-Before" in LSB tag lingo. I assume that the X- (as in HTTP headers) marks a nonstandard extension. > heartbeat should start DRBD; I did this wrong even having DRBD's init.d > script active. On the other, if both are being started, heartbeat should > start first, in which case if heartbeat starts DRBD it will get that done > ... and the DRBD init.d, if triggered, will just fail since it's already > started. Not quite. Heartbeat will usually take some time itself before it launches any processes (configurably), so you really want init to not run your HA services. > Okay, I can cycle power from remote all I like. The problem is the > SuperMicro IPMI has Java Web applets for SOL - which handles the BIOS end of > the thing, and for Console Redirection - which presents the boot process ... > BUT ... the boot process as shown through Console Redirection shows up a bit > late in that process visually, and apparently the keyboard isn't active > either until then (I've tried, repeatedly), so there's no effective way to > get grub to boot into anything else. OK, that just sucks. >> Also, what would (in your eyes) be wrong about configuring a wait >> timeout and then just leave DRBD "running"? It sure won't break anything. > > Sure, I should configure a wait timeout. But what's wrong in my tired eyes > is drbdadmin, when called from an init.d script at least, by default running > forever waiting for the connection. As we see here, in some situations that I can sympathize with this notion. Although it's never bitten me myself, I can see how it can be potentially harmful. But then, we have to find an answer to "what's a sensible default?". Anyway, there's apparently no solution for the problem at hand. Sorry. Regards, Felix