FAQ

ZoneMinder Frequently Asked Questions

This is the new FAQ page. I will be migrating the existing FAQs here as soon as possible. In the meantime the old FAQ page is available here.

Feel free to contribute any FAQs that you think are missing.

How can I stop ZoneMinder filling up my disk?

Recent versions of ZoneMinder come with a filter you can use for this purpose already included. However by default it is not enabled for event deletion.

The filter is called PurgeWhenFull and to find it, choose one of the event counts from the console page, for instance events in the last hour, for one of your monitors. This will bring up an event listing and a filter window. In the filter window there is a dropdown select box labelled 'Use Filter', that lets your select a saved filter. Select 'PurgeWhenFull' and it will load that filter. Make any modifications you might want, such as the percentage full you want it to kick in, or how many events to delete at a time (it will repeat the filter as many times as needed to clear the space, but will only delete this many events each time to get there). Then click on 'Save' which will bring up a new window. Make sure the 'Automatically delete' box is checked and press save to save your filter. This will then run in the background to keep your disk within those limits.

After you've done that, you changes will automatically be loaded into zmfilter within a few minutes. Check the zmfilter.log file to make sure it is running as sometimes missing perl modules mean that it nevers runs but people don't always realise.

What does a 'Can't shmget: Invalid argument' error in my logs mean?

This error is discussed in the README in the following excerpt:- ...this is caused by an attempt to allocate an amount of shared memory greater than your system can handle. The size it requests is based on the following formula, ring buffer size x image width x image height x 3 (for 24 bit images) + a bit of overhead.

So if for instance you were using 24bit 640x480 then this would come to about 92Mb if you are using the default buffer size of 100. If this is too large then you can either reduce the image or buffer sizes or increase the maximum amount of shared memory available. If you are using RedHat then you can get details on how to change these settings at http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/kernel-resources.html

You should be able to use a similar procedure with other distributions to modify the shared memory pool without kernel recompilations though in some cases this may be necessary. Note, this error also sometimes occurs if you have an old shared memory segment lying around from a previous run that is too small. Use the ipcs and ipcrm system commands to check and remove it if necessary.'"

You can often find out how much shared memory is available by typing the following :-

cat /proc/sys/kernel/shmall

and the most you can allocate in one go :-

cat /proc/sys/kernel/shmmax

To change these values type (for example) :-

echo 134217728 >/proc/sys/kernel/shmall echo 134217728 >/proc/sys/kernel/shmmax

However be aware that sometimes you will only need to change the shmmax value as shmall is often large enough. Also changing these values in this way is only effective until your machine is rebooted. To change them permanently you will need to edit /etc/sysctl.conf and add the following lines (for example) :-

kernel.shmall = 134217728 kernel.shmmax = 134217728

Which will enforce the changes the next time your machine is restarted.

Why is ZoneMinder using so much CPU?

The various elements of ZoneMinder can be involved in some pretty intensive activity, especially while analysing images for motion. However generally this should not overwhelm your machine unless it is very old or underpowered.

There are a number of specific reasons why processor loads can be high either by design or by accident. To figure out exactly what is causing it in your circumstances requires a bit of expermentation.

The main causes are.

1. Using a video palette other than greyscale or RGB24. This can cause a relatively minor performace hit, though still significant. Although some cameras and cards require using planar palettes ZM currently doesn't support this format internally (yet) and each frame is converted to an RGB representation prior to processing. Unless you have compelling reasons for using YUV or reduced RGB type palettes such as hitting USB transfer limits I would experiment to see if RGB24 or greyscale is quicker. Put your monitors into 'Monitor' mode so that only the capture daemons are running and monitor the process load of these (the 'zmc' processes) using top. Try it with various palettes to see if it makes a difference.

2. Big image sizes. A image of 640x480 requires at least four times the processing of a 320x240 image. Experiment with different sizes to see what effect it may have. Sometimes a large image is just two interlaced smaller frames so has no real benefit anyway.

3. Capture frame rates. Unless there's a compelling reason in your case there is often little benefit in running cameras at 25fps when 5-10fps would often get you results just as good. Try changing your monitor settings to limit your cameras to lower frames rates. You can still configure ZM to ignore these limits and capture as fast as possible when an event is detected.

