You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating a crash of mserver5 I remarked that the monetdb tool reports an incorrect crash time. It seems to report the time when the database was started and not the time when the database (mserver5 instance) crashed.
Reproducible: Always
Steps to Reproduce:
Create a new database: sudo monetdb create test
Release the database: sudo monetdb release test
Start the database: sudo monetdb start test
Wait 5 minutes
Find out pid of mserver5 instance: ps -ef | grep mserver5
Kill mserver5 instance and print current time: sudo kill -9 ;date
Check status of database: sudo monetdb monetdb status
Compare time shown in 6. and time reported by monetdb
Actual Results:
The monetdb tool reports time when database was started.
Expected Results:
The monetdb tool should report the time when the database crashed.
monetdb --version
MonetDB Database Server Toolkit v11.35.3 (Nov2019)
The report is indeed confusing.
Currently we don't know at what time the server crashed, we only know when it was started and that it crashed.
Of course, mserver5 can't tell monetdbd that it is about to crash (especially not if you kill it with kill -9), so we need to figure it out in some other way. What we should probably do is catch the SIGCHILD signal, but that'll take some effort to implement (catching isn't hard, avoiding the resulting race conditions is).
Comment 27469
Date: 2019-12-10 09:36:36 +0100
From: Olaf Flaschel <<olaf.flaschel>>
(In reply to Sjoerd Mullender from comment 1)
The report is indeed confusing.
Currently we don't know at what time the server crashed, we only know when
it was started and that it crashed.
Of course, mserver5 can't tell monetdbd that it is about to crash
(especially not if you kill it with kill -9), so we need to figure it out in
some other way. What we should probably do is catch the SIGCHILD signal,
but that'll take some effort to implement (catching isn't hard, avoiding the
resulting race conditions is).
Date: 2019-12-05 21:30:20 +0100
From: Olaf Flaschel <<olaf.flaschel>>
To: Merovingian devs <>
Version: 11.35.3 (Nov2019)
Last updated: 2019-12-20 15:36:32 +0100
Comment 27454
Date: 2019-12-05 21:30:20 +0100
From: Olaf Flaschel <<olaf.flaschel>>
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Build Identifier:
While investigating a crash of mserver5 I remarked that the monetdb tool reports an incorrect crash time. It seems to report the time when the database was started and not the time when the database (mserver5 instance) crashed.
Reproducible: Always
Steps to Reproduce:
Actual Results:
The monetdb tool reports time when database was started.
Expected Results:
The monetdb tool should report the time when the database crashed.
monetdb --version
MonetDB Database Server Toolkit v11.35.3 (Nov2019)
Comment 27456
Date: 2019-12-06 14:31:31 +0100
From: @sjoerdmullender
The report is indeed confusing.
Currently we don't know at what time the server crashed, we only know when it was started and that it crashed.
Of course, mserver5 can't tell monetdbd that it is about to crash (especially not if you kill it with kill -9), so we need to figure it out in some other way. What we should probably do is catch the SIGCHILD signal, but that'll take some effort to implement (catching isn't hard, avoiding the resulting race conditions is).
Comment 27469
Date: 2019-12-10 09:36:36 +0100
From: Olaf Flaschel <<olaf.flaschel>>
(In reply to Sjoerd Mullender from comment 1)
Maybe just changing the message would be enough:
"crashed (started on 2019-12-05 21:06:43)"
or
"crashed"
instead of
"crashed on 2019-12-05 21:06:43"
Comment 27472
Date: 2019-12-10 16:45:57 +0100
From: MonetDB Mercurial Repository <>
Changeset 2ea938bafd98 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=2ea938bafd98
Changeset description:
Comment 27473
Date: 2019-12-10 16:49:32 +0100
From: @sjoerdmullender
I've implemented your suggestion.
The text was updated successfully, but these errors were encountered: