2

For our file transmission and manual storage we have a simple RHEL server on which all other Linux clients are connecting by SSH.

Whenever any client wants to access/store data, they connect to the server via nautilus and the connection remain established even if data transmission ceases, until its unmounted manually OR the client shuts down their system.

When I monitored the CPU usage on the server, most of CPU usage is due to these established connections.

[root@server]# top

top - 11:22:13 up  2:36,  6 users,  load average: 2.79, 2.19, 1.90

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                         
17247 share     20   0 55640 1924  972 S 26.7  0.1   7:36.72 sftp-server                                                                                                                                                                     
17900 share     20   0 55640 1932  972 S 17.5  0.1  10:16.45 sftp-server                                                                                                                                                                     
26152 share     20   0 55596 1872  972 S 17.5  0.1   8:12.04 sftp-server                                                                                                                                                                     
17487 share     20   0 55636 1864  972 R 15.5  0.1   9:58.56 sftp-server                                                                                                                                                                     
 2852 root      20   0  195m  55m 7872 R 13.8  2.7  17:01.72 X                                                                                                                                                                               
11768 share     20   0 55560 1684  832 S  8.9  0.1   3:12.00 sftp-server                                                                                                                                                                     
17486 share     20   0 98172 1884  784 R  8.2  0.1   4:48.35 sshd                                                                                                                                                                            
26151 share     20   0 98236 1872  784 S  7.9  0.1   4:03.29 sshd                                                                                                                                                                            
17899 share     20   0 98204 1916  784 S  7.2  0.1   5:00.17 sshd                                                                                                                                                                            
12569 tejas     20   0  322m  11m 7808 S  5.9  0.6   0:28.12 gnome-system-mo                                                                                                                                                                 
17246 share     20   0 98204 1840  784 S  5.9  0.1   3:33.18 sshd                                                                                                                                                                            
11767 share     20   0 98008 1716  772 S  4.3  0.1   1:28.73 sshd                                                                                                                                                                            
15168 tejas     20   0  989m  64m  18m S  0.7  3.2   0:01.31 chrome                                                                                                                                                                          
 4077 tejas     20   0  109m 9312 5584 S  0.3  0.5  24:26.08 App                                                                                                                                                                             
11360 tejas     20   0  304m  10m 5144 S  0.3  0.5   0:05.23 gnome-terminal                                                                                                                                                                  
14236 root      20   0 15168 1380  928 R  0.3  0.1   0:00.36 top                                                                                                                                                                             
    1 root      20   0 19324 1056  844 S  0.0  0.1   0:00.67 init                                                                                                                                                                            
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                                                                                                                                        

So I am looking for a automatic way to unmount that ssh connection if no data is flowing say for 10 minutes or so, Or any other idea to minimize this CPU usage.
EDIT: After slm's comment,can you explain how they're connecting from Nautilus?
Here is how clients normally connected to the server by SSH.

  • Enter required Fields and enter Password :

enter image description here

enter image description here

  • Transfer/Create File/s.

enter image description here

  • Wait for 30 Min after closing the directory.
  • Still showing connection...

enter image description here

  • Yes @slm, i did – Tejas Apr 17 '14 at 14:07
  • 2
    An idle connection should not be using any CPU. What is going on with this connection (tcpdump, wireshark, …)? What are the sftp-server processes doing (strace)? Could this be a known bug in your version? – Gilles Apr 17 '14 at 23:34
2

Method #1 - Using timeouts via SSHD/SFTPD

If the connections are over SSH you can set these settings on the SSHD's side in the config file /etc/ssh/sshd_config.

ClientAliveInterval 30
ClientAliveCountMax 5

Where these settings have the effect:

  • ClientAliveInterval: Sets a timeout interval in seconds (30) after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only.

  • ClientAliveCountMax: Sets the number of client alive messages (5) which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session.

To get 10 minutes you'll need to adjust the times accordingly, perhaps like this:

ClientAliveInterval 120
ClientAliveCountMax 5

Method #2 - Using cutter

If the above methods do not work then it's entirely possible that the client is making use of a keep-alive which is artificially propping up the low trafficked connection. If this is your situation then your limited to what actions you can take to disconnect these otherwise idle connections.

One method would be to develop a cronjob that would watch for connections that have been idle for a particular period of time, say 10 minutes in your scenario.

Once this script has detected one of these connections, you could use a command such as cutter to tell the client to disconnect, against their will.

$ cutter <ip> <port>

Example

$ cutter 192.168.1.20 22

NOTE: Cutter should be in most of the major distros' repositories. I was able to install it on Fedora/CentOS/RHEL as well as Debian/Ubuntu in this manner.

Debugging the connections

@Gilles brought up an excellent point in the comments under your Q that idle connections should really not be causing any CPU load. The fact that all these sftp-server processes are causing what I would consider is significant load (20-30%) in top would seem to indicate that something is going on.

To start I would use strace and connect to one of the sftp-server processes to see what it's up to. For example to connect to PID 17247:

$ sudo strace -p 17247

See if it's actually doing anything. It really shouldn't be. You could also use tcpdump or wireshark to monitor the network traffic going back and forth between Nautilus and sftp-server as well.

References

  • NOT working for nautilus, I have changed /etc/ssh/sshd_config -> ClientAliveInterval 200, restarted sshd service, and waiting from more than 15 Min. – Tejas Apr 17 '14 at 7:21
  • @Tejas - can you explain how they're connecting from Nautilus? What do the URL's look like in the address bar when they're connecting. I believe it's possible that the clients are sending their own keep alives, which would be overriding this setting too. – slm Apr 17 '14 at 7:25
  • 1
    @Tejas - Also be sure to use the times that I provided. Those aren't wrong. It maintains the connection for 120 seconds, at which time the server sends a "are you there packet" to the client. It does this 5 times and then takes the connection down. (120 * 5 = 600 secs). – slm Apr 17 '14 at 7:27
  • please see update – Tejas Apr 17 '14 at 9:53
  • @Tejas - did you restart SSHD after making the above changes? service sshd restart. – slm Apr 17 '14 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.