Description of problem: upstart has no mechanism at the moment for adding services which may or may not be enabled according to sysadmin preferences. Something like this will need added. Version-Release number of selected component (if applicable): 0.3.9-2.fc9
Various suggestions for this at the moment, not sure what the favourite is: - in-file "disabled" stanza - overlay configuration files which add or remove stanzas - directory-o-symlinks into event.d to enable/disable - as above, but with multiple selectable profiles - profiles defined by separate config files - "with networking" flag stanzas and option to enable/disable by flag
(In reply to comment #1) > Various suggestions for this at the moment, not sure what the favourite is: > > - in-file "disabled" stanza Works horribly with package managers who package the scripts. > - directory-o-symlinks into event.d to enable/disable This is the chkconfig mechanism, for better or worse. > - as above, but with multiple selectable profiles Isn't this essentially re-implementing runlevels?
I don't know that I'd say "re-implementing." We might want to experiment with having multiple profiles in a manner that is a bit less cumbersome than runlevels, though as much as the idea appeals to me, I don't know of many people who used runlevels 2 thru 4 for anything previously. --CJD
Looking at this more closely I'd say Scott's last idea sounds best. We should see if this can be ready in time for us.
Is this necessary for F9? This is morally equivalent to commenting lines out of inittab right now, and roughly the same solution works for Upstart
True, I don't know that there's a rush on this, especially considering the vast majority of F9 scripts will be sysv ones, so chkconfig itself will still be preferred.
There are enough issues with having sysv scripts depending on upstart events that I'm not comfortable with any 'service' script moving from sysv -> upstart yet, so yeah, this is somewhat not needed yet.
People who use runlevels 2 through 4 *do* exist - for starters, 3 is reserved for "multiuser nographics" - very handy if you're doing a headless server and don't need to start up a totally useless X server. And I for one use '4' as a "stripped down 5" - stuff like vmware, snort, nessus, and a bunch of other stuff that I don't need on most boots is left in 5, and I boot into 4 with a lot less stuff running. Incidentally, I had the following line in /etc/inittab: x:45:respawn:/etc/X11/prefdm -nodaemon And now I need to manually do a 'initctl start prefdm'. Whatever magic hard-coded 'prefdm == runlevel 5' needs to either not hard-code it, or do a better job of detecting what it should be doing.
It isn't hardcoded, its just not in inittab anymore. In fact there probably will be no inittab in F9. To get what you want, edit /etc/event.d/prefdm. Below the line that says 'start on stopped rc5' add one that says 'start on stopped rc4'
Wow, that sort of thing is going to surprise a *lot* of people if they have customized entries in inittab. Is there a way for the upgrade-to-F9 process to detect a not-stock-vanilla inittab and warn the admin to make sure they make the appropriate conversions, or will a more automated converter be included?
Comment #9: I don't think it's as simple as adding that line, because there's another line that says: stop on runlevel [!5] I'm not feeling brave enough to reboot just to find out if [!45] does what I hope. 'man init' is terribly clear about it: On startup init reads the /etc/event.d directory, each file describes a job that should be managed. This includes the particulars about what binary or shell script code should executed while the job is running, and which events can cause the job to be started or stopped. Yea, that doesn't tell me anything about the semantics of each file. Definitely need at least a manpage about it. But it's unclear if that should be part of this bug, or another bugzilla opened for that.
[!45] should work. Worst that can happen is prefdm won't start.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Moving to rawhide, FutureFeature, and F10Target, assuming that we're going to have more items managed by upstart rather than sysv scripts and will need some admin-friendly way to enable/disable those services. Again, I think that the idea of profiles is the best - you need a way to specify profiles in a textual way (for instance the previous poster in this bug might have a 'minimal-x' and 'full-x' profile). This should be specifiable on the boot command line, just like '3' is today.
Removing F10Target, this is not going to be addressed there.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is roadmapped for 0.10/1.0. Its not going to happen in 0.3.9 and we aren't deploying 0.5.x. Do we still need the bug?
Eh, probably not for now.