lsof常用参数
lsof 如果不加任何参数，就会打开所有被打开的文件，建议加上一下参数来具体定位
lsof -i 列出所有网络连接
lsof -i tcp 列出所有tcp连接信息
lsof -i udp 列出所有udp连接信息
lsof -i :3306 列出谁在使用某端口
lsof abc.txt 显示开启文件abc.txt的进程 (谁在使用某个文件)
lsof -u username 列出某用户打开的文件
lsof -c abc 显示abc进程现在打开的文件
lsof -c -p 1234 列出进程号为1234的进程所打开的文件
lsof -g gid 显示归属gid的进程情况
lsof +d /usr/local/ 显示目录下被进程开启的文件
lsof +D /usr/local/ 同上，但是会搜索目录下的目录，时间较长 lsof -d 4 显示使用fd为4的进程
lsof -i 用以显示符合条件的进程情况
lsof -i[46] [protocol][@hostname|hostaddr][:service|port] 46 --> IPv4 or IPv6 protocol --> TCP or UDP hostname --> Internet host name hostaddr --> IPv4地址 service --> /etc/service中的 service name (可以不止一个) port --> 端口号 (可以不止一个)
恢复删除的文件
当Linux计算机受到入侵时，常见的情况是日志文件被删除，以掩盖攻击者的踪迹。管理错误也可能导致意外删除重要的文件，比如在清理旧日志时，意外地删除了数据库的活动事务日志。有时可以通过lsof来恢复这些文件。 当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。 在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。 当系统中的某个文件被意外地删除了，只要这个时候系统中还有进程正在访问该文件，那么我们就可以通过lsof从/proc目录下恢复该文件的内容。假如由于误操作将/hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log文件删除掉了，那么这时要将hadoop-linyouyi-namenode-hadoop01.log文件恢复的方法如下： 首先使用lsof来查看当前是否有进程打开hadoop-linyouyi-namenode-hadoop01.log文件，如下：
[root@hadoop01 ~]# lsof | grep /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log java 83121 linyouyi 182w REG 202,2 63699885 983759 /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log java 83121 41206 linyouyi 182w REG 202,2 63699885 983759 /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log java 83121 41207 linyouyi 182w REG 202,2 63699885 983759 /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log
根据信息我们查一下83121的进程
[root@hadoop01 ~]# ls /proc/83121 attr comm fd map_files net pagemap sessionid status autogroup coredump_filter fdinfo maps ns personality setgroups syscall auxv cpuset gid_map mem numa_maps projid_map smaps task cgroup cwd io mountinfo oom_adj root stack timers clear_refs environ limits mounts oom_score sched stat uid_map cmdline exe loginuid mountstats oom_score_adj schedstat statm wchan [root@hadoop01 ~]# ls /proc/83121/fd 0 107 116 125 134 143 152 161 170 18 189 198 21 22 229 28 37 46 55 64 73 82 91 1 108 117 126 135 144 153 162 171 180 19 199 210 220 23 29 38 47 56 65 74 83 92 10 109 118 127 136 145 154 163 172 181 190 2 211 221 230 3 39 48 57 66 75 84 93 100 11 119 128 137 146 155 164 173 182 191 20 212 222 231 30 4 49 58 67 76 85 94 101 110 12 129 138 147 156 165 174 183 192 200 213 223 232 31 40 5 59 68 77 86 95 102 111 120 13 139 148 157 166 175 184 193 201 214 224 236 32 41 50 6 69 78 87 96 103 112 121 130 14 149 158 167 176 185 194 205 215 225 24 33 42 51 60 7 79 88 97 104 113 122 131 140 15 159 168 177 186 195 206 216 226 25 34 43 52 61 70 8 89 98 105 114 123 132 141 150 16 169 178 187 196 207 217 227 26 35 44 53 62 71 80 9 99 106 115 124 133 142 151 160 17 179 188 197 208 219 228 27 36 45 54 63 72 81 90 #发现182描述符是读取的hadoop01.log的文件 [root@hadoop01 ~]# ll /proc/83121/fd | grep hadoop-linyouyi-namenode-hadoop01.log l-wx------ 1 linyouyi linyouyi 64 Aug 11 12:17 182 -> /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log #如果能通过文件描述符查看相应数据,那么就可以使用 I/O 重定向将其复制到文件中，如: cat /proc/83121/fd/182 > /hadoop/module/hadoop-2.7.7/logs/hadoop-linyouyi-namenode-hadoop01.log 对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用
[root@hadoop01 ~]# tail -10 /proc/83121/fd/182 2019-09-10 12:46:29,780 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Quota initialization completed in 0 milliseconds name space=72 storage space=1611569721 storage types=RAM_DISK=0, SSD=0, DISK=46719, ARCHIVE=0 2019-09-10 12:46:29,780 INFO org.apache.hadoop.hdfs.server.namenode.ha.EditLogTailer: Loaded 2 edits starting from txid 57195 2019-09-10 12:47:29,804 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Initializing quota with 4 thread(s) 2019-09-10 12:47:29,804 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Quota initialization completed in 0 milliseconds name space=72 storage space=1611569721 storage types=RAM_DISK=0, SSD=0, DISK=46719, ARCHIVE=0