手动执行logrote 测试命令
logrotate -d debug 调试
-f force 强制执行， 跟想要执行的 日志轮询的 单独配置文件
配置文件 ，参数 create 和 copytruncate 的区别：
总的说 就是 create = mv + cerate , copytruncate = cp + echo > log file
详情如下：
1）create：
这也就是默认的方案，可以通过 create 命令配置文件的权限和属组设置；这个方案的思路是重命名原日志文件，创建新的日志文件。详细步骤如下：
-
重命名正在输出日志文件，因为重命名只修改目录以及文件的名称，而进程操作文件使用的是 inode，所以并不影响原程序继续输出日志。
-
创建新的日志文件，文件名和原日志文件一样，注意，此时只是文件名称一样，而 inode 编号不同，原程序输出的日志还是往原日志文件输出。
-
最后通过某些方式通知程序，重新打开日志文件；由于重新打开日志文件会用到文件路径而非 inode 编号，所以打开的是新的日志文件。
如上也就是 logrotate 的默认操作方式，也就是 mv+create 执行完之后，通知应用重新在新文件写入即可。mv+create 成本都比较低，几乎是原子操作，如果应用支持重新打开日志文件，如 syslog, nginx, mysql 等，那么这是最好的方式。
不过，有些程序并不支持这种方式，压根没有提供重新打开日志的接口；而如果重启应用程序，必然会降低可用性，为此引入了如下方式。
2）copytruncate：
该方案是把正在输出的日志拷 (copy) 一份出来，再清空 (trucate) 原来的日志；详细步骤如下：
-
将当前正在输出的日志文件复制为目标文件，此时程序仍然将日志输出到原来文件中，此时，原文件名也没有变。
-
清空日志文件，原程序仍然还是输出到预案日志文件中，因为清空文件只把文件的内容删除了，而 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