1.21.4 Early Release

Support and queries relating to all previous versions of ZoneMinder
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

1.21.4 Early Release

Post by zoneminder »

I'm just about ready to release 1.21.4. However is has turned out a lot larger than I originally expected which a bunch more features and fixes. So I would prefer to release it initially to users who are willing to test it and report back any issues which I can correct before before a wider release.

If you would like to try the initial version of 1.21.4 on the proviso that it might trash your DB etc then please let me know and I will send you the link.

Cheers

Phil
SyRenity
Posts: 301
Joined: Mon Jan 24, 2005 2:43 pm

Post by SyRenity »

Hi Phil.

Me, of course :). I will set for it an additional, test DB.
User avatar
lazyleopard
Posts: 403
Joined: Tue Mar 02, 2004 6:12 pm
Location: Gloucestershire, UK

Post by lazyleopard »

Yep, I think I should be able to give it a try.
Rick Hewett
jameswilson
Posts: 5111
Joined: Wed Jun 08, 2005 8:07 pm
Location: Midlands UK

Post by jameswilson »

me too. but i have only ever done rpm's before so ill learn how to do it properly now
James Wilson

Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Post by zoneminder »

PMs with download details sent. Good luck and feel free to report back on any issues (or successes :D) here.

Phil
User avatar
lazyleopard
Posts: 403
Joined: Tue Mar 02, 2004 6:12 pm
Location: Gloucestershire, UK

Re: 1.21.4 Early Release

Post by lazyleopard »

zoneminder wrote:on the proviso that it might trash your DB etc
Yep, that does seem to be a likely consequence at present. It's not yet clear where everything went or what wiped it, but my test system (it watches TV rather than actual live video) is now as clean as a whistle... ;)
Rick Hewett
User avatar
lazyleopard
Posts: 403
Joined: Tue Mar 02, 2004 6:12 pm
Location: Gloucestershire, UK

Post by lazyleopard »

Other than that, it seems to be alive. More testing will have to wait...
Rick Hewett
martymoose
Posts: 128
Joined: Tue Jul 12, 2005 9:59 am
Location: australia

Post by martymoose »

i have a go
will have to have the steps to install, linux newbie

i have hard drive version of live cd running very sweet at the moment

thanks
User avatar
cordel
Posts: 5210
Joined: Fri Mar 05, 2004 4:47 pm
Location: /USA/Washington/Seattle

Post by cordel »

whoohoo,
Send me a link and i'll start working out the changes for packaging.
Also I know you have been working out ffmpeg issues so whats the scoop?

Regards,
Cordel
User avatar
lazyleopard
Posts: 403
Joined: Tue Mar 02, 2004 6:12 pm
Location: Gloucestershire, UK

Post by lazyleopard »

Another oddness: I shut zm down using init.d/zm and then went to the control web page and hit "Refresh" to get confirmation. That seems to have caused a new "zmdc.pl status" process to be spawned, and it stayed up overnight. That wasn't a problem until the web-server was bounced by the overnight cron job. At that point apache closed down and then wouldn't restart because the "zmdc.pl status" had bound to ports 80 and 443.

To reproduce, stop the zm processes, then visit the zoneminder control page. Then look for processes and ports:

Code: Select all

chui ~ # ps auxwww |grep zm
apache   22107  0.0  1.0   7960  5256 ?        S    08:36   0:00 /usr/bin/perl -wT /usr/bin/zmdc.pl status
root     22147  0.0  0.0   1504   464 pts/1    R+   08:37   0:00 grep zm
chui ~ # netstat -tupan |egrep -w '80|443'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      21970/apache2       
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      21970/apache2       
tcp        0      0 192.168.17.226:80       192.168.17.228:57262    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57260    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57261    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57259    TIME_WAIT   -    
Now stop apache and look for processes and ports again:

Code: Select all

chui ~ # /etc/init.d/apache2 stop 
 * Stopping apache2 ...                                                   [ ok ]
chui ~ # netstat -tupan |egrep -w '80|443'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      22107/perl          
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      22107/perl          
tcp        0      0 192.168.17.226:80       192.168.17.228:57262    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57261    TIME_WAIT   -                   
Rick Hewett
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Re: 1.21.4 Early Release

Post by zoneminder »

lazyleopard wrote:
zoneminder wrote:on the proviso that it might trash your DB etc
Yep, that does seem to be a likely consequence at present. It's not yet clear where everything went or what wiped it, but my test system (it watches TV rather than actual live video) is now as clean as a whistle... ;)
That was actually an offhand, cover my arse, comment rather than a prediction :lol:

Nothing should actually get deleted form your DB during the upgrade. I was more referring to it falling over in the middle of the upgrade and leaving it somewhere between 1.21.3 and 1.21.4. When you did the upgrade did you use the backup facility in zmupdate? (which I might remove for the real release as it could do with doing a backup before then really).

Phil
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Post by zoneminder »

lazyleopard wrote:Another oddness: I shut zm down using init.d/zm and then went to the control web page and hit "Refresh" to get confirmation. That seems to have caused a new "zmdc.pl status" process to be spawned, and it stayed up overnight. That wasn't a problem until the web-server was bounced by the overnight cron job. At that point apache closed down and then wouldn't restart because the "zmdc.pl status" had bound to ports 80 and 443.

To reproduce, stop the zm processes, then visit the zoneminder control page. Then look for processes and ports:

Code: Select all

chui ~ # ps auxwww |grep zm
apache   22107  0.0  1.0   7960  5256 ?        S    08:36   0:00 /usr/bin/perl -wT /usr/bin/zmdc.pl status
root     22147  0.0  0.0   1504   464 pts/1    R+   08:37   0:00 grep zm
chui ~ # netstat -tupan |egrep -w '80|443'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      21970/apache2       
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      21970/apache2       
tcp        0      0 192.168.17.226:80       192.168.17.228:57262    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57260    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57261    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57259    TIME_WAIT   -    
Now stop apache and look for processes and ports again:

Code: Select all

chui ~ # /etc/init.d/apache2 stop 
 * Stopping apache2 ...                                                   [ ok ]
chui ~ # netstat -tupan |egrep -w '80|443'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      22107/perl          
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      22107/perl          
tcp        0      0 192.168.17.226:80       192.168.17.228:57262    TIME_WAIT   -                   
tcp        0      0 192.168.17.226:80       192.168.17.228:57261    TIME_WAIT   -                   
I can't actually reproduce this behavious as you have described it. I can sort of think of a circumstance where if you hit 'refresh' manually halfway through it shutting down that you might end up starting up an additional orphaned zmdc.pl process but otherwise the refresh should not take place until the processes are all stopped, and then it should br protected.

Although there are a lot of changes in 1.21.4 there aren't actually any in the main control scripts so I can't think why things might be different than before in this area.

Phil
User avatar
lazyleopard
Posts: 403
Joined: Tue Mar 02, 2004 6:12 pm
Location: Gloucestershire, UK

Re: 1.21.4 Early Release

Post by lazyleopard »

zoneminder wrote:Nothing should actually get deleted form your DB during the upgrade. I was more referring to it falling over in the middle of the upgrade and leaving it somewhere between 1.21.3 and 1.21.4. When you did the upgrade did you use the backup facility in zmupdate?
I couldn't get zmupdate to run. It doesn't seem to want to cope with a main mysql password, and it does seem to need to run with --user=root rather than --user={zmuser}. So I applied the schema update manually.

The events were deleted by zmfilter.pl, but it's not clear from the log which filter has done the deleting. The events it deleted should all have been marked as Archived, and the filters permitted to delete events should all act only on Unarchived events, but all the events ended up being deleted.
zoneminder wrote:end up starting up an additional orphaned zmdc.pl process
It seems that "zmdc.pl status" may hang around waiting to see whether ports 80 and 443 are available. If they are not bound to apache (or if apache lets go of them) then it grabs them. The orphaned "zmdc.pl status" seems to be started from something on the cgi/php side that deals with the web interface when zoneminder isn't running. However, I've noticed that if apache is stopped while zoneminder is running then a "zmdc.pl status" will grab ports 80 and 443 and prevent apache from starting again. On my main zoneminder machine I make sure in all the relevant cron jobs that zoneminder is always shut down before apache and then re-started after apache, so I think I've noticed this port-grabbing before.
Rick Hewett
jameswilson
Posts: 5111
Joined: Wed Jun 08, 2005 8:07 pm
Location: Midlands UK

Post by jameswilson »

my 2 pence i have noticed this port grabbing too before so i doubt its new and i didnt know (didnt look) what was grabbing the ports
James Wilson

Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
User avatar
zoneminder
Site Admin
Posts: 5215
Joined: Wed Jul 09, 2003 2:07 pm
Location: Bristol, UK
Contact:

Re: 1.21.4 Early Release

Post by zoneminder »

lazyleopard wrote:
zoneminder wrote:Nothing should actually get deleted form your DB during the upgrade. I was more referring to it falling over in the middle of the upgrade and leaving it somewhere between 1.21.3 and 1.21.4. When you did the upgrade did you use the backup facility in zmupdate?
I couldn't get zmupdate to run. It doesn't seem to want to cope with a main mysql password, and it does seem to need to run with --user=root rather than --user={zmuser}. So I applied the schema update manually.
Ah, I think that is the root of your problem then. As well as the schema change zmupdate also does some data munging, moves things around and basically fixes up the db for the new version. Without this you may well hit problems, though I don't think it should result in deleted events. Any saved filters might not work though (until you load and resave them) and the monitor sequencing might be a bit screwed up. You can pass in a priveleged DB user and password via the -u and -p switches though you still have to run it as root. I'm looking at revamping this, and the whole zmconfig thing in the next release as they have grown out of their shoes really.
lazyleopard wrote:It seems that "zmdc.pl status" may hang around waiting to see whether ports 80 and 443 are available. If they are not bound to apache (or if apache lets go of them) then it grabs them. The orphaned "zmdc.pl status" seems to be started from something on the cgi/php side that deals with the web interface when zoneminder isn't running. However, I've noticed that if apache is stopped while zoneminder is running then a "zmdc.pl status" will grab ports 80 and 443 and prevent apache from starting again. On my main zoneminder machine I make sure in all the relevant cron jobs that zoneminder is always shut down before apache and then re-started after apache, so I think I've noticed this port-grabbing before.
This is most strange. I don't see any of this kind of behaviour. What distro are you running?

Phil
Locked