DEV Community: Abhinav Kumar

Keep your SSH sessions alive until you don't want to

Abhinav Kumar — Sat, 23 May 2020 20:43:17 +0000

I do almost all of my work remotely on a server. I as well as my colleagues have a ton of SSH sessions open at all times. And I have seen them getting frustrated when they take a break and come back to see the terminal tab not responding.

This is very easy to fix though. We just have to tell the SSH daemon at the server or the client in our system to send packets at a specific interval to avoid that.

Configuration on the server

In the config of OpenSSH server in /etc/ssh/sshd_config, add the following:

ClientAliveInterval 300
ClientAliveCountMax 3

It will make sure that the OpenSSH server keeps the all the connections alive with no effort on the part of the clients.

Configuration on the client

Add the following lines to any of the SSH configs in your system:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 3

You should add this to /etc/ssh/ssh_config for system-wide change or ~/.ssh/config to apply just for the current user.

Per-Host Configuration

You can replace * in Host * with a hostname to only apply the configuration for connections to that specific server. e.g.

Host *abhnv.dev
    ServerAliveInterval 300
    ServerAliveCountMax 3

Explanation for the settings

ServerAliveInterval 300 or ClientAliveInterval 300 means that the server or the client will send a null packet to the other end every 300 seconds.

ServerAliveCountMax 3 or ClientAliveCountMax 3 means that the server or the client will try 3 times before giving up.

Originally posted at https://abhnv.dev/blog/2020-05-24-ssh-keep-alive/

Bump up the number of files your system can monitor for changes

Abhinav Kumar — Mon, 18 Nov 2019 12:49:40 +0000

Have you ever been working on a project and realized that project is not being hot-reloaded or re-compiled when you save or have auto-save enabled.

I almost always run into this issue after I have set up a new development environment. It seems like the system just stops monitoring for files. I have only encountered this issue on Linux systems though. Never on Windows or macOS.

After a bit of googling, I found out that the default limit of file watchers count, that Linux systems allow to monitor for filesystem changes is very low. 8192 to be exact. I know that it is very reasonable for a normal user. But not for a development use case. Our workspace's file count is usually upwards of 8192. JavaScript projects? Even more so.

The most common way, applications like VSCode or IntelliJ IDEs monitor filesystem changes on Linux, is inotify. We can query the current limit by running

$ cat /proc/sys/fs/inotify/max_user_watches

If you see a value in thousands, this is your problem. Fortunately, it's very trivial to fix. No kernel compilation needed. 😋

This limit configuration can be set by changing the value of fs.inotify.max_user_watches in /etc/sysctl.conf. You can put it to any number you want but I think ~65000 is a good enough limit. I set it to 65536 because Base 2!

You can do this using:

$ echo fs.inotify.max_user_watches=65536 | sudo tee -a /etc/sysctl.conf
# Then reload the new configuration values
$ sudo sysctl -p

And that's it.

If you just want to set it temporarily, just run

$ sudo sysctl fs.inotify.max_user_watches=65536
$ sudo sysctl -p

You can also put it in your /etc/profile so it will run on every restart. But I feel /etc/sysctl.conf is the better way.

Moore's Law and Programming languages

Abhinav Kumar — Thu, 02 Aug 2018 10:13:13 +0000

Since Moore's law is leveling off, now developers will have to level up their game to extract more performance out of same chips. I predict less JS (or Electron) and Python/Ruby/node, and more Go, Rust, Scala (and maybe assembly on the side).

What do you think?

How do you think Guido stepping down as BDFL will affect Python?

Abhinav Kumar — Sat, 14 Jul 2018 13:00:07 +0000

Edit:
I missed the earlier discussion from 2 days ago

Guido van Rossum steps down as Python's BDFL, thoughts?

Ben Halpern ・ Jul 12 '18

#python #discuss

What are the most used commands in your shell history?

Abhinav Kumar — Wed, 04 Jul 2018 18:55:46 +0000

Recently I came across a thread on reddit which asked users the most used command in their shell history.

My results:

     1  419  13.0489%    git
     2  265  8.25288%    cd
     3  239  7.44316%    sudo
     4  122  3.79944%    cat
     5  77   2.39801%    which
     6  76   2.36686%    dkr
     7  72   2.24229%    rm
     8  60   1.86858%    rg
     9  57   1.77515%    yarn
    10  57   1.77515%    nvim

Obviously git is my most used command because I ran it on my work laptop. It should be a lot more but I have been using prezto's git aliases lately. Other common commands are dkr which is an alias for sudo docker and rg, the binary for ripgrep.

I wonder how is it for the dev.to community?

Use this command from linux.byexample.com to list your most used commands:

history | awk '{CMD[$2]++;count++;}END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl |  head -n10

I use zsh and it was not working for me because zsh's history command just prints a few most recent commands only. I had to tweak it a bit:

history 1 | cat | awk '{CMD[$2]++;count++;}END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a; }' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl | head -n10
# or
fc -l 1 | awk '{CMD[$2]++;count++;}END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a; }' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl | head -n10

Rest in peace, grep!

Abhinav Kumar — Wed, 16 May 2018 21:16:00 +0000

I'm not saying that grep is slow or flawed in any way but it can be definitely faster (and better). And GNU grep is not the only player out there.

Let me introduce ripgrep, a grep/ag/ack alternative written in Rust.

So why should you use ripgrep? Because it's fast. Very fast! It has saner defaults. And it's written in Rust. (Topic for another time:)

Also, I just learnt that ripgrep powers Visual Studio Code's search.

Benefits

Did I tell you that it's crazy fast?
It searches recursively by default.
It ignores hidden and binary files by default.
It respects .gitignore. It will skip listed files and directories by default.
You can restrict your search to specific filetypes.
It prints pretty.
It supports file encodings other than UTF-8.
It's crazy fast.

Gotchas

Doesn't have multiline search.
Since it uses threads heavily to do work, ripgrep's output is not deterministic. Tip: Pipe the output through sort.

It's not a drop-in replacement for GNU grep or ag though. So don't replace them with rg in scripts without testing.

Installation

If you have Rust toolchain (1.20 or newer) installed, you can install it using cargo. Add ~/.cargo/bin to $PATH if you haven't yet.

$ cargo install ripgrep

If you run bleeding-edge Arch, run

$ pacman -S ripgrep

Fedora users can install it using:

$ dnf install ripgrep

On macOS, run

$ brew install ripgrep

If you are worrying about having to type 3 more letters everytime you search and don't know what an alias is, don't worry. The binary is called just rg. (:

Usage

If you know how to use grep, you can use ripgrep. I'll just outline basic usage here though. Read the instructions on its GitHub page if you want to know everything about it.

To search any word recursively in a directory:

$ rg <keyword>

ripgrep's default behavior is to skip hidden and binary files apart from everything ignored by git. Use -uuu to disable that.

To search a keyword in only specific filetypes, pass the file extension to -t switch:

$ rg -tjs foo

To search a keyword in files matching the specified glob:

$ rg foo -g 'bar.*'

Basic Benchmarks

I ran simple benchmarks on my machine (Core i7 6500U, 8GB RAM, KDE neon 5.12.5 based on Ubuntu 16.04) using /usr/bin/time binary and ripgrep seems to beat GNU grep everytime (by a huge margin!).

$ /usr/bin/time rg -uu import > /dev/null # ~24 seconds

$ /usr/bin/time grep -r import * > /dev/null # ~3 min 27 seconds

Keep in mind that these are not scientific benchmarks by any means. Go to ripgrep's GitHub page for more comprehensive numbers.

This post was originally published on my website.