配置文件详解

[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. Java MongoDB 资料集合

    一.Mongodb介绍及对比 1.NoSQL介绍及MongoDB入门 http://renial.iteye.com/blog/684829 2.mongoDB 介绍(特点.优点.原理) http:/ ...

  2. eclipse 中 maven3 创建web项目

    一.创建项目 1.Eclipse中用Maven创建项目 上图中Next 2.继续Next 3.选maven-archetype-webapp后,next 4.填写相应的信息,Packaged是默认创建 ...

  3. [RxJS] Handling Multiple Streams with Merge

    You often need to handle multiple user interactions set to different streams. This lesson shows hows ...

  4. python应用之文件属性浏览

    import time,os def showFilePROPERTIES(path): for root,dirs,files in os.walk(path,True): print('位置:' ...

  5. 新闻滚动marquee标签

    先上代码: <marquee behavior="" direction="up" onMouseOver="this.stop()" ...

  6. AVD启动不了 ANDROID_SDK_HOME is defined but could not find *.ini

    报错提示______________________________________________________________________ Starting emulator for AVD ...

  7. android 隔几秒再执行

    今天做项目,需要前面的方法执行完等待2秒在关闭当前页面.之前使用的是Thread.sleep(2000)发现根本没有作用.经过多次尝试,发现需要使用以下方法才能实现: new Thread(){ pu ...

  8. 华为Oj 找出字符串第一个出现一次的字符

    #include <stdio.h> #include <string.h> char firstSingle(char *str) { int hash[255]={0}; ...

  9. oc随笔四:NSString、NSNumber

    #import <Foundation/Foundation.h> int main(int argc, const char * argv[]) { @autoreleasepool { ...

  10. Objective-C 协议(接口)

    Objective-C 协议类似于java语言中的接口 新建文件步骤:Objective-C File ---> File Type = "Protocol" @protoc ...