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 ;-
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 Ubu
On Mon, May 30, 2011 at 11:31 PM, Florian Haas wrote:
>
> If you're using Pacemaker (and you should), then you don't need the drbd
> init script, and it can be safely disabled with "chkconfig drbd off" or
> whatever is the equivalent command on your preferred platform.
I think in this case it woul
On 05/28/2011 08:22 PM, Whit Blauvelt wrote:
> Hi,
>
> I've got myself in a sticky situation. Restarting a system remotely that was
> a drbd primary, it's getting to "Starting DRBD resources," and then, after
> finding the meta data, there's the "DRBD's startup script waits for the peer
> node(s)
Hello,
On 05/28/2011 08:22 PM, Whit Blauvelt wrote:
> Meanwhile, any suggestions on getting past this will be most appreciated.
incidentally I was faced with a similair situation just today and my
workaround was to modify the bootscript:
instead of
-8<-
$DRBD
On 05/29/2011 01:57 AM, Whit Blauvelt wrote:
> DRBD is running with heartbeat in this case, and you're right that the drbd
> init script probably shouldn't be called this way. Although to quote from
> the INIT INFO section of the script:
>
> # X-Start-Before: heartbeat corosync
> # X-Stop-After:
On Sat, May 28, 2011 at 02:58:28PM -0700, Matt Graham wrote:
> If you can ssh to the bad machine, fix the /etc/init.d/drbd script so that it
> starts *after* all the NICs are running.
Yeah, I could do that if I could ssh. If I could ssh all would be pretty.
But the drbd init.d script is blockin
From: Whit Blauvelt
> On Sat, May 28, 2011 at 11:12:50PM +0200, Valentin Vidic wrote:
>> If there is a second node, perhaps you can make it appear? And
>> after the primary finishes with the boot adjust the startup timeouts
>> from the default values.
> Sadly, the second node is up. But the node
On Sat, May 28, 2011 at 11:12:50PM +0200, Valentin Vidic wrote:
> If there is a second node, perhaps you can make it appear? And after the
> primary finishes with the boot adjust the startup timeouts from the default
> values.
Sadly, the second node is up. But the node that's stuck was dumb enou
On Sat, May 28, 2011 at 04:25:45PM -0400, Dan Barker wrote:
> The setting is wfc-timeout and possibly degr-wfc-timeout. Unless you can
> force power off the machine and mount it's boot disk (like you would be able
> to in a VM setting), I think you have to drive over there or talk the
> janitor in
On Sat, May 28, 2011 at 02:22:49PM -0400, Whit Blauvelt wrote:
> Meanwhile, any suggestions on getting past this will be most appreciated.
If there is a second node, perhaps you can make it appear? And after the
primary finishes with the boot adjust the startup timeouts from the default
values.
Hi,
I've got myself in a sticky situation. Restarting a system remotely that was
a drbd primary, it's getting to "Starting DRBD resources," and then, after
finding the meta data, there's the "DRBD's startup script waits for the peer
node(s) to appear," plus mention that degr-wfc-timeout and wfc-ti
12 matches
Mail list logo