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.
Launchpad entry: https://launchpad.net/products/upstart/+spec/profiles
Currently when you boot the system using Upstart, every job file is taken into account. This specification proposes a "profiles" system which allows you to specify exactly which files to take into account in a profile.
Sysvinit currently has a runlevel system. This would be a way of replacing it.
- A configuration GUI for Upstart would require a system like this to allow services to be enabled and disabled
- If the user wants to boot into what sysvinit calls single-user mode, they will want a minimal system with nothing unnecessary running. Creating a single user profile would allow this to be done
The scope of this proposal is limited to the part of Upstart that monitors the event.d directory and parses the files.
- Profiles would be defined in files under /etc/init/profiles.d
Profiles are in a simple '(enable|disable) <jobname>' format. A star for job-name indicates every job
ScottJamesRemnant: "enable all" would be more Upstartish
- If no value for '*' is explicitly defined, it would default to enabled.
- Specifically named entries would take priority over the star value. In this example every job file would be taken into account apart from apache.
# This line isn't really needed, see the above point enable * disable apache
- Unless specified on the kernel command line (see below), the profile used when the system starts would be the 'default' profile. If the default profile doesn't exist under /etc/init/profiles.d, every job file would be taken into account.
- The profile can be overridden at boot-time by specifying an argument on the kernel command line. This kernel command line would tell Upstart to use the noserver profile
ro root=/dev/hda2 noserver
- Profiles would be changeable at runtime with initctl, as shown below:
$ initctl profile nonetwork
- When a job is disabled by the current profile, it still responds to events, it'll just not actually start. If the system is currently in a state when it can be running, and the profile is changed to one which allows it to be run, it'll start.
Code changes are primarily limited to init/cfgfile.c, init/cfgfile.h, init/main.c and init/job.h
Data preservation and migration
These changes are backwards compatible with the previous behaviour.