Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The nomad logs -f command can make windows clients unresponsive/crash. #3342

Closed
angrycub opened this issue Oct 9, 2017 · 1 comment · Fixed by #3608
Closed

The nomad logs -f command can make windows clients unresponsive/crash. #3342

angrycub opened this issue Oct 9, 2017 · 1 comment · Fixed by #3608
Labels
theme/driver/docker theme/logging theme/platform-windows type/bug

Comments

@angrycub
Copy link
Contributor

angrycub commented Oct 9, 2017

Nomad version

Nomad v. 0.6.3

Operating system and Environment details

Nomad Server - CentOS 7
Nomad Client - Windows Server 2016
Task Driver - Windows Docker container; sample job attached.
Nomad CLI was run on one of the Linux server nodes.

Issue

After running nomad logs -f «allocation id» example-task the allocation will eventually become unresponsive.

Reproduction steps

Start job

nomad run 4973-reproducer.nomad

Note allocation id, get ip:port via

nomad alloc-status «allocation id»

Tail logs with

nomad logs -f «allocation id» example-task

While tail is running, request the web page around 20 times at the IP and port noted in alloc-status. Should see access style logs returned via the nomad logs process. Stop the tail and wait.

Nomad agent on client will emit massive panic. One time it was too many threads, this time it was out of memory.

Nomad Client logs (if appropriate)

output.log.zip

Job file (if appropriate)

4973-reproducer.nomad.zip
@angrycub angrycub changed the title The nomad logs -f command can make windows docker allocations unresponsive. The nomad logs -f command can make windows clients unresponsive/crash. Oct 9, 2017
schmichael added a commit that referenced this issue Dec 1, 2017
@schmichael
Fix race in framer and improperly returned err
ac3fffc 
Fixes #3342

Two bugs were fixed:

* Closing the StreamFramer's exitCh before setting the error means other
  goroutines blocked on exitCh closing could see the error as nil. This
  was *not* observered.
* parseFramerError on Windows would fall through and return an
  improperly captured nil err variable. There's no need for
  parseFramerError to be a closure which fixes the confusion.
@schmichael schmichael mentioned this issue Dec 1, 2017
Merged
@github-actions
Copy link

github-actions bot commented Dec 5, 2022

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
theme/driver/docker theme/logging theme/platform-windows type/bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix bug in log framer only affecting Windows hashicorp/nomad
2 participants
@schmichael @angrycub