# Maximum time for which a Linux PC can be UP? [closed]

Actually I had a linux system ( running Ubuntu 12.04.3 ) for days without reboot. I ran in to some errors like sleep getting hang and some network mounted file system not getting mount even able to ping it (verified via other PC, the network mount was working fine).

Wanted to check if Linux also requires to reboot the machine after some time frame to avoid these types of weired errors which are non repeatable.

What is the maximum time we can maintain the PC up? Are there some other problems that could occur if we have a system up for year or more without reboot?

• I don't think there's a static limit, since computers just aren't meant to be awake and running for such a long time. There's no rated limit; it's just how long your computer can stay up. Why would you not want to reboot occasionally. – TheWanderer Apr 29 '15 at 10:53
• @Zacharee1 umm, why would you WANT to reboot? Unless it's power consumption, there really isn't much of a reason. In fact, it's better if you don't. Hardware will generally last, X years per part. Let's for simplicity's sake say that X is universally 10 (it's not going to be far off either) - that's usually 10 continuous years of use it can last. That's normal use. If you reboot that's not continuous use but you're also hitting the hardware big next time the machine boots. If you just leave it be - most components spin down, reduce consumption and wear anyway. – VLAZ Apr 29 '15 at 20:08
• It's obviously the case that parts undergo more wear when in use. However, rebooting (as distinct from just shutting the system down) does not decrease the wear on components, it increases it. Also, you fundamentally misunderstand how caches work if you think that data cached in RAM slows down your computer. – user6053 Apr 30 '15 at 2:40
• If you're running a web server on Linux (e.g. LAMP) you want to avoid reboots as much as possible since doing so would bring your web sites down for the time it takes for the system to come back up. I don't think I've ever gone a year but certainly several months without rebooting. – tcrosley Apr 30 '15 at 6:55
• @Zacharee1 pretty much anything in the RAM would not slow down your computer. If there is a memory leak in an application, it could take, say, 60% of the RAM and the system would soon start swapping which is slow, however, the solution is to restart the application, not the OS. Stopping the machine stops the wear of components but you'd be replacing them sooner than they usually wear in most cases anyway. And moreover, as I pointed out, hardware components already decrease wear by themselves. Simply by leaving the system idle. – VLAZ Apr 30 '15 at 7:26

Working as a system administrator, I see Linux servers up for over 700-800 days without reboot, so there are no uptime limitations; the errors you got are not related to Linux (the kernel) itself.

A lot of services can be restarted and most errors can be solved on production systems.

• Can confirm this. Current uptime on one of my servers: ~\$ uptime 00:13:15 up 883 days, 9:00, 1 user, load average: 0.00, 0.01, 0.05 Ubuntu 12.04.4 LTS. No need to update anything as it's not running anything important. – Minthos Apr 29 '15 at 22:17
• I have successfully kept an embedded Linux instance up for 3+ years. – Rafał Cieślak May 4 '15 at 10:08

There is no technical need to restart your computer after a certain time period. I've had mine running for months (incl. kernel module updates) with some suspensions (to RAM and disk) in between.

There are occasions where

• it's absolutely necessary to reboot, like kernel updates (but those aren't urgent in many situations, and in some cases you can replace a running kernel with a new one on a live system. See kexec and Ksplice)
• it may be easier to restart the whole system instead of just a particular (set of) subsystem(s).

There may be some issues that “become worse” over time (e. g. hardware driver issues, leaky processes), but those are considered bugs and can often be fixed with a software upgrade or worked around by a reload/restart of that particular subsystem (also see above).

• On the fly kernel patching gets more hype than it deserves. It's great if you have the time to verify that an update will work that way, but any code change that makes in-memory data structures different can't just be live-patched. It's not going to enable reboot-less upgrading to new kernels in general. It will allow reboot-less fixes for things like permission-checking bugs. It's GREAT, and awesome to not have to reboot a server, but don't expect this to give you reboot-free upgrades to new versions. – Peter Cordes Apr 30 '15 at 0:27
• I agree with Peter. That's why I didn't mention live patching in this context as to not make things more complicated; alas someone edited my answer. – David Foerster Apr 30 '15 at 13:34

I don't know whether this has an impact over system's stability, but the maximum uptime shown in Ubuntu with kernel 3.19-xx is 68,0962597349822 years on a 32-bit machine and 292471208677,8627 years on a 64-bit machine.

