Due to the socket communication encountered in the project recently, a TCP connection was established with the server, but the data to be sent to the server was not sent. The reason for the analysis not sent may be: the application process closed the file descriptor 0, Then the socket obtains 0 as the file descriptor for socket communication, and then the establishment of TCP is successful, but because 0 is the standard input file descriptor of the system, the data sent is abnormal.
The above reasons are just speculation, and there is no definite evidence. Just this morning, I found that the equipment at the scene could not send messages, so I wanted to check the situation myself and find the exact evidence of the reason, so I asked Du Niang for relevant information, Du Niang Say, to view the relevant details of the process, it is in the directory under /proc/PID/. The following takes the process number 820 as an example. I want to see what file descriptor 0 is used for, use the command
ls -l /proc/820/fd 或 ll /proc/820/fd
The command will list the detailed information of each file under fd, and you can see the file corresponding to each file descriptor, or its purpose.
The result of running the command on my faulty device is as follows:
[root@jx fd]#ll /proc/820/fd
total 0
dr-x------ 2 root root 0 Aug 7 08:30 .
dr-xr-xr-x 7 root root 0 Jul 31 10:10 ..
lrwx------ 1 root root 64 Aug 7 09:13 0 -> socket:[26598188]
l-wx------ 1 root root 64 Aug 7 09:13 1 -> /dev/null
l-wx------ 1 root root 64 Aug 7 09:13 2 -> /dev/null
lrwx------ 1 root root 64 Aug 7 09:13 3 -> /mnt/database/Configdb.db
lrwx------ 1 root root 64 Aug 7 09:13 4 -> /mnt/database/RetransmitData.db
lrwx------ 1 root root 64 Aug 7 09:13 5 -> /mnt/database/Hisdatadb.db
lrwx------ 1 root root 64 Aug 7 09:13 6 -> /mnt/database/Curdatadb.db
File description 0 is used for socket connections, which clearly proves my guess here.