ZoneMinder Forums

good afternoon,

just installed 1.36.20 (armhf version) on xenial. Receiving the below error trying to go to ZM site:



1.36.19 was running fine.
Any idea to solve the issue?
Downgraded to 1.36.19 and running again fine.
thanks

hi Isaac,

could you suggest me what could be the issue? The strange is that the previous versions are working fine.
The above error is only with 1.36.20. Downgrading to 1.36.19 is working fine.
Is there a way to understand/debug the configuration error?

I suspect it could be related to

- Remove dependency on php-apc
- Add php-intl as a dependency

thanks for your support

pat2 wrote: ↑Fri Jul 15, 2022 9:20 pmIs there a way to understand/debug the configuration error?

Try to load the page, check your apache error log (tail -f /var/log/apache2/ssl_error_log ), hit refresh, you should get a debuggable breakdown of the error dumped to the terminal.

Thanks, Ralphred.

You are right. I found the error:

tail -200 /var/log/apache2/error.log

[Sat Jul 16 12:40:48.479707 2022] [core:notice] [pid 925:tid 3069239296] AH00094: Command line: '/usr/sbin/apache2'
[Sat Jul 16 12:42:53.869603 2022] [proxy_fcgi:error] [pid 938:tid 2509239344] [client 192.168.1.1:64898] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Class 'IntlDateFormatter' not found in /usr/share/zoneminder/www/includes/config.php:142\nStack trace:\n#0 /usr/share/zoneminder/www/index.php(46): require_once()\n#1 {main}\n thrown in /usr/share/zoneminder/www/includes/config.php on line 142'

it seems a class (probably new) IntlDateFormatter used by config.php is not found:

it seems an issue of not perfect installation for my platform armhf/xenial. It should be only for this platform since none claimed for such issue.
thanks

EDIT: edited config.php and IntlDateFormatter is called:

global $dateFormatter;
global $dateTimeFormatter;
global $timeFormatter;
$dateFormatter = new IntlDateFormatter(null, IntlDateFormatter::SHORT, IntlDateFormatter::NONE);
$dateTimeFormatter = new IntlDateFormatter(null, IntlDateFormatter::SHORT, IntlDateFormatter::LONG);
$timeFormatter = new IntlDateFormatter(null, IntlDateFormatter::NONE, IntlDateFormatter::LONG);

probably not able to find the library where it is defined.

I'm not an expert, probably Isaac could help.
It's not a great issue since 1.36.19 is running fine.
thanks

You are right about php-intl. Need to make sure it’s installed and in use.

This is being widely reported, would it be useful if someone who knows what they are doing gave a few guidelines on installation and use of php-intl?

egglestn wrote: ↑Sat Jul 16, 2022 12:39 pmThis is being widely reported, would it be useful ... few guidelines on installation and use of php-intl?

So, there are instructions about enabling php-intl floating around all over the web, and depending on your XP level you may or may not want to find one tailored to your system, but you basically need `extension=intl` to be set, and the module to be installed.
For me, I know my system has multiple php.ini files, but apache only uses the ones associated with apache, and my goldfish brain couldn't remember where they are, so I locate the files and grep for the setting:I'm using php-8.1, so edited '/etc/php/apache2-php8.1/php.ini' to take out the semicolon and make the config line "active", and because I used the -n switch on grep I know which line number.
After restarting apache it was still throwing errors, and if I wasn't using gentoo I'd just check my package manager software and install the php-intl package*, restart apache again and it'd be solved.

*Because this is pat2's thread, I checked, and the php-intl package does exist for xenial (in the universe repo, is that the right nomenclature?), but I can't find any arm repos at all, so YMMV, but looking at the .deb, I think you just need the config change.

Now I jumped through my gentoo hoops and this particular issue won't come up again because I'm maintaining my own ebuild (package) and the dependency on this php module is now hard coded.

Thanks for that, and thats exactly what I did, however after restarting apache I still got a 500 error.. The log file is not that illuminating I wonder if I have to tweak the config.php file, but that looks & feels wrong