That's because the system's current uptime, which is returned by the sysinfo() syscall, is returned as a __kernel_long_t type, which is a declared as a long in a 32-bit kernel and as a long long in a 64-bit kernel;

A long on a 32-bit machine has a maximum value of 2147483647;

A long long on a 64-bit machine has a maximum value of 9223372036854775807;

Doing the math, 2147483647s = 68,0962597349822 years and 9223372036854775807s = 292471208677,8627 years.

Once this value increases exceeding its type's capability, an arithmetic overflow takes place and it's set to the smallest value allowed by its type (in both cases a negative number): this might be an issue for programs relying on it.

• The OP is not asking for the maximum uptime the system can log accurately, he is asking whether he will need to reboot his system regularly due to some stability/etc. limitation. – Boluc Papuccuoglu Apr 30 '15 at 8:14
• @BolucPapuccuoglu See if in your opinion it fits better in this format, expecially the last part. I pointed out explicitly what the problem could be. If you still think it doesn't, I'll delete my answer. – kos Apr 30 '15 at 10:24

While I'm certain that there are servers with a higher uptime, I present the following from one of mine as an example of what is possible:

# uptime
04:58:44 up 2186 days, 23:15,  1 user,  load average: 0.02, 0.02, 0.00


This server was installed shortly after the DC it's in went live and hasn't been turned off since. Thus far it has continued happily doing what it was originally intended for and when that purpose gets moved to a different server I'll put something on there just to monitor the uptime and it will probably stay up until I can't justify keeping it alive any longer.

Thus I think "There is no maximum" is quite definitely the correct answer.

I was in a class once with a sysadmin who claimed he had a linux server which was running with no reboots for over a decade. There is no inherent reason a system needs to be rebooted regularly. It is only required in limited instances such as kernel updates.

FWIW, I usually leave my Windows home computer running. It will usually run just fine for weeks without rebooting.

• If your Windows computer goes for weeks without rebooting, you obviously don't have automatic updates enabled. They are usually downloaded weekly and almost always result in a reboot. – tcrosley Apr 30 '15 at 6:56
• @tcrosley Who needs automatic updates anyway? It's one of the first things I turn off on those machines. I'll decide how to use my computer, not some automatic service. – Mast Apr 30 '15 at 7:46
• @tcrosley Are you sure Windows security updates are usually downloaded every week? My understanding, both from Microsoft's update release policies and from personal experience using Windows, is that updates are usually released about once per month. Mast: While you're certainly free to disable automatic updates, I don't know why that would result in longer uptimes. Presumably--hopefully!--you are manually updating, at least for security fixes. On the other hand, disabling automatic updates may make it easier to control when downtime occurs. – Eliah Kagan Apr 30 '15 at 9:52
• @EliahKagan I have my machine setup to download not only security fixes, but also updates to applications, drivers, etc. I may be wrong about it being once a week, but it is certainly more often than once a month. It checks for updates every morning at 3:00 am. I'll come in in the morning, and find my system has rebooted, and after logging on, there is a message "Your system was rebooted to install updates." – tcrosley Apr 30 '15 at 11:35

Linux (the kernel) is very good at freeing resources when programs exit. GNU/Linux, the entire OS, is generally fine to run indefinitely. Restarting user-space programs after you update them is generally a good idea, and often the easiest way to get everything using an updated glibc is to reboot the system.

On systems with driver bugs (typically graphics driver bugs, everything else is usually rock solid), you sometimes get weird behaviour that gets weirder if you don't reboot soon. If you see a kernel OOPS in your dmesg output, you should reboot as soon as is convenient, and report it (or google around for other people with similar problems on similar hardware, in case it's a known problem). Distros don't ship the very latest dev versions of the graphics stack, so sometimes the bug is already fixed upstream, and your graphics card is just too new for the drivers on the distro version you're running to be stable. In that case, look for a PPA with updated builds of mesa/drm/xorg. (I'm not sure what the best choice for running Ubuntu with a bleeding edge graphics stack is ATM).

Anyway, barring driver or other kernel bugs, Linux can run indefinitely without needing a reboot to clear memory fragmentation or anything like that.

I have a Linux router/firewall/mailserver/shell box (P3 450MHz, OCed to 500MHz) which routinely sees uptimes of hundreds of days. I reboot only to rearrange power cords, or to replace a failing power supply. It's been going steady with the same CPU/RAM/hard drives for probably 15 years. I've never had to reboot "because it was getting unstable". It was always for a specific reason, like failing power supply, or kernel upgrade, or power outage and my UPS battery was almost drained (triggering auto shutdown with apcupsd).

If your system is acting weird, check dmesg for problems. If it's just your desktop, then if you just installed some non-kernel package updates, log out / log in (or reboot, but you don't have to). I've found Kubuntu 15.04 will easily run into problems after package updates, I think due to binary incompatibility between upgraded / non-upgraded versions of the same library running in the same binary. (See discussion on this bug).

