I want to run one of my startup script S21mystartup.scr in rc3.d directory so it boots with the system, however, can i do this as other than root? Don't want it to run as root. how can i get this to go as another user?

You may be able to call the actual executables within the script using "su". You can specify which user to run each executable.

I am somewhat curious as to what advantage you would gain from this configuration. Are you wanting to be able to restart the script after the box is up in case of trouble?

From what I can tell on my HPUX system, my /sbin/rc3.d directory has read and exe for all of the startup scripts there.

Now that I look closer, I believe that you would actually exe the script from/sbin/init.d/myscript, and not from startup script directory /sbin/rc3.d/myscript. You can use the myscript stop; myscript start functionality from /sbin/init.d. Most likely, you should already be able to exe the scripts from there if the permissions are at least 755.

However, I don't see any advantages/disadvantages of having it owned by a non-root user. I think it is entirely possible that you can do this, but I don't see any gain by this configuration.

Maybe you can elaborate on your situation.

__________________
My brain is your brain

We have a configuration tool, and I've been told i can't bring up the license manager or that database in the initial startup scripts as root since it won't allow others to modify files checked in and out, i haven't foudn this to be true yet, but one of our other sites says this happens. So was wondering if i could set it to start up as another user. so could i set up my startup script like this:
start:

su otheruser
myscript



:
end

What you need to do to write a script to be run to bring up the tool. Then the startup script will do:
su whoever -c /path/to/true.startup.script

changing the script to say su -c .... worked! Thanks, so simple, and I didn't even think about it, thanks for the help!

As far as the question of advantages/disadvantages of having a process started up as non-root, many times the different SQL processes start as either root or as their own user (Sybase or Oracle). The Sybase folks (half of them) know that they don't need root to run and set up their scripts with a su to the sybase user. Oracle folks almost always do this. Our other Sybase folks like to run Sybase from root - then they need root to work on their servers. This was started because someone many years ago didn't care about security - just wanted to get things working. Although it's been proven and implemented on some servers to remove the root/Sybase connection, getting it pushed across all servers is a hassle.

There is no disadvantage to my knowledge but the advantage is not having another process that could be hacked and leave someone with root on a server.