timestamp on proc (was Re: Mystery: disappearing .mailfilterrc)
I think I've figured out why the log file wasn't purged, but have
uncovered some strange behavior for the date of the proc filesystem.
It seems to get the wrong timestamp if the hardware clock is not on UTC
Is this a bug, and if so, in what package?
On Thu, Oct 23, 2003 at 11:07:38PM -0700, Ross Boylan wrote:
> On Thu, Oct 23, 2003 at 09:52:20PM -0700, Ross Boylan wrote:
> > On Fri, Oct 24, 2003 at 01:29:09AM +0100, Pigeon wrote:
> > > On Thu, Oct 23, 2003 at 12:11:18AM -0700, Ross Boylan wrote:
[...]
> > > /var/run is not a place to put things that you want to survive a
> > > reboot...
> >
> > Aha! Thanks for the tip.
> >
> > I don't see that in my logs, and haven't noticed it on my screen.
> > But I think I found the code in init.d/bootmisc.sh.
> >
> > #
> > # Clean up /var/run in the same way as /var/lock,
> > # and create /var/run/utmp so that we can login.
> > #
> > [ "$VERBOSE" != no ] && echo -n "/var/run"
> > ( cd /var/run && \
> > find . ! -type d ! -name utmp ! -name innd.pid ! -name pump.sock \
> > ! -newer /proc -exec rm -f -- {} \; )
> >
[...]
>
> This leaves the mystery of why one file survived the reboot.
>
The file that was not wiped out was frequently written, and so had a
recent time-stamp.
The time-stamp on /proc appears to be wrong, at least if it's meant to
show when the system started. Mine says
dr-xr-xr-x 139 root root 0 2003-10-22 16:32 /proc
But the system started at 23:32 (local time)! So anything under 7
hours old is retained.
I have a theory of the cause. My hardware clock uses the local clock
time, Pacific, which is 7 hours ahead of GMT (aka UTC). /dev seems to
get stamped before all the necessary adjustments are made. When /dev
got stamped the OS thought the time was 23:32 GMT, and translated that
to 16:32 local.
P.S. Not using devfs, I'm pretty sure.
Reply to: