I have 6 Raspberry Pi 3. A Bash script works on 5 of them, not on 1.

I use uptime -s > file1 [or -p, tried both] then later I cp file1 file2 at the end of my script.

The next time I run the script after 10 min, I do the uptime -s > file1 and compare using the last file2.

I compare file1 and file2 with:

if [[ "$(cat file1)" != "$(cat file2)" ]]; then …

I run this every 10 min. Every other time I see the values from file1 and file2 differ by 1 sec, thus the string compare test fails.

What in the world is going on with this one Pi? – the other 5 work fine.

Is there a better way to do this?

  • 2
    What is the actual goal you're trying to accomplish? If you wait 10 minutes between runs why would file1 and file2 be the same? It wouldn't shock me if things cross a 1 second boundary every so often. Also, to compare the files you could consider using diff Sep 5, 2017 at 23:17
  • Trying to detect a boot/power cycles and write a file "POWER..." to record previous and now uptimes -since the boot. I am recording time since boot every 10 minutes [uptime]. If i detect this change, I call it a power cycle. Have not figured out any better way to detect power loss/reboot. I tried the "-p" which doesn't have the seconds, but the SAME thing happens, different symptom. There must be a better way to do this. No RTC in this thing. Thanks.
    – user322035
    Sep 6, 2017 at 1:26
  • To detect a boot cycle, use tuptime
    – rfmoz
    Jun 9, 2019 at 19:01

1 Answer 1


Putting aside if your way is a good way to do what you want to achieve. A possible explanation:

strace uptime -s shows it reads /proc/uptime, I checked on Debian and Raspbian. It seems it also reads current time (I can't tell for sure, it's a reasonable guess) and subtracts to tell at what moment in the past the system was started.

These two read events are separated by some interval. There's no guarantee the interval will be exactly the same every time you run the command. So the subtraction result will "float" a little.

Then this value is rounded somehow because the final output needs to provide integer number of seconds. It doesn't matter whether the rounding is "down" or "up", or "half up" etc. What does matter is: there's a certain fractional part where the rounding result "jumps" instantly from N to N+1. If the subtraction result "floats" near this critical value you'll get N sometimes, N+1 some other times.

By chance one of your Raspberries was started at such split second its uptime behaves like this, the others were not that "lucky". Any of them may or may not be "lucky" after you reboot it.

I think if you stressed your systems and managed to slow uptime execution down enough, you would get different results even on these other five Raspberries.

Have not figured out any better way to detect power loss/reboot. (...) There must be a better way to do this. No RTC in this thing.

Work with /etc/rc.local maybe. It's designed to run things once when system starts.

  • I appreciate your explanation. I may try running the original uptime -s in the rc.local once, and then reference it from the script. Anything to change the dynamics... It seems there is no good way to detect power off in linux?
    – user322035
    Sep 6, 2017 at 15:07
  • @user322035 If we knew your goal you might get better help. First it was about string comparison, now it's about detecting power off but I don't think you just need to know for this knowledge itself. What are you trying to do really? Normally every time rc.local is run it means the system was (re)started. What more do you need to detect this? Sep 6, 2017 at 15:17
  • Sorry, I tried to simplify for a description. My end goal is to detect power off and record the time. But this seems near impossible. I am reading a current uptime every 10 min, saving it, and comparing to the last one and declaring a power up when they differ.... Maybe if I could detect WHEN rc.local was run? That might solve it. Thanks.
    – user322035
    Sep 6, 2017 at 19:31
  • We see the same problem on an Intel NUC; the boot time forwards every day 10 seconds (we're also using uptime -s)
    – cweiske
    Jan 18, 2019 at 9:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .