Your search query "linkto:"SplashIntegration"" didn't return any results. Please change some terms and refer to HelpOnSearching for more information.
(!) Consider performing a full-text search with your search terms.

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This specification proposes that a way of communicating between Upstart and splash screen programs such as Usplash and Splashy be developed. It discusses the various ways that this could be done.


Currently we run the existing Sysvinit scripts using Upstart. This is fine because the scripts can update the splash screen themselves as they always did. However, now that Feisty and also Frugalware Linux 0.7 will be using a fully event-based system, there is a need for a way for job status to be communicated from Upstart to the splash program

Use cases


The scope of this specification is limited to either the creation of a program to listen to upstart events and communicate to the splash screen or the modification of the existing Upstart codebase to be able to call the splash update program itself.


There needs to be a way for information about what the boot process is doing to be passed to the splash screen. We could say "let's go put splash calls directly into the job files", however this would be bad because it would require every job to have a script section which calls the splash update program and then the program it wants to run. Also, if more jobs are added to the boot process it would start to become inaccurate.

Another possible solution would be to develop a daemon (like logd) that runs in the background and uses libupstart to listen for events and calculate what percentage of boot is done. This percentage could be then passed on to whatever splash program is running. This would be a more reliable solution as the percentage is dynamically worked out rather than hard-coded to the jobs. However, there would be a very slight memory waste because of there being Yet Another Daemon.

The other solution would be to integrate code into Upstart itself to do the same functionality as the above way proposes, however this would significantly increase the Upstart codebase to contain functionality that a lot of distros do not even use.



Either the Upstart codebase would have to be modified in several places or a new daemon would have to be written using libupstart

Data preservation and migration

These changes are backwards-compatible.

Unresolved issues