Arch Linux User Repository

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.

Had problems updating to 1.32.3 from 1.32.2

had to mysql -u root -p and then set global log_bin_trust_function_creators=1; before running zmupdate.pl to upgrade database, Then ran mysql -hlocalhost -u zmuser zm < /usr/share/zoneminder/db/zm_update-1.32.3.sql in order run zoneminder.

was this intended behavior after "Gave 'zmuser' some new privileges on database 'zm' that are needed to perform the 1.32.3 update." Nocifer?

@a36233 weird, it should have been installed along with the rest of the modules, it's a dependency after all. Why would it be the only one missing? You could try reinstalling the perl-sys-mmap package, maybe something went wrong. Or maybe you're trying to install it on ARM..? But that would mean you bypassed this package's architecture field.

Other than that I can't really think of anything else.

-- Checking for perl module Sys::Mmap -- Checking for perl module Sys::Mmap - failed -- Could NOT find PerlModules (missing: PERLMODULES_SYS_MMAP_MODULE) CMake Error at CMakeLists.txt:764 (message): Not all required perl modules were found on your system