Can't start background processes from /etc/inittab in AIX 5.3

[Wolfram Roesler]

Hi,

I have an AIX 5.3 machine which has a peculiar problem: All background
processes I start from /etc/inittab are immediately terminated and
don't run anymore by the time I can log into the machine. I have,
for instance, once inittab entry like this:

myrc:2:wait:ksh /myfiles/myrc.ksh </dev/null >/tmp/myrc.out 2>&1

The myrc.ksh starts a program which is supposed to run in the
background (started via nohup). By the time I can log on, however,
I can see in my program's log files that it has been started but
terminated with SIGTERM almost immediately. When I type "ksh
/myfiles/myrc.ksh" manually everything works fine, and the
background program keeps running.

Also, I installed Oracle 10g on the machine which is supposed to
be started during reboot via inittab. Same thing here: It seems
to start up, but when I log on, no Oracle processes are running
any more. Starting Oracle manually works fine.

Did anyone encounter similar problems? Any known cure?

oslevel prints 5.3.0.0.

Thanks for any help
W. Rösler

[aix...@yahoo.com]

Oracle 10g on AIX 5.3ML2 on p5 520 starts fine for us.
Here are our /etc/inittab entries:

orapw:2:wait:/etc/loadext -L /etc
oracle:2:wait:/bin/su - oracle -c /u01/app/oracle/OraHome_1/bin/dbstart
oracle:2:wait:/bin/su - oracle -c /u01/app/oracle/OraHome_1/bin/lsnrctl
start
oracle:2:wait:/bin/su - oracle -c
/u01/app/oracle/OraHome_2/opmn/bin/opmnctl startall
oracle:2:wait:/bin/su - oracle -c
/u01/app/oracle/OraHome_1/bin/searchctl start
oracle:2:wait:/bin/su - oracle -c
/u01/app/oracle/OraHome_1/bin/isqlplusctl start

[aix...@yahoo.com]

sorry for the formatting mess (thanks Google)
of course each line starts with oracle:

[sa]

Is your script entry in inittab before or after the rc entry? Maybe not
all of your file systems are mounted at that point? Try moving your
script to /etc/rc.d/rc2.d - IMHO, this is where all non-system-level
customization belongs.

Alex.

[Wolfram Roesler]

aix...@yahoo.com wrote in
news:1120139828....@z14g2000cwz.googlegroups.com:

> orapw:2:wait:/etc/loadext -L /etc
> oracle:2:wait:/bin/su - oracle -c /u01/app/oracle/OraHome_1/bin/dbstart
> oracle:2:wait:/bin/su - oracle -c /u01/app/oracle/OraHome_1/bin/lsnrctl
start

I have these too, plus the following which I suppose has something
to do with Oracle:

h1:2:respawn:/etc/init.cssd run >/dev/null 2>&1 </dev/null

Yet it doesn't work. Does anyone know what the h1 entry is good for?

Regards
Wolfram

[aix...@yahoo.com]

We have the init.cssd commented out of /etc/inittab
Cluster support daemon

Please post your inittab for us to view

[Nathan]

Wolfram Roesler wrote:

This is part of PSSP / SP Switch (css should be the give away).

> Regards
> Wolfram

You might consider a ML update, the base 5.3 level has a fair number of
bugs resolved in ML01 at the very least (ML02 is out now). Also, you
could try putting those entries towards the bottom if they are not
already. Just a couple of ideas.

-Nathan

[aix...@yahoo.com]

CSSD daemon has nothing to do with PSSP

CSSD daemon is the daemon that controls communications between your
database instance and the Oracle ASM instance.

Unless you are using Oracle RAC or Oracle ASM you can comment out the
line. We have done this and it works.

[Nathan]

Doh! Served!

[Wolfram Roesler]

"sa" <sysad...@gmail.com> wrote in news:1120141054.785110.129190
@g49g2000cwa.googlegroups.com:

Thanks a lot, that was a great hint. I'm running myrc.ksh from
/etc/rc.d/rc2.d/S01-myrc now, and the background process works
flawlessly!

BTW, my entry was at the very end of the inittab, and all my file
systems were mounted already (my script was on one of them), so
that was not the problem.

Oracle still doesn't however. I'll investigate further.

Thanks again, and best regards
Wolfram

[Wolfram Roesler]

Wolfram Roesler <w...@spam.la> wrote in news:Xns96866D8F834A7wrgrpde@
62.153.159.134:

> Thanks a lot, that was a great hint. I'm running myrc.ksh from
> /etc/rc.d/rc2.d/S01-myrc now, and the background process works
> flawlessly!

There's still another question. I created K02-oracle to have
Oracle be shut down when shutting down the machine. Now, it looks
like K02-oracle is executed during startup as well! This is
not the reason for my Oracle problems, but the question is,
is it intended to work that way? I thought the S files were
supposed to be run on startup and the K files on shutdown
only?

Thanks
Wolfram

[sa]

Not really. ALL scripts for a certain level will be run, K-scripts
first, then S-scripts. But K-scripts will be given "stop" as a
parameter, S-scripts will be given "start". Besides, often both K- and
S- scripts are links to the same script that starts or stops a service
depending on the parameter.

That was originally system V functionality which IBM adopted, I think,
in AIX 4.3. System V was doing it via /etc/init (or /sbin/init) and AIX
is doing that via inittab entries l2 - l9. They all invoke /etc/rc.d/rc
with the run level as a parameter. Check this script out and you'll see
for yourself.

