Re: [pm] fix time after suspend-to-*

[Gabriel Paubert <paubert@iram.es>]

On Wed, Oct 29, 2003 at 10:38:03AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > You are not asking userspace whether to reboot or not, and you should
> > > not ask them about suspend, either.
> > 
> > OK, so how should the system behave when a real-time-like process is
> > running? I talked about the CD burning example. Should the kernel simply
> > ignore the process and suspend?
> 
> Yes.
> 
> > > > 1. Network connections must be reestablished. A userspace program can't
> > > > try to automatically reestablish a broken TCP connection for no apparent
> > > > reason. A broken TCP connection could be the cause of an overloaded or
> > > > broken server/service. If we do not inform userspace processes that the
> > > > system is going to sleep (or that the system has been brought up from
> > > > standby), they will blindly try to restore TCP connections back, even
> > > > when the remote server is broken, generating a lot of unnecesary
> > > > traffic.
> > > 
> > > gettimeofday(), if I slept for too long, oops, something strange
> > > happened (maybe there was heavy io load and I was swapped out? or
> > > suspend? Did machine sleep for 20 minutes in cli?) try to reconnect.
> > 
> > Does "gettimeofday()" have into account the effect of adjusting the time
> > twice a year, once to make time roll forward one hour and another one to
> > roll it back?
> 
> Not sure how it is supposed to work, but here I just have ntpd
> step-setting by one hour...

Well, gettimeofday() is supposed to return UT. It does not care at all
about local time, which would be a 100% userspace problem if it were
not for broken filesystems which store timestamps in local time.

Going off-topic: on a typical distribution the files used for UT to 
localtime conversion are in/usr/share/zoneinfo. Also ntp exclusively
transmits UT, and is certainly not responsible for these hour steps.

	Gabriel.