Hi, could you please check if the issue persists with Monit 5.35.2? There was a fix that might result in false negatives when LWP (thread) exists that matches the old PID of the process.
Best regards, The M/Monit team > On 7. 7. 2025, at 13:27, lejeczek via This is the general mailing list for > monit <[email protected]> wrote: > > Hi guys. > I do: > -> $ monit procmatch "^/usr/bin/conmon(.*?)-n freeipa.mine.priv " > List of processes matching pattern "^/usr/bin/conmon(.*?)-n freeipa.mine.priv > ": > Total matches: 0 > > yet I have a monit file like: > > check process freeipa.mine.priv.container with matching > "^/usr/bin/conmon(.*?)-n freeipa.mine.priv " > start program = "/usr/bin/podman start freeipa.mine.priv" with timeout 30 > seconds > stop program = "/usr/bin/podman stop freeipa.mine.priv" with timeout 30 > seconds > if 3 restarts within 5 cycles then alert > if 3 restarts within 5 cycles then timeout > > and monit thinks, say: > > -> $ monit status freeipa.mine.priv.container > Monit 5.33.0 uptime: 4d 6h 18m > > Process 'freeipa.mine.priv.container' > status OK > monitoring status Monitored > monitoring mode active > on reboot start > pid 3617222 > > What is going on there? 'Pid' above, is of another container's of name > 'freeipa.mine.priv.c9s' > If @devel reads this - a bug? > many thanks, L.
