Mercury in capture mode can have high CPU utilization after suspend

[davidmcgrew]

After resuming from a suspend, mercury may cause high CPU utilization, in cases where it was running in capture mode before the suspend operation. Workarounds:

1. Don't suspend while mercury is running, or
2. Restart mercury; if you are using systemctl, as with the default install, you can perform 'sudo systemctl restart mercury'.

Speculation about the root cause: it is possible that the mercury code that uses the AF_PACKET ring buffer(s) shared with the kernel are getting out of sync during the suspend/resume process, and the application code keeps reading through the circular buffer in an attempt to catch up with the kernel.

[davidmcgrew]

It seems that few people are bothered by this issue, so it is low priority. But it would be good to pay attention to interface events (up/down/etc) through Netlink, which would probably solve this problem, and we could also use Netlink to find the interface associated with the default route for use as a default interface for capture. If that's an acceptable default, it would make it possible to have a default capture configuration, which would make it possible to auto-start systemd from a Debian/RPM package.