Date: 2012-07-29 11:25:45 +0200
From: Christian Braun <>
To: Merovingian devs <>
Version: 11.11.7 (Jul2012-SP1)
CC: ivanzolotuhin

Last updated: 2012-09-21 11:51:26 +0200

Comment 17583

Date: 2012-07-29 11:25:45 +0200
From: Christian Braun <>

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build Identifier:

A database does not get started if there is a lot of old temporary data to be removed during startup. Happens for me most of the time when a database gets stopped with running query.

Reproducible: Always

Comment 17584

Date: 2012-07-29 11:27:16 +0200
From: Christian Braun <>

Created attachment 136
Adds property starttimeout

Makes the default 10 seconds startup timeout configurable.

Attached file: monetdbd.diff (text/plain, 2440 bytes)
Description: Adds property starttimeout

Comment 17585

Date: 2012-07-29 11:30:43 +0200
From: @grobian

Oh, wow, thanks. I was thanking in a different direction, to make merovingian know the difference between a database recovering, and a database not starting up.

Another way would be to unify start and exit timeout values.

Comment 17603

Date: 2012-08-02 16:05:39 +0200
From: @grobian

Changeset ab6705d3d0b1 made by Fabian Groffen fabian@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=ab6705d3d0b1

Changeset description:

monetdbd: wait for servers to be fully started

This is a solution for bug #3134.

Sabaoth now makes a difference between starting and started.  mserver5
uses this, such that processing the write ahead log should delay the
state of the server becoming started.  This way, monetdbd can wait for a
server to become fully available.
Unfortunately our global lock in combination with a possible indefinite
wait is a potential killer of the entire system.

Comment 17604

Date: 2012-08-02 16:06:48 +0200
From: @grobian

This should be implemented without flags now, giving the database as much time as it needs.

Comment 17606

Date: 2012-08-03 09:53:49 +0200
From: @grobian

*** Bug #3133 has been marked as a duplicate of this bug. ***

Comment 17644

Date: 2012-08-23 10:14:41 +0200
From: @sjoerdmullender

Jul2012-SP1 has been released.

Comment 17645

Date: 2012-08-23 11:48:28 +0200
From: Christian Braun <>

Hello,

i updated to latest release (from 11.11.5-20120710 to 11.11.7-20120813). The database did not start automatically and i had to execute "monetdb start" multiple times. The error i was getting:

start: starting 'db' failed: database 'db' started up, but failed to open up a communication channel

Regards,
Christian.

Comment 17646

Date: 2012-08-23 11:49:18 +0200
From: Christian Braun <>

Created attachment 141
monetdb logfile

Attached file: merovingian.log (text/plain, 8578 bytes)
Description: monetdb logfile

Comment 17647

Date: 2012-08-23 11:49:53 +0200
From: Christian Braun <>

Created attachment 142
shell commands log

Attached file: cmd.log (text/plain, 725 bytes)
Description: shell commands log

Comment 17648

Date: 2012-08-23 12:24:21 +0200
From: @grobian

the database gets a SIGTERM almost immediately after it's been started, I wonder why monetdbd does that

Comment 17670

Date: 2012-08-24 14:55:09 +0200
From: @sjoerdmullender

Jul2012-SP1 has been released.

Comment 17706

Date: 2012-08-29 15:56:48 +0200
From: @grobian

we have confirmed this issue here now, but I have no clue yet why the database is reported "started" while it has no connections and scenarios available

Comment 17712

Date: 2012-08-31 14:01:11 +0200
From: @grobian

Changeset 9e0f79672cf9 made by Fabian Groffen fabian@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=9e0f79672cf9

Changeset description:

sabaoth: resolve race-like condition in determining state

Because GDKinit can take some time, GDKlockHome may have been called
while msab_registerStarting was not.  In this gap, any msab_getStatus
call would conclude the database to be running, since the GDK lockfile
is locked.  Since we cannot set anything before we actually know that we
can start the database to be started (e.g. not locked by another
process), we now flag when a database is done starting, instead of
flagging it is still busy starting up.
This resolves the problem reported in bug #3134, comment 7, that was
introduced in Jul2012-SP1.

Comment 17713

Date: 2012-08-31 14:02:26 +0200
From: @grobian

Found the cause for this, will be released in Jul2012-SP2