[systemd-devel] Journal API demo application: "tallow" - a fail2ban replacement
Lennart Poettering
lennart at poettering.net
Tue Nov 20 09:44:56 PST 2012
On Sun, 11.11.12 17:24, David Strauss (david at davidstrauss.net) wrote:
>
> Units "subscribed" to specific message IDs has two negative effects:
> (1) massive proliferation of units, since each one can supposedly only
> handle one UUID and (2) unit names that are useless from a human
> perspective.
>
> It would be much cleaner to offer "message activation" though a unit
> with an arbitrary name and a journalctl-style filter for incoming
> messages.
>
> I'd also consider a socket-based approach for event "subscriptions" as
> long as it's efficient to stat() the non-existence of the appropriate
> Message ID socket, since the common case would be no listener. If a
> socket unit is the only supported way to listen, even the stat() would
> be unnecessary, as systemd would know all active sockets to begin
> with. There could be a standard naming convention for such sockets,
> like /var/run/journal/msgid/<UUID>. This would allow message
> "activation" of a listener and human-friendly unit names. It would
> also allow listening to happen in both "accept" and non-"accept"
> socket modes. Even a shell script could easily receive and handle
> certain events.
Having message ID based activation is definitely something we want to
add, i.e. by adding a new unit type ".msgid" or so which can be used to
trigger services, much the same way as ".timer" or ".socket" trigger
anothe runit on time or on socket. It's not trivial to do though, since
there are a couple of corrner cases where we need to get good behaviour.
Biggest question right now is: if a .msgid unit is activated, should it
look at the history of journal messages, or not? It probably should, if
we start a .msgid unit at boot at least look at everything that happened
in early-boot/kernel so far. But then again, maybe it shouldn't, i.e. if
we start a .msgid late during runtime, it probably shouldn't "replay"
all the journal that has been accumulated in the last 4 weeks. So, this
is a bit contradictory. Maybe we can make this configurable in the
.msgid unit file, or so but I am a bit unsure how this should best work...
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list