Early Internet?

I found the problem with Alarm (and Organizer too). It needs to update the database at startup, simply because time is 2100. So repeating alarms needs are configured for next day… in 2100 (you can wait). The same with Organizer. At boot, my first alarm is in 2100, the second one in 2035-2050, as NetTime did make time slipping to the correct one.

It’s really a problem if you don’t have RTC, since any application that relies on time or Internet will break. For example, NetTime gives a “Wait for DNS message” the first time, just because Internet is still down. Then, it works, but as it take time to call NTP and make time going from 2100 to 2015, all the other applications will run into troubles.

My suggestion: fire Internet as soon as possible, then – when up – fire NetTime with a strict ‘set the clock now’ (and not ‘make it slip slowly to the right value’). Then you can go to other parts of boot. Not before. Never. Of course, a configurable timeout could be fixed by user. A risky asynchronous mode could be preserved too.

Today, it’s really crazy. Desktop applications are launched before Internet and NetTime (see Desktop file). And even if you launch them after, since it takes time to wake up lan and set up time, many applications have problems. Alarms tries to update the 2015 Alarm file, since we are in 2100. Organizer makes the same, then crashes when time goes in wrong direction. My logs are going crazy with 2100 dates everywhere (not very useful), etc. In fact, it’s a miracle if the system boots. Good news: most if the time it does not :)

The year shouldn’t be getting set to 2100 on startup if you don’t have a battery-backed RTC – that sounds like it’s the main cause of your problems.

Looking at the OMAP4 HAL, it looks like it will start the onboard RTC before setting the time, which might be the cause of your problems (on OMAP3 it will only start it when the time is set).

Time is set to late too.
After Filer_booting and Filer_running all applications. Not a very logical way. The same with network.

Organizer makes the same, then crashes when time goes in wrong direction.

The next version of Organizer when it starts will compare the date in it’s OrgData file (ie the last time it was run) with the machine date. If there is more than one year difference, it will raise an error and ask if you want to: Cancel Organizer startup; Open the Set Clock dialogue; or continue with Organizer startup.

No help to you now, I am afraid!
But does it seem the right things to do?

Yes and no. For me it’s a server, so it’s no use to open dialogs. But it would be useful to recalculate next repeating alarms if time & date are changed. I have sometimes Organizer crashes, but its’ probably when time & date change at the wrong moment.

Nota: I delayed the launch of Organizer to the end of the desktop file. Then time & date seem to be always synced. But I cannot be sure, since there is no “noasync” command to sync time. To avoid more problems, I did protect the settings of Organizer, so it can’t save/update the database. And all seems OK like this. Of course, Organizer is only used for tasked alarms (I should use cron, but I did not take the time to recompile it).

Thanks for the patch. Now date is 1970. Much better, as Organizer can cope with date changing to go to the future, not the opposite :)