I performed some additional observations, I agree Nigel's statements in #13:
disabling the "change" ACTION in /lib/udev/rules.d/95-multipath.rules is just a bandaid, the memory leak is there anyways, just that it takes waaaaaaaay longer to fill in the memory.
The problem "solved" by disabling the "change" ACTION in /lib/udev/rules.d/95-multipath.rules seems to be a real bug somewhere in udev or multipath: monitoring with udevadm the number of events gets reduced from "tons per second" to one every 30 seconds in my hardware, which shows all the other events were spurious events generated by a udev/multipath feedback loop...
I performed some additional observations, I agree Nigel's statements in #13:
disabling the "change" ACTION in /lib/udev/ rules.d/ 95-multipath. rules is just a bandaid, the memory leak is there anyways, just that it takes waaaaaaaay longer to fill in the memory.
The problem "solved" by disabling the "change" ACTION in /lib/udev/ rules.d/ 95-multipath. rules seems to be a real bug somewhere in udev or multipath: monitoring with udevadm the number of events gets reduced from "tons per second" to one every 30 seconds in my hardware, which shows all the other events were spurious events generated by a udev/multipath feedback loop...
That issue is being tracked in /bugs.launchpad .net/ubuntu/ +source/ udev/+bug/ 578180 bugs.debian. org/cgi- bin/bugreport. cgi?bug= 581791
https:/
and also Debian bug
http://