init.rc script fails because tty detach

[Laurent Laperrousaz]

Hi,

we tried to set an init script to start an application on system boot using an init script (rc).

The process starts but is killed by the next inittab line: getty console.

I know there is a way to "demonize" the process and then detach it from the console but I can't remember
what is the means.
I tried to "nohup" the script but it fails to detach the process from console

help needed!
thanx
Laurent

PS here is my inittab file:

init:3:initdefault:
ioin::sysinit:/sbin/ioinitrc >/dev/console 2>&1
tape::sysinit:/sbin/mtinit > /dev/console 2>&1
muxi::sysinit:/sbin/dasetup /dev/console 2>&1 # mux init
stty::sysinit:/sbin/stty 9600 clocal icanon echo opost onlcr ixon icrnl ignpar brc1::bootwait:/sbin/bcheckrc /dev/console 2>&1 # fsck, etc.
link::wait:/sbin/sh -c "/sbin/rm -f /dev/syscon; /sbin/ln /dev/systty /dev/syscon" >/dev/console 2>&1
cprt::bootwait:/sbin/cat /etc/copyright >/dev/syscon # legal req
sqnc::wait:/sbin/rc /dev/console 2>&1 # system init
#powf::powerwait:/sbin/powerfail >/dev/console 2>&1 # powerfail
cons:123456:respawn:/usr/sbin/getty console console # system console
#ttp1:234:respawn:/usr/sbin/getty -h tty0p1 9600
#ttp2:234:respawn:/usr/sbin/getty -h tty0p2 9600
#ttp3:234:respawn:/usr/sbin/getty -h tty0p3 9600
#ttp4:234:respawn:/usr/sbin/getty -h tty0p4 9600
#ttp5:234:respawn:/usr/sbin/getty -h tty0p5 9600
ems1::bootwait:/sbin/rm -f /etc/opt/resmon/persistence/runlevel4_flag
ems2::bootwait:/sbin/cat /etc/opt/resmon/persistence/reboot_flag
ems3:3456:wait:/usr/bin/touch /etc/opt/resmon/persistence/runlevel4_flag
ems4:3456:respawn:/etc/opt/resmon/lbin/p_client
#ups::respawn:rtprio 0 /usr/lbin/ups_mond -f /etc/ups_conf

[Bill Hassell]

Using inittab to start a process is definitely non-standard and you will run into a lot of problems. init is not the method used to start subsystems and applications. Make a copy of the template file stored in /sbin/init.d and add your startup code. Remember that like all startup processes, there is no login so it will be your responsibility to set an appropriate environment. You'll still need to disconnect from the parent process using nohup and place it in the background with & (assuming you did not write the program as a true daemon).

Once you get your script finished and tested, copy it to the /sbin/init.d directory, then create start/stop links in /sbin/rc3.d so your script starts and stops in the right sequence. Look in /usr/share/doc for startup script information.

[twang]

Share my experience, I start oracle application on system boot using following way:
1. create script to shutdown oracle database & oracle application, and locate in /sbin/init.d
2. to start: create symbolic link on /sbin/rc3.d:
eg.
ln -s /sbin/init.d/oradb S800oradb
ln -s /sbin/init.d/oraapp S850oraapp
3. to stop: create symbolic like on /sbin/rc0.d:
eg.
ln -s /sbin/init.d/oradb K200oradb
ln -s /sbin/init.d/oraapp K150oraapp

[Laurent Laperrousaz]

Hello Bill

I think you misunderstood me.

I showed the inittab file just to mention that it is when
cons:123456:respawn:/usr/sbin/getty console console # system console

starts that my rc3 script which is attached to the system console is killed by that getty .

So my question is : how can I detach my process launched by rc3 script from the console to avoid being killed by getty ?

[Bill Hassell]

getty doesn't kill processes. If the console is open, then getty doesn't run. getty's only job is to run when the console is not open. The respawn line is what starts getty--init see the console device file is not open and starts getty. Your rc script, if it is started from the /sbin/rc3.d directory of links, should not be attached to the console but instead to stdout for start/stop scripts which is the logfile /etc/rc.log.

When you start a process in a start/stop script, the shell running the script will terminate and kill any child processes. That is why you must put nohup in front of the process (to protect the process from kill) and place the process into the background as in:

nohup /usr/contrib/bin/myprocess &

[Laurent Laperrousaz]

thank you Bill for your precisions!
But I already tried the nohup & and it doesnot change!
Maybe because myprocess is in fact forking a lot of new processes!

Laurent

[Bill Hassell]

Are the new processes being put into the background? Once you start running myprocess, which program is the parent for the subprocesses? If these subprocesses are disconnected to run independently, then they must also be protected from the shell's timeout (and accidental termination too) with nohup. Use ps to see the hierarchy as in:

UNIX95= ps -efH

This will show the parent-child relationship of all processes.