Since I updated to the snap-based Firefox on Ubuntu recently, I see it reporting SECCOMP_RET_TRAP messages to the journal whenever some application is drawing a canvas.

And since applications drawing canvasses usually do that with 30 frames per second, there is a lot of useless spam filling up the log, and, in fact, also consuming a lot of CPU usage.

What I could dig up was that this sort of behaviour was reported before, but both sides tried to pass the buck, then fell back to a plain "wontfix". ( https://bugzilla.mozilla.org/show_bug.cgi?id=1465152, https://bugzilla.redhat.com/show_bug.cgi?id=1507282, https://linux-audit.redhat.narkive.com/BnWpkAXa/limiting-seccomp-audit-events )

So, how can one keep the journal from being flooded with useless "a canvas has been drawn in your browser! Oy vey! Run for help" messages? Is there some configuration where you can filter specific SECCOMP messages, or better: keep Firefox from generating these?

(addition: sample line Sep 13 16:01:48 MYHOST audit[97745]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj=? pid=97745 comm="CanvasRenderer" exe="/snap/firefox/1775/usr/lib/firefox/firefox" sig=0 arch=c000003e syscall=312 compat=0 ip=0x7f48ae38573d code=0x50000)

Edit: I am not looking to

  • turn off security entirely
  • stop all security events from getting logged
  • recompile applications or kernel

I want to tone down/turn off the spamming by configuration in a reproducible way, so everybody with the same issue can apply that solution. Dropping messages matching a specific "comm" field value, for example.

1 Answer 1


Until the issue is properly fixed by either Mozilla or Canonical, you can disable audit logs for Firefox as a temporary workaround.

Start by installing auditd to allow managing audit logs:

sudo apt install auditd

Add an audit rule to the end of /etc/audit/rules.d/audit.rules to exclude logging Firefox:

-a never,exclude -F exe=/snap/firefox/current/usr/lib/firefox/firefox

Alternatively, you can create a separate file and add the audit rule there (e.g., /etc/audit/rules.d/firefox.rules).

Enable and start the auditd service:

sudo systemctl enable --now auditd

Verify the rule is loaded:

sudo auditctl -l

Restart the auditd service if you ever need to update the rule:

sudo systemctl restart auditd
  • 1
    Thank you! suggested improvement: there is an /snap/firefox/current/... directory. Might that remove the need to update the rules? And tidying up: place above filter line as separate file in /etc/audit/rules.d ; the rules get recombined automatically on (restart).
    – foo
    Sep 24, 2022 at 19:10
  • Thanks for the great suggestions. Using /snap/firefox/current/ does indeed avoid the need to update the rule as it is a symlink that should always point to the directory of the newest version.
    – Snake
    Sep 24, 2022 at 19:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .