Arch Linux User Repository

---- 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 :)

@pgkool, this is from the PKGBUILD:

# 2) By default, ZoneMinder now runs at localhost:8095 instead of localhost/zm (this can be changed by editing the provided conf files).

So yeah, I guess it makes sense that http://yourip/zoneminder/ will give you a 404, since nothing is listening on that address - you should be accessing ZM at http://yourip:8095.

Of course, as per the comment above, this is just a default; you can always change it to your preference.

EDIT: Also, I don't see you mention MariaDB anywhere. Is that by accident, or could this be a case of you forgetting to start the database?