lsof用户及恢复日志文件

lsof这个命令大家可能有点陌生,因为平时很少用到。今天特意拿出来说一下,希望对做运维的朋友有点点帮助,也当是自己回忆一下知识点。

先来说说lsof最基本的参数:

lsof -i:(端口) 查看这个端口有那些进程在访问,比如22端口

[[email protected] fd]# lsof -i:22

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME

sshd      567 root    3r  IPv4 8956289      0t0  TCP bogon:ssh->bogon:51479 (ESTABLISHED)

sshd     1875 root    3u  IPv4   11442      0t0  TCP *:ssh (LISTEN)

sshd     1875 root    4u  IPv6   11444      0t0  TCP *:ssh (LISTEN)

sshd    32661 root    3r  IPv4 8949387      0t0  TCP bogon:ssh->bogon:50966 (ESTABLISHED)

从上面我们不难看出有两个会话于22端口,当你怀疑某个端口被黑客利用时,第一个办法就是用这个命令查一下有哪

些IP在访问此端口。

利用lsof可以恢复一些系统日志,前提是这个进程必须存在。这里就拿最常用的/var/log/messages来举例说明,大家

在做测试的时候最好先备份一下。

[[email protected]_backup ~]# lsof |grep /var/log/messages

syslogd    3477      root    2w      REG       8,6        418    2097231 /var/log/messages

进程在运行中,接下来我就把/var/log/messages这个文件删掉

[[email protected]_backup ~]# rm -rf  /var/log/messages

删掉之后,我再来看看这个进程的变化

[[email protected]_backup ~]# lsof |grep /var/log/messages

rsyslogd   1520      root    1w      REG       8,6     5344     786679 /var/log/messages (deleted)

大家看到有变化了吧, 对比两个之后发现多了(deleted)。要找到这个文件在哪还要看看这个

COMMAND:进程的名称

PID:进程标识符

USER:进程所有者

FD:文件描述符,应用程序通过文件描述符识别该文件。如cwd、txt等

TYPE:文件类型,如DIR、REG等

DEVICE:指定磁盘的名称

SIZE:文件的大小

NODE:索引节点(文件在磁盘上的标识)

NAME:打开文件的确切名称

PID:1520 FD:1 那我们有直接进入/proc/1520/FD/1用ls查看一下

lrwx------ 1 root root 64 01-16 08:32 0 -> socket:[6561]

l-wx------ 1 root root 64 01-16 08:32 2 -> /var/log/messages (deleted)

l-wx------ 1 root root 64 01-16 08:32 3 -> /var/log/secure

l-wx------ 1 root root 64 01-16 08:32 4 -> /var/log/maillog

l-wx------ 1 root root 64 01-16 08:32 5 -> /var/log/cron

l-wx------ 1 root root 64 01-16 08:32 6 -> /var/log/spooler

l-wx------ 1 root root 64 01-16 08:32 7 -> /var/log/boot.log

看到了2对应/var/log/messages (deleted)好,我看看文件是不是我们要的文件

[[email protected]_backup ~]# head -n 10 2

Jan 14 08:26:36 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:36 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:36 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:37 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:37 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:40 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:26:49 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 08:27:16 new90 avahi-daemon[1690]: Invalid query packet.

Jan 14 11:05:43 new90 dnsmasq[2085]: no servers found in /etc/resolv.conf, will retry

我看到更我以前数据的一样啊。可以恢复了

[[email protected]_backup ~]cat 2 > /var/log/messages

ok,我成功恢复了文件。

lsof用户及恢复日志文件,布布扣,bubuko.com

时间: 2024-10-11 23:21:10

lsof用户及恢复日志文件的相关文章

mysql数据库用户管理及日志文件

用户管理实际应用:MySQL数据库是信息系统中非常重要的一个环节, 默认有个root用户,但是这个用户权限太大,一般只在管理数据库时候才用.所以通常由管理员创建不同的管理账户,分配不同的操作权限,交给相应的人员使用.下面将详细介绍mysql数据库的用户创建.授权等操作.(一)用户查看: select user,authentication_string,host from user; (二)创建用户方法1: create user 'test01'@'localhost' identified

基于c++的日志文件实现

概述 所有的商业软件或线上系统都具有日志功能,因为日志信息提供了系统启动以来的重要的操作或状态迁移记录,是追踪各种异常错误的第一手资料.绝大部分系统的日志模块会自动保留历史日志文件,即:日志文件大小达到约定上限时,自动转储到一个新的历史文件,当前文件清空并继续记录新的日志信息,例如:假设当前日志文件名为test.log, 当它的大小到达上限(例如10MB)时,就把其文件内容转储到新文件test.log.1, 然后test.log清空并继续记录新信息.根据配置不同,我们可以保留1到N份历史日志文件

