The monitoring box kept insisting another copy was already running.
Every scheduled MRTG run produced the same ugly result. A few Perl warnings appeared first. Then the useful line: another copy of MRTG seemed to be running, so the new process quit.
The alerts were frequent enough that nobody could ignore them. I spent time looking for the process that was starting it, but could not catch anything obvious. I suspected cPanel because other people had reported similar behavior. Most of the forum answers seemed to amount to living with it.
That was not much of an answer when the system kept sending mail.
I wrote back from a plane and promised to have it handled by noon the next day. I would look again after landing, then come back to the larger firewall work later in the week.
The eventual fix was much less interesting than the investigation. A stale lock file made the monitor believe another copy was active. Remove the bad state, run it again, and the noise stopped.
“Should be fixed now,” was the whole useful update.
This kind of problem happened constantly in small environments. A monitoring tool could be technically running while also being useless because every alert was about the monitor itself. If those messages kept coming, the important one would eventually look like more junk.
There was no architecture meeting and no new platform. It was a scheduled task, a stale file, and a few hours split between travel and other work.
Delete the lock. Verify the next run. Move on.