Auto Reboot after Specific Hours

In all earnest:

They took that article as gospel: you just spoke Latin to them.

@MoqaddasAli: I understand you came here asking for knowledge and while you may not have gotten the knowledge you wanted, you got the knowledge you needed.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

Trust us all: it is solved.

1 Like

On the last line they say the thing with the whole article. “Buy our router and all will be fine”.
The whole article is pretty much a sales commercial.

1 Like

@slh said to keep it PG-13...

So I have nothing to add to that.

I lied:
They, also , said to buy a new one ~2-3 years.

The money are rolling in…

Maybe we can convince @MoqaddasAli to donate instead of wasting their money?

Build Date 10-08-2023

root@OpenWrt:~# uptime
10:51:33 up 184 days, 23:19, load average: 0.01, 0.00, 0.00

My power is not that good at my house :slight_smile:

Most short power interrupts can be handled with a UPS to get nice continuous uptimes.

They are showing their up-time.

Yea, but 180+ days in uptime also means 180+ days without firmware upgrade.

So I don’t really see the point of championship in really long uptime either.

But sure, the firmware is stable but if it run 30days it should run 300days also just as stable.

But if it doesn’t even survive 24h without memory issues I wouldn’t say it is stable. And many original firmwares aren’t better than this unfortunately.

But the common home router owner has made bad internet connections because of router firmware quality to a religious process of rebooting and/or power cycle once every 24h.
This is so common that it has become industry standard. That is why it is so hard at this place to explain why they don’t need to do it anymore.

We don't run “daily reboot” as the standard ‘it ain’t a bug, it’s a feature” thing.

They are making the point that daily shut downs are not necessary; you know: the Topic.

1 Like

Uptime is important, but it shouldn't come at the expense of neglecting firmware updates. While a stable firmware can run for extended periods, it's crucial to address security vulnerabilities and bug fixes through updates.

Oh, you're back now.

With an argument.
Great...

I'm happy to discuss this, but can we use a calmer tone?

I, really, don't have anything more to discuss with you in this thread; as it is as dead as a doorknob...

Okay, moving on.

FWIW, I build my own firmware from main/snapshot sources on all my OpenWrt devices (always have/always will).

But your latest point regarding neglecting firmware updates to address security vulnerabilities and bug fixes at the expense of maintaining extended Uptimes because it’s a Stable Firmware doesn’t comport to the topic being discussed.

You postulate earlier that:

Don’t conflate the two.

My post was to reinforce that a properly configured device based on your use case just doesn’t support your argument.

I'll add the following:

  • Absent power glitches/outages, OpenWrt, when properly configured, should be stable essentially indefinitely with an uptime to match.
  • Ideally, the device will only need to be restarted (and thus the uptime reset) for firmware updates, certain types of configuration changes [1], or other voluntary situations (such as unpluging momentarily to relocate the device or clean up cable clutter :slight_smile: ).

If you are running into a situation where your OpenWrt router is not performing properly after some period of time, and restarting it helps, that means something is wrong with the configuration, user installed packages, or possibly impending hardware failures. Restarting OpenWrt under these circumstances simply masks the problem, it doesn't actually solve anything. The priority should be to find and resolve the problematic configurations or packages. There are no normal circumstances where OpenWrt should need to be restarted on a specific cadence to keep it running smoothly or to ensure security.


  1. In many cases, config changes can be implemented simply by restarting the specific services affected, but sometimes it is easiest to simply restart the whole device. ↩︎

1 Like

From time to time and from hardware to hardware we have drivers faults that makes everything stop working. Sometimes forever and sometimes until someone fix the driver.

I'd say that it is the exception more than the rule. It does happen, for sure, but it's not a common situation.

You can schedule auc via crontab to reboot with updates, Openwrt does not have telemetry software that leaks memory and mandates regular reboots.