A few weeks back, I was working on a project that had the Husky pre-push hook configured. After working on it for a few days, I noticed that sometimes code is not getting pushed to the remote repository.
After a headache of trial and error, I realized that the pre-push hook was taking so much time to finish. And when it did, there was no message of code being pushed to the remote repo in the terminal. Something was odd.
I learned that the SSH connection between the terminal and GitHub initiates when we execute git push
and terminates when the code is pushed successfully. However, if the connection is inactive for a certain period of time, it terminates itself due to timeout.
Since Husky pre-push was taking so long time to finish its job, the SSH connection with the GitHub server was timing out. The dead connection resulted in the code not getting pushed at all.
I needed a way to keep the connection alive for a few more minutes. Luckily, we can do this in the terminal itself.
Your terminal must be connected to your GitHub account via SSH. You can find more information here.
As I said, the solution is to keep the connective alive until the husky finish its task. It's easier than I thought.
In your terminal, go to the directory that stores SSH information. Usually, it's /.ssh
folder in the home directory. Execute this command in the terminal:
cd ~/.ssh
The tilde symbol(~) represents /home
directory. Since our desired destination folder is in the home directory itself, this command will change the current working directory to /home/.ssh
.
Create a file named config
without any extension. Add the following text to the file:
Host *
ServerAliveInterval 60
ServerAliveCountMax 30
Connect to the host once again and you'd see the success. If not, increase the duration by a few minutes until you find your sweet spots. The way to understand this setting is explained in the next section.
But what ServerAliveInterval
and ServerAliveCountMax
actually do?
According to the SSH manual:
ServerAliveInterval: Sets a timeout interval in seconds after which if no data has been received from the server, ssh will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server. This option applies to protocol version 2 only.
ServerAliveCountMax: The default value is 3. If, for example,
ServerAliveInterval
is set to 15 andServerAliveCountMax
is left at the default, if the server becomes unresponsive, SSH will disconnect after approximately 45 seconds. This option applies to protocol version 2 only.
So to summarize:
ServerAliveInterval
time.ServerAliveCountMax
. So it will wait for 1800 seconds, which is half an hour.In our case, the client is waiting for the server's response. Because the GitHub server sends a response back when the code is pushed. If you want the client to send a response, you should use ClientAliveInterval
and ClientAliveCountMax
.
The asterisk symbol (*) sets this configuration for every connected host. If you want to set this for a particular host, or only one host, you can do it in following way:
Host hostname1
SSH_OPTION value
SSH_OPTION value
Host hostname2
SSH_OPTION value
Host *
SSH_OPTION value
The list of available connected hosts can be found in the known_hosts
file, which is located in the same directory.
Server alive messages are useful when an SSH server has been configured to close connections after a period of time with no traffic. Setting these two options keeps the session alive by sending a packet every *ServerAliveInterval *seconds for a maximum of ServerAliveCountMax times.
As a developer, we come across new problems every single day. Some of those problems challenge our skills; others challenge our patience. For me, this problem falls into the latter category. Hence I decided to write an article about it.
I hope you found this article helpful. If you want to say hi, my DMs are always open. I am most active on Twitter, LinkedIn and Showwcase.
Happy coding! 👨💻
Also published here.