From anti-systemd to pro-systemd in the shortest time

Posted Jan 31, 2014 22:42 UTC (Fri) by cortana (subscriber, #24596)
In reply to: From anti-systemd to pro-systemd in the shortest time by dlang
Parent article: This week in "As the Technical Committee Turns"

One of the reasons I like journald is because it captures a lot of useful metadata along with each message. Does rsyslog do something similar?

$ journalctl -o verbose | grep $'^\t' | cut -d = -f 1 | sort | uniq -c | sort -n
      1 	EXIT_CODE
      1 	EXIT_STATUS
      4 	SEAT_ID
      5 	KERNEL_USEC
      5 	USERSPACE_USEC
     13 	ERRNO
     13 	EXECUTABLE
     61 	_SYSTEMD_USER_UNIT
    187 	_KERNEL_DEVICE
    187 	_KERNEL_SUBSYSTEM
    187 	_UDEV_SYSNAME
    273 	LEADER
    273 	SESSION_ID
    273 	USER_ID
    451 	RESULT
    795 	UNIT
   1137 	CODE_FILE
   1137 	CODE_FUNCTION
   1137 	CODE_LINE
   1138 	MESSAGE_ID
   1409 	_SOURCE_MONOTONIC_TIMESTAMP
   1824 	_SYSTEMD_OWNER_UID
   1824 	_SYSTEMD_SESSION
  52403 	SYSLOG_PID
  65664 	_SYSTEMD_UNIT
  67418 	_SOURCE_REALTIME_TIMESTAMP
  67928 	_CMDLINE
  67930 	_EXE
  68473 	_SYSTEMD_CGROUP
  68474 	_COMM
  68986 	_GID
  68986 	_PID
  68986 	_UID
  69095 	SYSLOG_FACILITY
  70330 	SYSLOG_IDENTIFIER
  70395 	_BOOT_ID
  70395 	_HOSTNAME
  70395 	_MACHINE_ID
  70395 	MESSAGE
  70395 	PRIORITY
  70395 	_TRANSPORT

FYI, the fields starting with an underscore are obtained by journald from the kernel, so can be considered unforgeable. The other fields are supplied by the process logging the message, so can't be trusted.

I certainly think that journald has room to improve, but I don't understand the attitude that it's some pointless NIH project that gets in the way of real logging. At the end of the day you can tell journald to set Storage=none and it mostly gets out of the way.

From anti-systemd to pro-systemd in the shortest time

Posted Jan 31, 2014 23:29 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

short version, rsyslog can grab metadata, the set of data gathered is not identical.

Rsyslog will get the UID, GID, PID, and path to binary, and name as visible to top (which I think is what you list as command line)

http://www.rsyslog.com/what-are-trusted-properties/

If there are other things that need to be pulled, they can be added (as it notes in that link), just identify what you are interested in and give some sort of explanation of why. Pulling every possible hunk of data takes time and space, so if there's a desire for a lot, it probably will need to be configurable.

mot of the other things that you list are things available to rsyslog already.

This had been discussed between Rainer (lead rsyslog developer) and Lennart prior to the announcement of journald, but Rainer had not added it to Rsyslog yet as of the time of the journald announcement.

> I don't understand the attitude that it's some pointless NIH project that gets in the way of real logging

the fact that there was so much FUD and misinformation in the initial announcement and follow-ups is the cause of a lot of this.

From anti-systemd to pro-systemd in the shortest time

Posted Feb 1, 2014 1:00 UTC (Sat) by cortana (subscriber, #24596) [Link] (1 responses)

Ah, that's very interesting, thanks. There's certainly more overlap between what rsyslog and journald can capture than I thought. Sadly I think that journald being interposed between a process transmitting a log message and rsyslog would prevent rsyslog from being able to get the original value of these fields. :(

From anti-systemd to pro-systemd in the shortest time

Posted Feb 1, 2014 2:38 UTC (Sat) by dlang (guest, #313) [Link]

actually, processes running as root can forge all that data, so journald can forge that data so that Rsyslog gets the correct data. However, as I understand it, not everything gets passed through the log socket, so Rsyslog doesn't get setup that way, instead there is an imjournal module that interfaces with the journal the same way that journalctl does, reading and parsing the files that it creates.