Librem 5 record uptime

Hardware Librem 5
21

Well you power it down and then turn it back on

2 Likes
22

Sure, that is a normal part of my workflow:

1 Like
23

Yes but if you run the command uptime it be ‘always’, it will be from when you last reflashed, which in the spirit of OP would be when most people reboot. (ie. from a bug or problem that requires rebooting or reflashing)

2 Likes
24

Well right now my Librem 5 USA is turned off with all of the hardware kill switches toggled downwards, while I am currently using my Librem 14 for more productive tasks. Later on this evening, I will probably turn the Librem 5 USA on with the Wi-Fi hardware kill switch toggled upwards, use Shortwave to connect to a Internet radio station, and play some music in the background to stay productively focused.

1 Like
25

So then this statement is incorrect

2 Likes
26

The statement is still valid since I never restart the phone and it is fully functional.

27

Powering it down and then powering it back up is restarting!

3 Likes
28

From my perspective, they are not equivalent operations.

29

Restart has two meanings:

  1. The “operation”, where PC shuts down and automatically starts again.
  2. The generell process where the PC switches the state from on to off to on again, while it can take multiple steps and does not need to be instantly (like shutting down, waiting a day, starting again).

When we speak about uptime, it’s clear that everyone understand “restart” as something about definition 2. Who cares if you restart it as one operation or if you shut it down, go sleep, start next day again? The uptime was interrupted and the purpose for that is (mostly) irrelevant. You’re maybe technical right about “I’m not restarting”, but that is misleading in context of this thread.

2 Likes
30

I care about every operation I ultimately end up deciding for myself.

31

And that is good, but in the context of this thread you restart your phone.

2 Likes
32

But the phone (OS) is not up the entire time, so “Always” is a false response.

2 Likes
33

It is not fully functional during the flashing.

I think the intended (and actual) meaning of the first post is quite clear.

And here I thought micrsoft’s attempt to redefine uptime fraction as (total uptime)/(elapsed time - scheduled down time) would never be beat.

2 Likes
34

I wasn’t keeping track, and I haven’t put in the time to extract it from system logs, but I feel like there have been times that I got a long uptime on my L5, by doing the following:

  • Use a fleet of batteries and chargers
  • When current L5 battery is low:
    – plug into the Librem 5 charger momentarily
    – rip off the backplate
    – rip out the battery while the L5 is still on
    – put a new battery from a wall charger into the L5 and throw backplate back on
    – put the old L5 battery back on the charger to continue the cycle
  • Never use waydroid
  • Never use suspend, as the above battery cycling renders it largely meaningless
  • Prefer keeping the modem turned off whenever possible, ideally most of all the time

Recently I’ve been having bad uptimes because I was caring less and letting the battery go flat, but when the “fleet of batteries” is up and running like a well-oiled machine, looping these behaviors can keep the L5 running pseudo indefinitely. If I’m going to travel away from the chargers, I can take all the batteries with me after charging them up and leaving the L5 to charge from the wall or something. The end result then is that I travel and can go for a day or two without charging, but with blips in the uptime because on-the-go it’s less likely that I would be able to connect to a wall charger to do a battery swap while the device is still on. (So, instead, at the end of each battery’s lifetime I power off the device, and insert the next battery.)

But I also had an event recently where the L5 froze and had to be hardbooted, which has not happened in a long time it seems like. I don’t know why that happened.

When I type last reboot in command line, I see some entries that are 2 days long and some that are 20000 days long. It seems that the 20000 days long are errors due to the clock resetting, and they make it difficult to determine for how long the device was actually running.

1 Like
35

This.

Regardless of all other considerations … issue the uptime command and determine the largest value ever seen.

Obviously reflashing will reset the uptime but so will just applying updates that require a restart (typically kernel updates) and so will certain bugs (hopefully eventually all of those will be fixed) and so will accidentally letting the battery go flat.

2 Likes
36 
purism@pureos:~$ uptime
 17:19:01 up 6 days, 10:04,  2 users,  load average: 0.06, 0.25, 0.30

But I’ve to boot now for the new image which came to /boot right now

3 Likes