配置文件详解

[Journal]
#Storage=persistent
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
ForwardToSyslog=yes
ForwardToKMsg=no
ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelKMsg=notice
MaxLevelConsole=info
#MaxLevelWall=emerg

SplitMode:Controls whether to split up journal files per user. One of "uid", "login" and "none". If "uid", all users will get each their own journal
           files regardless of whether they possess a login session or not, however system users will log into the system journal. If "login", actually
           logged-in users will get each their own journal files, but users without login session and system users will log into the system journal. If
           "none", journal files are not split up by user and all messages are instead stored in the single system journal. Note that splitting up journal
           files by user is only available for journals stored persistently. If journals are stored on volatile storage (see above), only a single journal
           file for all user IDs is kept. Defaults to "uid".

Seal:默认开启，保护journal file日志文件不会被篡改，sealing key可以通过：journalctl(1)'s --setup-keys命令获得，Forward Secure Sealing (FSS) for all persistent journal files is enabled.

SYSLOG(3)

Journal Export Format

Note that this document describes the binary serialization format of journals only, as used for transfer across the network. For interfacing with web technologies there's the Journal JSON Format. The binary format on disk is documented as Journal File Format. Before reading on, please make sure you are aware of the basic properties of journal entries, in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't).

这么看journal有几种格式：

  • ‘binary serialization format’，also 'Journal Export Format',used for transfer across the network
  • 'Journal JSON Format',For interfacing with web technologies
  • 'binary format ',he binary format on disk is documented as Journal File Format

systemd-journald行为方式

