长话短说 – 我设法搞砸了Centos 7服务器上的rsyslogd服务。 现在只有在/ var / log / messages中出现的是：
12月14日22:13:27 {myhostname} rsyslogd：[origin software =“rsyslogd”swVersion =“7.4.7”x-pid =“1286”x-info =“http://www.rsyslog.com”]退出开信号15。
Dec 14 22:13:27 {myhostname} rsyslogd：[origin software =“rsyslogd”swVersion =“7.4.7”x-pid =“1477”x-info =“http://www.rsyslog.com”] start
其他日志（安全，cron等）也是空的。 重新启动服务和服务器没有帮助。 使用logging器发送的消息不会以/ var / log / messages文件结束。 rsyslogd服务正在运行。 configuration文件似乎是正确的。 我可以看到journalctl日志中的所有事件。 我已经search了几个类似于我的问题的post，但没有一个解决scheme。
虽然最快的解决scheme可能是重新安装服务器，但我想弄清楚是什么引起了这个问题，以及如何解决它，以防万一它发生在未来。 服务器正在运行简单的LEMP堆栈，最后一次重大更改是系统主机名更改。
这是解决scheme，但不是永久性的：
rm -f /var/lib/rsyslog/imjournal.state
服务rsyslog重新启动
来源： https ： //bugzilla.redhat.com/show_bug.cgi？id = 1088021
你可以尝试debuggingrsyslog来找出导致它出现故障的问题。
从正在运行的实例获取debugging信息
从正在运行的实例中获取debugging信息是可能的，但是这需要一些设置。 我们假定实例在后台运行，所以不需要将输出debugging到标准输出。 因此，所有debugging信息都需要进入日志文件。
要创build此设置，需要将
RSYSLOG_DEBUGLOG环境variables指向在运行时期间可以访问的文件（我们强烈build议在本地文件系统中使用文件！）至less将DebugOnDeman NoStdOut设置为DebugOnDeman NoStdOut确保设置了这些环境variables在正确的（distro-specifc）启动脚本中，如果你不交互运行rsyslogd这些设置使得能够对SIGUSR1做出反应。 信号将在收到时切换debugging状态。 所以发送一个打开debugginglogin，并再次发送它closuresdebugging注销。 第三次它会再次打开…等等。
在一个典型的系统上，你可以用rsyslogd来表示如下：
kill -USR1 `cat /var/run/rsyslogd.pid`重要提示：“猫”命令周围有反响。 如果您使用正常的报价，它将无法正常工作。 debugging日志将显示debugging日志logging是否已打开或closures。 没有其他状态的迹象。
一步一步如何在这里： 如何使用debugging点播？
这是我的解决scheme – 不是很好，当然你放弃了所有的日记：
rm -rf /var/log/journal/* reboot
我仍然不确定为什么一切都开始了，因为我所做的只是在正常运行6个月后重新启动。