Tiny Core Extensions > TCE News

Basic init.d script example

(1/4) > >>

Jason W:
When extensions contain daemons, it is helpful to provide  an init script to allow the user to start and stop it.  /usr/local/etc/init.d/ is the standard location for extension startup script on TC.  We have the start-stop-daemon in base to make it easy to start and stop processes.  Below is an example of an init script to start and stop rpc.mountd:


--- Code: ---#!/bin/sh
# Starts and stops rpc.mountd
#


case "$1" in
start)

start-stop-daemon --start --exec /usr/local/sbin/portmap -u `id -u`
        start-stop-daemon --start --exec /usr/local/sbin/rpc.mountd

;;

stop)

start-stop-daemon --stop --exec /usr/local/sbin/rpc.mountd
;;

restart)
   $0 stop
   $0 start
;;

status)
             if pidof -o %PPID rpc.mountd > /dev/null; then
                     echo "Running"
                     exit 0
             else
                     echo "Not running"
                     exit 1
             fi
;;

*)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
esac


--- End code ---

Notice that as rpc.mountd depends on portmap already running, portmap is started by the start-stop-daemon in the rpc.mountd script.  The start-stop-daemon does not force start a process, it simply echoes "portmap already running" if it has already been started.  There are other ways to check for a pid and such, but start-stop-daemon makes it easy for most daemons.   Also, the rpc.mountd script does not stop portmap when the stop function is used since portmap may be needed by other processes.

It is my personal preference not to start processes in the /usr/local/tce.installed startup script as I don't believe that is where daemons should be started.  But a call to the init.d script can be put in the tce.installed script if the extension maker feels it is absolutely necessary to have that daemon running at all times unless the user feels the need to stop it.   Since init.d scripts can start dependent processes, and most distros use that approach, there really should not be a need to start a daemon in the tce.installed script in my opinion.  But the support for it is there if needed with the order of execution of startup scripts.

There is no push to remake extensions that use another method to fit this method, this approach can be seamlessly worked in as extensions are updated.

As always, any ideas or suggestions are welcome.

A pid approach would be like below:


--- Code: ---#!/bin/sh
# Starts and stops rpc.mountd
#


case "$1" in
start)


             if ! pidof portmap >/dev/null; then
                   /usr/local/sbin/portmap -u `id -u`
                   echo "Starting portmap..."
             else
                    echo "Portmap already running.."
             fi
             fi
             if ! pidof rpc.mountd >/dev/null; then
                    /usr/local/sbin/rpc.mountd
                    echo "Starting rpc.mountd.."
             else
                    echo "Rpc.mountd already running.."
             fi

;;

stop)

               if pidof rpc.mountd >/dev/null; then
                    killall -9 rpc.mountd  >/dev/null
                    echo "Rpc.mountd stopped.."
               else
                    echo "Rpc.mountd not running.."
               fi
;;

restart)
   $0 stop
   $0 start
;;

*)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

--- End code ---

danielibarnes:
That looks useful. Has anyone considered the use of Upstart with TC to help manage this? Debian is transitioning to it, and it looks interesting.

Jason W:
The main purpose with the init.d scripts is to simply give the user the ability to start/stop/restart processes.   To automate them, placing the command in bootlocal.sh would start on boot, while a shutdown.sh seems planned for 2.7 so that would provide basic control during startup/shutdown.  Of course, one process that simple distros (Arch, Crux) use and has been mentioned here is having a file like /etc/rc.conf that has a place to enter the init scripts' name to be ran during boot and stopped during shutdown.  

Though that approach is simple, it does add one more file to manage and back up.  Also, with some things like alsa or cups the timing of the starting of those files seems to be touchy.  Alsa needs a sleep command to work properly on some machines and I believe cups likes X to be already started (correct me Juanito if I am wrong about cups).  

With bootlocal.sh and a shutdown.sh equivalent, I am not sure we want to add more complexity, however small, or files involved to the process.  


Correction:  The first post said "There is push to remake extensions".  It meant to say "There is no push to remake extensions". 

danielibarnes:

--- Quote ---I am not sure we want to add more complexity, however small, or files involved to the process.
--- End quote ---
I agree. Perhaps an Upstart extension (or similar) could provide that complexity as an option rather than part of the base. Then, extensions which require this complexity could add it as a dependency. Using sleeps to manage timing is very touchy, and using an event-based startup could smooth that out.

Juanito:

--- Quote from: Jason W on December 02, 2009, 02:18:09 PM ---..and I believe cups likes X to be already started (correct me Juanito if I am wrong about cups).

--- End quote ---

It looks that way, but I've not yet managed to find out why.

I've added init.d scripts to a few extensions - acpid, cpufreqd, samba3 - and have already noticed that one size does not fit all, but with further testing, we should be able to refine them for tc.

Navigation

[0] Message Index

[#] Next page