Arch Linux User Repository

Any and all feedback will be much appreciated. Thanks!

CHANGELOG

Update: 1.32.2-3 -> 1.32.3-1

• Changed Nginx's configuration so that now it listens on all interfaces instead of only on localhost. This fixes remote access and also prevents some potential conflicts with other conf files that may be present.
• Added proper support for multiserver setups in the install script during updates: now it will properly check whether we're running a local database server or not and will run the updater accordingly. Also added a new function for updating the PTZ control presets.
• Enabled PHP's disabled-by-default semaphore support. This fixes issues like camera playback controls not working and camera device info (e.g. current state, fps, zoom level, et al) not being shown.
• Gave 'zmuser' some new privileges on database 'zm' that are needed to perform the 1.32.3 update.

Update: 1.32.2-2 -> 1.32.2-3

• Added spawn-fcgi & multiwatch as dependencies. Now fcgiwrap will spawn in multiple instances, so ZoneMinder will be able to utilize more than one CGI threads at the same time and thus show concurrent camera streams, which solves issues like having no image while editing zones, etc. The default number of instances is 10, which should be enough for 2 or 3 cameras, but you can of course edit the provided service file and change the number as you see fit. Big thanks to @chapatt for bringing this to my attention!

Update: 1.32.2-1 -> 1.32.2-2

• Included a /zm/ link inside the /www/ folder that points back to /www/. This fixes pretty much every instance of sloppy hardcoded links within ZM's codebase. Big thanks to @Kubax for the idea!

Update: 1.32.1-3 -> 1.32.2-1

NOTE: There's a bunch of small-ish errors in ZM's operation due to some parts of it having the localhost/zm/ link hardcoded and thus breaking when ZM is run from anywhere else, e.g. localhost:8095. I'm in the process of locating these errors and either reporting them upstream or fixing them myself, but I can't know for sure when or even if they'll be fixed. Big thanks to @Kubax for reporting this.

• Changed temp folder location: /var/lib/zoneminder/temp -> /var/tmp/zoneminder
• Fixed /api/app/tmp to correctly point to the temp folder
• Overhauled how the install script makes the choice between Nginx and Apache, as follows:
  • If Nginx is installed and active, regardless of whether Apache is also installed or active or both, we choose Nginx.
  • If Nginx is installed but inactive, and Apache is not installed, we choose Nginx.
  • If Nginx is installed but inactive, and Apache is installed, we choose Apache.
  • If Nginx is not installed, and Apache is installed, we choose Apache.
  • If neither of them is installed, we simply inform the user about it and do nothing.

It's a fairly simple script and I have tested it as much as I can, but things usually find a way to break apart after introducing such... uhm... breaking changes. If things do break for you, please blame me and not the script itself; and also report here what exactly is broken so I can fix it ;)

Update: 1.32.1-2 -> 1.32.1-3

• MariaDB no longer required (for use with remote databases)
• Apache added as an optional dependency and preferred over Nginx if both are installed

Update: 1.32.1-1 -> 1.32.1-2

• Fixed update process (it erroneously required zoneminder.service to be active while updating its database, when it should rather be the opposite)
• Fixed desktop launcher
• Added logrotate support
• Removed 'perl-module-load-conditional' from dependencies as it is already included in core Perl package
• Other minor fixes (e.g. the license file was being installed in the wrong place)

@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.

---- 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.

@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.

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.

@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.

@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

Having a daily issue where fcgiwrap-multiwatch.service has to get restarted about every 20 hours in order to maintain functionality.

Service does not degrade, but it seems to stop taking memory at around 230-250mb, and stops fulfilling requests; resulting in 'Socket does not exist' errors in the ZM logs.

Service can be restored by using 'sudo systemctl restart fcgiwrap-multiwatch.service' -- one can watch montage and all other 'in-picture' frames reload successfully while it happens.

I'm not very familiar with fcgiwrap or nginx; can anyone point me in the direction I need to look to understand what's going on? No service degradation and no service errors in log make this difficult; the only one complaining is ZoneMinder, but the complaint seems legitimate.

@pgkool the installer automatically starts the required services, along with MariaDB, but does not enable them. Since you mentioned remote access, I assume it's a dedicated server which you haven't rebooted since you installed ZM, and that's why MariaDB is already active. I'd suggest you enable it along with the rest of the services so they can all survive a future reboot.

Also, even if you didn't read the PKGBUILD, you should have noticed a similar message printed at the end of the install process saying something along the lines of "Zoneminder is listening at localhost:8095" (which, now that I think about it, I should probably alter to also cover the case of remote access). And anyway, you should make a habit of at least skimming through PKGBUILDs in AUR packages, since they're not provided by official Arch sources but by anonymous maintainers like e.g. myself. For all you know I could have made a mistake (or not) and included a "sudo rm -rf /" somewhere in there, and then... poof! There goes your precious server and here I am laughing at your expense.

@Kubax: ;-)

@Nocifer

Thankyou, to be honest, I didn't think to look in PKGBUILD for notes of any kind. Anyways, that seemed to work.

You are right, I didn't mention MariaDB nor did I start it, but just checked the mariadb.service, and its running/active. Not sure who/what started it.

Thanks @Kubax aswell...now on to setting this thing up...

@pgkool zoneminder @nginx should run at port 8095 if you didn't change this.

EDIT: Nevermind, Nocifer was faster than me :)