配置文件详解

[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. Hive集成HBase详解

    摘要 Hive提供了与HBase的集成,使得能够在HBase表上使用HQL语句进行查询 插入操作以及进行Join和Union等复杂查询   应用场景 1. 将ETL操作的数据存入HBase 2. HB ...

  2. tomcat下配置https环境

    在网上搜了一下,内容不是非常完好. 现进行整理,做个学习笔记,以备以后使用. (1)进入到jdk下的bin文件夹 (2)输入例如以下指令"keytool -v -genkey -alias ...

  3. C++ MPICH

    假设一个C++的MPI程序在单机上能够跑.可是在多机上跑会报下面错误: Fatal error in MPI_Send: Unkown error class , error stack. 解决方法: ...

  4. VC6.0建立控制台程序实现PDA应用

    作者:iamlaosong 由于须要,又写起了文本界面的程序,以便PDA通过telnet连上运行. 假设是Linuxserver的话.这是非常easy的事,但是用户server是windows ser ...

  5. [ES6] ITERATORS

    Iterables return an iterator object. This object knows how to access items from a collection 1 at a ...

  6. 如何给你的Android 安装文件（APK）瘦身

    如何给你的Android 安装文件(APK)瘦身 本文翻译自:Putting Your APKs on Diet           原作者:Cyril Mottier Android的apk文件越来 ...

  7. 代码实现Layout android:layout_alignParentRight

    代码实现Layout android:layout_alignParentRight 例如: android:id="@+id/account_option" android:la ...

  8. (转)HTTP 无法注册 URL http://+:9999/CalculatorService/。进程不具有此命名空间的访问权限

    写WCF时在 1 host.Open(); 报错:HTTP 无法注册 URL http://+:9999/CalculatorService/.进程不具有此命名空间的访问权限(有关详细信息,请参见 h ...

  9. .NET 笔试分享

    最近一直在面试,每次面试前也不怎么准备,虽说碰到的题大部分都很简单的,但是在现场答题的时候由于自己紧张脑子就空了,一些题答的不是很好,所以只有每次回来的时候才能好好想想怎么答: 题大部分还是挺简单的, ...

  10. kafka的一些常用命令

    启动zookeeper bin/zookeeper-server-start.sh config/zookeeper.properties & 启动kafka bin/kafka-server ...