Why isn't `uptime -s` output constant?

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.

Kamil Maciorowski

Posted 2017-09-05T23:08:43.173

Reputation: 38 429

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 – 2017-09-06T15:07:46.180

@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?

– Kamil Maciorowski – 2017-09-06T15:17:34.947

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 – 2017-09-06T19:31:48.310

We see the same problem on an Intel NUC; the boot time forwards every day 10 seconds (we're also using uptime -s) – cweiske – 2019-01-18T09:24:35.753

2What 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 – Eric Renouf – 2017-09-05T23:17:42.533

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 – 2017-09-06T01:26:36.570

To detect a boot cycle, use tuptime – Rfraile – 2019-06-09T19:01:14.767

Why isn't `uptime -s` output constant?

Answers