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.

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

Custom message outputs require a restart to work #4747

Closed
lennartkoopmann opened this issue Apr 21, 2018 · 1 comment
Closed

Custom message outputs require a restart to work #4747

lennartkoopmann opened this issue Apr 21, 2018 · 1 comment
Assignees
Labels
Milestone

Comments

@lennartkoopmann
Copy link
Member

@lennartkoopmann lennartkoopmann commented Apr 21, 2018

When creating a new (TCP) GELF output and assigning it to a stream, it does not actually write messages until graylog-server is restarted. I can reproduce this behavior.

UPDATE: I just confirmed the same behavior with a STDOUT output and adapted the title accordingly. This seems to be a problem with the output in general and not specific to GELF or TCP.

Steps to Reproduce (for bugs)

  1. For a stream that receives messages, go to the Outputs page, select "GELF output" and click "Launch new input".
  2. Note that no messages are being sent and the receiving side receives no new TCP connections.
  3. Restart graylog-server on the sending side.
  4. Note that messages are being sent and TCP connections are properly initiated.

I think a fix for this should be in v2.4.4 if at all possible.

  • Graylog Version: 2.4.3
@lennartkoopmann lennartkoopmann added this to the 2.4.4 milestone Apr 21, 2018
@lennartkoopmann lennartkoopmann changed the title GELF Output requires a restart to work Custom message outputs requires a restart to work Apr 21, 2018
@lennartkoopmann lennartkoopmann changed the title Custom message outputs requires a restart to work Custom message outputs require a restart to work Apr 21, 2018
@bernd bernd self-assigned this Apr 23, 2018
@bernd
Copy link
Member

@bernd bernd commented Apr 23, 2018

@lennartkoopmann I just tried to reproduce this. Assigning a stream output works for me without restart except for the default stream. This is because the default stream is currently loaded only once at server startup and doesn't get reloaded when something is changed. I will try to come up with a solution.

bernd added a commit that referenced this issue Apr 23, 2018
Without this, changes to the default stream would not become active
until a server restart because the default stream is only loaded once
when it's first accessed. (see DefaultStreamProvider)

Fixes #4747
kroepke added a commit that referenced this issue Apr 23, 2018
* Make sure to reload the default stream if it has been changed

Without this, changes to the default stream would not become active
until a server restart because the default stream is only loaded once
when it's first accessed. (see DefaultStreamProvider)

Fixes #4747

* Create StreamsChangedEvent when removing an output from all streams
kroepke added a commit that referenced this issue Apr 23, 2018
* Make sure to reload the default stream if it has been changed

Without this, changes to the default stream would not become active
until a server restart because the default stream is only loaded once
when it's first accessed. (see DefaultStreamProvider)

Fixes #4747

* Create StreamsChangedEvent when removing an output from all streams

(cherry picked from commit 13e142f)
bernd added a commit that referenced this issue Apr 24, 2018
#4754)

* Make sure to reload the default stream if it has been changed

Without this, changes to the default stream would not become active
until a server restart because the default stream is only loaded once
when it's first accessed. (see DefaultStreamProvider)

Fixes #4747

* Create StreamsChangedEvent when removing an output from all streams

(cherry picked from commit 13e142f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants