|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Editions | myCNN | Video | Audio | Headline News Brief | Feedback | ![]() |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Troubleshooting the Linux way
(IDG) -- The rapid growth of Linux in the server market means that people who are primarily familiar with Windows will need to learn how to administer Linux servers. If you're one of these people, please accept some friendly advice: don't treat Linux like Windows. Most Windows troubleshooting sessions go something like this: First, reboot. If that doesn't fix the problem, try reinstalling or upgrading one or more drivers and then rebooting again. If that still doesn't work, reinstall or upgrade the application that is giving you trouble and reboot again. If that doesn't work, reinstall everything. Start with Windows, add the latest Windows fix pack, install the latest drivers, and then reinstall all your applications and their fix packs. Configure everything again.
While this works for Windows, it is probably the worst approach possible for troubleshooting a Linux system. First, you should never reboot Linux as the first step in trying to solve a problem. Outside the obvious motivations -- upgrading the kernel, adding memory, changing hardware, etc. -- the only reason you might ever have to reboot Linux is if you have running processes that won't die because they are hung up in an I/O state. This usually only happens when a piece of hardware dies and a driver gets stuck trying to make that hardware work. Otherwise, Linux is very robust and can run for years without a reboot. The LinuxWorld Web server is based on Red Hat Linux 5.1, and as of this writing it has been running for 477 days without a reboot -- the entire time LinuxWorld has been online.
This is true despite the fact that LinuxWorld has made a number of changes to the server since it was first fired up. For example, we added PHP and the MySQL database as part of a site redesign. The Apache Web server was upgraded. Disk-full errors led to some corrupted forum configuration files, which required significant repairs to the forum software. But none of these important changes to the system required a reboot. You particularly don't want to reboot when attempting to solve problems if you are inheriting a Linux system that was configured by someone else. A sloppy administrator may have left the machine in a state wherein some critical services are started manually, others automatically. When you reboot the server, you'll now have the additional tasks of discovering why some services aren't running (or why some unwanted services are) and then deciding how best to start and stop them. You'll eventually want to fix these problems, but why unnecessarily complicate your current task with a reboot? And whatever you do, don't upgrade software packages unless you know in advance that the upgrade will solve your specific problem. In most cases, you're better off taking an "if it ain't broke, don't fix it" approach when it comes to Linux. Some Linux installation programs replace existing configuration files with new ones, although they usually create backups of the old files. When this occurs, you may need to merge all your custom configuration settings into the new configuration files just to get back online. Unfortunately, many Linux programs lack a friendly graphical configuration interface for doing this. On the other hand, most Linux configuration files are in text format, so they're easy to edit. But it isn't always easy to use an editor to merge all your old custom settings into a brand new configuration file. That could be a lot of trouble if all you want is to have the most brand-new-shiny version of a package. While there are many good reasons to adopt the "if it ain't broke, don't fix it" attitude, there is also a bad one -- annoying version conflicts with the most commonly-used shared library, glibc. Hopefully, the Linux Standard Base (LSB) should make most glibc version conflicts a thing of the past. But until LSB is finished and widely adopted, think of glibc version problems as the Linux equivalent of DLL hell. In general, Linux isn't nearly as vulnerable as Windows. And if you know what you're doing, you can work around all library conflicts. But if you don't know what you're doing, a reckless upgrade of one package may get you into a situation that will make you want to upgrade your whole Linux distribution to solve the problem. The Windows reboot-and-reinstall method may sound like a simple two-step process compared to administering a Linux system, but as long as you treat Linux like Linux instead of Windows, you should enjoy more uptime and less tribulation. The well-tempered LinuxNow that you know what not to do, here are a few tips for those of you moving from Windows to Linux. The first thing you should do is become familiar with the man command. This command brings up online manual pages (usually just called man pages) for various parts of your Linux system. Man pages are not restricted to commands and utilities. You can bring up man pages on many other details, such as C library functions. The first command you should try is man man. This brings up a man page on the man command itself. After you've been using Linux for a while, your list of most-commonly-used commands becomes second nature. Until then, you may need to use another utility called apropos. This command tells you which man pages deal with a given topic. For example, suppose you forget which command removes a job from your print queue. You know it has something to do with the lpr utility, so you type apropos lpr. Bingo -- the results include lprm, which is the command you're looking for. Another thing you should do is install online documentation when you install Linux. Whenever you need tips on a command or service, check the /usr/doc directory for documentation. If you can't find what you want there, check the /usr/doc/HOWTO/other-formats/html directory for an HTML file on the topic in question. Finally, you can usually get a good lead on how to solve a problem by taking some important bit of information about your problem and entering it as search criteria on the Deja Discussions site. One of the most useful troubleshooting techniques is to browse through your error logs until you find an error message related to the problem you're having. Cut the important portion of that error message and paste it into the search field for Deja Discussions, and then browse through the search hits. RELATED STORIES: Two Linux standards groups combine into one RELATED IDG.net STORIES: How to get help with free software RELATED SITES: Deja Discussions Website | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back to the top |
© 2001 Cable News Network. All Rights Reserved. Terms under which this service is provided to you. Read our privacy guidelines. |