1.28.1: /usr/bin/zmpkg.pl's Fatal doesn't output anything (debian)

[marcmerlin]

/usr/bin/zmpkg.pl start would just return with -1 and no output after upgrading from 1.26. I have no idea where Fatal is going, but not /var/log/zoneminder.log

In the end I ran s/Fatal/die/ in /usr/bin/zmpkg.pl and now I see what I needed: Version mismatch, system is version 1.28.1, database is 1.26.5, please run zmupdate.pl to update. at /usr/bin/zmpkg.pl line 163.

[knight-of-ni]

I can't duplicate this. Each time I intentionally try to start zoneminder under conditions I know it won't run, I get an appropriate error message shown on stdout and in the log.

One always needs to run sudo zmupdate.pl after every package upgrade. ZoneMinder will not run if the dB schema does not match what it expects. Additionally, the version number in the web console will appear red and will indicate a version mismatch.

Did you install from a package? Your package should have included some kind of upgrade instructions, which should have instructed you how to upgrade. I don't use Debian and am not aware of how they are handling that.

ZoneMinder's log output is controlled by the web console under Options -> Logging, which you can get to regardless of zoneminder's run state. Verify you've told ZoneMinder where you want log entries to show up.

Executing "zmpkg.pl" start is not the intended way to start zoneminder. Executing that as a normal user will fail every time. Zoneminder was intended to be run as a service.

This is how you should start zoneminder: sudo service zoneminder start -or- sudo systemctl start zoneminder

depending on your system type.

[marcmerlin]

Christian/Vagrant, see below for your package probably not running zmupdate.pl on package update.

On Sat, Oct 03, 2015 at 05:56:29AM -0700, Andrew Bauer wrote:

I can't duplicate this. Each time I intentionally try to start zoneminder under conditions I know it won't run, I get an appropriate error message shown on stdout and in the log.

So maybe the debian package is broken, can't say.

One always needs to run sudo zmupdate.pl after every package upgrade. ZoneMinder will not run if the dB schema does not match what it expects. Additionally, the version number in the web console will appear red and will indicate a version mismatch when clocked.

I totally understand that, I just don't understand why I got no error telling me so.

Did you install from a package? Your package should have included some kind of upgrade instructions, which should have instructed you how to upgrade. I don't use Debian and am not aware of how they are handling that.

Package: zoneminder Status: install ok installed Priority: optional Section: net Installed-Size: 13278
Maintainer: Christian Marillat marillat@deb-multimedia.org
Bugs: mailto:marillat@deb-multimedia.org
Architecture: i386
Source: zoneminder-dmo Version: 1.28.1-dmo11 Config-Version: 1.26.5-3

now looking at pre/postinst, it indeed does not run zmupdate.pl, so that's a small bug with the package, but I don't understand why Fatal in zmpkg.pl just doesn't get output on my console.

/usr/share/doc/zoneminder/README.Debian does mention you should run zmupdate.pl but I'm not sure why it does not do so automatically in postinst since it'll just update you and leave you in a broken state.

ZoneMinder's log output is controlled by the web console under Options -> Logging, which you can get to regardless of zoneminder's run state. Verify you've told ZoneMinder where you want log entries to show up.

I'm looking at LOG_LEVEL_SYSLOG which is set to info. So it's possible the failure was being logged to syslog, but that's not what you expect for a launch failure. Is Fatal in zmpkg.pl supposed to also go to console/stderr, or not at all?

Executing "zmpkg.pl" start is not the intended way to start zoneminder. Executing that as a normal user will fail every time. Zoneminder was intended to be run as a service.

Yes, I did run the init script and only when the init script was failing silently did I bash -vx it, and then run zmpkg.pl manually to see why it wasn't starting and why it was outputting nothing.

Mmmh, but actually I just changed zmpkg.pl to do this:

use lib '/usr/lib/i386-linux-gnu/perl5'; use ZoneMinder; use DBI; use POSIX; use Time::HiRes qw/gettimeofday/;

Detaint our environment

$ENV{PATH} = '/bin:/usr/bin'; $ENV{SHELL} = '/bin/sh' if exists $ENV{SHELL}; delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};

logInit();

Fatal( "test" );

I got absolutely nothing in syslog and nothing in /var/log/zoneminder.log

So for now I changed s/Fatal/die/ in zmpkg.pl and die properly gives errors while Fatal seems to go to /dev/null.

Marc

"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901

[connortechnology]

I am re-introducing zmupdate.pl into the postinst in our copy of the package scripts.

I think debian should put them back too.

[knight-of-ni]

/usr/share/doc/zoneminder/README.Debian does mention you should run zmupdate.pl but I'm not sure why it does not do so automatically in postinst since it'll just update you and leave you in a broken state.

You assumed the upgrade process was automatic, when in fact the Debian package maintainers made it a manual process and even documented it in their README. You may not agree with why they did it, but that is their choice to make. You should go through normal Debian channels if you wish to discuss the "why" part with them. They don't necessarily read our forum or use the packaging scripts we provide in our source tree. They've actually told us they don't use our packaging scripts. This is not the case with Ubuntu, however, since @connortechnology manages those.

You should always read the Debian README file after every upgrade. This is how changes are documented, and as you have discovered they are not guaranteed to always be automatic. I'm going out of my way to say this, because there are changes coming in the next release which might cause similar kinds of issues. I'd expect the Debian guys to document in their README how they want you to handle those changes when the time comes.

This is how ZoneMinder is to be started:

[abauer@localhost log]$ sudo service zoneminder start
Starting ZoneMinder:                                       [FAILED]

Seeing that the service failed, one should check the syslog:

[abauer@localhost log]$ sudo cat /var/log/messages |grep zmpkg
Oct  7 08:05:33 localhost zmpkg[6454]: INF [Command: start]
Oct  7 08:05:33 localhost zmpkg[6454]: FAT [Version mismatch, system is version 1.28.107, database is 1.28.101, please run zmupdate.pl to update.]

And just for giggles, here is the same thing on Ubuntu:

user@vmubuntu:~$ sudo service zoneminder start
Starting ZoneMinder: failure

We check the syslog since the service failed:

user@vmubuntu:/var/log$ cat /var/log/syslog |grep zmpkg
Oct  7 08:43:36 vmubuntu zmpkg[2949]: INF [Command: start]
Oct  7 08:43:36 vmubuntu zmpkg[2949]: FAT [Version mismatch, system is version 1.28.1, database is 1.28.0, please run zmupdate.pl to update.]

This is normal behaviour for any service. As you can see the Perl sub Fatal is working as intended.

Yes, I know you said you did not get anything in your syslog, but what I'm saying is that the problem is specific to the environment you are running in. So far you have not produced any data that might hint at the cause. You need to keep digging.

You mentioned this was an upgrade from 1.26. I'm not aware that Debian built a package from version 1.26. How did you install that version originally? Was it from source? It is very easy to end up with stale files lying around when migrating a from-source install to a package based install. That could cause all sorts of unexpected behaviour.

[marcmerlin]

On Wed, Oct 07, 2015 at 06:50:38AM -0700, Andrew Bauer wrote:

You assumed the upgrade process was automatic, when in fact the Debian package maintainers made it a manual process and even documented it in their README. You may not agree with why they did it, but that is their choice to make. You should go through normal Debian

Understood, and I'm not complaining about that :) As explained below, zmpkg doesn't even seem to send anything from Fatal() to syslog.

You should always read the Debian README file after every upgrade. This is how changes are documented, and as you have discovered they are not guaranteed to always be automatic. I'm going out of my way to say this, because there are changes coming in the next release which might cause similar kinds of issues. I'd expect the Debian guys to document in their README how they want you to handle those changes when the time comes.

Debian actually as a special way to report "please read this" notes on upgrades. I just wasn't used here. But again, not your fault, nor the main issue I was reporting.

This is how ZoneMinder is to be started:

[abauer@localhost log]$ sudo service zoneminder start
Starting ZoneMinder:                                       [FAILED]

Seeing that the service failed, one should check the syslog:

[abauer@localhost log]$ sudo cat /var/log/messages |grep zmpkg
Oct  7 08:05:33 localhost zmpkg[6454]: INF [Command: start]
Oct  7 08:05:33 localhost zmpkg[6454]: FAT [Version mismatch, system is version 1.28.107, database is 1.28.101, please run zmupdate.pl to update.]

Right. I'd still say that I can't see why Fatal would not also output on stderr.

I have: /etc/rsyslog.conf:if $programname startswith 'zm' then /var/log/zoneminder.log

I see zm logs in that file, but nothing from zmpkg, and nothing from zmpkg in any other syslog file either.

Yes, I know you said you did not get anything in your syslog, but what I'm saying is that the problem is specific to the environment you are running in. So far you have not produced any data that might hint at the cause. You need to keep digging.

That's fair. I've modified zmpkg.pl to do this: logInit(); Fatal("test"); << added this line

gargamel:~# strace -s 256 -f /usr/bin/zmpkg.pl 2>&1 | grep test read(6, "package Sys::Mmap;\n\n=head1 NAME\n\nSys::Mmap - uses mmap to map in a file as a Perl variable\n\n=head1 SYNOPSIS\n\n use Sys::Mmap;\n\n new Mmap $str, 8192, 'structtest2.pl' or die $!;\n new Mmap $var, 8192 or die $!;\n\n mmap($foo, 0, PROT_READ, MAP_SHARE"..., 8192) = 8192 read(3, "use DBI;\nuse POSIX;\nuse Time::HiRes qw/gettimeofday/;\n\n# Detaint our environment\n$ENV{PATH} = '/bin:/usr/bin';\n$ENV{SHELL} = '/bin/sh' if exists $ENV{SHELL};\ndelete @ENV{qw(IFS CDPATH ENV BASH_ENV)};\n\nlogInit();\nFatal(\"test\");\n\nmy $command = $ARGV[0];\n\nmy"..., 8192) = 6810

This does not show zmpkg sending "test" to syslog.

You mentioned this was an upgrade from 1.26. I'm not aware that Debian built a package from version 1.26. How did you install that version originally? Was it from source? It is very easy to end up with stale files lying around when migrating a from-source install to a package based install. That could cause all sorts of unexpected behaviour.

Not sure where I got it from anymore: gargamel:/# dpkg --status zoneminder Package: zoneminder Status: install ok installed Priority: optional Section: net Installed-Size: 10198 Maintainer: Peter Howard pjh@northern-ridge.com.au Architecture: i386 Version: 1.26.5-3 Depends: libavcodec54 (>= 6:9.1-1) | libavcodec-extra-54 (>= 6:9.10), libavdevice53 (>= 6:9.1-1), libavformat54 (>= 6:9.1-1), libavutil52 (>= 6:9.1-1), libbz2-1.0, libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libgcrypt11 (>= 1.5.1), libgnutls-openssl27, libgnutls26 (>= 2.12.17-0), libjpeg8 (>= 8c), libmysqlclient18 (>= 5.5.24+dfsg-1), libpcre3 (>= 8.10), libstdc++6 (>= 4.1.1), libswscale2 (>= 6:9.1-1), zlib1g (>= 1:1.1.4), perl, apache2, libapache2-mod-php5, php5, php5-mysql, libphp-serialization-perl, libdate-manip-perl, libmime-tools-perl, libmime-lite-perl, mysql-server, mysql-client, libwww-perl, libarchive-tar-perl, libarchive-zip-perl, libdevice-serialport-perl, rsyslog | system-log-daemon, libmodule-load-perl, libjs-mootools, libsys-mmap-perl, zip, javascript-common Conffiles: /etc/init.d/zoneminder a8907f39b5963868855e60e175d3ca24 /etc/zm/apache.conf 20eb5d0df8842df2df7e75d60330d3b9 /etc/zm/zm.conf 551a7afcd89fc2d7d501e16478e54043

Marc

"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901

[knight-of-ni]

I'm closing this out because this does not appear to be something that we can fix on our end. If new information becomes available which indicates otherwise, then we can reopen it at that time.

[marcmerlin]

I agree that it's probably nothing wrong in Zoneminder that is causing Fatal not to reach syslog in my install, but as I showed in my last update, the zoneminder build I have never even sends the Fatal message to syslog (as shown by strace) and yet sends normal messages there.

Either way, would you agree to having a feature request to have Fatal also go to stderr? I'm not sure if this would be desired in all cases (although in mine it's obvious), so you can tell me what you think. If needed, I can open a separate issue for that feature request