My go-to for checking for hardware problems is to boot memtest86+. (aptitude install memtest86+) Let that run a full pass, or run overnight. That doesn't guarantee a stable system, since power supply voltage dips on spike loads can happen with CPUs these days, and memtest won't rule that out. Nor will it get your CPU hot, like Prime95.

My machine only restarted today for the 15.04 after being up for 11 days without any strange errors which I can recall. If you are doing heavy work and development on a system, it can sometimes be the only option to reboot, but it's only ever on a need-basis.

• Exactly you are right! I've been developing on 16.04 for a couple of months. Because of freezing I restart my computer generally at every day. But I am sure the reason is what I installed and I use on and drivers etc. – efkan Jan 24 '17 at 6:44

Technically there are no limits. you just have to set it to not sleep or shut down.

• Could you please clarify and elaborate your answer more? Specially this line you just have to set it to not sleep or shut down. – heemayl Apr 29 '15 at 11:14
• “Technically there are no limits” would have been enough as a short answer, concise and correct. – Léo Lam Apr 29 '15 at 15:33

Personally I wouldn't want to run my laptop or PC for days with out rebooting or shutting it down.

Simply because of the main components that generate heat can speed up the wear and tear on the MB.

(Thats if you don't have the proper cooling and ventilation)

• If it's consumer-grade garbage like Acer or HP, but business-grade Thinkpads or Dell Latitude laptops are usually better made; I personally have a Latitude running 24x7 for more than a year now, it's right next to me and still works perfectly. – user249743 Apr 29 '15 at 16:31
• @kingtoor Why would it be better to run an inadequately cooled machine 24x7 with occasional reboots than to run it 24/7 without reboots? (Or is that not what you mean to say?) – Eliah Kagan Apr 29 '15 at 19:20
• Powering down / sleeping when not in use on a laptop that gets hot when left running 24/7, ok sure. That's unrelated to rebooting (with no time spent off) vs. continual uptime. – Peter Cordes Apr 30 '15 at 0:03
• My answer is in my comment. – Kingtoor May 5 '15 at 2:29
• Also i don't really see any reason for a average user to run their pc 24/7 unless they have a server. Thats my opinion. – Kingtoor May 5 '15 at 3:58

Not specific to Ubuntu, but I've got a 1997 vintage laptop (300 MHz, 288 MB RAM) running a Debian-based distro that has had uptime upwards of 60 days, while running a single program (plus system stuff and conky) and not starting and stopping other software except a terminal to load updates weekly. Eventually, it crashed when loading the updates, at around 63 days. By contrast, my Kubuntu 14.04 desktop system will freeze in screen lock after around two weeks. I agree with other answers; it's more about what software you run and how often you start and stop other programs, than about Linux as such.

• If it crashed (I mean hard crash or freeze, not just X crashing which is fixable without rebooting), that probably means there is a hardware problem (overheating, bad RAM, etc). As a sysadmin I sometimes have my servers running for months without rebooting, though I prefer to avoid it since you need to reboot to apply kernel updates. – user249743 Apr 29 '15 at 16:07
• When the screen lock has gone black screen, there's no effective way to tell if it's a hard system lock or an X server failure -- and no way to access the command line (without ability to enter the password) to restart X or whatever else it might be. I'm inclined to think if it takes two weeks, it's not overheating or bad RAM. – Zeiss Ikon Apr 29 '15 at 16:17
• Ctrl+Alt+F1 doesn't work ? And a bad graphics driver may be the culprit - they may not have been tested with high uptime in mind, but Linux is definitely able to run for years without issues. – user249743 Apr 29 '15 at 16:18
• I'll have to try CTL-ALT-F1, if I can remember it next time I get a screen lock freeze (I've been using the hard reset). I presume I'd then use startx to restart the X server? Or do I need to use a special command to restart the service? I am well aware of the old Linux saying, that "Restarts are for kernel upgrades and hardware installation." – Zeiss Ikon Apr 29 '15 at 16:21
• Login as root or as a normal user and use sudo, and follow these instructions – user249743 Apr 29 '15 at 16:22