日志文件写入失败(permission denied)

用过Laravel的小伙伴一开始安装完框架后可能都遇到过daily 日志文件写入失败的问题,接下来我们就来详细说下日志文件写入失败的原因以及对应的解决方案. 在讲这个问题之前可能需要简单介绍下Linux系统下的文件的Ownership和Permission. Ownership User User是文件的所有者,默认情况下,用户创建了一个文件,该文件的所有者就是该用户. Group 一个用户组能包含多个用户,所有属于这个组的用户都有相同的权限来访问文件.假设你有一个项目,很多用户都需要访问这个项

使用lsof回复误删日志文件或数据库

查找谁在使用文件系统 在卸载文件系统时,如果该文件系统中有任何打开的文件,操作通常将会失败.那么通过lsof可以找出那些进程在使用当前要卸载的文件系统,如下: # lsof /GTES11/ COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME bash 4208 root cwd DIR 3,1 4096 2 /GTES11/ vim 4230 root cwd DIR 3,1 4096 2 /GTES11/ 在这个示例中,用户root正在其/GTES1

记录SQL Server2008日志文件损坏的恢复过程

记录SQL Server2008日志文件损坏的恢复过程: 环境:系统Windows Server2003 数据库SQL Server2008 故障原因:通过mstsc链接同一服务器时,用户界面不一致.决定重启服务器,未正确关闭应用程序的情况下(程序在访问数据库),导致数据库日志文件损坏,自然也就无法访问mdf文件!(都是微软自家的产品,重启服务器为什么不能检查数据库的状态,将数据库设置在安全状态后在重启呢??所以,要养成良好的习惯.关闭现有数据库链接,再重启服务器) 故障表现:无法访问数据文件,

人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程

有人因为不熟悉InnoDB引擎,而误删除innoDB ibdata(数据文件)和ib_logfile(redo log重做事务日志文件),结果导致了悲剧的发生.如果有做主从复制同步那还好,如果是单机呢?如何恢复? 1)使用rm –f ib* 删除数据文件和重做日志文件 下面就来使用具体看看如何恢复. 若此时你发现数据库还可以正常工作,数据照样可以写入,切记,这时千万别把mysqld进程杀死,否则没法挽救. 先找到mysqld的进程pid,如下所示. mysql01:/data/mysql3306

实验:模拟场景中误删除mysql数据库表,然后使用全备份以及二进制日志文件恢复操作

一.实验环境: 1.准备两台虚拟机,一台用于破坏数据库,一台用于还原,两台在同一个网络 2.两台最小化安装centos 7系统,并直接yum安装maraidb数据库 3.准备一个测试数据库文件,例如,hellodb_innodb.mysql 测试库里面最少有两个表. 二.实验步骤: 1.开启数据库的二进制日志功能 vim /etc/my.cnf[mysqld] 下面加入log-bin 表示开启二进制日志功能 2.完全备份 mysqldump -A -F --master-data=2 --sin

数据库恢复之丢失联机重做日志文件的恢复

联机重做日志文件用来循环记录ORACLE数据库的所有操作,几乎时刻都在读写,因此单纯备份某个时间点的联机重做日志文件没有意义,恢复时根本用来上.RMAN的备份里根本就没有备份联机重做日志的功能,而且不止RMAN,所有的备份软件都没有备份联机重做日志文件的说法.因此,丢失联机重做日志后的数据库恢复也用不到RMAN. 如果ORACLE数据库在启动时发现丢失某一某一联机重做日志文件,则直接报错.ORACLE通过文件冗余的方式来确保联机重做日志文件的安全.即每组联机重做日志创建 多个文件,至少两个,每个

RMAN数据库恢复之恢复归档日志文件

恢复归档日志文件如果只是为了在恢复数据文件之后应用归档文件,那并不需要手动对归档文件进行恢复,RMAN会在RECOVER时自动对适当的归档进行恢复.单独恢复归档文件一般是有特别的需求,如创建了Data Guard环境.Standby端丢失了部分归档文件,需要从Primary端重新获取.1.恢复全部归档日志文件RMAN> RESTORE ARCHIVELOG ALL; 2.恢复归档序号为20至30之间的归档文件RMAN> RESTOER ARCHIVELOG SEQUENCE BETWEEN 2