Sponsored Content
Operating Systems Solaris daemon dies, need to know why Post 302069380 by reborg on Friday 24th of March 2006 05:26:08 PM
Old 03-24-2006
Does the deamon in question have a log file and/or debug mode?
 

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
inittab(4)						     Kernel Interfaces Manual							inittab(4)

NAME
inittab - script for the boot process DESCRIPTION
The file supplies the script to the boot daemon in its role as a general process dispatcher (see init(1M)). The process that constitutes the majority of boot process dispatching activities is the line process that initiates individual terminal lines. Other processes typi- cally dispatched by boot are daemons and shells. The file is composed of entries that are position-dependent and have the following format: Each entry is delimited by a newline; however, a backslash preceding a newline indicates a continuation of the entry. Up to 1024 charac- ters per entry are permitted. Comments can be inserted in the process field by starting a "word" with a (see sh(1)). Comments for lines that spawn are displayed by the command (see who(1)). It is expected that they will contain some information about the line such as the location. There are no limits (other than maximum entry size) imposed on the number of entries within the file. The entry fields are: id A one- to four-character value used to uniquely identify an entry. Duplicate entries cause an error message to be issued, but are otherwise ignored. The use of a four-character value to identify an entry is strongly recommended (see WARNINGS below). rstate Defines the run level in which this entry is to be processed. Run levels correspond to a configuration of processes in the system where each process spawned by boot is assigned one or more run levels in which it is allowed to exist. Run levels are represented by a number in the range through For example, if the system is in run level only those entries hav- ing a in their rstate field are processed. When boot is requested to change run levels, all processes that do not have an entry in the rstate field for the target run level are sent the warning signal and allowed a 20-second grace period before being forcibly terminated by a kill sig- nal You can specify multiple run levels for a process by entering more than one run level value in any combination. If no run level is specified, the process is assumed to be valid for all run levels, through Three other values, and can also appear in the rstate field, even though they are not true run levels. Entries having these characters in the rstate field are processed only when a user process requests them to be run (regardless of the current system run level). They differ from run levels in that boot can never enter "run level" or Also, a request for the execution of any of these processes does not change the current numeric run level. Furthermore, a process started by an or option is not killed when boot changes levels. A process is killed only if its line in is marked in the action field, its line is deleted entirely from or boot goes into the single-user state. action A keyword in this field tells boot how to treat the process specified in the process field. The following actions can be specified: Process the entry only at boot boot-time read of the file. Boot starts the process, does not wait for its termination, and when it dies, does not restart the process. In order for this instruction to be meaningful, the rstate should be the default or it must match boot run level at boot time. This action is useful for an initializa- tion function following a hardware boot of the system. Process the entry only at boot boot-time read of the file. Boot starts the process, waits for its termination, and, when it dies, does not restart the process. An entry with this action is only scanned when boot is initially invoked. Boot uses this entry, if it exists, to determine which run level to enter initially. It does this by taking the highest run level specified in the field and using that as its initial state. If the rstate field is empty, boot enters run level The entry cannot specify that boot start in the single-user state. Additionally, if boot does not find an entry in it requests an initial run level from the user at boot time. If the process associated with this entry is currently running, send the warning signal and wait 20 seconds before forcibly terminating the process via the kill signal If the process is nonexistent, ignore the entry. When boot enters a run level that matches the entry's rstate, start the process and do not wait for its termina- tion. When it dies, do not restart the process. If boot enters a new run level but the process is still running from a previous run level change, the process is not restarted. This instruction is really a synonym for the action. It is functionally identical to but is given a different keyword in order to divorce its asso- ciation with run levels. This is used only with the or values described in the rstate field. Execute the process associated with this entry only when boot receives a power-fail signal see signal(5)). Execute the process associated with this entry only when boot receives a power-fail signal and wait until it terminates before continuing any processing of If the process does not exist, start the process; do not wait for its termination (continue scanning the file). When it dies, restart the process. If the process currently exists, do nothing and continue scanning the file. Entries of this type are executed before boot tries to access the console. It is expected that this entry will be only used to initialize devices on which boot might attempt to obtain run level information. These entries are executed and waited for before continuing. When boot enters the run level that matches the entry's rstate, start the process and wait for its termination. Any subsequent reads of the file while boot is in the same run level cause boot to ignore this entry. process This is a command to be executed. The entire field is prefixed with and passed to a forked as "". For this reason, any syntax that can legally follow can appear in the process field. Comments can be inserted by using the syntax. WARNINGS
The use of a four-character id is strongly recommended. Many pty servers use the last two characters of the pty name as an id. If an id chosen by a pty server collides with one used in the file, the file can become corrupted. A corrupt file can cause commands such as to report inaccurate information. FILES
File of processes dispatched by boot SEE ALSO
sh(1), getty(1M), exec(2), open(2), signal(5). inittab(4)
All times are GMT -4. The time now is 01:35 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy