- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: About the output of tusc
Operating System - HP-UX
1748081
Members
5254
Online
108758
Solutions
Forums
Categories
Company
Local Language
юдл
back
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
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
тАО05-07-2007 05:11 PM
тАО05-07-2007 05:11 PM
About the output of tusc
Hi,
I am new to this forum. I attached a output of tusc of a select command which fails. Can anyone advice me how to analyse this tusc output and to rectify the errors ERR#12 ENOMEM and ERR#25 ENOTTY
I am new to this forum. I attached a output of tusc of a select command which fails. Can anyone advice me how to analyse this tusc output and to rectify the errors ERR#12 ENOMEM and ERR#25 ENOTTY
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-07-2007 06:46 PM
тАО05-07-2007 06:46 PM
Re: About the output of tusc
Shalom,
This is normally a problem with a terminal device (NOTTY) not being correct. If this involves oracle, you need to set up an environment, including a terminal, even when firing up batch style processes in the background.
SEP
This is normally a problem with a terminal device (NOTTY) not being correct. If this involves oracle, you need to set up an environment, including a terminal, even when firing up batch style processes in the background.
SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
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
тАО05-07-2007 06:49 PM
тАО05-07-2007 06:49 PM
Re: About the output of tusc
After the ENOMEM errors, the command is doing the analysis for you. It appears to be trying to print an error message:
jBase: Unable to allocate 279442109 bytes, errno = 12 at jlibBStore.c,347(ENQSELCRITSUBS.h,1)
It's very clearly saying it needs about 270 megabytes more memory. Run "ulimit -a" and "ulimit -a -H". Is it hitting any of those limits, or are the machine's memory and swap completely in use?
If it's the ulimit, evaluate whether you have enough system resources (=memory and swap) to raise the limit. If not, add some memory to the server before raising the ulimit.
In this case, the ulimit just stopped the problem before it caused system-wide trouble. If you just increase the limit without actually having the memory to support the increased limits, the system-wide lack of memory may cause other unrelated processes to die, and that may make the machine unresponsive: if inetd (and sshd, if you have it) die in an out-of-memory situation, you need console access to recover. A situation like that is generally so messy that it might be easier to just reboot...
If the problem is that there is not enough physical memory nor swap free, the solution is to add some memory. If your need is temporary and you can afford to take a *major* performance loss, you can just add more swap instead.
After the error message, something interesting happens: the program gets a SIGSEGV. The siginfo says "faulting addres: 0". My guess is that after trying to allocate more memory, receiving a failure indication, and printing the error message about it (explained above), the program just tried to use the memory anyway. That is a stupid thing to do. Instead of gracefully rolling back the transaction and reporting "the system is overloaded" (or whatever is appropriate) to the end user, the program is now firmly on its way to crash.
The ENOTTY error does not seem to be harmful.
Just before the error, the program is opening a file /usr/jbc/tmp/jbase_error_trace. Note that it gets 46 as the response: that's the file descriptor. The next system call is lseek, which gets the same file descriptor as the first parameter. The same is true about the ioctl system call which produces the error... so now we know the ioctl was targeted to /usr/jbc/tmp/jbase_error_trace, which obviously is not a terminal device, so the ENOTTY return code is absolutely correct.
My guess is that there is just one error output function in the program, and nobody has thought about what happens if the error message is redirected to a file. The program is simply ignoring the errors from a terminal-related system call, because it is not essential for that call to succeed. The error happens in a point where the program is already reporting a critical error: as it's essential that the error reporting code is as simple and robust as possible, this ignoring of ENOTTY error is acceptable. Getting the error message nicely wrapped according to the terminal width is not important: getting the error information to the people who can fix the problem _is_ essential.
Of course, the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.
MK
jBase: Unable to allocate 279442109 bytes, errno = 12 at jlibBStore.c,347(ENQSELCRITSUBS.h,1)
It's very clearly saying it needs about 270 megabytes more memory. Run "ulimit -a" and "ulimit -a -H". Is it hitting any of those limits, or are the machine's memory and swap completely in use?
If it's the ulimit, evaluate whether you have enough system resources (=memory and swap) to raise the limit. If not, add some memory to the server before raising the ulimit.
In this case, the ulimit just stopped the problem before it caused system-wide trouble. If you just increase the limit without actually having the memory to support the increased limits, the system-wide lack of memory may cause other unrelated processes to die, and that may make the machine unresponsive: if inetd (and sshd, if you have it) die in an out-of-memory situation, you need console access to recover. A situation like that is generally so messy that it might be easier to just reboot...
If the problem is that there is not enough physical memory nor swap free, the solution is to add some memory. If your need is temporary and you can afford to take a *major* performance loss, you can just add more swap instead.
After the error message, something interesting happens: the program gets a SIGSEGV. The siginfo says "faulting addres: 0". My guess is that after trying to allocate more memory, receiving a failure indication, and printing the error message about it (explained above), the program just tried to use the memory anyway. That is a stupid thing to do. Instead of gracefully rolling back the transaction and reporting "the system is overloaded" (or whatever is appropriate) to the end user, the program is now firmly on its way to crash.
The ENOTTY error does not seem to be harmful.
Just before the error, the program is opening a file /usr/jbc/tmp/jbase_error_trace. Note that it gets 46 as the response: that's the file descriptor. The next system call is lseek, which gets the same file descriptor as the first parameter. The same is true about the ioctl system call which produces the error... so now we know the ioctl was targeted to /usr/jbc/tmp/jbase_error_trace, which obviously is not a terminal device, so the ENOTTY return code is absolutely correct.
My guess is that there is just one error output function in the program, and nobody has thought about what happens if the error message is redirected to a file. The program is simply ignoring the errors from a terminal-related system call, because it is not essential for that call to succeed. The error happens in a point where the program is already reporting a critical error: as it's essential that the error reporting code is as simple and robust as possible, this ignoring of ENOTTY error is acceptable. Getting the error message nicely wrapped according to the terminal width is not important: getting the error information to the people who can fix the problem _is_ essential.
Of course, the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.
MK
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-08-2007 03:17 PM
тАО05-08-2007 03:17 PM
Re: About the output of tusc
>MK: The ENOTTY error does not seem to be harmful.
Right. You don't have to worry about ENOTTY. This could occur because stdio needs to figure out the buffering and handles TTYs special.
>MK: the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.
That's what fread/fwrite(3) is doing. It has to call ioctl (really isatty(3)) to find this.
Right. You don't have to worry about ENOTTY. This could occur because stdio needs to figure out the buffering and handles TTYs special.
>MK: the neater way would be to test whether the target file descriptor is a TTY or not, and then skip the ioctl call if the target is not a TTY.
That's what fread/fwrite(3) is doing. It has to call ioctl (really isatty(3)) to find this.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP