Inittab command as diferent user

[Victor Pavon]

I have a line in inittab as this:
dcam:2:once:su - aimadm2 -c "/pvh/aim/20051/decam/decam"

The machine reboots on Sun @ 1PM and I see one entry on the sulog that looks like this:
SU 01/17 13:10 + tty?? root-aimadm2

I need to make sure the dcam process is re-spawn if it dies, so I changed the inittab to look like:
dcam:2:respawn:su - aimadm2 -c "/pvh/aim/20051/decam/decam"

The issue with this is that it logs the SU attempt to the sulog several (11) times every minute, causing sulog to fill up with unecessary data (and my security audit to be on my case)
...
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
SU 01/20 17:03 + tty?? root-aimadm2
...

I'm assuming this is normall behavior, so my question is there any way to eliminate su logs from init for processes that are in normal running mode?

[Johnson Punniyalingam]

>>so my question is there any way to eliminate su logs from init for processes that are in normal running mode?<<<<

su logs has mentioned earlier that its normal behaviour that it records every entry automatically to keep an record how many times root had switch user to run the said job.

so I believe its the nature of the "su logs"
wish if you could house keep the "su logs"

[Keith Bryson]

I suppose this may be a silly question, but couldn't you just script this respawn-process and place as a cron entry for the aimadm2 user, rather than using init?

All the best

[Matti_Kurkela · Accepted solution]

Write a small script to re-spawn dcam if necessary, and start *that* script using su, so su gets executed only once:

su - aimadm2 -c /usr/local/bin/decam-keeper.sh

Contents of /usr/local/bin/decam-keeper.sh:
-----
#!/bin/sh
LOGFILE=/var/adm/decam-keeper.log
RESTARTDELAY=15

# get rid of input, re-direct output and erros to our logfile
exec $LOGFILE 2>&1

while true #infinite loop
do
echo "$(date): starting decam"
/pvh/aim/20051/decam/decam

# Because there is no "&" in the decam command line,
# the script holds still while decam is running.

# If decam stops, the loop resumes,
# so if we get here, decam has died.

DECAMRESULT=$?
echo "$(date): decam exited with result code $DECAMRESULT"
sleep $RESTARTDELAY
# wait a while before restart so the repeated start attempts won't overload
# the system if decam just keeps dying
done
-----

Change the LOGFILE variable into whatever you wish: any output from decam to standard output will go into the LOGFILE.

The LOGFILE will look like this:

---
Thu Jan 21 14:12:56 EST 2010: starting decam

Sat Jan 23 04:13:02 EST 2010: decam exited with result code 2
Sat Jan 23 04:13:17 EST 2010: starting decam
---

In other words, the log file will allow you to determine exactly when and how often decam dies. You can use this log as justification for bugfix/update request, if necessary.

If you change the infinite loop into a smarter one, you could even create behaviors like "try restarting decam for X times, then give up if it keeps failing".

If you want to stop decam while it's being monitored by this script, kill the decam-keeper.sh script first, then stop decam.

MK

[mvpel]

Victor, the problem may be that "init" doesn't have a PATH variable, and so doesn't know where to find the "su" command. Try changing the command line to

/usr/bin/su - aimadm2 -c "/pvh...

... with the full path to the su command, and see if that helps the respawning problem.

Also, check to make sure that decam isn't running into some error that's causing it to die after only a few seconds. This issue could be exposing a problem you didn't know you had with decam itself.

[Victor Pavon]

I've figured there are several "problems" with this dcam application that needs to be addressed by the developers. The idea of using init to monitor an unstable code is not a very good one, just because we loose administrative visibility.

Johnson: We're in agreement, the su logging is behaving as design. Grepping out the init logging defeats the purpose.

Matti: I greately appreciate your time in creating the script. I will use it to push the application issue with the developers

Thank you all for such high quality responses.

[Victor Pavon]

Using the script to re-spawn the process resolves the sulog issue. Now I have something to show the developers to fix the dammed thing.
Thank you all