Sponsored Content
Operating Systems Solaris daemon dies, need to know why Post 302069354 by Silver11 on Friday 24th of March 2006 02:20:47 PM
Old 03-24-2006
daemon dies, need to know why

Say I have a daemon that dies for an unknown reason. Is there a way to track its process ID to try to determine when it dies and what causes it to go away?
 

9 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

email notification if job is killed/dies

hi folks, anybody there with suggestions on how to have an email sent to an address (if a certain job (jobA) ever dies. the concern is over the trigerring of sending the email (not the actual sending of the email) 1. is it possible for the job in question, jobA, itself do such a thing... (2 Replies)
Discussion started by: jacob_gs
2 Replies

2. SCO

xdmcp dies in sco600

We have just installed a sco 600 server. Xdmcp comes up in the chooser but if you don't log in within a few minutes it disappears and you have to log in and then out on the console before you can see it in the chooser. Xdmcp is suppossed to be setup for continuous logins automatically. We... (0 Replies)
Discussion started by: khafner
0 Replies

3. Windows & DOS: Issues & Discussions

How to detect if a Windows app dies??

Hello All: I hope this is the right category... I have a application (this app runs under java and jboss) that runs under Windows, it's started as a service. If that application should become disabled, crash or no longer function, what would be the best method for determining it is no longer... (6 Replies)
Discussion started by: jimmyc
6 Replies

4. Solaris

cronjob dies when user password expires

I noticed for some time now on solaris 8 whenever our root or oracle password expires after 12 weeks the cronjob for the expired user will totally stop working, it will start working again once the password has been changed. I wonder if anybody encountered this problem and knows of a fix other... (4 Replies)
Discussion started by: sparcguy
4 Replies

5. UNIX for Advanced & Expert Users

script dies prematurely and unpredictably

Hi, I have over 5 gb of data in a files structure in which month folders are in year folders, day folders are in month folders, and individual climate stations are in each day. I am trying to extract precipitation measured at 5 minute intervals for a duration of 15 years, but the script never... (2 Replies)
Discussion started by: mlw63@me.com
2 Replies

6. IP Networking

TCP server dies after few hours of inactivity

We have a NAS application which can be accessed by both HTTP and HTTPS connections. The issue we are facing is that the tcp server instance that initiates the HTTP access dies after a few hours of inactivity(the NAS application was kept idle for around 10 hours). However, the tcpserver that... (1 Reply)
Discussion started by: swatidas11
1 Replies

7. Hardware

Wireless works, then dies requiring a reboot

Hello, I am having a problem with my wireless. Seems to be a relatively new problem over the past few weeks. I have an intel wireless. It seems like it can be fine for days, then in will quite working to the point a reboot is necessary. It may happen once and be fine, or may happen several times... (0 Replies)
Discussion started by: Narnie
0 Replies

8. UNIX for Advanced & Expert Users

Xterm dies after being idle

I am running eod8 to connect to a linux machine running carnesr==>uname -a Linux hostname 2.6.32-220.2.1.el6.x86_64 #1 SMP Tue Dec 13 16:21:34 EST 2011 x86_64 x86_64 x86_64 GNU/Linux I have a script that opens up several xterms as follows: /usr/bin/xterm -geometry 150x60+0-0 -name... (1 Reply)
Discussion started by: rcarnesiii
1 Replies

9. HP-UX

Xterm display immediatly dies in hpux 11.23

After install of the Sept. 2010 patch set on my hpux 11.23 system, my xterm when launched, dies immediately on the client with the xserver, with a core.xterm file in root of the hpux server. This had been working before the patch install. I tried to find xterm patches from ITRC (yes the old... (1 Reply)
Discussion started by: mrmurdock
1 Replies
pthread_mutexattr_getrobust_np(3C)										pthread_mutexattr_getrobust_np(3C)

NAME
pthread_mutexattr_getrobust_np, pthread_mutexattr_setrobust_np - get or set robustness attribute of mutex attribute object SYNOPSIS
cc -mt [ flag... ] file... -lpthread [ library... ] #include <pthread.h> int pthread_mutexattr_getrobust_np(const pthread_mutexattr_t *attr, int *robustness); int pthread_mutexattr_setrobust_np(pthread_mutexattr_t *attr, int robustness); The following applies only if the symbol _POSIX_THREAD_PRIO_INHERIT is defined, and the mutex attributes object attr should be used only to initialize mutexes that will also be initialized with the protocol attribute having the value PTHREAD_PRIO_INHERIT. See pthread_mutex- attr_getprotocol(3C). The pthread_mutexattr_setrobust_np() and pthread_mutexattr_getrobust_np() functions set and get the robustness attribute of a mutex attribute object pointed to by attr that was previously created by the function pthread_mutexattr_init(3C). The robustness attribute defines the behavior when the owner of a mutex dies. The value of robustness may be ether PTHREAD_MUTEX_ROBUST_NP or PTHREAD_MUTEX_STALLED_NP, which are defined by the header <pthread.h>. The default value of the robustness attribute is PTHREAD_MUTEX_STALLED_NP. When the owner of a mutex with the PTHREAD_MUTEX_STALLED_NP robustness attribute dies, all future calls to pthread_mutex_lock(3C) for this mutex will be blocked from progress in an unspecified manner. When the owner of a mutex with the PTHREAD_MUTEX_ROBUST_NP robustness attribute dies, the mutex is unlocked. The next owner of this mutex acquires it with an error value of EOWNERDEAD. Note that the application must always check the return value from pthread_mutex_lock() for a mutex initialized with the PTHREAD_MUTEX_ROBUST_NP robustness attribute. The new owner of this mutex should then attempt to make the state protected by the mutex consistent, since this state could have been left inconsistent when the last owner died. If the new owner is able to make the state consistent, it should call pthread_mutex_consistent_np(3C) for the mutex and then unlock the mutex. If for any reason the new owner is not able to make the state consistent, it should not call pthread_mutex_consistent_np() for the mutex, but should simply unlock the mutex. In the latter scenario, all waiters will be awakened and all subsequent calls to pthread_mutex_lock() will fail in acquiring the mutex with an error value of ENOTRECOVERABLE. The mutex can then be made consistent by uninitializing the mutex with the pthread_mutex_destroy() function and reinitializing it with the pthread_mutex_init() function. If the thread that acquired the lock with EOWNERDEAD dies, the next owner will acquire the lock with an error value of EOWNERDEAD. Note that the mutex may be in memory shared between processes or in memory private to a process, i.e. the "owner" referenced above is a thread, either within or outside the requestor's process. The mutex memory must be zeroed before initialization. Upon successful completion, the pthread_mutexattr_getrobust_np() and pthread_mutexattr_setrobust_np() functions return 0. Otherwise, an error number is returned to indicate the error. The pthread_mutexattr_getrobust_np() and pthread_mutexattr_setrobust_np() functions will fail if: EINVAL The value specified by attr or robustness is invalid. ENOSYS The option _POSIX_THREAD_PRIO_INHERIT is not defined and the implementation does not support the function. ENOTSUP The value specified by robustness is an unsupported value. See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |MT-Level | MT-Safe | +-----------------------------+-----------------------------+ pthread_mutex_lock(3C), pthread_mutex_consistent_np(3C), pthread_mutexattr_getprotocol(3C), attributes(5), mutex(5), standards(5) 23 Mar 2005 pthread_mutexattr_getrobust_np(3C)
All times are GMT -4. The time now is 04:33 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy