Strange atime/mtime after boot

Dies_Irae

Active Member

Reaction score: 58
Messages: 136

hi all,

I have a little doubt about how FreeBSD sets the atime/mtime of some files and directories right after boot.

I have 2 FreeBSD 8.2-RELEASE systems: my desktop at home and a virtual machine at work, and both behave in the same manner and have the same configurations.

I am a little paranoid, so I have installed security/aide on both systems, and I have a cron job that performs the check every day.
Some times ago I noticed that sometimes aide reports several warnings like this:

[cmd=]/var mtime in future[/cmd]

At first I tought that I could have a problem in my date/time settings, but it's all ok: CMOS time is set to local time, /etc/wall_cmos_clock exists, /etc/localtime is right and I keep the clock updated with ntp. So, my time settings are correct - or at least i think they are correct.

But investigating I found that after the system starts, some files and directories have the atime and/or mtime set in the future - like aide said:

Code:
# date
Fri Sep 16 15:31:06 CEST 2011
# last | head -2 | grep reboot
reboot           ~                         Fri Sep 16 15:29
# ls -ltu /
total 323
-rw-------   1 root  wheel    4096 Sep 16 17:29 entropy
dr-xr-xr-x   5 root  wheel     512 Sep 16 17:28 dev/
drwxr-xr-x   4 root  wheel     512 Sep 16 15:31 mnt/
<cut>
/entropy and /dev/ have the atime forward by 2 hours, and other files under /etc, /dev and /var have the same time.
It seems that everything "touched" during the system startup will get these times in the future.
So, if I don't want to see these warnings, I must make sure that by the time the aide cron job starts, the system was started at least 2 hours before.

It's not a real problem, but I am just curious.

Anyone have an idea?
 

jalla

Well-Known Member

Reaction score: 85
Messages: 385

Your kernel keeps time in UTC. Check adjkerntz(8)() and the startorder of rcscripts (rcorder /etc/rc.d/*).

There are quite a few scripts that run at boot before your local timezone is registered.
 
OP
OP
D

Dies_Irae

Active Member

Reaction score: 58
Messages: 136

Thank you, but I'm still confused.

I know that the kernel keeps time in UTC, and my date, time, timezone are all correct.
I'm not sure that the order of rc scripts is meaningful, since I haven't touched nothing inside /etc/rc.d/.

I have just created a new virtual machine with FreeBSD 8.2-RELEASE: CMOS time set to local time, minimal install, configured only time zone and user from sysinstall, /etc/wall_cmos_clock exists, then reboot.

Results:

Code:
# date
Fri Sep 16 18:05:19 CEST 2011
# last | grep reboot | head -1
reboot           ~                         Fri Sep 16 18:04
# ls -ltu /
total 45
dr-xr-xr-x   4 root  wheel     512 Sep 16 20:04 dev
lrwxr-xr-x   1 root  wheel       8 Sep 16 19:46 home -> /usr/home
<cut>
This is from a fresh new install - and time/date/timezone are all correct.
 

jalla

Well-Known Member

Reaction score: 85
Messages: 385

When you start out going to multiuser your system is effectively in the UTC TZ. A number of scripts run before the adjkerntz script which sets your local timezone.

Any files touched by those scripts in between will appear to have been touched two hours later when you move to CEST.
 
OP
OP
D

Dies_Irae

Active Member

Reaction score: 58
Messages: 136

I too have thought this was the reason, but I was not sure.

Thank you very much.
 

aragon

Daemon

Reaction score: 278
Messages: 2,029

Yep, these issues might arise when your CMOS clock is in local time. The real question is why are you running it like that? It is a fundamentally broken concept that, to my knowledge, only Windows needs.
 
OP
OP
D

Dies_Irae

Active Member

Reaction score: 58
Messages: 136

aragon said:
It is a fundamentally broken concept
You are absolutely right, and I totally agree with you.
I too hate this type of tricky setups, but like you said, I need to dual boot with Windows.
Oh, well, the truth is that I want to use Windows: I use it only for games that don't run on *BSD - so it's merely a waste of disk space :e

However, even if I dedicate the whole system to FreeBSD and set CMOS clock to UTC I think that this strange/obvious/logical/harmless behaviour remain.

[OT]
@jalla + @aragon: one from Norway and one from Sweden, I've always dreamed to visit your countries!
[/OT]
 
Top