Bug 431122 - upstart: no chkconfig-type mechanism to enable/disable services
upstart: no chkconfig-type mechanism to enable/disable services
Product: Fedora
Classification: Fedora
Component: upstart (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: upstart
  Show dependency treegraph
Reported: 2008-01-31 15:40 EST by Bill Nottingham
Modified: 2014-06-18 04:46 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-10 14:04:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-01-31 15:40:08 EST
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):

Comment 1 Scott James Remnant 2008-02-11 06:25:09 EST
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
Comment 2 Bill Nottingham 2008-02-11 13:29:30 EST
(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?
Comment 3 Casey Dahlin 2008-02-11 16:21:41 EST
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.

Comment 4 Casey Dahlin 2008-02-16 19:39:09 EST
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.
Comment 5 Scott James Remnant 2008-02-17 12:27:03 EST
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
Comment 6 Casey Dahlin 2008-02-17 13:11:38 EST
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
Comment 7 Bill Nottingham 2008-02-18 15:44:49 EST
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.
Comment 8 Valdis Kletnieks 2008-03-17 16:11:49 EDT
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.
Comment 9 Casey Dahlin 2008-03-17 16:33:05 EDT
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'
Comment 10 Valdis Kletnieks 2008-03-17 17:37:24 EDT
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 11 Valdis Kletnieks 2008-03-17 22:32:59 EDT
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.
Comment 12 Casey Dahlin 2008-03-18 11:08:11 EDT
[!45] should work. Worst that can happen is prefdm won't start.
Comment 13 Bug Zapper 2008-05-14 00:57:10 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 14 Jon Stanley 2008-05-24 16:04:10 EDT
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.
Comment 15 Bill Nottingham 2008-10-24 15:19:08 EDT
Removing F10Target, this is not going to be addressed there.
Comment 16 Bug Zapper 2009-06-09 19:28:31 EDT
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: 
Comment 17 Casey Dahlin 2009-06-10 13:23:49 EDT
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?
Comment 18 Bill Nottingham 2009-06-10 14:04:02 EDT
Eh, probably not for now.

Note You need to log in before you can comment on or make changes to this bug.