Previous Table of Contents Next
Application Celebration
Some applications are pretty complicated. For example, email and
scheduling applications can be insanely complex with lots of
configuration files, incoming, outgoing, administrative, and extra
queue directories, and so on. It can be hard to identify a corrupt
file-or any other cause-that's the monkey wrench in the works.
Here are some strategies that work with file and print application
problems:
o Check server and application logs.
o Change the rules. (Can you simplify them? Can you move the
app?)
o Restore from a "known good" point in time.
Happy Fun Logs
A log file typically tells the tale pretty well. You'll want to make
sure that your application is configured for verbose- or debug-level
logging if you're experiencing problems. You don't necessarily need to
be an expert to take action after looking at the logs-you can always
search an error message on the Web, or sometimes the log file will
suggest an action, like so:
file.idx is corrupt-run rebuild process
Environment
Changing the environment is pretty case-specific. For example, you
might be able to move the application from one server to another to
rule out server problems-but I wouldn't do this unless you had reason
to believe that the problem was server-related. If you're having
problems that seem capacity-related, can you move some users to a
different application server?
Restoring from a Known Good Point
If you're not an expert in the application, and neither of the first
two strategies work out, the beautiful thing about file-level
applications is that they're well-suited to fixing by restoration.
You'll still need to know where the application lives in order to
restore it, but if you installed it, or if you have the manual, this
should be trivial to find out.
______________________________________________________________
Complex applications sometimes have more than one location-an app
that exchanges state information with another location should not
be restored on its own. The app might get really, really, confused
if all of a sudden half of its brain gets restored.
______________________________________________________________
Experts Inaction
I've been in a shop where nobody had been trained on the email system;
that is, although everybody had been trained on how to use the system,
nobody had been trained in how to administer it. So when the mail
system stopped talking one fine morning, nobody really knew how to
deal with it.
Log files showed nothing in particular. A search of the Web revealed
nothing. Technical support hold times were in excess of an hour, with
the promise of a callback later that afternoon-maybe.
All the IT personnel in this shop were highly trained
professionals-but not having been trained on the administration of
this application, they were just as useless as anybody else in
diagnosing this problem. But waiting all day for tech support was not
a popular option.
After restoring the system from backup, everything worked-nobody even
lost any mail, since the problem had occurred during the night, after
the backup ran. To this day, nobody knows what the specific problem
was-and nobody cares. Moral of the story: Good backups win.
Client/Server Maitre d'
Client/server troubleshooting basically entails verifying that TCP/IP
communications are working okay and then verifying that the server
program is answering the phone on the other end-that is, the correct
socket is listening at the server end.
Let's quickly review TCP/IP connectivity techniques:
1. Ping by name: Is the name resolvable?
2. Ping by IP address: Is the server reachable at all?
3. Use traceroute: Why can't you get there? Where does the
packet stop?
State of the Socket Address
Get used to typing the netstat -a command-it is the tool for
troubleshooting client/server application problems. Let's quickly go
over what the output of netstat -a shows you:
Proto Local Address Foreign Address State
o Proto This refers to the protocol (either TCP or UDP).
o Local Address This refers to the address and socket that
the workstation is using to speak.
o Foreign Address This shows the remote address and socket
number that you're speaking to.
o State This describes the state of the socket (see the
following note).
______________________________________________________________
Does the local socket address matter? No. Just like with a phone
call, you can use just about any free extension to dial out-and
your computer will do so automatically. The local socket address
only matters if the computer that you're sitting on is a server. In
that case, it must be listening at the correct socket number;
otherwise, nobody will be able to talk to it.
______________________________________________________________
Depending on the operating system, you'll see one of the following
various states in the State column:
_________________________________________________________________
State Description
_________________________________________________________________
LISTENING "I'm a server, and I'm ready to talk to someone."
ESTABLISHED "I'm having a conversation."
SYN_SENT "I'm trying to synchronize the call with someone, but no luck
so far."
SYN_RECV "I'm in the process of synching up with someone."
CLOSE_WAIT "The other end just hung up; I'm waiting for the dial
tone."
TIME_WAIT "I hung up; I'll get rid of this entry shortly."
LAST_ACK "The other end said goodbye and will shut down shortly."
FIN_WAIT1 "The socket is closed. I'll get rid of this shortly."
FIN_WAIT2 "The socket was closed by other end. I'll get rid of this
shortly."
_________________________________________________________________
Previous Table of Contents Next
Wyszukiwarka
Podobne podstrony:
293 296293 296296 297296 299293 295291 296296 15296 05296 0914 (296)296 21więcej podobnych podstron