Hi, Charlie wrote: > The date on that system is one day in advance and one hour late. Not > terrible, > However after a short period 100% of one of the CPU cores is used, > noisy running, and top -c shows this as the user: > /usr/libexe/fvwm2/2.7.0/FvwmScript 17 4 none 0 8 FvwmScript DateTime
Looking at https://raw.githubusercontent.com/fvwmorg/fvwm3/main/default-config/FvwmScript-DateTime and reading "man FvwmScript" i'd say that the promised 1-second waiting period of "PeriodicTasks" is heavily shortened by the clock peculiarity. > Managed to get date and time right with the ntp commands, set location > etc., on Gkrellm at least. But the fvwm clock had frozen up and stopped. That's quite normal with periodic jobs when the system time gets changed backward. Possibly the clock would come back to life after the last shown time is reached again 23 hours later. > Then tried to set the date manually with hwclock but no joy. Please detail "no joy": Does hwclock show the future time after rebooting if you have set it to the right time before rebooting ? (Or is it only the system clock which hops ahead ?) Does hwclock get changed to the future time without rebooting ? > Removing FvwmScript which I can't open to edit removes the clock from > the FVWM taskbar, Does this solve the problem with the future time ? > And haven't tried to > but Gkrellm is now using the same time? (I don't understand this statement. Maybe it's important for finding the explanation.) > It would appear to be an fvwm problem The fast running CPU might be related to poor handling of weird times by FvwmScript. But for now i doubt that fvwm sets the system date on its own. Have a nice day :) Thomas
