hi Goshawk, This is Jacobo221. I read from the #splashy@freenode IRC log that you are interested in knowing how splashy-init does its &quot;magic&quot; (when it works hehe). I am writing a quick but deep explanation for you. If there is any part which you'd like to know more about, i'll be pleased to write you about it.

---- First, notice that the README file in the scripts/ directory explains all the details about configuring splashy-init. splashy-init is a normal service that will be run by rc or rcS during boot/reboot/shutdown/runlevel-switch.

modes other than &quot;start&quot; and &quot;stop&quot; won't be explaied here since they are pretty easy and non-tricky, so nothing to explain really. Of course, it is LSB complaint (mostly, though in some aspects it cannot be made compatible due to some LSB restrictions which cannot be applied here). It will use LSB functions if LSB is installed. if it is not, it will emulate the LSB functions with builtin functions which provide similar (if not the same) functionality. This is to avoid adding LSB as a dependency to splashy.

When splashy-init starts it tries to determine what runlevel it is going to and what runlevel it is on, if it is being run as an init (rc/rcS) script or by hand by the user, if it is supposed to start or stop splashy, etc. it set s some variables according to these values. It will refuse to start if runlevel is 1 or if another splashy-init is running.

then it will check all the configuration settings. if any setting is incorrect, it will stop. unset settings wil be set to their default values. inmediately after it will try to start splashy. this is only an attempt. if this attempt fails, splashy-init will go on normaly as if it hadn't tried. this is because at boot time, splashy-init might be run before /proc or /dev are mounted. In this case splashy could not be run because /dev/fb0 is not accessible. so, in case it can, it will start splashy inmediately, but if it cannot, it will try again later.

next it will call itself (splashy-init) to background itself. that is, it will enter daemon mode. the caller splashy-init will exit so that the rc/rcS scripts can keep calling the rest of the services. the backgrounded dameon splashy-init will start. first it will make absolutely sure that it hsan't been called directly by a user running &quot;splashy-init daemon&quot; explicitly. In other words, it makes sure that it has been called from another splashy-init process. if it wasn't, it will exit.

next it will check if splashy was successfully started from the caller splashy-init. if it wasn't, it will try to start it now. before starting splashy it will check that the console and the framebuffer devices are available and that the proc filesystem is mounted. if any of them isn't, it will wait until it is. It will wait indefinitely for proc since it is supposed to be mounted on any linux system, while for the fb and the console devices it will timeout if they take too long to be available. if it timesout, it will exit.

after starting splashy it will explicitly check that it has been successfully started since that is the key part. next it will initialize progress variables (only if the installed theme has a progress bar) and set up the signals trapping.

up to now all this is done in few deciseconds. now comes the main loop. this is very tricky so i'll just sum it up: splashy-init will now check the runlevel it is going to and get the list of scriptnames that will be executed. it will generate an index out of the list.

from now on it will now go checking the running processes' complete command names to find init scripts. when it finds one, it will check the index and see in what step of the runlevel change that script is being called. it wil then update the progress in splashy through the fifo (actually, through splashy_update). if the progress number is the same as the last sent, it will not call splashy_update. of course, all the progress stuff is skipped if the isntalled theme doesn't have a progress bar. when it detects that the last script is being executed it will complete the bar and exit.

some init scirpts are executed when splashy should have already been completed. for example, any service running after gdm or kdm. in such case, when splashy-init sees that a service is being run and that it it is run after gdm/kdm/etc it will also complete the bar and exit.

if at any moment it cannot detect the running service, it will determine if that is because init has stopped running rc/rcS. if it has, it will complete the bar and exit. otherwise it will keep looping. when completing the bar, unless otherwise set in the settings, it will detect if X is running and, if so, in which console and switch there.

---- as you can see, i avoided the details, but went through a complete description with the code in front of my eyes to follow up. i hope this can help you to understand how it works. Anyway, the code is quite commented explaining almost every single line so it should be easy to go into details seeing the code now that you should get the general idea quite well (if i did well in this task, that is).

<br><br>i'm CC-ing this to splashy-devel so anyone can check this in the future.<br><br>greets!<br>