Thanks for your help and advice

egglestn wrote: ↑Sat Jul 16, 2022 4:13 pmI wonder if I have to tweak the config.php file, but that looks & feels wrong

Yeah, it's basically registering functions that are used all over the code, if you took out those definitions you'd just get errors everywhere they are used instead.
So what distro/os are you using?

Using Ubuntu 20.04 LTS which has been bulletproof Maybe I should upgrade to 22.04...do you think that would fix it

Also using php7.4 and Apache2 If that helps diagnosis
Cheers

do you think that would fix it

Maybe, but it's bit extreme!

So I installed ubuntu 20.04 and put 1.36.20 on it. It works out the box and intl is loaded by default, but by /etc/php/7.4/apache2/conf.d/20-intl.ini and not /etc/php/7.4/apache2/php.ini.
If I disable intl in both, I get your error (as expected).
I'd do a reinstall of php7.4-intlthen post the output of I also copied the default phpinfo() from the VM and published it here so you can compare for discrepancies.

Magic919 wrote: ↑Sat Jul 16, 2022 11:46 am You are right about php-intl. Need to make sure it’s installed and in use.

thanks. I'm on xenial/armhf with php 7.4 by Ondrej.
I see zoneminder tries to install php-intl of php 7.0...

pat2 wrote: ↑Sun Jul 17, 2022 3:10 pmwith php 7.4 by Ondrej.

I think this might be the root cause of your issue, Ondrej's php PPA doesn't have any xenial packages in it on checking today, only >=18.04.
That said there are php7.x packages in the standard xenial repos.
Do you know why you are using this `out of tree` php build? If it's because is was ahead of the curve in the past, it may just be time to use ubuntu's own php7.4 packages for 16.04 now they exist.

For both you and egglestn, I've tracked down the .so library responsible for making the IntlDateFormatter class available to php in ubuntu:
For me it's /usr/lib/php/20190902/intl.so, but I wouldn't be surprised to see it as /usr/lib/php/[some date]/intl.so depending on php and distro version. If you list the /usr/lib/php/[some date]/ directory contents and there is a lack of other modules in there then you probably have the wrong phpX.X-intl version installed. If you can't find it at all, default to using mlocate to see if it's in the wrong placeIf it doesn't come back with a intl.so file in a php related context then you need to install the phpX.X-intl package for your php version*.

Obviously I've posted about finding the correct php.ini file and making sure intl is enabled before, but if there is still some doubt in your mind as to which php.ini is being used by your webserver, make the following myphpinfo.php fileput it in a location you know how to reach on your webserver (/var/www/html/myphpinfo.php in my 18.04 VM), and open it in a browser (http://localhost/myphpinfo.php in this case).
The first block of information tells which .ini file(s) was loaded, and if you scroll down far enough you find the "Internationalisation support" section.
If you have a web facing server it's IMPORTANT to remove this file ASAP afterwards (you don't want to publish your attack surface to any passing script kiddy).

*If you are reading this and aren't using ubuntu, just because ubuntu loads intl.so as a module doesn't mean your distro does, I know mine is built in on my production server, yours may be too...

Well...Turns out to be a bit simpler than i realised...I apparently had multiple versions of PHP running
The phpinfo showed I was running 7.1 but the intl file was enabled in 7.4 so simply disabling 7.1 and enabling 7.4 seems to have done the trick..


I honestly had no idea what I was doing, but you have helped a huge amount..Thank you so much for your help & patience
Cheers

egglestn wrote: ↑Sun Jul 17, 2022 7:41 pmThank you so much for your help & patience

You're welcome, I'm used to linux, just not ubuntu or ZM, so it helped me to get some insight into how to poke around inside a .deb package manager, plus VM's are so quick to set-up nowadays it's silly NOT to try and emulate someones issue, plus fixing someones OS issue lets the devs write code instead of troubleshooting