lsof -p $(pidof /usr/lib/systemd/systemd-journald)

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#cat /etc/systemd/journald.conf
[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
SystemMaxFileSize=8M
SystemMaxFiles=4
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
ForwardToSyslog=yes
ForwardToKMsg=no
ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelKMsg=notice
MaxLevelConsole=info
#MaxLevelWall=emerg

SystemMaxFiles 参数貌似没有起到作用！！！

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#ll
total 180280
-rw-r-----  1 root root 8388608 Sep 13 17:23 system@95b85109e44b4ea89ce66e094c94279b-0000000000004e88-00053c5ff5809def.journal
-rw-r-----  1 root root 8388608 Sep 13 17:25 system@95b85109e44b4ea89ce66e094c94279b-0000000000006e68-00053c602bb61502.journal
-rw-r-----  1 root root 8388608 Sep 13 17:27 system@95b85109e44b4ea89ce66e094c94279b-0000000000009f12-00053c60322d04c3.journal
-rw-r-----  1 root root 8388608 Sep 13 17:29 system@95b85109e44b4ea89ce66e094c94279b-000000000000cb31-00053c6038479d6c.journal
-rw-r-----  1 root root 8388608 Sep 13 17:29 system@95b85109e44b4ea89ce66e094c94279b-000000000000f4be-00053c603ebe24f1.journal
-rw-r-----  1 root root 8388608 Sep 13 17:30 system@95b85109e44b4ea89ce66e094c94279b-000000000001160d-00053c6041a0db53.journal
-rw-r-----  1 root root 8388608 Sep 13 17:31 system@95b85109e44b4ea89ce66e094c94279b-0000000000013963-00053c6045174c27.journal
-rw-r-----  1 root root 8388608 Sep 13 17:32 system@95b85109e44b4ea89ce66e094c94279b-00000000000158cf-00053c604839c78f.journal
-rw-r-----  1 root root 8388608 Sep 13 17:33 system@95b85109e44b4ea89ce66e094c94279b-0000000000016f16-00053c6049a0781f.journal
-rw-r-----  1 root root 8388608 Sep 13 17:33 system@95b85109e44b4ea89ce66e094c94279b-0000000000019a25-00053c604e8e6c3e.journal
-rw-r-----  1 root root 8388608 Sep 13 17:35 system@95b85109e44b4ea89ce66e094c94279b-000000000001a953-00053c604eca2bf0.journal
-rw-r-----  1 root root 8388608 Sep 13 17:37 system@95b85109e44b4ea89ce66e094c94279b-000000000001d162-00053c6054d3d62b.journal
-rw-r-----  1 root root 8388608 Sep 13 17:39 system@95b85109e44b4ea89ce66e094c94279b-000000000001fb55-00053c605bd49733.journal
-rw-r-----  1 root root 8388608 Sep 13 17:40 system.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:23 user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000004ef3-00053c5ffc035f5e.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:29 user-120063@eca90592d5664b05b2105e0c4e422d85-000000000000d096-00053c60386fd583.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:30 user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000012a78-00053c60434097e3.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:33 user-120063@eca90592d5664b05b2105e0c4e422d85-00000000000176ad-00053c604a4e7164.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:39 user-120063@eca90592d5664b05b2105e0c4e422d85-000000000001fda6-00053c605c2d0517.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:40 user-120063.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:23 user-122575@a0ae95f91a2f430d8869228a5c1d142f-0000000000004eb3-00053c5ff957f41a.journal
-rw-r-----+ 1 root root 8388608 Sep 13 17:40 user-122575.journal

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#du -sh *
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000004e88-00053c5ff5809def.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000006e68-00053c602bb61502.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000009f12-00053c60322d04c3.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000000cb31-00053c6038479d6c.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000000f4be-00053c603ebe24f1.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001160d-00053c6041a0db53.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000013963-00053c6045174c27.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-00000000000158cf-00053c604839c78f.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000016f16-00053c6049a0781f.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000019a25-00053c604e8e6c3e.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001a953-00053c604eca2bf0.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001d162-00053c6054d3d62b.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001fb55-00053c605bd49733.journal
8.1M    system.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000004ef3-00053c5ffc035f5e.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000000d096-00053c60386fd583.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000012a78-00053c60434097e3.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-00000000000176ad-00053c604a4e7164.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000001fda6-00053c605c2d0517.journal
8.0M    user-120063.journal
8.0M    user-122575@a0ae95f91a2f430d8869228a5c1d142f-0000000000004eb3-00053c5ff957f41a.journal
8.0M    user-122575.journal

前面SystemMaxFileSize=8M，

现在修改为如下：

SystemMaxFileSize=20M，然后执行：systemctl daemon-reload;systemctl restart systemd-journald;

继续狂打日志：for i in seq 1 20000;do logger -p authpriv.info hello$i;done

按照我的猜想，后面的文件最大，应该只有20M左右了吧，于是开始打日志，打了一会儿，发现还是8M，多打一会儿日志后，后面滚动的文件大小确实差不多是20M了，看来不是立即生效，很让人费解；

如下，你可以看到滚动后产生的靠近20M的文件了，但是，还是不知道究竟什么时候开始删除之前的文件；究竟可以保存多少个文件？？？

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#du -sh *
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000004e88-00053c5ff5809def.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000006e68-00053c602bb61502.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000009f12-00053c60322d04c3.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000000cb31-00053c6038479d6c.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000000f4be-00053c603ebe24f1.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001160d-00053c6041a0db53.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000013963-00053c6045174c27.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-00000000000158cf-00053c604839c78f.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000016f16-00053c6049a0781f.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000019a25-00053c604e8e6c3e.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001a953-00053c604eca2bf0.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001d162-00053c6054d3d62b.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-000000000001fb55-00053c605bd49733.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000022537-00053c6062d58196.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000024f10-00053c6069d64213.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-00000000000278e2-00053c6070d787d1.journal
17M     system@95b85109e44b4ea89ce66e094c94279b-000000000002a1a4-00053c607a097db8.journal
8.0M    system.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000004ef3-00053c5ffc035f5e.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000000d096-00053c60386fd583.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000012a78-00053c60434097e3.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-00000000000176ad-00053c604a4e7164.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000001fda6-00053c605c2d0517.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000024151-00053c60674ac34c.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000026981-00053c606e1343f0.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000002a927-00053c607ff1def4.journal
8.0M    user-120063.journal
8.0M    user-122575@a0ae95f91a2f430d8869228a5c1d142f-0000000000004eb3-00053c5ff957f41a.journal
8.0M    user-122575.journal

另外发现，之前将journal文件改为persistent后，/run/log/journal/613fd1717b844226af5ea83f4849d6dd目录下的文件的数量并没有随即自动删除。

root@srmbuffer010242252156.cloud.dg /run/log/journal/613fd1717b844226af5ea83f4849d6dd]
#systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Tue 2016-09-13 17:47:23 CST; 12min ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 53736 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─53736 /usr/lib/systemd/systemd-journald

Sep 13 17:47:23 srmbuffer010242252156.cloud.dg systemd-journal[53736]: Permanent journal is using 216.0M (max allowed 4.0G, trying to leave 4.0G free…t 4.0G).
Sep 13 17:47:23 srmbuffer010242252156.cloud.dg systemd-journal[53736]: Journal started

当前可以发现，现在已经使用了216.0M ，但是最多可以使用4.0G；

于是，我们修改：

SystemMaxUse=100M

看看什么报错：

#systemctl daemon-reload;
#systemctl restart systemd-journald
[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Tue 2016-09-13 18:02:15 CST; 6s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 5270 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─5270 /usr/lib/systemd/systemd-journald

Sep 13 18:02:15 srmbuffer010242252156.cloud.dg systemd-journal[5270]: Permanent journal is using 264.0M (max allowed 100.0M, trying to leave 4.0G fre…264.0M).
Sep 13 18:02:15 srmbuffer010242252156.cloud.dg systemd-journal[5270]: Journal started

结果，发现没有什么报错，反而是/var/log/journal/目录下的，老旧的文件被删除了；

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#du -sh *
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000022537-00053c6062d58196.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-0000000000024f10-00053c6069d64213.journal
8.1M    system@95b85109e44b4ea89ce66e094c94279b-00000000000278e2-00053c6070d787d1.journal
17M     system@95b85109e44b4ea89ce66e094c94279b-000000000002a1a4-00053c607a097db8.journal
17M     system@95b85109e44b4ea89ce66e094c94279b-000000000002c796-00053c608966f4f5.journal
8.1M    system.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000001fda6-00053c605c2d0517.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000024151-00053c60674ac34c.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-0000000000026981-00053c606e1343f0.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000002a927-00053c607ff1def4.journal
8.0M    user-120063@eca90592d5664b05b2105e0c4e422d85-000000000002c9a0-00053c608b0fc119.journal
8.0M    user-120063.journal
8.0M    user-122575.journal

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#du -sh /var/log/journal/613fd1717b844226af5ea83f4849d6dd
121M    /var/log/journal/613fd1717b844226af5ea83f4849d6dd

按照这个逻辑，我继续写大量日志，应该找个目录大小不会增加了吧。只会删除老旧文件：

测试一下：

[root@srmbuffer010242252156.cloud.dg /var/log/journal/613fd1717b844226af5ea83f4849d6dd]
#for i in `seq 1 20000`;do logger -p authpriv.info test$i;done
Sep 13 18:41:35 srmbuffer010242252156.cloud.dg systemd-journal[5270]: Suppressed 18998 messages from /user.slice/user-122575.slice

哟呵，日志被抑制了；不过，看来，日志文件有多少个，是根据总的可用空间决定；比如：我们只有SystemMaxUse=100M可用空间，SystemMaxFileSize=20M设置单个journal文件大小只有20的话，那基本上只会保存5个历史文件左右；

systemd-journald详解的更多相关文章

  1. systemd服务详解-技术流ken

    简介 在centos5中生成和管理用户空间中的进程以及完成系统的初始化使用的是init,并且是依次启动.在centos6中则是使用的upstart,在一定程度上实现了并行启动,但是仍然存在依赖关系,到 ...

  2. CentOS7进程管理systemd详解

      概述: 系统启动过程中,当内核启动完成,后加载根文件系统,后就绪的一些用户空间的服务的管理工作,就交由init进行启动和管理,在CentOS6之前的init的管理方式都类似,相关的内容我们在之前的 ...

  3. centos7上systemd详解

    centos7上systemd详解  发表于 2016-06-07 |  分类于 linux CentOS 7继承了RHEL 7的新的特性,例如强大的systemd, 而systemd的使用也使得以往 ...

  4. cetos7 systemd 详解

      CentOS7/RHEL7 systemd详解 目录1. 为什么是systemd(1) 关于Linux服务管理(2) SysV init的优缺点(3) UpStart的改进(4) systemd的 ...

  5. systemd详解

    CentOS 7 使用systemd替换了SysV.Systemd目的是要取代Unix时代以来一直在使用的init系统,兼容SysV和LSB的启动脚本,而且够在进程启动过程中更有效地引导加载服务. s ...

  6. CentOS 7 中 Systemd详解

    一.systemd的由来 Linux一直以来采用init进程但是init有两个缺点: 1.启动时间长.Init进程是串行启动,只有前一个进程启动完,才会启动下一个进程.(这也是CentOS5的主要特征 ...

  7. linux systemd详解

    CentOS 7 使用systemd替换了SysV.Systemd目的是要取代Unix时代以来一直在使用的init系统,兼容SysV和LSB的启动脚本,而且够在进程启动过程中更有效地引导加载服务. s ...

  8. docker入门级详解

    Docker 1 docker安装 yum install docker [root@topcheer ~]# systemctl start docker [root@topcheer ~]# mk ...

  9. [转帖]持久化journalctl日志清空命令查看配置参数详解

    持久化journalctl日志清空命令查看配置参数详解 最近 linux上面部署服务 习惯使用systemd 进行处理 这样最大的好处能够 使用journalctl 进行查看日志信息. 今天清理了下 ...

随机推荐

  1. WPF与输入法冲突研究之二：汉字输入法会导致WPF程序的崩溃！

    如果是输入非汉字的数据信息,可以添加一下内容: xmlns:input="clr-namespace:System.Windows.Input;assembly=PresentationCo ...

  2. JavaScript 数组的遍历

    var a = [1, 2, 3]; // for循环 for(var i = 0; i < a.length; i++) { console.log(a[i]); } // while循环 v ...

  3. android 开发随笔 - 开发环境搭建

    1.1 问题: 'tools.jar' seems to be not in Android Studio classpath. Please ensure JAVA_HOME points to J ...

  4. python进阶之路4.2---装饰器

    *:first-child { margin-top: 0 !important; } body>*:last-child { margin-bottom: 0 !important; } /* ...

  5. oracle监听

    启动实例时,监听程序进程会建立一个指向Oracle DB 的通信路径.随后,监听程序可接受数据库连接请求.使用监听程序控制实用程序可控制监听程序.使用lsnrctl,可以:• 启动监听程序• 停止监听 ...

  6. iOS应用性能调优的25个建议和技巧【转】

    转载自:http://blog.jobbole.com/37984/ 首页 最新文章 资讯 程序员 设计 IT技术 创业 在国外 营销 趣文 特别分享 更多 > - Navigation -  ...

  7. 你使用PetaPoco必须知道的事情

    之前没有用PetaPoco调用过存储过程,今天发现问题 Sql sql = ); var list = sqlserverDB.GetInstance().Fetch<AdminGroup> ...

  8. Markdown 学习笔记: Basics

    Markdown 学习笔记: Basics 原文:Basics. 了解Markdown格式化句法的要点 本页对如何使用Markdown提供了一个简单的概述.在"句法"页中对Mark ...

  9. Java数据结构漫谈-Stack

    Stack(栈)是一种比较典型的数据结构,其元素满足后进先出(LIFO)的特点. Java中Stack的实现继承自Vector,所以其天然的具有了一些Vector的特点,所以栈也是线程安全的. cla ...

  10. JQuery中parents和closest的区别

    jquery中查找上层元素一般都习惯了用parents方法,往往忽略了还有一个效率更高的closest方法,看下w3cschool的解释 过程不一样,closest是找到一个即停止,而parents将 ...