On Fr, 09.05.25 09:31, Johannes Barthel 
(johannes.bart...@farming-revolution.com) wrote:

> Hi,
>
> we're using an Ubuntu setup where systemd-coredump is set up as the coredump 
> handler. This is fine, coredumps end up in /var/lib/systemd/coredump/. We 
> would however like to additionally run our own event handler (for remote 
> error reporting) in case of a process dumping core.
>
> Does systemd-coredump provide any facilities for registering an event handler 
> for this? Or should we create our own handler, register that as 
> kernel.core_pattern in sysctl and forward the coredumps to systemd-coredump? 
> I considered subscribing to the journal and filtering the coredump event out 
> there, but that might cause unnecessary CPU load and also the API seems to be 
> kind of broken, I ran into this issue [1].
>
> What is the best way of running our custom error reporting script in
> addition to systemd-coredump's default behavior?

You could just define your own template unit, and then run that after
each systemd-coredump@.service instance. i.e. maybe name it
mysecondcoredumphandler@.service, and then do:

   mkdir -p /etc/systemd/system/systemd-coredump@.service.d
   cat 
>/etc/systemd/system/systemd-coredump@.service.d/mysecondcoredumphandler.conf 
<<EOF
   [Unit]
   Wants=mysecondcoredumphandler@%i.service
   Before=mysecondcoredumphandler@%i.service
   EOF
   systemctl daemon-reload

or something like that.

That means you service is enqueued whenever the primary handler is
invoked, and runs right after it.

Lennart

--
Lennart Poettering, Berlin

Reply via email to