zmtrigger.pl or alternatives

[lazyleopard]

With previous versions of ZoneMinder I've hacked together a zmforce.pl script to allow me to put a monitor into alarm state, take it out of alarm state, or tell it to produce a one-frame alarm event by issuing a single command. I use it from remind like this:

Code: Select all

REM AT [sunrise()-15] RUN /usr/bin/zmforce.pl -c snapshot -r Sunrise
REM AT [sunrise()+((sunset()-sunrise())/2)] RUN /usr/bin/zmforce.pl -c snapshot -r Midday
REM AT [sunset()+15] RUN /usr/bin/zmforce.pl -c snapshot -r Sunset
REM AT 00:00 RUN /usr/bin/zmforce.pl -c snapshot -m 9 -r Midnight

I'm wondering how to achieve this with 1.22.0. It looks as if zmtrigger.pl ought to be usable somehow or other, but I've not figured out the simplest way to get the appropriate commands into it. Also it does seem to be a bit fragile in its current state, as I keep seeing this in my logs:

Code: Select all

Jan 22 18:40:51 chui zmdc[19703]: INF [Starting pending process, zmtrigger.pl] 
Jan 22 18:40:51 chui zmdc[19703]: INF ['zmtrigger.pl' starting at 06/01/22 18:40:51, pid = 32411] 
Jan 22 18:40:51 chui zmdc[32411]: INF ['zmtrigger.pl' started at 06/01/22 18:40:51]
Jan 22 18:40:51 chui zmdc[19703]: ERR ['zmtrigger.pl ' crashed, exit status 2] 

Thoughts, anyone?

[lazyleopard]

Of course, carefully reading the documentation in ZoneMinder/lib/ZoneMinder/SharedMem.pm reveals the necessary information, and allows my earlier zmforce.pl script to be re-coded for 1.22.0 by removing most of it and adding a few new lines. The important magic words are zmTriggerEventOn and zmTriggerEventCancel.

[lazyleopard]

Doesn't explain the

Code: Select all

Jan 22 18:40:51 chui zmdc[19703]: ERR ['zmtrigger.pl ' crashed, exit status 2] 

which I'd helpfully failed to paste in earlier, though.

[zoneminder]

I will look at that error. In 1.22.0 and onwards zmtrigger.pl is intended more as a trigger daemon, but it is a bit rough around the edges until I get some concrete examples of how people want to use it.

As you correctly surmised, using the perl modules is the new way to go for generating bespoke events. An example script might just be this

Code: Select all

#!/bin/perl -w

use strict;

use ZoneMinder;

my $monitor = { Id=>1 };

zmDbgInit( "test", level=>1 );

my $ok = zmShmVerify( $monitor );
if ( $ok )
{
    zmTriggerEventOn( $monitor, 100, "test", "this is a test event" );
    sleep( 10 );
    zmTriggerEventCancel( $monitor );
}

or even less if you don't want debug. The shared memory function descriptions etc are available via 'perldoc ZoneMinder::SharedMem' as well as in the normal docs.

[lazyleopard]

Of course, turning Options->System->ZM_OPT_TRIGGERS off gets rid of the zmtrigger.pl crashes by making sure nothing tries to start it in the first place.

Another thing is that many more zoneminder messages now seem to be going to syslog. That makes chasing problems down easier because everything's in the same place. Is it also controlled by an option somewhere, or is it built-in.

[zoneminder]

Of course, turning Options->System->ZM_OPT_TRIGGERS off gets rid of the zmtrigger.pl crashes by making sure nothing tries to start it in the first place.

Yes, it's only necessary to switch it on if you need to run the daemon to interface with other systems. It's also worth remembering that as shipped, zmtrigger.pl is probably not a lot of use. It needs to be tailored to individual circumstance to have much benefit.

Another thing is that many more zoneminder messages now seem to be going to syslog. That makes chasing problems down easier because everything's in the same place. Is it also controlled by an option somewhere, or is it built-in.

It's pretty much built in. There is a discussion of changes to logging in the Troubleshooting section of the new README.

[lazyleopard]

Ah. Found it.

FEATURE – Script debug now follows the same format as all debug and uses the syslog facility. This means that all important messages go into the /var/log/messages file (or equivalent). This can be modified by redirecting the local1 facility in syslog.conf to go elsewhere, or be ignored, if so desired.

Does all the syslog information go to local1 (with the appropriate severity) or does some of it go onto other queues?

[zoneminder]

It all uses the local1 facility, though with different priorities depending on the message. As I mentioned, the Troubleshooting section gives sample entries for syslog.conf that will direct all ZM messages to one file, or filter off just errors to messges etc. I assume this is the same across all distros but I couldn't say for sure!

[lazyleopard]

I guess it'll depend on the syslog daemon being used. The one I use (sysklogd) does use /etc/syslog.conf as described. No idea what the other ones do. The Gentoo default is syslog-ng.