[systemd-devel] Options for logging from service started before journald?

[Lennart Poettering]

On Sun, 18.10.15 18:05, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> What can be done to log from unit that needs to be started before
> journald?

Why would you ever do that?

> Journal, syslog or kmsg all require journald connection and as far as I
> understand will deadlock on waiting for journald to accept it. NULL is not
> an option; is tty the only choice left?

you can always make your app log directly to kmsg. That's where PID 1
logs too that early.

> Background - openSUSE tries to start haveged before journald to add
> randomness.

Why? Just why?

I mean, i seriously question the purpose of haveged anyway, what can
it still do that current kernels and VM managers can't anyway? Why
would you rather add this extra daemon to your system than just add
the remaining bits that haveged can do hat VM managers and kernels
can't to those VM managers and kernels?

I really don't get this at all?

But even if there's purpose in it, why would you bother with running
it before journald? journald doesn't need entropy. It uses them as
seed for the hash functions used by its hashtables, but that's pretty
much it. And those are not really exploitable, as the daemon isn't
network facing. And even if you distrust your local clients so much
too: the hash table will use a new seed when it reaches a certain
fill-level and needs to rehash. Hence, crappy entropy at early boot
doesn't really matter: at the point where hash collisions could be
exploited, we pick a new seed anyway, and that seed will then be
stronger...

It's completely fine if journald starts up with crappy entropy. In
fact, you could even hack it to use a seed of 0 during the early part
of boot and it would still be fully safe.

systemd/PID 1 itself is certainly more affected by crappy entropy than
journald. But even then it's really a pointless excercise, as we
reseed the hashtables on high fill-levels.

> This sounds like reincarnation of "how to log to syslog and be started
> before syslogd". This was solved by moving logging connection to journald
> and starting it very early. May be something like minilod or blogd that
> buffers output until journald is started would be appropriate here?

Why would you think that it's OK to run those daemons before haveged,
but it's not OK to  simply run the journal itself before haveged?

Are you actually fixing any real-life issues here? 

Lennart

-- 
Lennart Poettering, Red Hat