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