4. Run function. Obviously running in Record or Mocord modes or in Modect with lots of events generates a lot of DB and file activity and so CPU and load will increase.

5. Basic default detection zones. By default when a camera is added one detection zone is added which covers the whole image with a default set of parameters. If you camera covers a view in which various regions are unlikely to generate a valid alarm (ie the sky) then I would experiment with reducing the zone sizes or adding inactive zones to blank out areas you don't want to monitor. Additionally the actual settings of the zone themselves may not be optimal. When doing motion detection the number of changed pixels above a threshold is examined, then this is filter, then contiguous regions are calculated to see if an alarm is generated. If any maximum or minimum threshold is exceeded according to your zone settings at any time the calculation stops. If your settings always result in the calculations going through to the last stage before being failed then additional CPU time is used unnecessarily. Make sure your maximum and minimumzone thresholds are set to sensible values and experiment by switching RECORD_EVENT_STATS on and seeing what the actual values of alarmed pixels etc are during sample events.

6. Optimise your settings. After you've got some settings you're happy with then switching off RECORD_EVENT_STATS will prevent the statistics being written to the database which saves some time. Other settings which might make a difference are ZM_FAST_RGB_DIFFS, ZM_OPT_FRAME_SERVER and the JPEG_xxx_QUALITY ones.

I'm sure there are other things which might make a difference such as what else you have running on the box and memory sizes (make sure there's no swapping going on). Also speed of disk etc will make some difference during event capture and also if you are watching the whole time then you may have a bunch of zms processes running also.

I think the biggest factors are image size, colour depth and capture rate. Having said that I also don't always know why you get certains results from 'top'. For instance if I have a 'zma' daemon running for a monitor that is capturing an image. I've commented out the actual analysis so all it's doing is blending the image with the previous one. In colour mode this takes ~11 milliseconds per frame on my system and the camera is capturing at ~10fps. Using 'top' this reports the process as using ~5% of CPU and permanently in R(un) state. Changing to greyscale mode the blending takes ~4msec (as you would expect as this is roughly a third of 11) but top reports the process as now with 0% CPU and permanently in S(leep) state. So an actual CPU resource usage change of a factor of 3 causes huge differences in reported CPU usage. I have yet to get to the bottom of this but I suspect it's to do with scheduling somewhere along the line and that maybe the greyscale processing will fit into one scheduling time slice whereas the colour one won't but I have no evidence of this yet!

Why is the timeline view all messed up?

The timeline view is a new view allowing you to see a graph of alarm activity over time and to quickly scan and home in on events of interest. However this feature is highly complex and still in beta. It is based extensively on HTML div tags, sometimes lots of them. Whilst FireFox is able to render this view successfully other browsers, particular Internet Explorer do not seem able to cope and so present a messed up view, either always or when there are a lot of events. Using the timeline view is only recommended when using FireFox, however even then there may be issues.

How much Hard Disk Space do I need for ZM?

Please see Storage Calc in excel format

Why don't all my cameras display when I use the Montage view in FireFox?

By default FireFox only supports a small number of simultaneous connections. Using the montage view usually requires one persistent onnection for each camera plus intermittant connections for other information such as statuses. You will need to increase the number of allowed connections to use the montage view with more than a small number of cameras. This is a simple process and details of how to do it are available from this forum thread. Certain FireFox extensions such as FasterFox may also help to acehive the same result.

When I try and run ZoneMinder I get lots of audit permission errors in the logs and it won't start

Many Linux distributions nowadays are built with security in mind. One of the latest methods of achieving this is via SELinux (Secure Linux) which controls who is able to run what in a more precise way then traditional accounting and file based permissions ([1]). If you are seeing entries in your system log like

Jun 11 20:44:02 kernel: audit(1150033442.443:226): avc: denied { read } for pid=5068 comm="uptime" name="utmp" dev=dm-0 ino=16908345 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:object_r:initrc_var_run_t tclass=file

then it is likely that your system has SELinux enabled and it is preventing ZoneMinder from performaing ceratin activities. You then have two choices. You can either tune SELinux to permit the required operations or you can disable SELinux entirely which will permit ZoneMinder to run unhindered. Disabling SELinux is usually performed by editing it's configuration file (e.g., /etc/selinux/config) and then rebooting. However if you run a public server you should read up on the risks associated with disabled Secure Linux before disabling it.