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