What is a .i file?

A .i file is a file that lets you start a service or program easily by using the ngc or ng-update commands.

Where are they located?

The .i files are located in the /etc/initng directory or subdirectories such as /etc/initng/system or /etc/initng/daemon.

Why would I want to edit or make one of these files?

Well the reason is simple what if you would like to have a program start on startup but currently there is no script for it. Or a program won't start yet there is a script so soon you will have the skills to edit and fix these files.

Notice: the file must end in .i or initng will not see it!

Basic Syntax:
# start SaTaN0rX

there are different things: daemons and services.

a service is something that is only run once and then terminates. examples
are: mount something, set the hostname, bring the network up, ...

in contrary, a daemon is a programm thats being started and runs all the time.
for example apache, cups, ...

the first thing you need to do is to figure out what you want to write:
an .i file for a service or a daemon?

SERVICES:

a service might look like this:

service system/foo {
   need = system/initial system/mountfs
   use = system/alsasound
   start = /sbin/foo
   start_args = bar baz
}

i'll explain these lines.
the first line says that this service requires system/initial and
system/mountfs to be run before it can be started.

the second line says that it should also wait for system/alsasound is also in
the current runlevel, then it should also wait for system/alsasound. but if
system/alsasound is NOT in the current runlevel,  this line would be ignored.
in contrary, if it would have said need = system/alsasound, then
system/alsasound would also have been started even if it is not in the current
runlevel.

the third line gives the program to start, in this case /sbin/foo

and the forth line, you may have guessed it, gives additional parameters that
should be passed to /sbin/foo.

ok, now can also have a service that does something on start and on shutdown.
it would look like this:

service system/foo {
   need = system/initial system/mountfs
   use = system/alsasound
   start = /sbin/foo
   start_args = bar baz
   stop = /sbin/foo
   stop_args = qux quux
}

here, the stop and stop_args lines have been added. pretty easy.
but there are situations in which you can not use some simple program, but u
need a shell script. one solution would be to write that shell script to a
file, and have a line like "start = /path/to/my/script.sh". while i would
suggest you to do that for really large scripts (>100 lines), it would be kind
an overkill to do so for a script with 5 lines of code. so initng provides a
possibility to include these scripts .i files. example:

service system/foo {
   need = system/initial system/mountfs
   use = system/alsasound
   start {
      [ -f /etc/conf.d/foo.conf ] && source /etc/conf.d/foo.conf
      [ -z "$FOO" ] & FOO="bar baz"
      /sbin/foo $FOO
   }
}

note that you could also have stop script-block that is executed on shutdown.

DAEMONS:

a basic daemon .i file might look like this:
daemon daemon/vixie-cron {
        need = system/initial system/clock system/mountfs system/bootmisc
        daemon = /usr/sbin/cron
        daemon_args = -n
}

it starts with "daemon daemon/blah {", and has a daemon = line in it.
the "daemon =" specifies the daemon executable. 

a daemon doesn't have start, start_args, stop, stop_args directives, but has a 
daemon and daemon_args directive. all other directives are the same then with
services.

initng will by default track what the daemons are doing, ie it will monitor if
a daemon crashes, etc. unfotunately, some daemons have a bad habit: forking.

when a daemon forks, it spawns a copy of itself with a new pid. then the
father process, with the old pid, dies. 

this has some advantages: if you start cron from your console, then you
instantly will see the bash prompt again. thats why most daemons fork.

unfortunately, initng has up to now no possibility to know if a daemon spawns
a child or not. initng will only notice that the father process dies, and
thinks that the daemon died.

fortunately most daemons have a commandline switch which makes them not
forking. in the case of vixie-cron it is -n. consult your daemons manpage.

in some cases, the daemon can't be prevented from forking, but it will write
the pid of the child process in a file, called the pid-file. initng can also use 
the pid file to track the daemon. an example:

daemon daemon/ntpd {
        need = system/initial system/mountfs system/mountfs net/lo
        require_network
        use = daemon/ntpdate
        daemon = /usr/sbin/ntpd
        daemon_args = -p /var/run/ntpd.pid
        pid_file = /var/run/ntpd.pid
}


this daemon WILL fork, but it will write the pid of the doughter process in
/var/run/ntpd.pid. initng can also track this daemon.

another thing you can see is the require_network directive. this will delay
the starting of this daemon until a network device is set up.

ok, what's the buzz when you need some shell script to bring up the daemon?
have a look at this example:

daemon daemon/acpid {
        need = system/mountfs system/modules
        use = system/discover system/coldplug
        daemon {


                # As the name says. If the kernel supports modules, it'll try to load
                # the ones listed in "MODULES".
                
		.....
                # Check for ACPI support on kernel side
                [ -d /proc/acpi ] || exit 0

                # Include acpid defaults if available
                OPTIONS=""
                if [ -f /etc/default/acpid ] ; then
                        . /etc/default/acpid
                fi

                [ -f /proc/modules ] && load_modules


                #for x in ac battery button fan ibm_acpi processor thermal video ; do
                #       modprobe ${x} &> /dev/null
                #done

                exec /usr/sbin/acpid -f -c /etc/acpi/events
        }
}

i've shortened this a little bit :P

as you can see you can also embedd an "daemon { script }" bash script in an .i
file. but notice the "exec blah" statement. when you write "exec blah" in an
bash script, the blah process will REPLACE the bash process, inheriting it's
pid. this is necessary, so that initng can track your service. if you use
pid_file, it is not absolutely necessary, but i'd suggest to do so.

note that if you have a daemon that neither could be prevented from forking,
nor does export a pidfile, you can write a shell script that figures out the
pid of your daemon with ps + [awk|sed|cut] and writes the pidfile. in this
case you must not use exec, cause exec will kill the bash, so your script will
stop at the exec statement.

NAMING THE .i FILE:
when you name the .i file:
initng will look for the service "daemon/something" in
"/etc/initng/daemon/smoething.i". so the exaple above has to go into
"/etc/initng/daemon/acpid.i".

DIRECTIVES:
this should give an incomplete list of the other directives not explained
above.

require_network: the start service or daemon is delayed until a network device
			other then lo is configured.

last: the start service or daemon is delayed until all services and daemons,
			which are not last, are started.

respawn: if the daemon dies, it will be restarted.

many others...

To be continued ...
