Docker logs stop logging to console when followed
I am running into what feels like the observer effect with regards to my Docker logs. I am running docker-compose logs -f containerName and the logs begin to print to my console. I happen to be using hot reloading in my JavaScript app such that modifying a file then saving it will trigger a hot reload which will be documented in the logs I am following. The hot reloading is controlled via gulp tasks that call on browserSync.
The hot reloading seems to appear in the logs as expected if I run it only a couple of times. If I wait an extended period of time (minutes), triggering a hot reload no longer appears in the logs. If I quit following the logs then immediately begin following them again, I can see that the most recent hot reload was logged, it just was not being previously displayed. This leads me to believe that something probably related to processes and file descriptors is causing this behavior.
Almost as if the process that is running the log following no longer is receiving the output from the logs. It also seems to happen inconsistently in that different numbers of hot reloads will get logged before they cease to be logged each time I run the docker logging command. Any suggestions to as how I can ensure that my logs are always printing new log info would be appreciated. Additionally an explanation as to what is causing this underlying behavior would be a bonus.
Running "Docker Desktop" (formerly called Docker for Mac?)
Version 2.0.0.0-mac78 (28905)
Engine: 18.09.0
docker logging file-descriptor
add a comment |
I am running into what feels like the observer effect with regards to my Docker logs. I am running docker-compose logs -f containerName and the logs begin to print to my console. I happen to be using hot reloading in my JavaScript app such that modifying a file then saving it will trigger a hot reload which will be documented in the logs I am following. The hot reloading is controlled via gulp tasks that call on browserSync.
The hot reloading seems to appear in the logs as expected if I run it only a couple of times. If I wait an extended period of time (minutes), triggering a hot reload no longer appears in the logs. If I quit following the logs then immediately begin following them again, I can see that the most recent hot reload was logged, it just was not being previously displayed. This leads me to believe that something probably related to processes and file descriptors is causing this behavior.
Almost as if the process that is running the log following no longer is receiving the output from the logs. It also seems to happen inconsistently in that different numbers of hot reloads will get logged before they cease to be logged each time I run the docker logging command. Any suggestions to as how I can ensure that my logs are always printing new log info would be appreciated. Additionally an explanation as to what is causing this underlying behavior would be a bonus.
Running "Docker Desktop" (formerly called Docker for Mac?)
Version 2.0.0.0-mac78 (28905)
Engine: 18.09.0
docker logging file-descriptor
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44
add a comment |
I am running into what feels like the observer effect with regards to my Docker logs. I am running docker-compose logs -f containerName and the logs begin to print to my console. I happen to be using hot reloading in my JavaScript app such that modifying a file then saving it will trigger a hot reload which will be documented in the logs I am following. The hot reloading is controlled via gulp tasks that call on browserSync.
The hot reloading seems to appear in the logs as expected if I run it only a couple of times. If I wait an extended period of time (minutes), triggering a hot reload no longer appears in the logs. If I quit following the logs then immediately begin following them again, I can see that the most recent hot reload was logged, it just was not being previously displayed. This leads me to believe that something probably related to processes and file descriptors is causing this behavior.
Almost as if the process that is running the log following no longer is receiving the output from the logs. It also seems to happen inconsistently in that different numbers of hot reloads will get logged before they cease to be logged each time I run the docker logging command. Any suggestions to as how I can ensure that my logs are always printing new log info would be appreciated. Additionally an explanation as to what is causing this underlying behavior would be a bonus.
Running "Docker Desktop" (formerly called Docker for Mac?)
Version 2.0.0.0-mac78 (28905)
Engine: 18.09.0
docker logging file-descriptor
I am running into what feels like the observer effect with regards to my Docker logs. I am running docker-compose logs -f containerName and the logs begin to print to my console. I happen to be using hot reloading in my JavaScript app such that modifying a file then saving it will trigger a hot reload which will be documented in the logs I am following. The hot reloading is controlled via gulp tasks that call on browserSync.
The hot reloading seems to appear in the logs as expected if I run it only a couple of times. If I wait an extended period of time (minutes), triggering a hot reload no longer appears in the logs. If I quit following the logs then immediately begin following them again, I can see that the most recent hot reload was logged, it just was not being previously displayed. This leads me to believe that something probably related to processes and file descriptors is causing this behavior.
Almost as if the process that is running the log following no longer is receiving the output from the logs. It also seems to happen inconsistently in that different numbers of hot reloads will get logged before they cease to be logged each time I run the docker logging command. Any suggestions to as how I can ensure that my logs are always printing new log info would be appreciated. Additionally an explanation as to what is causing this underlying behavior would be a bonus.
Running "Docker Desktop" (formerly called Docker for Mac?)
Version 2.0.0.0-mac78 (28905)
Engine: 18.09.0
docker logging file-descriptor
docker logging file-descriptor
edited Nov 19 '18 at 20:13
Bob Smith
asked Nov 14 '18 at 22:57
Bob SmithBob Smith
1731316
1731316
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44
add a comment |
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
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%2fstackoverflow.com%2fquestions%2f53309972%2fdocker-logs-stop-logging-to-console-when-followed%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- 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%2fstackoverflow.com%2fquestions%2f53309972%2fdocker-logs-stop-logging-to-console-when-followed%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
Which platform are you running Docker on? If you're running via moby on windows or hyperkit on OSX then this is related to the following docker issue: github.com/moby/moby/issues/30046 ... I've found that the best way to watch logs in realtime is to have the logs output to a logfile in a host mounted volume (docs.docker.com/storage/volumes/…) , and use the usual methods (lnav, tail, etc ...) to monitor the log.
– eurythmia
Nov 17 '18 at 1:38
@eurythmia I've updated the post to include my versions. The mounted volume solution seems very cumbersome. I am seeing multiple online plugins/packages that can be used to do this but that seems like it is more effort than it is worth. I've only noticed this issue as of ~1 month ago and certainly can't be the first to experience this behavior.
– Bob Smith
Nov 21 '18 at 16:29
No, it's been hanging around for well over a year now. I discovered it in docker for mac around june 2017. The bug I linked is targeted at the windows version, but D4M suffers from the same issue. I don't have any other solutions for you as I wiped OSX off of my macbook in favor of linux shortly thereafter because there were just too many issues with D4M. Besides myself, there are a few other D4M "me too"s on the above linked issue, but no acknowledgement from the docker team.
– eurythmia
Nov 22 '18 at 3:13
Unfortunate for sure. Thank you for your help.
– Bob Smith
Dec 5 '18 at 15:44