FYI, your mailer is not using TLS, so it's getting marked a spam.
On Thu, Jan 12, 2017 at 5:07 AM, Simon McVittie <s...@debian.org> wrote: >> 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. It's quite true that doing anything *complicated* is forbidden. But there's no need to be complicated. Just write(2) a newline, a handful of fixed strings, and the hex value of the syscall and instruction. snprintf(3) isn't safe, but converting an integer to hex by hand is trivial anyway, compared to using a seccomp sandbox. Personally, I would've just chrooted (having userns these days makes sandboxing *so* much easier since you don't need permissions to become a new "root"). >> 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. True, but the crashing application is still responsible for the consequences, especially when it's something that nobody ever asked for anyway.
