Debian TC vote on init system coupling

> My main concern with regards to transaction-like logging semantics is that the processes of updating the log indexes, updating the rolling log hash, and writing the log message do not occur as a single atomic operation. A crash in the middle of logging a message would leave the logs, indexes, and hashes in an inconsistent (but potentially recoverable) state. Does your implementation address this? As in, once you expose a log record over kdbus, are its associated hashes and indexes guaranteed to be consistent?

This requires a little more explanation on what I'm actually trying to do. There's two separate pieces:

1) Modifications to systemd that expose log messages as signals. (Currently, there are methods to query log messages, but that won't be sufficient for constant forwarding.)

2) A service that listens for these signals and does *something* with them. (My something is sending them across the network to a listening service.)

#1 is the only part that necessarily lives within the systemd tree. Anyone is free to make their own #2, and they can even do wildly different things with those messages (like write them out locally in their own format). Furthermore, since #2 is subscribing to a set of signals, multiple services can simultaneously perform #2, and journald has no clue (except that subscribers >0).

Back to atomic operation, consistency, and tampering.

I suppose that it would be possible for journald to make some sort of log_entry_ack() method available that a #2 service could send back to the journal confirming receipt. The question is what's the purpose? Obviously, that ack cannot be forwarded back to #2 or else there is infinite amplification of acks. The only use would be for journald to use it's internal storage mechanism, but then you're dependent on local logs (which I'm trying to avoid and you don't like due to corruption and other concerns).

A #2 service is free to implement any sort of fancy syncing/checkpointing that it wants. The journal messages already contain useful monotonic timestamps that could be immediately written to disk in a durable manner and with the desired anti-tampering protection. That's certainly going to have performance implications, but you should be able to add as much safety as is desired.

KDBus is still in active development, so we'll have to wait to see what guarantees it provides to message. Nonetheless, it's running as part of the kernel, so there should at least be highly reliable signal delivery, possibly even guaranteed. DBus currently (and safe to assume that KDBus will continue to) guarantees message ordering, so that's also helps with consistency.

Lastly, journald has supported forward secure sealing (FSS). I'm not a cryptographer, but my understanding is that FSS is quality anti-tampering implementation. It would not appear to be that much of a challenge to send the sealing key over the system bus, allowing a #2 service to verify the integrity based on the verification key.

Let me know if you have additional questions or comments. As I said, I'm just getting started on implementation, and I don't want to pigeon-hole this idea to my use case, general network log aggregation.