I want to delegate SysV init scripts to each user.

Like the SysV init, each item in ${HOME}/rc.d starting with S will be launched on server start-up with the start argument. The same for the server shut-down with the one starting with K and with the stop argument.

I thought about scripting it myself, but maybe there is already some kind of implementation out there1. In summary it would be a script in /etc/init.d/ that iterates through all the users and launches runparts as the user on the relevant scripts.

The platform here is a Linux (Debian flavour), but I think the solution would be quite portable among various Unix-like platforms.


The point here is for users to be able to create their own init scripts that should be launch on their behalf when the system boots up. As Dan Carley pointed out, the services won't be able to access any system asset (priviledged ports, system logs, ...).

1. This way I don't have to think that much about all the subtle security implications such as script timeouts for example...

  • 2
    Why do you want to do this? – Dennis Williamson Nov 10 '09 at 14:16
  • Some services are managed by users (start/stop/installation/...). I don't want to give them root access, but I don't want to force them to relaunch manually each servers after a reboot (or spawning a new node) either. – Steve Schnepp Nov 10 '09 at 15:15

Your question basically includes the answer.... A script that'll iterate through a subdir of each users home, looking for executable scripts. Then it sudo -u user /export/home/user/scripts/scriptname.sh start. You'll have no control over what the scripts do, so you`ll need to trust your users.

Insist that they write their scripts to accept stop start restart as $1 param and that they shouldn't use any environment variables that have been set up in their .profile, .cshrc or .bashrc files. The script effectively needs to be standalone.


run_cmd {
cd /export/home
for HOMEDIR in *; do
  for SCRIPT in /export/home/$HOMEDIR/scripts/*;  do
     if [ -x $SCRIPT ]; then
       echo "$ACTION user $HOMEDIR's script $SCRIPT"
       sudo -u $HOMEDIR $SCRIPT $ACTION &


case $1 in
    start) ACTION=start;
    stop) ACTION=stop;
    restart) ACTION=stop;
             sleep 60;
    *) echo "$1 not recognized as valid cmd";;

exit 0

You'll need to tweak this for your environment, location of bash/homedirs etc.

  • Yup, what I was really wondering is : does such an implementation already exists ? – Steve Schnepp Nov 10 '09 at 16:45
  • +1: for a ready-to-use script that does the job. – Steve Schnepp Nov 10 '09 at 16:49
  • If you aren't a roll your own kinda guy. Take your pick from this list. en.wikipedia.org/wiki/Job_scheduler Automan & Control-M are the two biggies i'm familiar with, but they're not bullet proof. They also may not have the user friendly ability to just drop a script somewhere in your own homedir. – Michael Henry Nov 10 '09 at 17:00
  • Actually I don't really need a job scheduler (I'm happy with cron for that), just an autoexec.bat-like fonctionality, but designed for users and not for the whole system. – Steve Schnepp Nov 10 '09 at 17:24
  • The point was that the job scheduler like Control-M can ensure all the processes start at boot running as the user who created the script. Using their batch discovery plugin, it could in theory discover scripts it had to ensure were running all the time. – Michael Henry Nov 10 '09 at 17:28

The point here is for users to be able to create their own init scripts that should be launch on their behalf when the system boots up.

This is already possible on most systems, using the cron utility. Simply instruct your users to do the following:

  1. run the command crontab -e
  2. add a line like the following:

    @reboot /home/user/script argument

  3. save

More info: http://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/

  • 1
    While yours is a nice less-known crontab feature, Michael Henry's answer gets the fact right, in that it was all about "delegate SysV init scripts to each user" : no rewrite is needed. – Steve Schnepp Nov 27 '12 at 13:48

I'm not quite sure of what you want to achieve, but to me, it sounds a bit similar to .profile and .bash_logout, which are executed when a user starts a shell, or exits a shell.

The difference with your solution is that the scripts are run when a user login, or start a new shell and not when the computer starts up. But I have to admit i would not feel comftable to let any users run scripts on startup ...

  • You got the point (start when a computer starts up). I don't really care about the scripts going crazy since right now they already autorun the script via a user cron entry that checks and starts if needed. – Steve Schnepp Nov 10 '09 at 15:18

You construction sounds like the makings of a nightmare :)

Just give your users sudo access to the existing init scripts as required.

  • How would you do that ? I need that users are able to create & edit scripts without me involved at all. – Steve Schnepp Nov 10 '09 at 15:37
  • It's not quite clear from the question that users are going to write their own init scripts. If that is the case, are you anticipating them all running as non-privileged users? ie. No binding to port <1024 or opening system log files. – Dan Carley Nov 10 '09 at 15:40
  • Yes. Sorry about it not being clear. I'll update my question for clarification. – Steve Schnepp Nov 10 '09 at 15:56

I would be inclined to disallow scripts and enforce a very strict short list of canned scripts and commands that a user can reference in a simple list file that can easily be validated at boot time. The canned scripts would be stored in a common place without user write permissions. The list file would name the script or command and any arguments required. One of these common scripts would provide the user with stop/start/restart processing if it is needed after they have logged in.

The reason for all this paranoia is partly due to security, but more about control of what goes on during startup. I mean can you imagine what kind of a nightmare it would be if your users get carried away with starting up all manner of stuff all at the same time "just because they can"? Not to mention poorly written scripts.

Otherwise, if you can find a ready-made solution that addresses these issues (which is one criteria you mention in your question), that would be the way to go.

  • I do understand your point, but since I have very cooperative users, the paranoid route is a little overkill. I just don't want to give away root access (and actually they don't want it either). – Steve Schnepp Nov 11 '09 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.