HTH,
Alex.

[Wolfram Roesler]

"sa" <sysad...@gmail.com> wrote in news:1120219437.412907.49690
@g44g2000cwa.googlegroups.com:

> Not really. ALL scripts for a certain level will be run, K-scripts
> first, then S-scripts. But K-scripts will be given "stop" as a
> parameter, S-scripts will be given "start". Besides, often both K- and
> S- scripts are links to the same script that starts or stops a service
> depending on the parameter.

I see. So, there's no way for the scripts to find out whether the
is system is currently going up or down?

Thanks
Wolfram

[Wolfram Roesler]

Nathan <nat...@nospam.org> wrote in news:da1253$dgm$1
@rainier.uits.indiana.edu:

> You might consider a ML update, the base 5.3 level has a fair number of
> bugs resolved in ML01 at the very least (ML02 is out now). Also, you
> could try putting those entries towards the bottom if they are not
> already. Just a couple of ideas.

How can I find out the current ML level?

The machine was bought and configured by a third company for our
customer who shipped it here to have it equipped with our software.
How can I get hold of an ML update?

Thanks
Wolfram

[sa]

On a system V there would be /etc/rc.d/rc0.d directory where you would
put your shutdown custom scripts. For some reason, IBM chose to skip on
that. On AIX you should create/modify /etc/rc.shutdown script to stop
services when your system is going down. Be aware your script MUST
return 0 if run from /etc/rc.shutdown or shutdown will stop. See man
shutdown for details.

HTH,
Alex.

[Wolfram Roesler]

Wolfram Roesler <w...@spam.la> wrote in news:Xns96866D8F834A7wrgrpde@
62.153.159.134:

> Thanks a lot, that was a great hint. I'm running myrc.ksh from

> /etc/rc.d/rc2.d/S01-myrc now, and the background process works
> flawlessly!

Oops, sorry, I've been looking in the wrong place it seems. It still
doesn't work. Oracle support has given up on this problem and is
suggesting to call IBM for help.

Did anybody ever see the same problem?

Thanks
Wolfram

[a...@mail.com]

its probably got something to do with environment variables that are
not sourced when your script runs from inittab, but they are part of
your profile or something like that which is sourced on normal login.
try sourcing your profile from within your script.

[aix...@yahoo.com]

oslevel -r

[aix...@yahoo.com]

Oops, sorry, I've been looking in the wrong place it seems. It still
doesn't work. Oracle support has given up on this problem and is
suggesting to call IBM for help.

Did anybody ever see the same problem?

Thanks
Wolfram

Check out info at the following link:

http://www.dbazine.com/olc/olc-articles/ault4

[Wolfram Roesler]

aix...@yahoo.com wrote in
news:1120228304.2...@g49g2000cwa.googlegroups.com:

> oslevel -r

This prints 5300-02. So, am I running at the latest level ML02
already?

Thanks
Wolfram

[Wolfram Roesler]

a...@mail.com wrote in news:1120226541.081041.250740
@g47g2000cwa.googlegroups.com:

I'm doing that already ... the program starts fine (from both inittab
and rc.d) but is SIGTERMed immediately thereafter.

Thanks
Wolfram

[Wolfram Roesler]

aix...@yahoo.com wrote in news:1120228402.158099.181230
@g44g2000cwa.googlegroups.com:

> http://www.dbazine.com/olc/olc-articles/ault4

Thanks, I tried that already, with no success. The article seems
a bit outdated since it doesn't mention that rc.d can be used
in AIX too, but then neither does Oracle's own documentation.

Thanks
Wolfram

[aix...@yahoo.com]

Also keep in mind how inittab works.

the "command" field portion of your inittab entry is prefixed with
"exec" and passed to a forked "sh" as
"sh -c exec command" (Bourne shell)

If by chance your script has been programmed for Korn shell, but you
did not specify this in the script itself,
unintended things could/might happen.

[Jurjen Oskam]

On 2005-06-30, Wolfram Roesler <w...@spam.la> wrote:

> myrc:2:wait:ksh /myfiles/myrc.ksh </dev/null >/tmp/myrc.out 2>&1
>
> The myrc.ksh starts a program which is supposed to run in the
> background (started via nohup).

Why do you use "wait" when the program is intended to run forever?
Try something like this:

myrc:2:respawn:/myfiles/myrc.ksh >/tmp/myrc.out 2>&1

where myrc.ksh is something like this (don't forget the x-bit):

#!/bin/ksh

print -- "do stuff"
exec /path/to/long/running/program

The "exec" causes the background program to replace the ksh instance.

--
Jurjen Oskam

[Wolfram Roesler]

Jurjen Oskam <jos...@quadpro.stupendous.org> wrote in
news:slrndcb171...@calvin.stupendous.org:

>> myrc:2:wait:ksh /myfiles/myrc.ksh </dev/null >/tmp/myrc.out 2>&1
>>
>> The myrc.ksh starts a program which is supposed to run in the
>> background (started via nohup).
>
> Why do you use "wait" when the program is intended to run forever?

The myrc.ksh file is intended to bring the program up only, the actual
background process is invoked from myrc.ksh. myrc.ksh must be run only
once (it does other things besides running the background process,
like clean up temp files, which must not happen during normal
operation).

> Try something like this:
>
> myrc:2:respawn:/myfiles/myrc.ksh >/tmp/myrc.out 2>&1

Did that too already, with the same result ...

Thanks for your help
Wolfram