Samuel Thibault, le dim. 23 août 2026 21:51:53 +0200, a ecrit: > Samuel Thibault, le sam. 18 juil. 2026 21:30:04 +0200, a ecrit: > > Samuel Thibault, le lun. 22 juin 2026 17:55:48 +0200, a ecrit: > > > We are seeing mdmonitor eat a lot of memory, we have to restart it now > > > and then, which fits this bug description. > > > > We are hitting the issue again. > > We have hit it again at the beginning of august, and yesterday... > > I have uploaded the patch from testing to stable-proposed-updates in the > delayed/15 queue.
FTR, more precisely, the attached change. Samuel
diff -Nru mdadm-4.4/debian/changelog mdadm-4.4/debian/changelog --- mdadm-4.4/debian/changelog 2025-04-25 18:24:19.000000000 +0200 +++ mdadm-4.4/debian/changelog 2026-08-23 21:40:00.000000000 +0200 @@ -1,3 +1,11 @@ +mdadm (4.4-11+deb13u1) trixie; urgency=medium + + * Non-Maintainer Upload. + * Adding patch from Peter Mann <[email protected]> to fix memory leak in + mdadm --monitor --scan (Closes: #1115497). + + -- Samuel Thibault <[email protected]> Sun, 23 Aug 2026 21:40:00 +0200 + mdadm (4.4-11) sid; urgency=medium [ Daniel Baumann ] diff -Nru mdadm-4.4/debian/patches/debian/0015-monitor-memory-leak.patch mdadm-4.4/debian/patches/debian/0015-monitor-memory-leak.patch --- mdadm-4.4/debian/patches/debian/0015-monitor-memory-leak.patch 1970-01-01 01:00:00.000000000 +0100 +++ mdadm-4.4/debian/patches/debian/0015-monitor-memory-leak.patch 2026-08-23 21:40:00.000000000 +0200 @@ -0,0 +1,39 @@ +Author: Peter Mann <[email protected]> +Description: Memory leak in mdadm --monitor --scan (Closes: #1115497). + At mdadm/udev.c:153: + ... + if (udev_monitor_receive_device(udev_monitor)) + return UDEV_STATUS_SUCCESS; /* event detected */ + ... + . + According to libudev docs: + On success, udev_monitor_receive_device() returns a pointer to a newly referenced device that was received via the monitor. The caller is responsible to drop this reference when done. + . + As you can see, the reference to the device never gets dropped. + We put together a quick patch, which seems to have fixed the issue or at least substantially reduced the amount of leaks. + . + Since we have no experience with the codebase, we have no idea about the implications of these changes. + We would appreciate if someone took a closer look. + . + Additionaly as a workaround, passing MDADM_NO_UDEV=1 env to mdadm stops the leaks as well, since it bypasses the leaking codepath. +Forwarded: https://github.com/md-raid-utilities/mdadm/pull/197 + +diff -Naurp mdadm.orig/udev.c mdadm/udev.c +--- mdadm.orig/udev.c ++++ mdadm/udev.c +@@ -149,9 +149,13 @@ enum udev_status udev_wait_for_events(in + tv.tv_sec = seconds; + tv.tv_usec = 0; + +- if (select(fd + 1, &readfds, NULL, NULL, &tv) > 0 && FD_ISSET(fd, &readfds)) +- if (udev_monitor_receive_device(udev_monitor)) ++ if (select(fd + 1, &readfds, NULL, NULL, &tv) > 0 && FD_ISSET(fd, &readfds)) { ++ struct udev_device *dev = udev_monitor_receive_device(udev_monitor); ++ if (dev) { ++ udev_device_unref(dev); + return UDEV_STATUS_SUCCESS; /* event detected */ ++ } ++ } + return UDEV_STATUS_TIMEOUT; + } + #endif diff -Nru mdadm-4.4/debian/patches/series mdadm-4.4/debian/patches/series --- mdadm-4.4/debian/patches/series 2025-03-09 18:03:14.000000000 +0100 +++ mdadm-4.4/debian/patches/series 2026-08-23 21:40:00.000000000 +0200 @@ -10,4 +10,5 @@ debian/0011-systemd-directory.patch debian/0012-bin-directory.patch debian/0013-xmalloc-ftbfs.patch +debian/0015-monitor-memory-leak.patch upstream/0001-manpage-remove-bitmap.patch
