"Kok, Auke-jan H" <[email protected]> writes: > Hi folks, > > I wrote a demo application that uses the journal API to scan for SSH > bruteforce logs in the journal, called "tallow".
Since Auke is on vacation now (and would *never* read email or work on projects on vacation ;) ) and has finally put this could out there, I want to ask about getting a general event response processor in the journal/systemd. In order to avoid 30 daemons each doing an inotify on the journal for their message of interest to pass by, I think having a simple .log-event type unit file be used by the journal would be a nice to have feature. An example of what I'm thinking of would be the following to run a processing script for each core dump: [Event] MessageID=fc2e22bc6ee647b6b90729ab34a250b1 (or SD_MESSAGE_COREDUMP) [Service] type=oneshot ExecStart=/usr/sbin/core-processor %data %pid Where Event can contain any journal field, conditions are done as normal ie ConditionFileExists and friends (including allowing ! prefixes). For the ExecStart line %data and %pid are examples of passing journal fields though I'm definitely looking for opinions on how this could best be done as it doesn't seem right to have them in the [Service] group but having some kind of ExecArguments in [Event] seems odd too. Anyway I'd like to hear people's opinions on why this feature is unneeded and what other way I should be doing this or maybe even this is a good idea and with some refinement could get merged in to systemd. -- William Douglas, Intel Open Source Technology Center _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
