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

Use /etc/host_hostname #22

Open
james-emerton opened this issue Jun 15, 2020 · 6 comments
Open

Use /etc/host_hostname #22

james-emerton opened this issue Jun 15, 2020 · 6 comments
Assignees
Labels
question Further information is requested

Comments

@james-emerton
Copy link

The upstream logspout project supports reading /etc/host_hostname to determine the hostname. This allows one to expose the actual hosts name to the container rather than using the container id.

Currently, this does not work for logdna's logspout as the HOSTNAME environment variable appears to be the only way to set the hostname.

I am currently working around this as follows:

docker run -d \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc/hostname:/etc/host_hostname:ro \
  -e LOGDNA_KEY=<key> \
  --entrypoint /bin/sh \
  logdna/logspout:latest \
  -c "HOSTNAME=\`cat /etc/host_hostname\` /bin/logspout"

I'm starting this container as part of an image baking process, so I cannot set the hostname to the value at the time the container is created as it will change.

@smusali smusali self-assigned this Jun 24, 2020
@smusali smusali added the question Further information is requested label Jun 24, 2020
@smusali
Copy link
Contributor

smusali commented Jun 24, 2020

@james-emerton, let me understand this clearly; so, you want to be able to set the hostname of each container's logs to a different value rather than using one HOSTNAME for all, right?

@james-emerton
Copy link
Author

@smusali No, I want to launch the container as part of a machine image baking process. When an instance is created using that image, the logspout container will start and should then pick up a the hostname of the machine it's running on.

Current behaviour is that the hostname associated with these logs is the original container id. Unfortunately that means that all logs coming from the set of instances launched from that image all posses the same uninformative hostname.

@smusali
Copy link
Contributor

smusali commented Jul 7, 2020

hey, @james-emerton, sorry for the late response!

I have internally filed a ticket for this request. We are going to make this change as soon as possible.

Thanks!

@agrushin
Copy link

Hi, any updates on this?

@darinspivey
Copy link
Contributor

darinspivey commented May 28, 2021

@agrushin So sorry, it looks like this fell off of our radar accidentally some time ago. We've picked this back up and have a branch and coding solution complete. Unfortunately, testing this change is proving to be challenging given the integration with logspout, so give us some time on that. We apologize for all the delay, but rest assured, we will finish the effort.

@darinspivey
Copy link
Contributor

Just an update to keep this active--we have a code fix, but testing it within the confines of logspout's implementation is making it very hard to test. We are looking into this now and are working towards resolving this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants