Package Details: zoneminder 1.36.35-1

Git Clone URL: https://aur.archlinux.org/zoneminder.git (read-only, click to copy)
Package Base: zoneminder
Description: A full-featured, open source, state-of-the-art video surveillance software system
Upstream URL: https://zoneminder.com/
Keywords: camera cctv monitor record security surveillance video zoneminder
Licenses: GPL-2.0-only
Submitter: None
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 72
Popularity: 0.39
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2024-10-22 17:14 (UTC)

Dependencies (45)

Sources (8)

Latest Comments

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 63 Next › Last »

felixita commented on 2019-05-16 19:38 (UTC)

Hi, i've made a fresh install of zm 1.32.3-1 but not work: zoneminder webpage get Unable to connect to ZM db.could not find driver. Mariadb work well. All service httpd.service, zoneminder.service, fcgiwrap-multiwatch and php-fpm.service are working.

Any ideas?

Nocifer commented on 2019-05-15 12:03 (UTC) (edited on 2019-05-15 12:04 (UTC) by Nocifer)

@zlqrn you're right, it's a syntax error I apparently introduced when I last updated the package, in my attempt to make ZoneMinder listen to all interfaces (*) rather than localhost only so it can be accessed remotely. But ServerName does not accept the '*' wildcard, it requires a single, definitive host name or address; so in this case either ServerAlias should be used in its stead or, since it's only a single VirtualHost, the ServerName/Alias directive could be removed altogether.

I'll do a little thinking over which solution is more appropriate and update the package in the next couple of days.

zlqrn commented on 2019-05-14 10:59 (UTC) (edited on 2019-05-14 11:03 (UTC) by zlqrn)

freshly installed zoneminder on linux-lts and have httpd error everything else "systemctl status" is green except for httpd.service

Syntax Error on line 4 of /etc/httpd/conf/extra/zoneminder.conf

Invalid ServerName '*:8095' use ServerAlias to set multiple server names.

all i did was follow the install instructions as always. i dont recall having to change Virutal Host Server section of /extra/zoneminder.conf

anybody have any clue or idea what is wrong? or how to fix

i change "*:8095" to other attributes and get another error .

applesnerd commented on 2019-04-23 16:56 (UTC)

When ffmpeg was upgraded to 1:4.1.2-2 and with it x264 to 157 Zoneminder stopped capturing. Was kind of a hassle to find out what was going on, as Zoneminder's log entries were somewhat cryptic. So I started debugging from the wrong end - of course. Long story short: Simply had to re-install the Zoneminder package - and everything worked again. Can you maybe force an update of Zoneminder in the future in case dependent libraries have changed? Or any other mechanism that forces a rebuild of the Zoneminder package? Thanks for all your work!

Nocifer commented on 2019-04-08 06:46 (UTC) (edited on 2019-04-08 06:48 (UTC) by Nocifer)

@zlqrn Yeah, that's usually the solution when something (anything) complains about not being able to find somelibrary.so.xxx. It actually happened again recently, with the update to mariadb 10.3. At the time I didn't push an update (to force a rebuild) because I didn't want to annoy people that may be running ZM without mariadb. Judging by the lack of complaints, it seems people figured it out themselves anyway :P

But now I think about it, I'm not sure that was the best course of action after all. What if someone ran the updater and missed the errors printed by ZM (which in this case, rather inconveniently, were actually printed not in ZM's service log but in fcgiwrap's)? If their ZM instance was borked after the mariadb 10.3 update, even a few hours of their cameras not recording before the issue came to their attention could have been... bothersome to say the least. Much less bothersome than an extra 5 minutes spent rebuilding ZM as part of the updating process would have been.

So I'm now of the opinion that whenever something like this happens, I should be pushing an update to force a rebuild. If anyone has an opinion on the matter, I'd gladly hear it.

zlqrn commented on 2019-04-07 22:43 (UTC) (edited on 2019-04-07 22:55 (UTC) by zlqrn)

---- FIXED--- when ffmpeg upgraded to 1:4.1.2-2 and with it x264.157 zoneminder stopped capturing >> zma -m 7 and zmc -m 2 errors << telling me x264.so.155 shared library can not open.

tried downgrading ffmpeg and x264 and then it zoneminder started to ask for x264.so.157!?!? wtf right

-- FIXED by REINSTALLING zoneminder with yay and (A)ll clean build option.

Nocifer commented on 2019-02-16 16:52 (UTC)

@alexandria

It "requires" nginx-mainline because that's what the nginx developers recommend using; and also because, this being an AUR package, anyone can freely and easily replace it with straight nginx or with whatever else floats their boat, or even remove the dependency altogether as you seem to be intent on doing. And no, it shouldn't be made into an optional dependency because that would confuse someone who'd expect a fully working CCTV solution, kitchen sink and all, after installing this package.

As I said (and as it also says in the PKGBUILD itself): you're free to remove any and all dependencies as you see fit; same goes for the install script as well if you don't want it to mess with your system.

@hikkakaru

Yeah, when I said "cron job" I meant it in a generic way, as in "a method by which to schedule a task to be run automatically"; it goes without saying that on an Arch system you'd use the tools provided by systemd. As for the issue at hand: you've pretty much confirmed that it's the same issue I and others have been having with the past few ZM releases, so there is no real need for you to go bug hunting. I don't know if it's due to fcgiwrap not being able to handle the stress or (most likely) due to ZM doing something it shouldn't be doing and eventually "oversaturating" the fcgiwrap process, but I do know that it's something that the ZM developers themselves will have to look into and fix. In the meantime, "cron job" it is.

alexandria commented on 2019-02-14 19:12 (UTC) (edited on 2019-02-14 19:13 (UTC) by alexandria)

Why does this require nginx-mainline as opposed to simply nginx, the latter of which can be supplied by any nginx-type package? Also, will build necessarily fail if you don't have nginx? If not, that dependency should be moved to opdepends.

hikkakaru commented on 2019-02-14 04:44 (UTC) (edited on 2019-02-14 04:45 (UTC) by hikkakaru)

@Nocifer

Yeah, the process eats CPU and the memory usage skyrockets suddenly. The processes lock one at a time, this can be seen as cameras dropping out of Montage view one-by-one until they're all gone.

As for what hacky fix I applied : rather than making a cron job I used 'Restart=always' and 'WatchdogSec=1200' in the '/usr/lib/systemd/system/fcgiwrap-multiwatch.service' file so that it'd restart itself preemptively using systemd.

When I get the energy to keep chasing the problem i'll look into reverting to fcgiwrap.service and recording the results.

It would be nice to rely on systemctl watchdog to restart it without a timer -- but as I said earlier the service never degrades, so that never happens.

Nocifer commented on 2019-02-11 13:51 (UTC)

@hikkakaru

Hmm, in theory this sounds more like an issue with fcgiwrap rather than ZoneMinder itself. Then again, I do remember having seen people complaining on the forums about ZM's montage view and camera feeds malfunctioning after ~24 hours of constant usage, though I cant't remember if they found out what the problem was, or even if they did find out at all. On the other hand, I myself have encountered issues where ZM would randomly stop working and the culprit ended up being not ZM but a malfunctioning fcgiwrap process.

Things you could try:

1) Stop/disable fcgiwrap-multiwatch and start fcgiwrap instead. This will make some parts of ZM not being able to work correctly (e.g. no more than one simultaneous views of your camera feed can be streamed) but will bypass the multiwatch binary. Then simply observe if the same thing happens again - if not, then multiwatch is at fault (which I doubt). If it does happen again, then it's not.

2) If/whenever this happens again, open up your task manager of choice and check if there is any fcgiwrap process eating up CPU like crazy (in my case, one was stuck at 12% when I had issues).

And of course, at the very worst, you can create a cron entry and have it restart fcgriwrap-multiwatch every X hours :P

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 63 Next › Last »