opus is a new init-system/service-manager derived from my older project ginitd. It is written mostly in Python, and makes heavy use of its object-oriented and dynamic capabilities. It organises the management of services around a few simple concepts: Units (which manage services or tasks, or similar), Dependencies (which are one of the activation conditions of Units - only when all Dependencies are satisfied will a Unit activate), and Triggers (which determine when a Unit will activate, e.g. in a 'runlevel', at a specific time, or whenever it is needed!). There is also a simple extension mechanism; hooking into the service-manager's mainloop and other startup stages is very simple, and you can write your own Dependencies or Triggers (for example, a DBus-activation Dependency).
Here is an example service definition file, for the example daemon 'exampled':
import opus class exampled(opus.Daemon): unit_name = "exampled" daemon_descript = "Example Daemon" daemon_cmdline = ["/sbin/exampled", "-d"] daemon_shutdown = opus.Daemon.Shutdown.Signal opus.add_unit(exampled)
This constructs a class derived from the opus.Daemon (actually opus.Daemon.Daemon) class. It says that the unit name is 'exampled', provides a description of the daemon, provides the command-line for the daemon to start, and tells opus that the shutdown mechanism is to use signals. Finally, it tells opus to register the Unit in the unit list, and add it to the mainloop.
The unit is not tied to the file that this is stored in (for
example, /etc/opus.units/exampled). It is generally best
practice to keep the main class name, file name, and unit name the same,
but throughout opus you will use the unit name to refer to it. The main
class name tends to only matter at startup, but if you want to remove a
definition file completely, or find out what unit(s) it contains, then
you need to look for the file itself.