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

silence 'Did not receive identification string from...' messages from SSHD/gikubed #114

Merged
merged 1 commit into from
May 14, 2019
Merged

silence 'Did not receive identification string from...' messages from SSHD/gikubed #114

merged 1 commit into from
May 14, 2019

Conversation

yld
Copy link
Contributor

@yld yld commented May 10, 2019

With current SSHD configuration, gitkubed deployement readynessProbe on port 22 is throwing dozens of logs message like Did not receive identification string from 10.93.50.85 port 5510 (every 2 seconds).

This tiny PR set SSH log level to ERROR instead of INFO fixing logs verbosity.

@tirumaraiselvan
Copy link
Collaborator

Although this is fine.

I think considering the readinessProbe is failing (hence it is continuously polled), we should also just remove the readinessProbe?

@yld
Copy link
Contributor Author

yld commented May 14, 2019

I like having this probe, otherwise how will we know if the service still up and running.

ReadynessProbe is a little bit misleading name but documentation state that:

Readiness probes runs on the container during its whole lifecycle.

Maybe setting the log level in an environment variable could be better (to ease debuging for example)?

@tirumaraiselvan
Copy link
Collaborator

But I am guessing the readinessProbe is not successful because sshd connections need to have identifying information atleast. I am not sure how k8s is marking this ready with such errors.

@yld
Copy link
Contributor Author

yld commented May 14, 2019

It is working fine, otherwise kubernetes won't allow any incoming connection to reach gitkube.

According documentation about tcpSocket probes:

(...) TCP Socket. With this configuration, the kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy, if it can’t it is considered a failure.

So it's working fine and useful.

@tirumaraiselvan
Copy link
Collaborator

Cool. Interesting behaviour of readinessProbe. I didn't imagine it would more than once after a container startup.

@tirumaraiselvan tirumaraiselvan merged commit c9f0d4a into hasura:master May 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants