ss – utility to investigate sockets.

Sometimes, you find some interesting application/command by accident, and that is just what happened a few days back. Well, I was doing a ssh and as usual made my share of mistake in typing and missed the “h” from the ssh command and saw a list of options instead of my prompt on remote server.

Now, that set me thinking and fond that its a very interesting command that comes with iproute on Fedoara, so if you want this command, then install iproute like this

1
 sudo yum install iproute

and then you can see the help with

1
man ss

 

By default, without any options you will see a list of all open sockets on your system.

There are a lot of options that you can use and couple of them are very interesting a useful.

-m — shows the memory

p — process associated with the socket.

-i — shows the TCP internal information

There are some other options which you might find useful.

Enhanced by Zemanta

[Solved] ssh works but scp does not

Structure of an SSH binary packet
Image via Wikipedia

For quite sometime now, I was having this issue, that for the home system, I was able to connect to is using ssh but it never worked. Fnally after quite some debugging finally I found that the issue was with thebashrc. So, everytime I had to do a scp I would have to move/rename bashrc and do the reverse action after the scp was done.

Finally today I fixed it and the solution was very simple. I put the offending code or rather complete bashrc in the loop as mentioned below:

 

1
2
3
4
5
6
7
if [[ $SSH_CLIENT = "" ]

then

<bashrc code here>

fi

By doing this the <dot>bashrc is never executed when a ssh session is initiated (which is what happens for scp also). đŸ™‚

Enhanced by Zemanta

faster bash operations on files with File Descriptors.

I was writing a bash script that would do some operations and read and write to file. Seems that that was pretty simple with

1
2
3
4
5
while read line

do

done<file

and then use redirection operations like “>” and “>>” to write to file. Done with the script pretty fast. So far so good, when I went for real life tests, no one was interested in using it, why? Simple, it was simply taking too long. The file was reading about 10K lines and writing about 50 lines and was taking about more than 10 minutes.

So, I sat down to debug what can increase the performance of the script and one change made the difference. The script was taking a lot of time in opening and closing the file. Pretty evident, isn’t it!!!

When using “>” or “>>”, each operation would require bash to open the file, write to it and close it. Un-necessarily we would be doing a open and close for each write operation. Pathetic and useless waste of CPU power and time. How to avoid this?

Open a file and get the file descriptor. Keep writing to the file descriptor and close the descriptor after you are done with the file operations.

1
2
3
4
5
exec 3> File

echo "" >&3

exec 3>&-

In the above commands,

1
 exec 3> File

will open the file descriptor FD 3

Note that when you are working with FD, you don’t need  “>>” as the echo command will put the statements in the current position of file. So, if you want to append to the file use

1
exec 3>> File

Then you can write to the FD with redirection and finally close the descriptor with

1
 exec 3>&-

HTH

Enhanced by Zemanta