配置文件详解

[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. NUnit - 使用感受

    Nunit使用 最近项目开始大量使用Nunit, 发现Nunit还是有很多好处的. 1. 测试驱动逻辑,这样可以尽最大可能减少“修改”引入的Bug. 如果你修改了一些东西,导致Case跑不过.请检查你 ...

  2. 跟我一起学extjs5(17--Grid金额字段单位MVVM方式的选择)

    跟我一起学extjs5(17--Grid金额字段单位MVVM方式的选择)         这一节来完毕Grid中的金额字段的金额单位的转换.转换旰使用MVVM特性,整体上和控制菜单的几种模式类似.首先 ...

  3. c++11 生产者/消费者

    下面是一个生产者消费者问题,来介绍condition_variable的用法.当线程间的共享数据发生变化的时候,可以通过condition_variable来通知其他的线程.消费者wait 直到生产者 ...

  4. StartService与BindService

    效果图 MainActivity.java package com.wangzhen.servicedemo; import com.lidroid.xutils.ViewUtils; import ...

  5. BULK INSERT如何将大量数据高效地导入SQL Server

    转载自:http://database.51cto.com/art/201108/282631.htm BULK INSERT如何将大量数据高效地导入SQL Server 本文我们详细介绍了BULK ...

  6. hadoop集群中的日志文件

    hadoop存在多种日志文件,其中master上的日志文件记录全面信息,包括slave上的jobtracker与datanode也会将错误信息写到master中.而slave中的日志主要记录完成的ta ...

  7. [转]JS基础之undefined与null的区别

    在JavaScript开发中,被人问到:null与undefined到底有啥区别? 一时间不好回答,特别是undefined,因为这涉及到undefined的实现原理.于是,细想之后,写下本文,请各位 ...

  8. 手把手教你如何使用webpack+react

    上一篇随笔讲述了新手入门入门前端 里面提到的第四阶段跟上当前前端的发展需要入门一个框架和自动化工具,当时推荐的是webpack+react 今天正好有空,也把自己入门webpack + react 的 ...

  9. jsp 、js和css

    css的一些样式 1.自动换行 .AutoNewline { Word-break: break-all;/*必须*/ width :50px;/*这里是设置多宽就进行换行 */ }

  10. Linux下安装并启动MongDB

    1.下载MongoDB 下载链接: http://www.mongodb.org/downloads 2.解压下载的压缩包 tar -zxvf mongodb-linux-x86_64-3.2.8.t ...