CVE-2019-5736 mitigation (cloned_binary) vs systemd

Since the mitigation for CVE-2019-5736 was amended with /proc/self/exe read-only bind mount in https://github.com/opencontainers/runc/pull/1984, every runc start/run/exec causes a mount and unmount event.
Those are picked up by systemd to create/remove a mount unit. This can be seen in system journal:

journalctl --follow
Jan 18 15:22:04 kir-rhat systemd[1]: run-runc-xx4-runc.Ho2X6M.mount: Deactivated successfully.

(for some reason, only the unmount is shown when the default log level is used).

First, this creates a load on the system -- systemd re-reads mountinfo on every event (maybe it is fixed in later versions to rate-limit the reading).

Second, with older systemd and some setups, due to a bug in systemd (fixed in 2018 by https://github.com/systemd/systemd/pull/10980, but not backported to certain distros), this eventually results in systemd unit table reaching its maximum size. Once this happens, systemd is not able to start or stop any more units, which is A Very Bad Thing.

I understand that this is a systemd (rather than runc) issue, but perhaps we can work around it in some way?

Start by tracing the /proc/self/exe read-only bind mount used during runc start, run, and exec, while following the system journal with journalctl --follow. Reproduce the mount and unmount events with systemd and determine whether runc can avoid the reported unit churn; done means a validated workaround or a clearly documented reason it cannot be provided.