Arch Linux User Repository

I can confirm ONVIF does not work without perl-xml-libxml (or a dependency that is installed with it).

Coming back to say I figured out my issue. It had nothing to do with this pkg. I'm also running home assistant and was using the zoneminder integration to get feeds from the cameras. When I stopped using it the issue I had went away. In the end I just ended up pulling the RTSP feeds from the individual cameras to get them into HA instead of using the outdated integration that most likely is still using outdated authentication that was leading to my issue.

Months have passed without zoneminder auth crashing now. problem solved.

Fixed it by installing the package with Perl's own package manager, cpan:

sudo cpan Crypt::Eksblowfish::Bcrypt

I also ran into a problem where zmupdate.pl was telling me the database was corrupted. After 2 hours of screwing around, I ran

sudo mysql_update -u root -p <database_root_password>

And everything was fine after that.

Besides Nvidia, Zoneminder has been the most frustrating part of my Linux experience.

I cannot run zmupdate.pl because it cannot find Crypt.Eksblowfish.Bcrypt. It looks like it is not compatible with the latest version of Perl (5.34) and yay keeps installing it in the directory for the older version. I'm struggling to get this fixed ASAP.

I updated the packages from AUR, everything worked.

Version 1.36.4-1 does not start for me.

@DaMadOne Just the other day I discovered by chance that since 1.34, Zoneminder has switched its API to a new v2.0 token-based system that utilizes the JWT library. AFAICT the library is supposed to be bundled with ZM itself, but I saw some comments by the devs discussing an issue with the bundled version not working correctly for some reason, and they thought that using an external instance might work more reliably. This could very well be the source of your issues.

The problem is, I've looked through the Arch repos and I could only find one package for libjwt, which is a C-based implementation of the JWT library and pulled from https://github.com/benmcollins/libjwt; while the one required by ZM is apparently 'wt-cpp, which is C++-based and is (probably) pulled from https://github.com/Thalhammer/jwt-cpp.

Because, like on Arch, there is/was no package for jwt-cpp in the Debian repos but only for libjwt, there was an attempt a year ago to make jwt-cpp optionally utilize an external C-based libjwt if it was found installed on the system (see here: https://github.com/ZoneMinder/zoneminder/pull/2844) but the functionality was subsequently removed. As far as I can tell, though, there is still an optional dependency libjwt in the CMake instructions, but installing the libjwt package does not satisfy that dependency and it's still declared as missing during compilation:

...
==> Starting build()...
-- Detected compiler: /usr/lib/ccache/bin/cc
-- Sendfile support: Linux/Solaris sendfile()
-- Building man pages: Yes (default)
-- Could NOT find LibJWT (missing: LIBJWT_LIBRARY)
-- Checking prototype MD5 for HAVE_MD5_OPENSSL - True
-- Using web user: http
-- Using web group: http
Building unit tests: No (default)
-- Optional libraries found: zlib cURL OpenSSL PCRE GCrypt AVFormat AVCodec AVDevice AVUtil SWScale SWResample libVLC libVNC
-- Optional libraries not found: LIBJWT
...

This is me compiling with libjwt installed. I even tried to manually export the variable LIBJWT_LIBRARY pointing to the location of the libjwt.so file, just in case the libjwt package is badly configured, but no dice.

TL;DR if you encounter the problem again, you could try to manually install the jwt-cpp library on your system and see if something changes (maybe it'll even satisfy that libjwt dependency for ZM).

Was recently having the web interface give me 502 bad gateway after upgrading. If I rebooted the VM it would work for some time and then fail again. Yet ZM was running and recording. After rebooting I could see recordings during times I knew that I was getting the 502 bad gateway error.

After checking/restarting various services I tracked it down to php-fpm.service. If I restarted just that one service things were back to normal. In hindsight I should have taken better notes but the issue with php-fpm boiled down to "error decoding JWT token" or something like that.

I tried some stuff.. I googled some things but didn't get anywhere. In the end I forced another proxmox backup and then did "pacman -Rnsdd php-fpm" and then reinstalled php-fpm and rebooted the VM. It came back up and has been fine for more than 24 hours, which is longer than it seemed to work before. If that changes I'll comment again, however the JWT token errors were immediate before I force reinstalled and they are not there now.

Just posting in case anyone is running into anything similar.

@Nocifer deleting zm_config_defines.h worked Thank you :D

@eriol As far as I can tell there is a class in the C++ code called Config that is supposed to have a property font_file_location that is supposed to be populated when you compile ZM, but which for some reason seems to be missing (or is not properly populated when the object is initialized during compilation, hence is then reported as missing).

I dug through the code some and found that the missing property is supposed to be autogenerated by a perl script just before compilation and stored in a file 'zm_config_defines.h' which is located at the root of ZM's build dir (e.g. in my case it's /tmp/makepkg/zoneminder/src/zoneminder-git/zm_config_defines.h'). This file won't be regenerated if it already exists in the build folder, so TL;DR since you haven't set makepkg's build folder to something volatile like /tmp/makepkg, first thing to do would be to delete your build folder so zm_config_defines.h can be regenerated. Maybe the transition to GCC11 messed something up and this alone could fix your issue.

If this is not the case, check in the first section of zm_config_defines.h if there is a line that reads '#define ZM_FONT_FILE_LOCATION 220', maybe with a different number at the end. If there isn't such a line then for some reason the perl script is not setting up its options properly, and that would probably call for a report to ZM's upstream.