Debugging write problems

Forum for questions and support relating to the 1.32.x releases only.
Post Reply
zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Debugging write problems

Post by zmeggyesi » Mon Dec 10, 2018 7:39 am

Hi,

After a recent upgrade to 1.32.2 (built from source, via packpack, on Raspbian), I've found that ZoneMinder is no longer storing detected images to an external drive.

Previously, on 1.31.1, storing worked perfectly well, and I can see the diagnostic images updating in real time, but event directories are not being created. Log shows no errors, nor any relevant warning.

Can anyone help me on how I can debug the issue?

security_dude
Posts: 19
Joined: Sun Oct 07, 2018 6:55 pm

Re: Debugging write problems

Post by security_dude » Tue Dec 11, 2018 5:52 am

Try updating to 1.32.3

zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Re: Debugging write problems

Post by zmeggyesi » Tue Dec 11, 2018 2:23 pm

Well, kind of the obvious thing to do, though not sure why writing would be broken in the first place...
Running the build will take some time, but once the server is back up, I'll see if it works.

If it doesn't, any ideas on how I could try to get to the bottom of it? It doesn't look like a *nix permissions issue, as the various directories on the external drive are all owned by the www-data user.

User avatar
iconnor
Posts: 727
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: Debugging write problems

Post by iconnor » Tue Dec 11, 2018 2:35 pm

Turn on debug and see what is happening?

zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Re: Debugging write problems

Post by zmeggyesi » Tue Dec 11, 2018 2:41 pm

Tried that - at debug level 9, with no module restrictions, nothing mentioned any failures. The external drive itself was only referenced when the analysis daemon launched, and never again.

zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Re: Debugging write problems

Post by zmeggyesi » Wed Dec 12, 2018 8:24 am

I've updated to 1.32.3, but writes were not fixed, although new log files now appeared. In particular, one of the analysis daemon logs had this line:

Code: Select all

12/12/18 07:10:03.278685 zma_m6[1224].ERR-zm_event.cpp/180 [Can't mkdir /8127: Permission denied]
which is both surprising and not: on the one hand, it's hardly surprising that a write to the root file system would be denied; but it is surprising that ZM tries to write to the root FS in the first place.

In the storage configurations, I'm looking at a scheme of SHALLOW, a fully specified path of /mnt/external, so I'm guessing this is intended to be concatenated?

zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Re: Debugging write problems

Post by zmeggyesi » Fri Dec 14, 2018 7:43 am

Does anyone have any ideas on how I could debug this further? I'm kind of at a loss as to why ZM would be attempting to write to the root dir...

User avatar
iconnor
Posts: 727
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: Debugging write problems

Post by iconnor » Fri Dec 14, 2018 1:51 pm

First off, don't use shallow, it is there for legacy reasons,or some weird special case. Switch to medium which is what most people are using, and hence has the most testing.

I will go take a look at the shallow code and see if I can see a bug.

User avatar
iconnor
Posts: 727
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: Debugging write problems

Post by iconnor » Fri Dec 14, 2018 1:56 pm

Dang it yeah. Shallow is no good. Fixed in master now. Switch to Either Medium or Deep and you will be ok.

zmeggyesi
Posts: 19
Joined: Mon Mar 05, 2018 12:10 pm

Re: Debugging write problems

Post by zmeggyesi » Sat Dec 15, 2018 1:42 pm

Just ran the build with your fix from master, and it seems to have worked, I'm seeing images come up in the right place.

There still seems to be something off in how filters handle paths during compression-upload, but I don't have anything specific on that front yet.

bbarnett
Posts: 11
Joined: Thu Dec 22, 2005 11:40 pm

Re: Debugging write problems

Post by bbarnett » Fri May 24, 2019 1:20 pm

Just got hit with this.

I've recently upgraded from 1.25 to 1.32.3.. and had a lot of events / monitors using Shallow. I don't care too much about moving historical events from Shallow to Medium, except that some cameras do have a lot of historical data... and Medium is better for this.

So.. I wrote this bash script. Feel free to package it / provide it as a user script in src, or what not.. consider it released under "I'm immune to you suing me, but you can do whatever you want with it" license.

Code: Select all

#!/bin/bash

# NOTE: this script is hacky.. I slapped it together for my own use...
# it does check quite a few things.. but will destroy your house, ruin your
# bread maker, and scare your cat... if you use it without care!

# steps to not feel horrible regret
# DO cp -a your entire monitor dir first.  EG...
#
# cd /where/i/keep/events/; cp -a <monitor_id> <tempdir>
# cd <tempdir>
# .. run script ..
# if all seems OK
# cd /where/i/keep/events/; mv <monitor_id> <monitor_id>.orig
# mv <tempdir> <monitor_id>
# DO SQL STUFF LISTED BELOW
# .. test .. can you view events?  is all OK?  then rm <monitor_id>.orig
#
# # # DO NOT FEEL HORRIBLE REGRET .. DO THE ABOVE! # # #

# after you run this successfully, you'll want to go into the DB, and modify these same
# events so that they are not Scheme=Shallow, but Medium...
# eg "update Events set Scheme='Medium' where Scheme='Shallow' and monitorid=<your monitor id>;"
# (why don't I do this in this script?  because it's one SQL when done, and plus I'm lazy)

# Next.. this takes time.  I don't care.  I don't care if you care.  I care about it working,
# or freaking out and aborting if it isn't.  Because any other method means MORE time, if it
# doesn't have sufficient checking, and borks!

# Uh.. last next.  Not tested on anything other than Debian, with a GNU userland..
# it'll surely break (date I think alone is different on MacOS?) elsewhere, but at
# least there is a lot of debug/testing available...

# oh.. right...
# If in the past, you moved/copied/messed with your event directories, for example
# you did a cp of <monitor_id> dir without -a, or -p / --preserve times_and_such,
# this this script will be angry, and refuse to work.  And it'll be because you
# didn't do your work, now did you?
#
# Instead, you slacked off, didn't 'man cp', and think about saving such
# Important Things as Timestamps.. as if when things happened was utterly and
# completely unimportant Henry... uh, I mean.. not Henry but anyone else.
#
#

# DEBUG to start!  Once happy, remove this..
debug=echo
# no debug
#debug=""

# chown command for zoneminder access
permcom="chown www-data:www-data"
# if you don't want to chown... I'll still touch your stuff
#permcom="touch"

function out() {
    if [ "$debug" != "" ]; then
        echo $lineout
    fi
    return
}

# mysql user
mysqluser=root

# your mysql pass (if required)
export MYSQL_PWD=""

# must be numeric value of monitor
monitor=6
testfile=001-capture.jpg
db=zm
query="Events where MonitorId=$monitor and Scheme='Shallow'";

count=$(echo "select count(id) from $query" | mysql -N $db)

if [ $? -ne 0 ]; then
    echo "mysql seemed to bork.. perms problem?  Exiting.."
    exit 1
fi

echo "Detected $count events to work with..."

echo "select id, date(StartTime) from $query" | mysql -N $db -u$mysqluser | while read id startdate; do
    echo "id=$id and startdate=$startdate"
    if [ -d $id ] && [ -x $id ] && [ -w $id ] && [ -r $id ]; then
        lineout="Found event dir $id... "; out
        if [ -f "$id/$testfile" ]; then
            filedate=$(date -r "$id/$testfile" +%Y-%m-%d)
            if [ "$filedate" == "$startdate" ]; then
                # extra check, mostly for debugging
                if [ -e "$startdate" ] && [ ! -d "$startdate" ]; then
                    echo "$startdate exists and is a non-dir... can't mkdir here!"
                    exit 1
                fi
                #
                if [ ! -e "$startdate" ]; then
                    echo "$startdate dir doesn't exist... creating.."
                    $debug mkdir "$startdate"
                    if [ $? -ne 0 ]; then
                        echo "Unable to mkdir $startdate, exiting..."
                        exit 1
                    fi
                    $debug $permcom "$startdate"
                fi

                $debug mv "$id" "$startdate/"
                if [ $? -ne 0 ]; then
                    echo "Borked on mv $id $startdate/, exiting..."
                    exit 1
                else
                    echo "mv succeeded!"
                fi
            else
                echo "Dir date does not match ZM DB date.. moving on for safety sake.."
                continue
            fi
        else
            echo "Borked"
            exit 1
        fi
    else
        echo "Can't find or read/etc $id dir, moving on.."
        continue
    fi
done


bbarnett
Posts: 11
Joined: Thu Dec 22, 2005 11:40 pm

Re: Debugging write problems

Post by bbarnett » Fri May 24, 2019 1:25 pm

I might add... lots of codebases have a <contrib> dir...

ZM doesn't seem to have one, but contrib dir / places to upload code can really help a project. So.. suggesting a 'contrib' dir, and if so, go ahead and throw this code there.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests