MongoDB server doesn’t close when pressing Ctrl+C after changing the system date to a date in the past
I'm currently using MongoDB 3.4.4.
I run MongoDB using the mongo_start batch file. I normally close the shell that appears using ctrl+c and it works most of the time. But when I roll back the system date to a previous one (ex. change system date to yesterday's date) while the MongoDB server is up, ctrl+c stops working (i.e. the shell does not close).
It seems like this was caused by the --journal parameter because when I changed it to no journal, I was able to close the shell with ctrl+c even after I changed the system date to a previous date. But after checking the same case with an older MongoDB server (which also has the --journal parameter), ctrl+c closed the shell after I changed system date to previous date.
I would like to know what exactly caused the shell to not close with ctrl+c after I changed the system date to an older date. Thanks!
windows-7 windows mongodb
edited Feb 9 at 3:39
Stennie
14218
asked Feb 8 at 3:06
berdyberdy
111
add a comment |
I'm currently using MongoDB 3.4.4.
I run MongoDB using the mongo_start batch file. I normally close the shell that appears using ctrl+c and it works most of the time. But when I roll back the system date to a previous one (ex. change system date to yesterday's date) while the MongoDB server is up, ctrl+c stops working (i.e. the shell does not close).
It seems like this was caused by the --journal parameter because when I changed it to no journal, I was able to close the shell with ctrl+c even after I changed the system date to a previous date. But after checking the same case with an older MongoDB server (which also has the --journal parameter), ctrl+c closed the shell after I changed system date to previous date.
I would like to know what exactly caused the shell to not close with ctrl+c after I changed the system date to an older date. Thanks!
windows-7 windows mongodb
edited Feb 9 at 3:39
Stennie
14218
asked Feb 8 at 3:06
berdyberdy
111
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16
add a comment |
I'm currently using MongoDB 3.4.4.
I run MongoDB using the mongo_start batch file. I normally close the shell that appears using ctrl+c and it works most of the time. But when I roll back the system date to a previous one (ex. change system date to yesterday's date) while the MongoDB server is up, ctrl+c stops working (i.e. the shell does not close).
It seems like this was caused by the --journal parameter because when I changed it to no journal, I was able to close the shell with ctrl+c even after I changed the system date to a previous date. But after checking the same case with an older MongoDB server (which also has the --journal parameter), ctrl+c closed the shell after I changed system date to previous date.
I would like to know what exactly caused the shell to not close with ctrl+c after I changed the system date to an older date. Thanks!
windows-7 windows mongodb
edited Feb 9 at 3:39
Stennie
14218
asked Feb 8 at 3:06
berdyberdy
111
I'm currently using MongoDB 3.4.4.
I run MongoDB using the mongo_start batch file. I normally close the shell that appears using ctrl+c and it works most of the time. But when I roll back the system date to a previous one (ex. change system date to yesterday's date) while the MongoDB server is up, ctrl+c stops working (i.e. the shell does not close).
It seems like this was caused by the --journal parameter because when I changed it to no journal, I was able to close the shell with ctrl+c even after I changed the system date to a previous date. But after checking the same case with an older MongoDB server (which also has the --journal parameter), ctrl+c closed the shell after I changed system date to previous date.
I would like to know what exactly caused the shell to not close with ctrl+c after I changed the system date to an older date. Thanks!
windows-7 windows mongodb
windows-7 windows mongodb
edited Feb 9 at 3:39
Stennie
14218
asked Feb 8 at 3:06
berdyberdy
111
edited Feb 9 at 3:39
Stennie
14218
asked Feb 8 at 3:06
berdyberdy
111
edited Feb 9 at 3:39
Stennie
14218
edited Feb 9 at 3:39
Stennie
14218
edited Feb 9 at 3:39
Stennie
14218
14218
asked Feb 8 at 3:06
berdyberdy
111
asked Feb 8 at 3:06
berdyberdy
111
asked Feb 8 at 3:06
berdyberdy
111
111
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16
add a comment |
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16
add a comment |
1 Answer
1
active
oldest
votes
Given your MongoDB server version of 3.4.4 and the current problem description (changing the system clock backwards), I expect that upgrading to MongoDB 3.4.6 or later will resolve this issue. The latest production release in that series is currently 3.4.19 (January, 28 2019), and there have been many bug fixes and stability improvements since 3.4.4 was released (April 21, 2017).
There were a few issues related to system clocks jumping backward which would cause WiredTiger stalls or hangs during checkpoints (for example, see WT-3331 and WT-3327 in the MongoDB issue tracker). These were addressed in the MongoDB 3.4.6 release.
This is also mentioned under the Clock Synchronization section of the MongoDB production notes:
Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.
It seems like this was caused by the --journal parameter
The shutdown sequence involves a checkpoint to make journaled writes durable in the data files. If you have disabled journalling (which is strongly not recommended for production environments), you would instead be triggering checkpoints on each write. I expect that disabling the journal would have made it less likely for your server to have a checkpoint including data that was written before the clock went backwards, although you could perhaps still run into issues in 3.4.4 if the system clock changes concurrently with writes.
answered Feb 9 at 1:35
StennieStennie
14218
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1403385%2fmongodb-server-doesn-t-close-when-pressing-ctrlc-after-changing-the-system-date%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Given your MongoDB server version of 3.4.4 and the current problem description (changing the system clock backwards), I expect that upgrading to MongoDB 3.4.6 or later will resolve this issue. The latest production release in that series is currently 3.4.19 (January, 28 2019), and there have been many bug fixes and stability improvements since 3.4.4 was released (April 21, 2017).
There were a few issues related to system clocks jumping backward which would cause WiredTiger stalls or hangs during checkpoints (for example, see WT-3331 and WT-3327 in the MongoDB issue tracker). These were addressed in the MongoDB 3.4.6 release.
This is also mentioned under the Clock Synchronization section of the MongoDB production notes:
Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.
It seems like this was caused by the --journal parameter
The shutdown sequence involves a checkpoint to make journaled writes durable in the data files. If you have disabled journalling (which is strongly not recommended for production environments), you would instead be triggering checkpoints on each write. I expect that disabling the journal would have made it less likely for your server to have a checkpoint including data that was written before the clock went backwards, although you could perhaps still run into issues in 3.4.4 if the system clock changes concurrently with writes.
answered Feb 9 at 1:35
StennieStennie
14218
add a comment |
Given your MongoDB server version of 3.4.4 and the current problem description (changing the system clock backwards), I expect that upgrading to MongoDB 3.4.6 or later will resolve this issue. The latest production release in that series is currently 3.4.19 (January, 28 2019), and there have been many bug fixes and stability improvements since 3.4.4 was released (April 21, 2017).
There were a few issues related to system clocks jumping backward which would cause WiredTiger stalls or hangs during checkpoints (for example, see WT-3331 and WT-3327 in the MongoDB issue tracker). These were addressed in the MongoDB 3.4.6 release.
This is also mentioned under the Clock Synchronization section of the MongoDB production notes:
Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.
It seems like this was caused by the --journal parameter
The shutdown sequence involves a checkpoint to make journaled writes durable in the data files. If you have disabled journalling (which is strongly not recommended for production environments), you would instead be triggering checkpoints on each write. I expect that disabling the journal would have made it less likely for your server to have a checkpoint including data that was written before the clock went backwards, although you could perhaps still run into issues in 3.4.4 if the system clock changes concurrently with writes.
answered Feb 9 at 1:35
StennieStennie
14218
add a comment |
Given your MongoDB server version of 3.4.4 and the current problem description (changing the system clock backwards), I expect that upgrading to MongoDB 3.4.6 or later will resolve this issue. The latest production release in that series is currently 3.4.19 (January, 28 2019), and there have been many bug fixes and stability improvements since 3.4.4 was released (April 21, 2017).
There were a few issues related to system clocks jumping backward which would cause WiredTiger stalls or hangs during checkpoints (for example, see WT-3331 and WT-3327 in the MongoDB issue tracker). These were addressed in the MongoDB 3.4.6 release.
This is also mentioned under the Clock Synchronization section of the MongoDB production notes:
Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.
It seems like this was caused by the --journal parameter
The shutdown sequence involves a checkpoint to make journaled writes durable in the data files. If you have disabled journalling (which is strongly not recommended for production environments), you would instead be triggering checkpoints on each write. I expect that disabling the journal would have made it less likely for your server to have a checkpoint including data that was written before the clock went backwards, although you could perhaps still run into issues in 3.4.4 if the system clock changes concurrently with writes.
answered Feb 9 at 1:35
StennieStennie
14218
Given your MongoDB server version of 3.4.4 and the current problem description (changing the system clock backwards), I expect that upgrading to MongoDB 3.4.6 or later will resolve this issue. The latest production release in that series is currently 3.4.19 (January, 28 2019), and there have been many bug fixes and stability improvements since 3.4.4 was released (April 21, 2017).
There were a few issues related to system clocks jumping backward which would cause WiredTiger stalls or hangs during checkpoints (for example, see WT-3331 and WT-3327 in the MongoDB issue tracker). These were addressed in the MongoDB 3.4.6 release.
This is also mentioned under the Clock Synchronization section of the MongoDB production notes:
Use NTP to synchronize the clocks on all components of your MongoDB deployment. Replica sets and sharded clusters running MongoDB 3.4.5 or earlier with the WiredTiger storage engine may experience checkpoint hangs on systems with unreliable clocks.
It seems like this was caused by the --journal parameter
The shutdown sequence involves a checkpoint to make journaled writes durable in the data files. If you have disabled journalling (which is strongly not recommended for production environments), you would instead be triggering checkpoints on each write. I expect that disabling the journal would have made it less likely for your server to have a checkpoint including data that was written before the clock went backwards, although you could perhaps still run into issues in 3.4.4 if the system clock changes concurrently with writes.
answered Feb 9 at 1:35
StennieStennie
14218
answered Feb 9 at 1:35
StennieStennie
14218
answered Feb 9 at 1:35
StennieStennie
14218
answered Feb 9 at 1:35
StennieStennie
14218
14218
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1403385%2fmongodb-server-doesn-t-close-when-pressing-ctrlc-after-changing-the-system-date%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Well, here’s a crazy question: Why are you changing the date to a date in the past? Testing some date-based logic?
– JakeGould
Feb 8 at 3:15
Yep. I tried a C# code that uses the SystemEvents.TimeChanged. I wanted to try closing the MongoDB shell "automatically" when the user changes the system date.
– berdy
Feb 8 at 3:37
By the way, on closing it automatically, I wanted to use the execution of ctrl+c. I do know that I can use Process.kill() instead, but I'm curious about what causes ctrl+c to not close the MongoDB shell when I rollback the system date.
– berdy
Feb 8 at 6:16