Hi
I am having a problem in understanding how to change the timezone correctly. I have a VirtualMin 3.79.gpl GPL installed on a amazon VM. The time is set to EDT even if the Amazon environment selected is the European one (based in Ireland I think)
The above is not the issue with the software, as in theory the time zone could be changed by going to myhost:10000/time/ -> change timezone
When i enter the /time/ page it gives me this error hwclock failed :
if I click on "change timezone" an empty page is returned under the menu
clicking "time server synch" returns a black page too
Do you know what i can do for this?
I would rather use the GUI if possible before attempting to fix it straight on the OS configuration
Thanks
Diego
You are never going to be allowed to change the hardware clock on Amazon's servers. (hwclock sets the hardware clock...a virtual machine does not have access to the hardware clock.)
The Amazon environment is irrelevant to the OS timezone.
I'm not sure about the blank pages for time zones. There's no obvious reason for that to happen. Any errors in the miniserv.error log in the /var/webmin directory?
I would rather use the GUI if possible before attempting to fix it straight on the OS configuration
I think that's wise. It sounds like your comprehension of time on UNIX systems is somewhat vague. ;-)
--
Check out the forum guidelines!
Hi Joe
I have managed to change the time by symlinking /etc/localtime to the right timezone file.
Steps for any user who needs it in the future
cd /etcthe localtime apparently holds the settings to the local timezone settings on your machine
ln -sf /usr/share/zoneinfo/EST localtime-> now just restart apache
In the zoneinfo folder you will find several timezone configurations you can point to but if yours is not there google it and surely you will find yours, I assume.
@Joe, the webmin error log does not get enriched with any lines when I access the change timezone or timeserver sync pages. Only when i go to Set time the hwclock error gets logged. I m willing to run more checks if it can help fixing the problem for future users.
Here is how to fix the timezone.
This bug still exists in Virtualmin 3.98 running on Xen PV.
Accessing the "Hardware: System Time: Change timezone" tab brings up an empty result. Same for the "Time server sync."
/var/webmin/miniserv.error says the following for all of my failed attempts:
Cannot access the Hardware Clock via any known method.Use the --debug option to see the details of our search for an access method.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Error: hwclock failed :
I understand the basic reason why it's happening: Xen does not have any hardware clock, and derives its time from the host system.
Fine, but we need a way to set the Timezone. It defaults to EST, and that means that all system timestamps are shown relative to eastern standard time (U.S. time) even if you run a Virtualmin system anywhere else in the world.
It's possible to individually override PHP via "Others: PHP Configuration: Manage: Other Settings: PHP Timezone", but it's annoying that we cannot set the system Timezone.
date +%Z outputs "EST"
There is of course a workaround mentioned above, where we overwrite /etc/localtime with the proper zone. I am using that for now to make the system understand where it is in the world. Don't make a symlink, though.
It's not really wise to make /etc/localtime a symlink. That used to be the standard behavior for Linux in the past, but then someone realized that /usr/share/zoneinfo could be on a different volume that's not always mounted, and we definitely don't want to be without /etc/localtime, so it's best to COPY the timezone you want:
cp /usr/share/zoneinfo/EST /etc/localtimeReplacing that file immediately makes things like "ls -al" list the proper local timestamps rather than eastern standard time. Thinks like apache also work with the new timezone after a restart. Even PHP works, but PHP should ALWAYS be set up on its own with a DEFINITE timezone in the location I described above, otherwise it will always output a warning that "PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in timezone.php on line 3"
So, the short version of what to do as an end-user: * Create a copy of the proper timezone to get your system to work properly, which we'll have to do for as long as Webmin has this bug and won't let us do it via the GUI * Set up a PHP timezone that matches your choice, so that PHP won't output warnings when you try to use the date() function. * Make sure you set up the PHP timezone for all existing servers as well (the place I showed you only sets it up as a default for new servers).
As for Webmin: * Please fix the time control panel for virtualized systems * Please make the PHP's timezone setting mirror the timezone chosen in the time control panel, because "use system time" is not a valid option for a production server, for the error reason seen above. This might be done by defaulting the system to EST and PHP timezone to EST, but then whenever the user changes the time via the time control panel, there could be an extra tickbox "Also update default PHP timezone" so that people can choose whether to fix PHP's date() functions to use the new zone too. * Have an option to make the new default PHP timezone apply to php.ini of all existing virtual servers as well, not just for new ones.
In Webmin's "System Time" module, select "Module Config" and change to "System Configuration".
Set "System supports hardware time" to automatic or no for virtualized hardware (VPS)
Then the module's "Change Timezone" tab will provide the interface which creates the localtime symlink.
Thanks, that's brilliant! Also good to hear that Jamie is fixing this behavior so it works out of the box.
I pointed out this post to Jamie -- he said part of the issue here is due to a Webmin bug... one which will be fixed in Webmin 1.620, which is coming out soon.
-Eric