Timestamp issues in File Manager with DirectAdmin on CentOS 6

H

HindrikOxilion

Verified User
Joined
Sep 23, 2011
Messages
33
Hello,

We have recently deployed two new DA servers based on CentOS 6, and these new servers are the only ones "featuring" the following issue (all our current CentOS 5.x based DA servers do not):

The timestamps of files as viewed within the File Manager are off by 1 hour. For instance, a file created or modified at 13:00 CET, will show up with time 12:00 in File manager.

Things I've checked so far:
- On the file system, the timestamp of the file are shown correctly in the console (13:00),
- 'date' outputs the correct local time (13:00 CET),
- the timezone is set correctly (symlink from /etc/localtime to /usr/share/zoneinfo/Europe/Amsterdam),
- 'hwclock --systohc' has been used,
- /etc/sysconfig/clock contains correct settings: UTC="false", ZONE="Europe/Amsterdam".

Can anyone tell me what I'm missing?

Thanks,
Hindrik
 
Then your server time is not in sync. Sync your time with ntp.
 
Thanks for the tip, but our servers are setup with ntpd, so they are always up-to-date so to speak ;)

Regardless, even after a manual ntpdate update, the timestamps in DA's File Manager are still 1 hour offset.

I've double-checked that the hardware-clock and the kernel clock are in sync, and both show the correct date/time in the correct timezone.

Any other hints?

Thanks,
Hindrik
 
Hello,

I checked over the code. The code used to display the time based on the stat is:
Code: 
struct tm *t = localtime(&(filestat.st_ctime));
You can run DA at debug level 30000 and you'll get more info:
Code: 
		if (isDebug() >= 30000)
		{
			debug(30000, "ctime for %s is %d. After localtime: %d:%d", path, (int)filestat.st_ctime, t->tm_hour, t->tm_min);
		}
See this guide to run DA at that debug level:
http://help.directadmin.com/item.php?id=293

John
 
Yup then it would be the creation time of the file.
 
No, it's status change. As per man fstat:
Code: 
                  time_t        st_atime;    /* time of last access */
                  time_t        st_mtime;    /* time of last modification */
                  time_t        st_ctime;    /* time of last status change */
John
 
Dear John,

I just ran DA in debuglevel 30000, and edited a file called "time.txt", and this is the output @15:17 local time:

ctime for /time.txt is 1323699455. After localtime: 14:17

Would it be possible that the function "localtime" is amiss in this case?

I'd appreciate all the hints I can get ;)

Hindrik
 
HindrikOxilion said:
Dear John,

I just ran DA in debuglevel 30000, and edited a file called "time.txt", and this is the output @15:17 local time:
Code: 
ctime for /time.txt is 1323699455. After localtime: 14:17
Would it be possible that the function "localtime" is amiss in this case?

I'd appreciate all the hints I can get ;)

Hindrik
Click to expand...
What shows up on disk?
Code: 
cd /home/user
ls -la time.txt
stat time.txt
ls -la /etc/localtime
as compared with the same time that DA shows in debug mode.

John

EDIT: Added "stat time.txt" to the commands.
 
@Jeff:

Yes, the /etc/localtime is a symlink to /usr/share/zoneinfo/Europe/Amsterdam:

ls -la /etc/localtime:
lrwxrwxrwx. 1 root root 36 Dec 15 09:35 /etc/localtime -> /usr/share/zoneinfo/Europe/Amsterdam

But even when replacing the symlink with /usr/share/zoneinfo/Europe/Amsterdam copied to /etc/localtime, nothing changes...

@John:

Running DA in debugmode 30000, and editing time.txt reveals:

ctime for /time.txt is 1324020503. After localtime: 7:28

ls -la time.txt:
-rw-r--r--. 1 admin admin 6 Dec 16 08:28 time.txt

stat time.txt:
File: `time.txt'
Size: 6 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 2897228 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 501/ admin) Gid: ( 502/ admin)
Access: 2011-12-16 08:23:14.903230522 +0100
Modify: 2011-12-16 08:28:23.648275635 +0100
Change: 2011-12-16 08:28:23.648275635 +0100

See my reply to Jeff regarding the timezone file.

Also, `cat /etc/sysconfig/clock`:
ZONE="Europe/Amsterdam"

I'd like to point out again, that this server's configuration is identical to our many existing DA servers, with only 1 difference: CentOS6. All aspects of time settings, timezones, ntp synchronization, etc. are the same, but this issue *only* presents itself on our new CentOS6 based DA servers, not on any others based on CentOS5.x...The DA versions are also the same across all our servers, since we update them with new updates when they are released.

Please let me know if you need more info...

Hindrik
 
Try a different shell like /bin/sh to see if its the same.
 
Sorry for my absence, was consuming some time-off ;)

What exactly should I be testing using another shell? I tried /bin/sh, but the displayed timestamps are no different. It's only within DA's File Manager that the timestamp is incorrect.

Let me know if you need any more information.

Hindrik
 
Also on debian 6.0

Hindrik,

The same problem with the file date in the DA File Manager you ran into on CentOS is also occuring on my Debian 6.0 system.

Did you find an answer?

Kind regards, Frank
 
Hello,

Since no clear cause/solution has been found, I've instead added this simple, yet functional workaround.
It's a directadmin.conf option where you can specify an integer to tell DA how many hours forward or backwards you want the files to display.
It will be available for the next release of DA (1.40.4), or in the pre-release binaries before the release (updated a few times a week).

http://www.directadmin.com/features.php?id=1327

John
 
Timestamp on CentOS 6 + DirectAdmin 1.50.1 is wrong

Hi there,

This problem still persists on CentOS 6 in DirectAdmin 1.50.1,.. 5 years after the start of this topic.

While all timestamps are in sync with ntpd, the filemanager is 2 hours behind.
DirectAdmin surely knows the correct time. I am using google two step authentication, it would not work without correct time.
 
I believe we found out why in a different thread.
The cause is that the file manager is chrooted, so any checks of the time won't be able to read the /etc/localtime file.

What I might be able to try would be to read the time both before and after the chroot, do the math, and internally set that as the new offset (assuming offset isn't set in the directadmin.conf)

John
 
You must log in or register to reply here.
Back
Top