Closed Maescool closed 10 years ago
Just so we don't have to guess, please verify you are running the latest version of zoneminder. I can see an issue at line 56 in zmfilter, and it will get fixed shortly. However I'm not sure it is the cause of your issue.
I don't have anything I can test zmtrigger with so could you try the following and report back? Change the portion of line 56 from:
path=>ZM_PATH_SOCKS
to:
path=>$Config{ZM_PATH_SOCKS}
He can't be running 1.26.5 line 55 prevents it from even running. The problem must lie elsewhere.
I'm running the git version compiled yesterday I did actually comment out Line 56,57,58 cause those lines indeed made it impossible to run. So only "Chan1" is active in my case.
I think what is happening is that zmc is exiting, reloading, etc... but zmtrigger.pl is not handling the closing/removal/reinit of the mmaped file. I'm working on it fix.. but am unfamiliar with most of this stuff.
Thanks for looking into it Seems like its an old bug that keeps popping up found this: http://www.zoneminder.com/forums/viewtopic.php?f=29&t=19318&p=76020#p76020
Remark out the lines in ZoneMinder/Memory/Mapped.pm where it does the munmap. The code seems to work fine without it and doesn't crash. It may be a mem leak but if it is, it's really really small.
https://rt.cpan.org/Public/Bug/Display.html?id=91483 is relevant and has a fix
Well.. it happens when it still has actions running (waiting for the timeout to cancel the alarm) but it seems to crash when the MONITOR_RELOAD_INTERVAL is happening when no actions are running, it exits and restarts just fine on the Reload interval.
With that post you just found, seems something is stored wrong? and this patch will show how it's stored? Or am I understanding this wrong?
The patch does more than just report how it's stored... it should fix the problem. It does here. Somehow writing to the mmap changes the type of variable that it is... and munmap wasn't handling that different variable type... that's what the fix is. Try it out.
Yep, first tests seem positive! So I guess I can close this issue and will also post on that cpan thingie that fix works Thanks for your help!
Above patch worked for me as well. Thanks for digging that up. For any newbies out there like me the trick is getting the source for libsys-mmap-perl (apt-get source libsys-mmap-perl on ubuntu) applying the patch and then recompiling and reinstalling the new libsys-mmap-perl package.
Note that you don't have to re-compile anything at all if you don't want to.
@connortechnology has placed an updated libsys-mmap deb package in his ppa: https://launchpad.net/~iconnor/+archive/zoneminder
For others that run rpm based distros and come upon this note, I've got patched rpms for redhat/centos here under the section titled "Prerequisites": http://www.zoneminder.com/forums/viewtopic.php?f=9&t=19119
and Fedora here: http://www.zoneminder.com/forums/viewtopic.php?f=9&t=21400
Ah, nice. Thanks for the tip!
I know this is an old question, but do you know if this fix is in the Trusty server version?
I just upgraded my server to Trusty, and I am having an issue similar to this one. However the fix is not available through the PPA for Trusty.
When i look at the alarmed pixel outline, they stay the same, and the events are really long.
Hope you can help. I am truly a fan of ZoneMinder.
Best regards Morten Attermann Holst
ok... how about: Why is zmtrigger crashing? have you tried running it manually to see if there is any useful output?
Can you guide me in doing that?
open a command prompt and do the following: sudo /usr/bin/zmtrigger.pl
Hmm... Nothing seems to happen. It must be my settings for the camera that are off, using "best, high sensitivity". However, they worked like a charm in version 1.25.
zmtrigger runs and waits for signals. Eventually it will crash.
Allright, i will give it a longer test. Could it cause the same alarm outline(the red indication) for hours? Thats what I experience. My silouette keeps "hanging" there. Even if the alarm where that was true is long gone.
Venlig hilsen Morten Attermann Holst
On 03 Jul 2015, at 00:29, Isaac Connor notifications@github.com wrote:
zmtrigger runs and waits for signals. Eventually it will crash.
— Reply to this email directly or view it on GitHub.
I suspect that the problem is not in zmtrigger.pl. I would suggest looking at your zmc and zma logs.
Hi, I have the same problem with the latest zoneminder package under Ubuntu 14. The zmtrigger.pl, running as "sudo zmtrigger.pl" is waiting for commands, but from zoneminder service it does not work. zmdc.log contains: "exited abnormally, exit status 9" :(
I'm seeing this on a new install on top of Ubuntu 14.04 with 1 monitor set to "Monitor". My version of ZM is 1.28.2
Mine seems to have quieted down after restarting services. Not sure what could have changed, but I have now added another monitor from the same IP camera and things seem ok.
in my case there is 1 monitor with function Nodect
When using the zmtrigger system for my IP camera's to trigger alarms, it functioned perfect until version 1.24 after that I noticed my diskspace was maxing out. What I saw was events that had over 3000 seconds. When looking in the syslog I noticed this:
After the zmtrigger dies for an unknown reason, (according to google it has something to do with shared memory?) The alert state is not reset of the Monitors and they keep recording, even after zmtrigger restarts, untill a new alarm event is generated and cancelled.
How can I debug this exit status? and is there a fix? (Yes the shmmax is upped)