wrong time stamping after booting up


I’ll try to explain this the best that I can. I am creating a simple bash script that runs on startup. This script is supposed to create an archive based on the current date, run a python program that generates an audio file (pyaudio), and then move the .wav files to the archive previously created.

Here is the code:


    timestamp=$(date +"%Y-%m-%d %H:%M")

    date=$(date +"%Y-%m-%d")


    # archive=/media/pi/ARCHIVE/$date


    echo "[ $timestamp ] Script Started" >> $log

    if [ ! -d $archive ]; then
        mkdir -m 777 -p $archive;
        echo "[ $timestamp ] Archive Created Successfully..." >> $log
        echo "[ $timestamp ] Archive Already Exists! No New Folder Created." >> $log

    sudo -H -u pi python3 /home/pi/bar/record_audio.py >> $log

    filecheck=$(ls /home/pi/*.wav 2> /dev/null | wc -l)

    if [ "$filecheck" != "0" ]; then
        mv *.wav $archive
        echo "[ $timestamp ] Files Moved." >> $log
        echo "[ $timestamp ] No Files Found." >> $log

It works fine if I run the bash script manually through the command line, but if I allow it to run automatically at startup, the timestamps for files and archives are completely wrong. I’m not sure where to start with troubleshooting this issue.

 New contributor

4 Answers


When the Pi boots it has no time reference.

Raspbian (default installation) will restore the time from the last saved by fake-hwclock, which should be within 1 hour of the time os shutdown.

Depending on how you run the script it should use this saved time until synchronised by NTP.

You could install a RTC or write a systemd service which waits for synchronisation.

You could check the output of timedatectl before your script gets time,

This will show something like:-

      Local time: Tue 2019-06-04 10:23:02 AEST
  Universal time: Tue 2019-06-04 00:23:02 UTC
        RTC time: n/a
       Time zone: Australia/Sydney (AEST, +1000)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no


You are aware the Pi has no built-in real time clock?

You either have to buy an RTC module for the Pi (DS3232 based preferred) or have to start your script after the Pi has got a valid time through NTP, from your Internet router for example.

  • Ah, you should not wait for the slow and stupid Pi to update the time when he thinks fit You are the master, you should order the lazy and stupid Pi to update the clock first thing after booting up. Every time I boot up Rpi, I notice that the little clock icon at the top right corner of the GUI desktop is not right. I become angry and hardly hit/click the clock icon to order it to update the newtwork time IMMEDIATELY. Of course the slave listens to the master. – tlfong01 yesterday   



Run [bash/python] automatically at startup, timestamp is wrong, …


Or you can try the python datetime thing.

python datetime

Update 2019jun05hkt2124

The OP says the following:

It works fine if I run the bash script manually through the command line, but if I allow it to run automatically at startup, the timestamps for files and archives are completely wrong. I’m not sure where to start with troubleshooting this issue.

I apologize that I suggested a solution but did not “troubleshoot” or explain why the OP gets the wrong time stamp.

The root cause is that linux does not update the user clock immediately after booting, and its reason is that it has too many higher priority (and less time consuming than getting network time) things to do (in the background) after booting. In other words, it is an engineering trade off and user experience/satisfaction vs system performance.

This is a quick and dirty update. Perhaps I can try a better explanation later.

Update 2019jun06hkt0857

Ideally, linux should keep a record (with the user’s authorization) of what the unique user has been doing in the past. Say, if Rpi discovers the angry user, ie, me, hits the little real time clock icon angry (many times in 0.1 second), it knows I want network time update ASAP (of course also checking my Rpi is connected online every time, otherwise it is a waste of time).

Actually MS has been doing research in the past 20+ years for their UI/UE, to make their booting as fast as possible. They from time to time invite users to join their real time online survey observing and collecting statistics on what the gereral/average users do, immediately after booting, and after which job, etc, … I always agree on their invitation as a volunteer, for the benefit of my user pleasure, and general user’s pleasure. Below is an article I read yesterday. Of course you can easily google for many more such articles on UI/UE things. In the past 20+ years or so, I have been on alert on many enggr computing thing, including “Code Project Insider Developer News” where this boot user survey article is coming from.

Microsoft wants to know how you feel about Windows 10’s Start menu – Code Project Insider Developer News Darren Allan 2019jun06

  • 1
    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. – Roger Jones yesterday
  • 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 / … – tlfong01 yesterday   
  • / 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. – tlfong01 yesterday    
  • 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”. – tlfong01 yesterday   
  • @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. – tlfong01just now   Edit   


There are several ways to wait until the system clock is synchronized with time servers after boot up. You can prepend a check in a loop to your script that will test with timedatectl and sleep if the the clock is synchronized. If you do that it is important to run the script in the background as service until it terminates successful.

You can also try to start your script as a oneshot service and if it fails because the time isn’t synchronized you can restart it again after a pause set in the systemd unit file for the service.

I have made a service that will look into the journal for a logged message that the clock is synchronized and then execute the script. How to do it you can look at How can I delay the startup of systemd services until the datetime is set (no RTC on the Raspberry Pi). The unit file there does not fit exactly your needs. Instead you can use this one:

Description=Archive wav files

ExecStartPre=/bin/bash -c '/bin/journalctl -b -u systemd-timesyncd | /bin/grep -q "systemd-timesyncd.* Synchronized to time server"'


You have to change myscript.py and maybe the WorkingDirectory.

Categories: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: