search

Graylog2 / graylog-docker

Official Graylog Docker image
https://hub.docker.com/r/graylog/graylog/
Apache License 2.0
361 stars 133 forks source link

Bash doesn't pass SIGTERM to java process #173

Closed asachs01 closed 2 years ago

asachs01 commented 3 years ago

This is from HS-514243459:

After doing some more digging, I believe the issue is that tini passes on SIGTERM to its child bash process (executing docker-entry.point.sh), but SIGTERM doesn’t get passed down to the Java process it invokes. Based upon https://github.com/krallin/tini/issues/72 and https://github.com/krallin/tini/issues/78 I created a lightly-modified “/docker-entrypoint.sh” that just prefixes the Java command with “exec”, making the Java process the direct child of tini. After implementing that on GRAYLOGSBSRV3 I verified Graylog shut down cleanly (respecting “GRAYLOG_LB_RECOGNITION_PERIOD_SECONDS” and gracefully stopping everything with accompanying log messages).

asachs01 commented 3 years ago

@juju2112 do you only release the docker image when there's a new version, or is it possible to cut a new image with this fix?

malcyon commented 3 years ago

@juju2112 do you only release the docker image when there's a new version, or is it possible to cut a new image with this fix?

We have a scheduled bugfix release coming up pretty soon. I normally wait to build new images then. If the issue is critical and I get the product manager's blessing, then I do an unscheduled release.

I wasn't able to login to Hubspot, so I am not really able to gauge the seriousness of it. I was pretty surprised to see this kind of issue though, and equally happy that the fix was so simple.

coffee-squirrel commented 3 years ago

@juju2112 My question to @asachs01 (leading to this reopening) was more in the general sense. We can certainly get by until the 4.1.4 image lands with this fix, but I wanted to learn what Graylog's process was to release fixes specific to various types of issues with the Docker images (e.g. the entrypoint script, critical vulnerabilities in the openjdk:#-jre-slim-buster base image, etc.).

malcyon commented 3 years ago

@coffee-squirrel We do a bug fix release once a month, on the first Wednesday of each month or the first business day following that day. If it's something critical, we'll normally just release it as soon as possible, provided it's been properly tested and is ready. Normally @kroepke or @boosty are "the deciders" there.

coffee-squirrel commented 3 years ago

@juju2112 Okay, thank you. Would images released for image-specific issues just have the build number bumped (e.g. 4.1.3-2 --> 4.1.3-3)? Would it be practical for this sort of info (and perhaps a changelog or integration w/ the main changelogs) to be added to https://docs.graylog.org?

kroepke commented 3 years ago

I think bumping the -z version of the container is perfectly fine to do in between bugfix releases, yeah. The next regular bugfix release would be in a week anyway, so either way I'm fine with it.

But it sounds to me like just bumping the container (package) version is easy enough to do and that should be harmless to do.

malcyon commented 3 years ago

That's right. I'd just bump the release version. They Graylog version would remain the same. I can definitely do that if we want.

We do have the changelogs in the documentation. But we don't have our release schedule there. I can open an issue on the documentation repo for it. Maybe add it to the FAQ? I'm not sure where it would go exactly.

malcyon commented 3 years ago

Of course, that would also mean it would release the new jdk-11 image, too. I think that might have been why I was waiting until next week.

coffee-squirrel commented 3 years ago

We do have the changelogs in the documentation.

Ah, I missed the reference to #153 in the 4.1.0 release notes, and might be overlooking other image-related items. Thanks!

But we don't have our release schedule there. I can open an issue on the documentation repo for it. Maybe add it to the FAQ? I'm not sure where it would go exactly.

I could almost see it as a dedicated "Release Strategy" (or whatever) page, covering Graylog's overall approach as well as more specific approaches (e.g. Docker images).

Of course, that would also mean it would release the new jdk-11 image, too. I think that might have been why I was waiting until net week.

Certainly no problem with that from our perspective.

malcyon commented 2 years ago

We had some issues with the 4.1.4 release, but I re-released 4.1.3. Use the tag graylog/graylog:4.1.3-3, and you should get the fix.