On Thu, Nov 8, 2012 at 8:54 AM, Kay Sievers <k...@vrfy.org> wrote: > On Thu, Nov 8, 2012 at 8:31 AM, William Douglas > <william.doug...@intel.com> wrote: >> "Kok, Auke-jan H" <auke-jan.h....@intel.com> writes: >>> >>> 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. > > Right, we already planned to have "message activation" in systemd. It > will probably its own unit type, called ".msgid", or something. The > details are not entirely clear, it's just a bunch of ideas that > moment. >
Awesome! > We need to sort out a few things, like what happens at startup, to > prevent the "30 daemons" to see all the old messages again and again > and getting activated for them. How to properly wake up an already > running daemon when a new message arrives. How to handle re-activation > for services which exit at idle. > Yes start up is interesting. I imagine an admin would probably want to be able to take action on messages that have happened before the journal and message activation are online. Is the BOOT_ID field useful for determining where to start processing these messages? Seems like it might be good to take an optional AfterJournal=Bool so some units could by pass on those earlier messages too. The already running daemon's I expect to have have a socket available for getting these messages, though I guess a SIGUSR# could work if there isn't need for much in the way of data transfer. For run once type processing, re-activation could work more like daemon@.service files. Each message event would just do a run with their cursor as the identifier. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
