I am in process of searching how to configure system logging in systemd. Back when Lennart wrote his blog articles, he even included running rsyslog into examples of socket activation. But some time around April 2011, systemd subsumed yet another function. Whoever instigated the takeover of logging thought it would be fun to stop updating /var/log/messages altogether and instead pollute the dmesg with usermode messages. He also neglected to document this in any way. If Lennart (or his overly smart disciple) were made to compensate frustrated sysadmins for hours spent banging their heads on desks, he might have thought otherwise. But the beauty of the scheme is that the companies employing said sysadmins get to pay... In fact, Lennart even listed "availability of specialized consulting" for systemd as a plus. He is my hero, really. If I were 1/10 as evil as that man, my life would've been an amazing success.

Aside from the training costs, there's also an insignificant resource cost. My side by side comparisons show RSS jumping from 1.3MB to 22MB (on top of total mapped size going from 19MB to 54MB). Basically nothing to talk about. I was never hit by the "systemd ate my CPU" syndrome.

UPDATE: A message by Kay suggests that rsyslog needs to be run. It simply was not configured right in F16 Rawhide, a small bug somewhere. Just needs "systemctl enable rsyslog.service". A day was wasted, however.

UPDATE M0AR: Andrey's message already has all the info, but I'm going to restate how systemd actually improves upon what we had previously. The confusing part is that systemd does not merely do socket activation for syslog, but acts as a syslogd. Once rsyslogd starts, it takes over. The dmesg then is saved in the usual way. This way, syslog service is available before rsyslogd is up, e.g. for initrd time. Why is this not documented? My guess is, as long as everything works smoothly, it is a transparent improvement, so needs no explanation.