With a couple new releases hot off the press, I’m wondering if we ever need to restart umbrel after an upgrade/update.
For example if the system/kernel is upgraded etc. will some of those updates not take unless the system is rebooted?
Just curious since my umbrel shows months of uptime since I started it, and it’s gone through a number of updates. Just wondering if there are cases I’d need to reboot for certain updates, or if the node will automatically reboot to install upgrades that require a reboot.
I always reboot. I don’t care too much about some numbers showing how much time my node was online. That’s just a game and is meaningless.
But my case is different than many umbrelians: I run an Umbrel in a NUC with DebianOS, so I do manual updates (not through web interface) and the procedure is:
stop Umbrel
update OS
restart system
update Umbrel
start Umbrel
Done.
Why? Because updating first the OS it brings all the fixes necessary for the OS and in special docker (Umbrel runs on docker) and is preparing the Umbrel update to go smooth.
For RaspiPi users is simple: they just have to update Umbrel (that already contain OS updates), in one go. But also is healthy to restart time to time, in special when are security patches at OS level. When is just a simple update on Umbrel apps is not really necessary.
I posted this under support but thought I would add to this thread as you seem to be the guy with the most knowledge on here.
Just wondering if you could read below and let me know if there is something I can do? Thanks!
I updated to the latest version today 0.4.13. Since the update, the syncing of the blockchain has slowed even though it says it’s 100% synchronised. Blocks are taking far too long to validate, roughly 5,10 or 20min. Prior to the update, the blockchain was validating every minute sometimes less.
Looking at MEMPOOL the graphical blocks are also taking a long time to move from incoming transactions to transacted (left to right)
Is anyone experiencing the same since updating to the latest version?
Other than disconnecting the SSD is there a way to manually re-synchronise the blockchain i.e. App/Pugin?
Thanks. Good to know we should restart the pi every once in a while.
There’s a satisfaction of having that uptime display a long time, but if some of the linux updates require a reboot to load, then sounds like the best thing for security is to reboot after big updates.
I did my first reboot of the node yesterday (t’s been months since a reboot), and the funny thing was that BTC RPC Explorer app that was previously active just wouldn’t load. The page for the app would time out. I uninstalled and reinstalled the app and same problem. Checked it this morning and it’s working. Weird. Everything seems to be fine now.
The uptime-since-last-restart display could potentially be harmful, if it’s treated like a badge of honor.
I remember seeing a post someone made with a really long umbrel uptime since their last reboot.
I’m guessing if there’s an update (kernel etc) that requires a reboot, and the umbrel is never rebooted because of a want to show X months/years of uptime, we could potentially open up security risks.
I’m not an expert on this, hence the question, and it seems that we should reboot periodically.
Apparently in debian, there a file that can be checked to see if a reboot is required: /var/run/reboot-required
I don’t have one since I just rebooted.
Maybe a fix for the badge-of-honor feeling we get by having a long uptime is to add under the “Uptime since last restart” a section that is “Cumulative/total uptime”
Just a thought. Or at least if an Umbrel update includes a major security update/upgrade, the team could put a note under the upgrade button to please reboot after the update.
I think it’s primarily there for troubleshooting reasons to know whether the pi rebooted unintentionally, but I agree some people might take pride in it for some weird reason.
It probably won’t last for anyone though, eventually, the SD card on a pi will wear out due to the nature of all hardware and you’ll have to restart.
eventually, the SD card on a pi will wear out due to the nature of all hardware and you’ll have to restart.
Love it. One way or another, we’ll get a reboot.
I think a lot of users will look at the uptime as a source of pride and forgo rebooting to keep that number ticking up. Or they won’t think they need to reboot.
Multiply that by thousands of umbrel nodes, and it could introduce a security risk if there were patches that did require a reboot.
Not a big deal if you’re using a pi as a print server at home, but when used as your own bank for bitcoin and lightning transactions, that’s where I wonder how important those reboots are for security, and if that Uptime display gives the wrong idea/incentive.
I like to see the uptime to know if the power got tripped or something else caused a problem, but it’s the idea it might give to a lot of users to avoid reboots to keep their number high.
Regarding badges, the one who should get a badge is @DarthCoin for # of answers in the forum.
Actually you are not wrong about the uptime. It is good to have a high uptime. This part of the node statistics in 1ML under the name Availability. My node
No, if your node is into an “updating” process, your LND and channels are anyways offline for that time.
How much will be? Like 10min max? That’s not even a block.
If you do also a OS update, let’s add to that another 10-15 min, Ok we have missed 2 blocks.
Gossip protocol is also really slow in updating nodes status, so 20 min is absolutely NOTHING to be considered “lost uptime” and will never influence your “score”.
Those scores are anyways not so transparent as it should be so you will never know how your node will get that score. Is all a paranoia for nothing.
My node btw is listed in BOS score. And I restarted every time I did a manual update to my umbrel, including OS update and a restart of the machine.
So that “uptime” score is total BS crap or is taken in consideration after 24h offline.
