sbin/init.d

[Andi Rigauer]

Hi Experts,

how can I start a process by the sbin/init.d with an other user than root ?

thanks in Advance

[Tom Geudens]

Hi,
That would not be advisable (if at all posible). However, it is "accepted behavior" :-) to do an "su -" inside the script. For example the standard oracle database startup script would do something like :
...
# Execute the commands to start your subsystem
echo "Starting databases ..."
su - oracle -c dbstart
...

Most softwares work this way ...

Hope this helps,
Tom Geudens

[Robert Gamble]

inside the script being run by root, you can do:

su -c $USER /foo/foo.sh > /foo/foo.out

Good Luck!

[Helen French]

Hi,

The permissions for the directory /sbin/init.d has been set to meet the system security. If you want another user to stop/start some process, you can copy that specific script to the user home directory ( eg: 'dbora' file in the Oracle $HOME directory).

HTH,
Shiju

[A. Clay Stephenson · Accepted solution]

Hi:

Your question is not clear. If the question is can you manually run an sbin/init.d script as a regular user then the answer is that depends entirely upon the permissions of the underlying commands. If you want to run an /sbin/init.d/ automatically as another user then you need to use the su command. e.g. su oracle -c "/u01/oracle/bin/orastart.sh". DO NOT USE su - -c "/u01/ ... " because the "-" option will run oracle's .profile. I know you think that is a good thing but the problem is that many of the commands assume an interactive user (tset, tabs) and under rc there will not be one. The correct way to do this is to create a file (e.g. /usr/local/bin/oraenv.sh) and do all the environment vars and PATHS stuff there. You then source that file as both part of your startup file AND as user oracle's .profile. Do it like this:

. /usr/local/bin/oraenv.sh (do not put an exit statement in the sourced file). The '.' causes the shell to include this file as part of the current shell.

[Mark Vollmers]

Andi-

The permissions dictate who can run the command. Not the permissions on the file in init.d, but the ones on the script itself (for example, sendmail is in /usr/sbin). You can change these to give any user access to run it, but I'd be careful. Normally, you don't want users to be able to start and stop these processes.

Mark