配置文件详解

[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. lucene4.6 索引创建和搜索例子

    本文转自:http://blog.csdn.net/jyf211314/article/details/17503997           点击打开链接 lucene4.6小例子,Lucene全文检 ...

  2. [Oracle] 使用触发器实现IP限制用户登录

    在Oracle里,不像MySQL那样方便,可以直接在用户上进行IP限制,Oracle要实现用户级别的IP限制,可以使用触发器来迂回实现,下面是一个触发器的例子: create or replace t ...

  3. 曾经的足迹——对Linux CAN驱动的理解（1）

    在Ti的AM335X系列Cortext-A8芯片中,CAN模块采用D_CAN结构,实质即两路CAN接口. 在此分享一下对基于AM335X的Linux CAN驱动源码的理解.下面来分析它的驱动源码及其工 ...

  4. JavaScript 函数基础

    1. JavaScript 函数基础 1. 定义方法 2. 函数的调用方法 3. 函数方法 apply : 将函数作为数组的方法来调用 将参数以数组形式传递给该方法 call   : 将函数作为对象的 ...

  5. 安装sql server提示挂起报错

    在安装sql server时出现“以前的某个程序安装已在安装计算机上创建挂起的文件操作.运行安装程序之前必须重新启动计算机”错误.无法进行下去. 参考有关资料后,以下步骤基本可以解决: 1)添加/删除 ...

  6. for循环和经典案例

    循环:初始条件,循环条件,状态改变,循环体.for(初始条件;循环条件;状态改变){ 循环体}for(int i=1;i<=10;i++){ }例子:100以内与7有关的数.求100以内所有数的 ...

  7. jquery操作iframe

    query取得iframe中元素的几种方法 在iframe子页面获取父页面元素 代码如下: $('#objId', parent.document); // 搞定... 在父页面 获取iframe子页 ...

  8. Oracle语句块PL/SQL循环判断

    - --pl/sql Procedural Language /sql --被数据库编译保存,由用户调用 --程序块 /* 语法 Declare – 声明变量 --声明变量 Age int; //没有 ...

  9. Sql 函数大全 （更新中...由难到简

    1.字符处理类: 1.1 指定指定字符输出的次数 ) 结果:1a1a1a1a1a (5个1a)

  10. Array.prototype.sort()

    sort() 方法对数组的元素做原地的排序,并返回这个数组.默认按照字符串的Unicode码位点(code point)排序. 语法 arr.sort([compareFunction]) 参数 co ...