- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Proper way to recover from hung system
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2010 09:58 AM
тАО07-16-2010 09:58 AM
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-16-2010 11:45 AM
тАО07-16-2010 11:45 AM
Re: Proper way to recover from hung system
Boot the system into single user mode at the console.
ISL> hpux -is
HPUX(IA-64 prompt)>hpux -is
mount -a
Try and clear the full file system.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2010 02:31 PM
тАО07-17-2010 02:31 PM
SolutionA system may be perfectly fine but a switch port has gone bad or turned off by a mistake in the network department. So start with the real console. Ideally, the console LAN port is on an isolated (and secure) network. If not, then a network outage will make all remote access impossible. Get to the computer room and hook up a serial console terminal or PC with a known-to-work serial adapter.
Start with console access to see if the server is even powered on. If you can get a GSP/MP prompt, then connect to the console. If you can't get a prompt, try CTRL-C to kill anything talking to the console. Then try CTRL-\ as a SIGQUIT signal. If you can get a system prompt and logged in, start by shutting down any applications or databases. Now you can take a look at the system. Start with bdf -l (-l = local, skips NFS). If the filesystems are OK, check NFS servers that are supposed to be working -- they can hang other computers.
Since you mentioned audsys, you must have some access to the system so shutting down audsys is your top priority. audsys is a very extensive monitoring tool but it can generate gigabytes of data in a few minutes if you monitor everything. Always choose audsys settings very carefully to record just what you need. It is not a monitoring tool to watch user activities.
Still no response? You'll probably need to TC the system (Transfer Of Control) which forces a crash dump. Once the system finishes selftest, interrupt the boot process and come up in single user mode. Run fsck on the lvols for /usr, /tmp and /var. You'll need to find the rlvol name for each of those mountpoints. Now mount those 3 filesystems (do not use mount -a). Now you'll have access to commands like bdf, du, vi and so on.
If you find and fix the problem then you can reboot into single user mode. If not, reboot and monitor the startup steps. They are also recorded in /etc/rc.log. Once the system is running, you can offload the /var/adm/crash directory so you can submit the dump to HP for analysis. Hangs in the HP-UX kernel are very unusual unless this is an old system with no patches. The dump itself will require HP-UX internals training to analyze the reason for the hang.
If you don't have HP software support, then bring your system up to the current (within 6 months) patch level.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2010 06:40 PM
тАО07-17-2010 06:40 PM
Re: Proper way to recover from hung system
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-17-2010 08:31 PM
тАО07-17-2010 08:31 PM
Re: Proper way to recover from hung system
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-18-2010 10:14 PM
тАО07-18-2010 10:14 PM
Re: Proper way to recover from hung system
- Increase the filesystem that was full ?
- Maybe set the "nolargefiles" option so that multigigabyte files cannot be created and cannot fill the filesystem to 100% ?
- Modify your auditing configuration ?