Uniqueness of cron with non-transfer of time to winter
Today we would translate time. And we would have done it if it had not been for the presidential decree “On the abolition of the transition to seasonal time” ... Everyone apparently updated the software on the servers (and we are no exception) and did not expect a trick, but ...
The test script, which tests the survivability of one of the systems, happily reported to me today at one o'clock instead of the scheduled noon. I got to the server. The time was correct (not translated), the timezone is also correct. Checked out how Ruby returns time. Also correct. Looked at the logs. Time is not transferred anywhere! (as it should be).
One suspicion crept in, and I entered a test launch of cron into the crontab - aha! - and it works with a delay of an hour! Restarted crowns. Another test. Yes, now it works as it should. Found! True, the subsequent manual restarting of the crowns on the rest (about 20) servers - the occupation was still that.
')
Moral: the default cron on FreeBSD (different versions, up to 8.2) needs to be restarted after the non-translation date, otherwise it translates it somewhere in its depths! I wonder what will happen in the spring (maybe by the spring will be updated?). Or maybe it was already worth updating, but now you can be sure only in the spring? ..
"To the hostess on a note," as the saying goes: "if the lomat has a head, what has gone wrong today, restart the kroner".
Ps. Linux-based machines (specifically: Debian and Gentoo with vixie-cron) were not affected. Well, it is not surprising - there is another crown. But nevertheless, on sabzhevoy OS, we still faced with this, let's say, the peculiar behavior of a single system application.