How check incoming request in Linux / ubuntu from port 443 – https

June 24, 2022 in Ubuntu

How check incoming request in Linux / ubuntu from port 443 – https

Check incoming request from port 443

$ netstat -an | grep 443

Check incoming request from port 443 with selected IP address

$ netstat -an | grep 443 | grep 103.173.93.2

Check incoming request from port 443 only ESTABLISHED connection

$ netstat -an | grep 443 | grep ESTABLISHED

Check number of incoming request from port 443

$ netstat -an | grep 443 | wc -l

June 13, 2022 in Ubuntu

check total incoming requests centos, linux, ubuntu

sudo netstat -anp |grep 80 | wc -l
sudo netstat -anp |grep 443 | wc -l

June 13, 2022 in Ubuntu

fin_wait2

The kernel timeout only applies if the connection is orphaned. If the connection is still attached to a socket, the program that owns that socket is responsible for timing out the shutdown of the connection. Likely it has called shutdown and is waiting for the connection to shut down cleanly. The application can wait as long as it likes for the shutdown to complete.

The typical clean shutdown flow goes like this:

1. The application decides to shut down the connection and shuts down the write side of the connection.
2. The application waits for the other side to shut down its half of the connection.
3. The application detects the other side’s shutdown of the connection and closes its socket.

The application can wait at step 2 for as long as it likes.

It sounds like the application needs a timeout. Once it decides to shut the connection down, it should give up waiting for the other side to do a clean shutdown after some reasonable amount of time.

June 13, 2022 in Ubuntu

client-side socket state 

• Server creates listening socket, binds it, etc.
• Server calls accept
• Client calls connect creating the connection (TCP state on both sides moves to ESTABLISHED
• send / recv / send / recv / etc (state still ESTABLISHED)
• Client calls close; client OS sends FIN packet to server (client OS moves socket state to FIN_WAIT1)
• Server OS sends ACK to acknowledge the client machine’s FIN (server OS moves socket state to CLOSE_WAIT; client OS moves socket state to FIN_WAIT2)
• Server (program) never closes its socket, and hence server OS never sends FIN, so client OS will maintain the socket in FIN_WAIT2 state. (Server socket state says in CLOSE_WAIT)

The client-side socket state could stay in FIN_WAIT2 state for a long time, or even forever, depending on the OS implementation. Linux, for example, has a tunable variable tcp_fin_timeout that specifies how long an otherwise idle connection will remain in FIN_WAIT2; but the TCP standard does not specify a time-out for FIN_WAIT2. (Note that the client program is not aware of any of this. It has closed the socket, the socket file descriptor has been destroyed and the socket is no longer accessible to it; this is all handled by the operating system.)

June 6, 2022 in Ubuntu

read text file in python

Create file named readfile.py

#!/usr/bin/python

import os
try:
    f = open("/home/directory/public_html/public/load.txt", "r")
    print(f.read())
    f.close()
    f.flush()
except IOError as (errno,strerror):
    print "I/O error({0}): {1}".format(errno, strerror)

run python file

$ python readfile.py

June 6, 2022 in Ubuntu

create text file in python

Create file named readfile.py

#!/usr/bin/python

import os
try:
    t = os.popen('uptime').read()[:-1]
    #print(t)
    f=open("/home/directory/public_html/public/load.txt", "a+")
    f.write("%s\r\n" %t)
    f.close()
    f.flush()
except IOError as (errno,strerror):
    print "I/O error({0}): {1}".format(errno, strerror)

run python file

$ python readfile.py