Help required with inittab mechanism on Solaris 11

[David Elliston]

Hi

we have an application running on Solaris 11 which uses /etc/inittab entries to spawn and maintain a number of daemon processes. I know that use of /etc/inittab is deprecated in Solaris 11 but at the moment we would prefer not to have to modify our software to use SMF. However saying that we have hit an issue which may force our hand....

We have inittab entries which look like this:

app1:34:respawn: su - appuser -c "exec /APP/myDaemon.sh >> /APP/myDaemon.log 2>&1" > /dev/null 2>&1 0<&1

When init state 3 is entered we see *two* processes associated with myDaemon:

# uname -a
SunOS host40054 5.11 11.0 sun4v sparc sun4v

# ps -Af |grep myDa
appuser 21383 21380 0 19:26:58 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log
root 21380 1 0 19:26:58 ? 0:00 su - appuser -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

If I drop the OS to init state 2 only the parent process is terminated:

# /usr/sbin/init 2

# ps -Af |grep myDa
appuser 21383 21380 0 19:26:58 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

leaving the daemon process still running. Returning to init state 3 we now see:

# /usr/sbin/init 3

# ps -Af |grep myDa
appuser 26997 1 0 19:30:54 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log
root 26994 1 0 19:30:54 ? 0:00 su - appuser -c exec /APP/myDaemon.sh >> /APP/myDaemon.log
appuser 21383 1 0 19:26:58 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

So now we've ended up with two daemon processes running (not what we want).

If I compare with Solaris 10 and earlier, the inittab works very well for us. We only ever see the single daemon process running and this is dropped and respawned as required.

# uname -a
SunOS host40041 5.10 Generic_147440-04 sun4u sparc SUNW,Sun-Fire-V210

# ps -Af | grep myD
appuser 2390 27941 0 19:38:21 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

# /usr/sbin/init 2

# ps -Af | grep myD
root 2665 1187 0 19:39:19 pts/1 0:00 grep myD

# /usr/sbin/init 3

# ps -Af | grep myD
appuser 2795 27941 0 19:39:30 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

With Solaris 11 it's as if the su shell process has been made explicit and now the mechnanism, as far as we are concerned, is broken.

Can anyone suggest a way to get back to the Solaris 10 way of working, or some kind of workaround for this issue, before we have to dust off our XML skills and wrestle with SMF.

Many thanks
Dave.

[Andreas F. Borchert]

On 2012-05-14, David Elliston <david.e...@gmail.com> wrote:
> we have an application running on Solaris 11 which uses /etc/inittab entries to spawn and maintain a number of daemon processes. I know that use of /etc/inittab is deprecated in Solaris 11 but at the moment we would prefer not to have to modify our software to use SMF. However saying that we have hit an issue which may force our hand....
>
> We have inittab entries which look like this:
>
> app1:34:respawn: su - appuser -c "exec /APP/myDaemon.sh >> /APP/myDaemon.log 2>&1" > /dev/null 2>&1 0<&1
>
> When init state 3 is entered we see *two* processes associated with myDaemon:
>
> # uname -a
> SunOS host40054 5.11 11.0 sun4v sparc sun4v
>
> # ps -Af |grep myDa
> appuser 21383 21380 0 19:26:58 ? 0:00 -ksh -c exec /APP/myDaemon.sh >> /APP/myDaemon.log
> root 21380 1 0 19:26:58 ? 0:00 su - appuser -c exec /APP/myDaemon.sh >> /APP/myDaemon.log

This behaviour of "su" appears to be different from that in Solaris 10
which directly exec()s into the shell executing the given command
instead of delegating this to a fork()ed subprocess. Once you have the
latter, the inittab line no longer works as intended. Whether "su"
forks or subprocess or not was never well specified. Hence you are
relying on something which has apparently changed.

If you insist on putting something into /etc/inittab (what I do not
recommend) I suggest to use something with a well-defined semantics
that guarantees you that you do not get any additional processes
you do not want. You'll get that using Perl which is shipped with
Solaris 11. Just have a Perl script that falls down to the privileges
of appuser, and which then exec's to the to be executed command
using

open(STDOUT, ">>/APP/myDaemon.log");
exec {'/APP/myDaemon.sh'} '/APP/myDaemon.sh';

Andreas.

[Casper H.S. Dik]

comp.uni...@expires-on-2012-05-23.usenet.andreas-borchert.de (Andreas F. Borchert) writes:

>This behaviour of "su" appears to be different from that in Solaris 10
>which directly exec()s into the shell executing the given command
>instead of delegating this to a fork()ed subprocess. Once you have the
>latter, the inittab line no longer works as intended. Whether "su"
>forks or subprocess or not was never well specified. Hence you are
>relying on something which has apparently changed.

"su" waits until the process is terminated as it needs to generate
an audit record.

The SMF stuff doesn't have this issue and it don't care how often you fork()
and it also doesn't require su; you just specifi the proper user.

Casper

[David Elliston]

Thanks for the heads up on the possible change to su behaviour in Solaris 11; it certainly would fit the symptoms I've been seeing.

I tried using a perl script as suggested but setting the uid/gid was not enough for some of our daemon processes which perform Oracle logins using /. I think this would have been sufficient for simpler daemons which just need a certain set of effective permissions.

I have had some luck replacing su with sudo. If I use an inittab entry like this:

app1:34:respawn:sudo -u appuser -s "/APP/inittabWrapper.sh /APP/myDaemon.sh" >> /APP/myDaemon.log 2>&1

where inittabWrapper.sh is simply:

#!/bin/ksh
. ~/.profile
exec $1

I still get two processes but now they both adhere to the changes in init state correctly, and if the child process dies init will respawn it as we would expect. Not sure I can explain why this works better than su and more testing is required but it looks promising at the moment.

Regards
Dave.

[YTC#1]

Would it not have been quicker by now to use SMF as suggested ?

You are trying to use deprecated facilities. You will probably find
setting up and SMF service far easier than you think. Just select one
that is similar and use that.

Or use the tool recently posted in the SMF thread (which I thought I had
book marked......)



--
Bruce Porter
"The internet is a huge and diverse community but mainly friendly"
http://blog.maui.co.uk/index.php/ytc/
There *is* an alternative! http://www.openoffice.org/

[Chris Ridd]

On 2012-05-17 09:27:17 +0000, YTC#1 said:

> Would it not have been quicker by now to use SMF as suggested ?
>
> You are trying to use deprecated facilities. You will probably find
> setting up and SMF service far easier than you think. Just select one
> that is similar and use that.
>
> Or use the tool recently posted in the SMF thread (which I thought I
> had book marked......)

manifold - <http://code.google.com/p/manifold/>

--
Chris

[Casper H.S. Dik]

And the additional features offered by SMF:

- restart when the service dies for whatever reason
- can start it as any user with whatever privileges you need
or hardly any privileges at all.
- easy way to enable/disable/restart it

It is a small investment.

Casper