This is a draft document, and describes a version of Upstart that hasn't been written yet |
Writing a Service
Services (and tasks) are defined in the /etc/init directory, and may be categorised into sub-directories if desired. The name of the service is taken from the filename, including any sub-directory path: thus "/etc/init/walld" defines the "walld" service, while "/etc/init/net/wpa" defines the "net/wpa" service.
The format of these files is plain text, and as with most Linux configuration files, comments begin with the # character and continue until the end of the line. Other than comments, each line begins with a keyword, which may have zero or more arguments. Any amount of whitespace is permitted before, after and between keywords and their arguments; to preserve whitespace (including newlines) within arguments, they may be quoted individually with a \ or the entire argument surrounded in single or double quotes.
Enough technicalities, let us define the simplest service that we can. We'll create an /etc/init/sleep file with the following content:
exec /bin/sleep inf
When we save the file, Upstart will automatically load the new service definition and (because it has no state definition) will appear in the service list straight away but not be started. We can verify this:
# initctl list | grep sleep sleep (stop) stopped
We can start the service, the binary named after the exec keyword is run with the specified arguments:
# start sleep sleep (start) running, pid 5412 # ps -p 5412 PID TTY TIME CMD 5412 ? 00:00:00 /bin/sleep inf
And we can stop the service, which will send it the TERM signal.
# stop sleep sleep (stop) stopped
That's pretty much as hard as it gets, obviously there are many more keywords that you can use in the definition for real world examples. To illustrate, we'll also write a service definition for the D-Bus daemon, starting with:
Obviously it wasn't a real world example, but we could have put `exec /usr/sbin/sshd` and the chances are it would have done the right thing. Upstart will consider the service running as long as at least one process is still running, there's no need to worry about options to remain in the foreground or fork into the background, the process can be supervised either way.
== Environment ==
When you start a service, you may pass environment variables on the command line which are set in the environment of the processes run for that service. For example, if you were to start the `sleep` service like this:
{{{
# start sleep TIME=5Then you could use $TIME in the service definition, e.g.:
exec /bin/sleep $TIME
You can also set environment variables in the definition directly using the env stanza. These are overridden by that passed with start, so this is also a useful way to set default values.
env TIME=inf exec /bin/sleep $TIME