Bug 431122

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.