Arch Linux User Repository

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?

30+ pages of comments, and outdated documents, I must say I am very in need of help. I installed from scratch, got all the dependencies (did no configuration changes from wiki, as it looks like its all self contained now) and then started 4 services below"

nginx.service zoneminder.service fcgiwrap-multiwatch php-fpm.service

All the services look like they are successful in starting, no errors all active.

I do not see any logs in /var/log/zoneminder/*

I AM able to (from a remote machine) get to the ngnix served page (http://<my ip>) however when I navigate to zoneminders page (http://<my ip>/zoneminder/), I get a 404 error.

I am new to this, and I see a comment about "had to edit the ZM nginx conf to access remotely" by @DaMadOne, but could not find the information for this change.

Any ideas?

@DaMadOne Hmm, no, that was the whole point of the new privileges, to avoid precisely this issue. Do you remember what kind of error you got? Was it perhaps a db root password error? Also, could you check if the 'zm' user has the new privileges as listed in the install script? If not, could you do me a favor and manually run the commands in the install script's post_upgrade function? For convenience, this is the interesting part:

# Temporary solution to apply new privileges on preexisting user & database
# Check for database root password
if [[ "$(mysql -uroot -e "select * from mysql.user;" 2>&1)" = *"Access denied"* ]]
then
    # If a database root password is set
    echo
    echo "* Secure MariaDB installation found, please enter the database root password."
    echo
    mysql -uroot -p -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"
else
    # If a database root password is not set
    mysql -uroot -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"
fi

This should have performed the same checks performed in the equivalent block in post_install, and seeing as you have created a db root password, it should have ended up running the first command (with the -p option). So, I'd like you to run:

if [[ "$(mysql -uroot -e "select * from mysql.user;" 2>&1)" = *"Access denied"* ]]; then echo "true"; fi

...which should print "true". If it doesn't print "true", then we have a faulty check. If it does print "true", next up would be to run:

mysql -uroot -p -e "grant select,insert,update,delete,create,drop,alter,index,lock tables,alter routine,create routine,trigger,execute on zm.* to 'zmuser'@localhost identified by 'zmpass';"

...which should ask you for your db root password, and then perform the upgrade without errors. If any errors whatsoever are produced, then we have a faulty db command.