Timeline for How do I fix incorrect timestamps in my bash script that launches on startup?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 7, 2019 at 14:28 | history | edited | tlfong01 | CC BY-SA 4.0 |
added rtc wakeup rpi project link and summary
|
| Jun 7, 2019 at 8:58 | comment | added | tlfong01 | My wild guess is that the OP is making an alarm clock which wakes him up every morning, say 7am sharp. The alarm clock uses WAV music or voice to wake him up. Actually I have tried DS3231 hardware interrupt to switch on/enable a low power standby LM2586/LM2741 voltage regulator to power on Rpi. You see, I can write my answer 10 times long, but StackExchane say we should be "laser sharp focus on the OP's topic. When I started answering one year ago, I always got the mods' "off topic" message, and my answer got "on hold", and then closed or removed, I frgt. I also hs a humn voice alrm clk. | |
| Jun 7, 2019 at 8:47 | comment | added | tlfong01 | Yes, I agree. There are three methods to get the correct time stamp: (1) change systemd to wait for network, but this is not proactive, (2) use python get network time function. I think this is protective. (3) Use I2C RTC DS3231. Actually I have been using RTC for one year. But the code is very messy and I have not documented it properly, so it is newbie scary. (I use DS3231 but not DS3232, because no 3232 module is available. So I am waiting for DS3232 module. I know we can use DS3231 DT overlay, but DTO is not OS version invariant, so I always refuse to use it. Just a short reply, .. | |
| Jun 7, 2019 at 7:43 | comment | added | Roger Jones |
I seem to recall that there's a way to change the systemd boot up to wait for the network before going on. This is usually disabled so as to get to the GUI quicker but with some network services still starting up in the background. Not sure where the OPs script comes in that flow but might be a way to make sure that the network is up & NTP is running before trying to run the script. I might add that I think that adding an RTC is a proactive "push" as it gets you the correct system time much faster in the boot sequence than having to wait for the network.
|
|
| Jun 7, 2019 at 1:17 | comment | added | tlfong01 | @Roger Jones Just now I updated my answer with an article reference on how MicroSoft's effort to improve their user booting satisfaction. Many thanks again for pointing out my careless mistake. Cheers. | |
| Jun 7, 2019 at 1:13 | history | edited | tlfong01 | CC BY-SA 4.0 |
add ms boot survey.
|
| Jun 5, 2019 at 13:49 | comment | added | tlfong01 | One short comment. I browsed other answers and was very surprised to find suggestions like "check", "wait", or use an RTC, but no one seems to be proactive to "push". | |
| Jun 5, 2019 at 13:36 | history | edited | tlfong01 | CC BY-SA 4.0 |
added reason why OP does not get correct time stamp.
|
| Jun 5, 2019 at 12:44 | comment | added | tlfong01 | / continued from above. My Chinese Windows 10 has the same problem. When booting up, some of the things I wish to do immediately is not yet ready, I need to wait for perhaps 30 seconds or more. I have not complained, because I know what I want to do immediately is low priority for most other users. I think you are right that I missed a point., Let me see how I can improve my answer. | |
| Jun 5, 2019 at 12:42 | comment | added | tlfong01 | Ah, many thanks for pointing out my careless mistake. I focused on solving the problem of wrong timestamping, but did not pay attention why the system is so slow to update the system time. Actually I noticed the slow update for a couple of years. Every time I boot up to GUI desktop, I noticed that the system time shown at the top right corner is not updated to Inernet time. I do notice that the update will come "a bit later". I used to think that when booting up, the system has too many higher priority things to do, so updating the time is low priority. And user can update at once / ... | |
| Jun 5, 2019 at 11:28 | comment | added | Roger Jones | This does not answer the question as to why the timestamp generated by the OP's script might be incorrect when run on startup but correct when run manually a little later on. | |
| Jun 4, 2019 at 2:26 | history | edited | tlfong01 | CC BY-SA 4.0 |
formatting
|
| Jun 4, 2019 at 2:00 | history | answered | tlfong01 | CC BY-SA 4.0 |