1

I need some education about the init.d system on Linux (Ubuntu 12.04, 64 bit, in my case), I have found hundreds of sites (no I didn't look at them all, but I did read some of them) that tell me how to write an init.d script and how to create the symlink in /etc/rc2.d. I still come up a little short on understanding and the ability to craft Google queries that can get me the answers I need. So,

I know my init.d script launches. I have it echo log messages into a file, thus I know it is running e.g. before any user's .profile has run. Question is, what is the nature of the environment where it is executing. What happens to the output sent to STDOUT? Does it write to a virtual terminal somewhere? Does it effect anything?

The "program" I actually want to launch from the init.d script is a shell scrip, my_shell_script, wrapped around my real program, my_program. The script sets up a bunch of environment variables including the PATH and LD_LIBRARY_PATH, then launches my_program.

Should I modify the line that launches my_program to redirect its outputs to /dev/null? Ditto STDERR? Should the launch line have a NULL <1 (or is it NULL <&1 ?) so STDIN gets disconnected?

In my init.d script, when I want to start the shell script, what is the proper way to call it?

my_shell_script

or

. my_shell_script

or

sh my_shell_script

and should I use sh or bash. I guess use the one necessary to make the script function? i.e. bash if there is non-sh bash in there?

When the init.d script tries to launch my_shell_script does it need to do the same redirection on STDIN, STDERR and STDOUT?

Now, my_program was originally developed as a terminal launched program with one graphical window. The main program launches the graphical window, then launches two xterms with separate programs running in them (I have no idea why, I inherited it.) All three programs run forever, but are not daemons: just infinite loops. The main program watches to make sure the other two are running and will relaunch them if they do happen to stop.

Should the progra,s I launch be daemons? Or are non-terminating applications ok? In the launch line in my_shell_script rmd with a & so the script can continue past the launch and return to the init.d script?

my_program, detects that the graphical window could/did not launch (so I could telnet/ssh into the server where it runs and (re)launch it). If it didn't run a GUI window, it launches the other two daughter programs in the same terminal (telnet) window and all the graphical output is sent as non-graphical text output to that terminal and log files.

When I would ssh/telnet into my development server the .profile would run, The .profile contains pretty much everything my_shell_script contains except it uses the screen program to launch my_program so that the logout from the telnet/ssh session would not terminate therunning my-program. Will I need the screen program wrapped around my_program in the init.d scheme.

Will the init.d time environment look like a terminal? I assume it looks like a runlevel 1 environment and the GUI window can 't open and that "terminal" is the only output.

Finally, what is the best way to stop my running applications? Right now, when they run as user apps, i use killall's to stop them having no way to tell them to shut themselves down.

Wes Miller
  • 125
  • 5

1 Answers1

2
http://upstart.ubuntu.com/cookbook/

Upstart is the Ubuntu init system. The cookbook should be helpful.

If you want to connect to terminal started from init system you most likily want to give tmux a try.

rhasti
  • 477
  • 3
  • 9
  • really the same questions will aply. What can I launch: daemons or apps? How to launch an app? With a &? Etc. etc. – Wes Miller Dec 21 '12 at 20:31
  • [run-a-java-application](http://upstart.ubuntu.com/cookbook/#run-a-java-application) is an example how to start an application. you could create upstart script in /etc/init.d exec tmux new-session -d "/bin/sh /path/to/my_shell_script" – rhasti Dec 21 '12 at 20:41
  • I read part of the http://upstart.ubuntu.com/cookbook/ stuff and elected not to use it this time because time is short and I was so tired i couldn't completely follow the discussion. – Wes Miller Dec 21 '12 at 20:44
  • np. you should checkout tmux then. its like a window manager for your terminal. you can have a session running even if you are not logged in into your server. its very useful for working in development environment – rhasti Dec 21 '12 at 20:59