logrotate

手动执行logrote 测试命令

logrotate -d  debug 调试

 -f  force  强制执行, 跟想要执行的 日志轮询的 单独配置文件

 

配置文件 ,参数  create 和   copytruncate  的区别:

总的说 就是 create = mv + cerate , copytruncate = cp + echo > log file 

详情如下:

1)create:

这也就是默认的方案,可以通过 create 命令配置文件的权限和属组设置;这个方案的思路是重命名原日志文件,创建新的日志文件。详细步骤如下:

  1. 重命名正在输出日志文件,因为重命名只修改目录以及文件的名称,而进程操作文件使用的是 inode,所以并不影响原程序继续输出日志。

  2. 创建新的日志文件,文件名和原日志文件一样,注意,此时只是文件名称一样,而 inode 编号不同,原程序输出的日志还是往原日志文件输出。

  3. 最后通过某些方式通知程序,重新打开日志文件;由于重新打开日志文件会用到文件路径而非 inode 编号,所以打开的是新的日志文件。

如上也就是 logrotate 的默认操作方式,也就是 mv+create 执行完之后,通知应用重新在新文件写入即可。mv+create 成本都比较低,几乎是原子操作,如果应用支持重新打开日志文件,如 syslog, nginx, mysql 等,那么这是最好的方式。

不过,有些程序并不支持这种方式,压根没有提供重新打开日志的接口;而如果重启应用程序,必然会降低可用性,为此引入了如下方式。

2)copytruncate:

该方案是把正在输出的日志拷 (copy) 一份出来,再清空 (trucate) 原来的日志;详细步骤如下:

  1. 将当前正在输出的日志文件复制为目标文件,此时程序仍然将日志输出到原来文件中,此时,原文件名也没有变。

  2. 清空日志文件,原程序仍然还是输出到预案日志文件中,因为清空文件只把文件的内容删除了,而 inode 并没改变,后续日志的输出仍然写入该文件中。

如上所述,对于 copytruncate 也就是先复制一份文件,然后清空原有文件。

通常来说,清空操作比较快,但是如果日志文件太大,那么复制就会比较耗时,从而可能导致部分日志丢失。不过这种方式不需要应用程序的支持即可。

 

 

说下: ssh 从 客户端向服务器连接时  出现   REMOTE HOST IDENTIFICATION HAS CHANGED

前提条件:  从跳板机 用  公钥连接 会出现这个错误, 

 

原因: 从跳板机 用账号  用 公钥连接时, 每次ssh 连接成功后, 客户端,即 跳板机,你的账号下 有一个 known_hosts 文件,路径:  ~/.ssh/known_hosts ,存储的是每次 ssh 连接后 的 被连接机器的 指纹

 

格式: 目标IP:端口(如果ssh 用的22 端口,默认不加,)   空格  指纹

如果一台机器重装了( 每次系统重装后,ssh 生成的系统指纹都不一样,即使 对 同一台机器而言),机器指纹变了,但 跳板机存储的指纹是 机器 上一个系统对应的指纹,会出现报错 REMOTE HOST IDENTIFICATION HAS CHANGED 

 

解决办法: 将机器公钥信息从跳板机的 known_hosts 文件里删除, 新的连接建联成功会,会将新的公钥信息重新写入。

 

注意区别是   跳板机记录的某台机器 指纹信息(唯一)  和  服务器本身的  指纹信息。(服务器公钥怎么在服务器上查看,????)和 服务器的某个用户的公钥信息。

 

更改连接服务器 时,不验证指纹信息,不记录指纹信息:

改如下配置,跳板机上: 

. 修改配置文件“~/.ssh/config”,加上这两行,重启服务器。
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null

 

posted @ 2019-10-14 20:33  BRUCECSDN  阅读(240)  评论(0编辑  收藏  举报