Time reverts to +8 hours ahead on Zabbix Appliance after reboot

[stack888]

I've set the timezone in: php.ini
I've updated timezone in both:
/etc/apache2/conf-available/zabbix.conf
and
/etc/apache2/conf-enabled/zabbix.conf

And I ran the following command:
hwclock --hctosys

And everything looks good - DATE is correct and HWCLOCK is correct...…UNTIL.....I restart the appliance and whilst the HWCLOCK stays at the correct time, DATE shows the time being 8 hours ahead again.

So all my PROBLEM panels etc show the wrong time for events on the front end.

There is obviously something I'm missing setting on the Server somewhere to retain the settings after a reboot but I don't know where else to change the time or timezone. Is there another file other than the PHP and 2 zabbif.conf files I need to update?
many thanks

[provels]

Did you do this? From https://www.zabbix.com/documentation...nual/appliance

4 Changing time zone

By default the appliance uses UTC for the system clock. To change the time zone, copy the appropriate file from /usr/share/zoneinfo to /etc/localtime, for example:
cp /usr/share/zoneinfo/Europe/Riga /etc/localtime

I used WinSCP to browse the folders.

[stack888]

yes, done that. Problem is it doesnt stay after a reboot.

[provels]

Looking over my install (4.4.6 appliance), I made no timezone changes to php.ini (was commented out) and did not need the hwclock command. All I did was edit /etc/apache2/conf-available/zabbix.conf in the 2 timezone lines, plus copying the timezone data. The /etc/apache2/conf-enabled/zabbix.conf is just a link back to the "conf-available" file. What timezone are you in?

sudo cp /usr/share/zoneinfo/America/Chicago /etc/localtime

<IfModule mod_php5.c>
        php_value max_execution_time 300
        php_value memory_limit 128M
        php_value post_max_size 16M
        php_value upload_max_filesize 2M
        php_value max_input_time 300
        php_value max_input_vars 10000
        php_value always_populate_raw_post_data -1
        php_value date.timezone America/Chicago
    </IfModule>
    <IfModule mod_php7.c>
        php_value max_execution_time 300
        php_value memory_limit 128M
        php_value post_max_size 16M
        php_value upload_max_filesize 2M
        php_value max_input_time 300
        php_value max_input_vars 10000
        php_value always_populate_raw_post_data -1
        php_value date.timezone America/Chicago 
    </IfModule>

[stack888]

pacific time. Pretty sure I did exactly what you suggested and tried multiple ways of writing the Pacific timezone entry but still same result.

[tim.mooney]

Does the appliance have the 'timedatectl' command, and if it does, what does

sudo timedatectl

output for the time zone? If it's wrong, look at the man page for 'timedatectl' for how to set it.

Just one more thing that systemd needs to be in charge of....

[stack888]

nope, says "failed to create bus connection: No such file or directory" when i typed that

[tim.mooney]

Hmmm, that looks like a different error message than the one you would get if the command didn't exist.

What does

type -a timedatectl

report?

[stack888]

it says:
timedatectl is /usr/bin/timedatectl

[tim.mooney]

So you have the timedatectl command, but it's not working. Doing some quick web searching for that message, looks like the appliance may not have the 'dbus' package installed.

I'm not sure what to tell you. On the one hand, having you install 'dbus' shouldn't be harmful; it's a very widely-used package. I'm frankly a little surprised that a "minimal" install can be done without it.

On the other hand, I'm not 100% certain that's going to fix your problem. All I do know is that the appliance image does have timedatectl, which means it has systemd, which means that you probably want systemd's idea of timesync and the time zone to match the rest of the system.

Maybe snapshot the VM, then install dbus, reboot (again), then see if timedatectl works? If that doesn't prove fruitful, you could roll back to prior to having dbus installed, and pursue some alternate path.

[provels]

So if you run

sudo cp /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

or

sudo cp /usr/share/zoneinfo/PST8PDT /etc/localtime

it just won't stick. Sorry, that's all I got.

I did see that if I run hwclock (without parameters), it returns a time 5 hours in the future (I'm -5 in CDT), which is UTC (actual output "Wed 15 Apr 2020 09:51:45 AM CDT" at 4:51 AM actual CDT). I think that might be your problem.