Closed sd3m0n closed 5 years ago
This usually means that you do not have php.timezone
set in your PHP.INI file. Most systems keep this ini file in /etc/php.ini, though you may find it located in other directories. I would advise running the following to see where there is an ini file:
sudo find / -name php\*.ini
This will give you multiple locations, only edit the ones that are definitely the live ini file.
Please note, you will likely have more than one because you'll have one for Apache/Ngix or whatever web server you are using, and another for the CLI.
On closer inspection of your images, you appear to be using Debian or a derivative thereof, so you're PHP location will likely be:
/etc/php/<version>/cli/php.ini
/etc/php/<version>/apache2/php.ini
@paulgevers do you set the timezone's at all or is that normally a local admin thing?
Thanks. It seems that solved the problem.
@paulgevers do you set the timezone's at all or is that normally a local admin thing?
That is not something the cacti package can do. I don't know if or how it is done by the package that provides those files.
Thanks for that Paul.
So just to check, that must be something they do before they can start to install Cacti then? Or are you saying that your installation script bypasses that setting, thus Debian/Ubuntu's would not be configured as per Cacti's installation requirements?
Sorry to bombard you with these questions, I would reference your script but I'm not at my desk right now.
@netniV what I meant to say is that this is up to the php package that creates those ini files to get this right. If this is not correct by default, it is either a bug in that package (if the default is wrong and/or stupid) or indeed up to the administrator of the system if the default is good except for Cacti.
I find this on my system:
paul@testavoira ~/cacti $ grep date\\.timezone /etc/php/*/*/php.ini
/etc/php/7.0/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.0/apache2/php.ini:;date.timezone =
/etc/php/7.0/cli/php.ini:; http://php.net/date.timezone
/etc/php/7.0/cli/php.ini:;date.timezone =
/etc/php/7.2/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.2/apache2/php.ini:;date.timezone =
/etc/php/7.2/cli/php.ini:; http://php.net/date.timezone
/etc/php/7.2/cli/php.ini:;date.timezone =
/etc/php/7.3/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.3/apache2/php.ini:;date.timezone =
/etc/php/7.3/cli/php.ini:; http://php.net/date.timezone
/etc/php/7.3/cli/php.ini:;date.timezone =
It seems that on Debian systems, this isn't set by default.
Is there a way for you to add a warning on the cacti package if these aren’t set? I guess upgrades wouldn’t really see the messages if they are done in bulk but if someone installs fresh they should do.
Do you consider these default OK? Is this "just" an issue for Cacti?
If you think these defaults are wrong, I rather have the php package that provides this fixed. If you think these defaults are reasonable, than I should add this to /usr/share/doc/cacti/README.Debian which is the right place to document this.
I already have this:
* Time zone names
Cacti takes the names of time zones from the mysql.time_zone_name
table. Because this table is a global table, which on Debian is empty by
default, I don't want to manipulate it during install of cacti. If you want
cacti to benefit from time zone names, than you should run the following
command manually.
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | sudo mysql mysql
@netniV I should ask more carefully: what goes wrong if this isn't set? My settings are as above, but I fail to spot where this is going wrong. Please direct me how to reproduce issues with the Debian setup where this date.timezone isn't set.
There are numerous functions within PHP that will generate warnings if a time zone is not set which are undesirable. I know that our installer has always asked the user to ensure that the time zone is set. It becomes a lot more important when dealing with multiple pollers operating in different time zones.
Oh and additionally any plugin that uses a function which generates a timezone warning will get disabled because Cacti traps errors in plugins to warn them about the situation and then suspends the plugin to prevent any issues with the core of Cacti.
grumble...
What a bad situation that is. In Debian I apply the installer at install time without the user needing to do anything. Hence, they will not see "your" warning. Adding a warning at Debian install time is indeed likely to go unnoticed.
Do you think it makes sense to ask the Debian php package to add defaults (which?)?
Does it make sense to a run time warning in Cacti somewhere (maybe only done for automatic installations like in Debian)?
Yeah things like this have only really come to light with me rejigging the installer and adding a lot more debug info then the extra cli checking. From 1.2.1 the installer is now checking that or both web and cli but if your bypassing it isn’t going to be seen.
Don’t some installs under Debian do provide prompts during installation? I thought I’d seen one before now such as Grub or something.
My other thought was maybe blocking the install at your end if the time zone doesn’t get set by the user or make the warning the last thing they see. The only problem with the warning would be if they specify multiple packages they might not see it like you said.
Not sure on the best route as it’s only Debian that bypasses our installer as far as I am aware.
Thinking more about it, I can see why they don’t apply the time zone so the user will do so to remove the errors but at the same time if that’s what they are defaulting to, why not set it in the ini file.
Maybe that’s something that could be done by the cacti package ? Run a script to see what result we get for the time zone and if the warning appears set the ini value ? Of course the same test would have to be run against the CLI and Apache ini files. If we do set it at it as a warning in the cacti log so it’s visible to the admin. We could also add a flag that displays a warning to the end user on first login to make it more visible though that would be a 1.3 feature.
The Cacti package is not allowed to change those ini files.
Yes, Debian packages can ask questions and show messages, but that is more and more frowned upon, so it should only be done for high profile questions and messages.
Yeah, I had a feeling you would say that. When the cacti package installs, does it not enable various PHP mods, etc? Can it set the timezone in an additional cacti configuration file under the php folders? Would that be acceptable?
@paulgevers, I suggest that the Debian installer for PHP pick up the system time zone and then set the date.timezone in the installer. I think this is rather important, and has been for a few year since php started issuing warnings for it not being set. Wish PHP would simply revert to the systems timezone silently when one is not set, but that is likely harder to fix actually.
For future reference, I file this a week ago as Debian bug 922309.
root@raspberrypi:~# grep date\.timezone /etc/php///php.ini /etc/php/7.3/apache2/php.ini:; http://php.net/date.timezone /etc/php/7.3/apache2/php.ini:date.timezone = "Europe/Bucharest" /etc/php/7.3/cli/php.ini:; http://php.net/date.timezone /etc/php/7.3/cli/php.ini:date.timezone = "Europe/Bucharest"
Wasted hours trying to get this to work , I still get de default values for the web section(the lack of timezone won't allow me to continue the install) , found some obscure bug on php 7.3.x that would not parse the timezone from config and compiled 7.3.6 , still no luck.
Do you have the correct PHP location in the settings table?
Do you have the correct PHP location in the settings table?
If it's about the sql table under mysql database , i did pupulate it acording to folowing the steps here:
https://dev.mysql.com/doc/refman/5.7/en/mysql-tzinfo-to-sql.html
I will reinstall the sistem since i want to downgrade to cacti 0.88/raspbian stretch anyway(it's a rasp. pi board) , thx for the help.
So, can't update. It seems that there are wrong values in 'current' field. Because I have memory_limit set to 400M in php.ini and max_execution time to 60. Here are some screens to clarify the proplem:
Installer can't fins timezone data:
System timezone:
MySQL timezone (it is set in the config):
PHP timezone:
And more from phpinfo:
They are all the same. In 1.2.0 everything was OK and now there is an error during install. Can You please clarify this situation?