Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Best practice for production servers: To reboot or not to reboot?



On 09/14/2010 02:30 PM, Robert La Ferla wrote:
> So now I'll refine my question. The servers that we're using are Solari=
s and are running various services including Java app servers, NFS, SMTP,=
 and others.=20
>
> If a server isn't rebooted on say an annual basis, fsck doesn't get run=
=2E Drive mounts that were added but not made permanent won't get remount=
ed. Configuration changes and network changes may affect the reboot. Give=
n this, is it better to never reboot or reboot on a periodic basis.=20
I think Richard and Jack mentioned Java. I alluded to disk checks in my
previous email. Today's Unix and Linux systems, especially those
commercial Unix systems with advanced file systems probably do not need
to be fsck'd. There are online diagnostic systems that can report the
health of the drives. Furthermore, fsck can be run on a mounted file
system in reporting mode only.  It is only when there are some potential
errors. Additionally, many commercial systems run external storage system=
s.

In my personal opinion based on my experience, periodic maintenance is
the key issue. Bringing a server down, vacuum out the dust bunnies, and
for Coats who lives in japoopiland, make sure there are no nutria down
there.  As far as drive mounts that were not made permanent can be
easily handle by procedure. On my systems, I rarely manually mount a
file system without first adding it to the automount maps. If you don't
use automount, simply add it to fstab, and manually mount it through the
fstab. Both will make it permanent and test your changes. I think it is
important to avoid issues, such as making config and network changes on
the fly.

Basically, other than applying patches to the kernel or to run a good
hardware diagnostic, there is no technical reason to reboot. I recently
had a power failure down here, and one of my systems failed to restart.
For some reason the file system was corrupted on the boot drive to a
point where I had to reinstall RHEL 5.3. That was also the system where
I had to blacklist a module before I could complete a boot. So, one
reason to reboot periodically is to make sure the system is still
bootable. You want to find this out on a schedule downtime, not when you
have an issue that causes a system failure. Fortunately, the system was
a lower priority server.


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org