On Thu, 12 Jan 2017 at 12:44:08 +0000, Simon McVittie wrote:
> On Mon, 19 Dec 2016 at 22:39:29 -0800, Ben Longbons wrote:
> > Remember, SIGSYS is catchable, and the siginfo_t contains details. If a
> > program is going to use `seccomp`, it should log those details, before
> > exiting with a value that tells systemd not to restart it.
>
> I've cloned a new bug for this.
(It is #851148.)
This restart behaviour is less straightforward than you might think.
There are two things that restart tracker-extract:
* On systems with dbus-user-session installed, `systemd --user` restarts
tracker-extract on failure, as requested by the systemd unit.
This is easy to avoid by adding SIGSYS to RestartPreventExitStatus,
and I'm trying a patch that does that.
* On all systems, tracker-miner-fs watches the tracker-extract process
and sends a D-Bus message to restart it, either started by
`systemd --user` (with dbus-user-session) or by dbus-daemon (without).
This is deliberate: tracker-extract only tries indexing any given
file a limited number of times, and will eventually skip over it.
Processing each file n times doesn't do much to mitigate missing benign
syscalls in the seccomp sandbox, because n tries * m files is still a
large number: the assumption is that the typical failure mode is a
particular file that trips a bug in the extractor libraries.
The introduction of the seccomp sandbox is an unusual situation that
caused extraction of broad equivalence classes of files to fail,
breaking that assumption. There are several patches upstream that
hopefully resolve this, which I'm testing now.
I agree with the maintainer that this is not release-critical,
although I personally think the actual crashes might be.
> should log those details
Logging in response to an async signal is problematic: it is not safe
to use anything much more complicated than a syscall in a signal
handler (in particular, stdio or GLib logging is a bad idea and
could deadlock). I think the correct thing here is for tracker-extract
to just crash, and let system-level diagnostic tools like
systemd-coredump work out why.
> During a recent apt run, my system became almost completely
> unresponsive.
I suspect that the thing stalling your system here is actually
the repeated core-dump processing, not the repeated
tracker-extract startup - at least, that has been my experience when
dealing with repeatedly crashing software. systemd-coredump uses
relatively expensive compression.
S
