Not sure if this who to report this to or how to view it, but wanted to share this experience.
I installed F10 x86_64 on a machine for work. I wanted a minimal X11 environment, so I opted to install just WindowMaker and no desktop environment like Gnome. No errors occurred, install completed successfully.
On firstboot I was greeted with the text-mode setup utility to configure firewall, networking, etc. I thought this odd, but went with it. After completing setup, I was in run level 3. Checking I realized no display manager were installed, nor was X. So I installed both.
Here are the issues. Doing a groupinstall for X did not prompt me for or change my default runlevel to 5. So I had to manually edit /etc/inittab to set it to 5. That's when the other issue popped up: no services were configured for runlevel 5. Networking, httpd, etc. all shut down when things booted. X displayed during boot but, when the system went to runlevel 5, everything else shut down.
Shouldn't installing X make runlevel 5 the default?
And, even if we don't install X, why should't services toggle their runlevel 5 state?
On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
Shouldn't installing X make runlevel 5 the default?
No.
And, even if we don't install X, why should't services toggle their runlevel 5 state?
This seems to be the interesting part. This... shouldn't happen.
On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
Shouldn't installing X make runlevel 5 the default?
No.
That's fine. I wasn't sure how it ought to proceed.
And, even if we don't install X, why should't services toggle their runlevel 5 state?
This seems to be the interesting part. This... shouldn't happen.
Agreed. I wasn't sure which component owned the services configuration, so thought I'd float this here before logging a BZ ticket.
Darryl L. Pierce (dpierce@redhat.com) said:
On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
Shouldn't installing X make runlevel 5 the default?
No.
That's fine. I wasn't sure how it ought to proceed.
If you install a desktop, anaconda will modify the default runlevel. (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
And, even if we don't install X, why should't services toggle their runlevel 5 state?
This seems to be the interesting part. This... shouldn't happen.
Agreed. I wasn't sure which component owned the services configuration, so thought I'd float this here before logging a BZ ticket.
Nothing should specifically change for runlevel 5 from the defaults.
Bill
On Wed, 2008-12-03 at 14:54 -0500, Bill Nottingham wrote:
Darryl L. Pierce (dpierce@redhat.com) said:
On Wed, Dec 03, 2008 at 11:43:14AM -0800, Jesse Keating wrote:
On Wed, 2008-12-03 at 14:30 -0500, Darryl L. Pierce wrote:
Shouldn't installing X make runlevel 5 the default?
No.
That's fine. I wasn't sure how it ought to proceed.
If you install a desktop, anaconda will modify the default runlevel. (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
It's based on whether gdm or kdm (kdebase-workspace) are installed
Jeremy
On Wed, Dec 03, 2008 at 03:11:16PM -0500, Jeremy Katz wrote:
That's fine. I wasn't sure how it ought to proceed.
If you install a desktop, anaconda will modify the default runlevel. (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
It's based on whether gdm or kdm (kdebase-workspace) are installed
So, when I installed gdm after the fact, should it have changed the runlevel?
On Wed, 2008-12-03 at 15:35 -0500, Darryl L. Pierce wrote:
On Wed, Dec 03, 2008 at 03:11:16PM -0500, Jeremy Katz wrote:
That's fine. I wasn't sure how it ought to proceed.
If you install a desktop, anaconda will modify the default runlevel. (This may be limited to GNOME or KDE.) Otherwise, we don't touch it.
It's based on whether gdm or kdm (kdebase-workspace) are installed
So, when I installed gdm after the fact, should it have changed the runlevel?
No. It's done by anaconda. anaconda doesn't do anything after your system is installed.
Jeremy
2008/12/3 Jesse Keating jkeating@redhat.com:
This seems to be the interesting part. This... shouldn't happen.
Is his /etc/event.d/rc5 script not firing?
-jef
On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
2008/12/3 Jesse Keating jkeating@redhat.com:
This seems to be the interesting part. This... shouldn't happen.
Is his /etc/event.d/rc5 script not firing?
Services such as network and httpd had "off" as their runlevel 5 setting.
2008/12/3 Darryl L. Pierce dpierce@redhat.com:
Services such as network and httpd had "off" as their runlevel 5 setting.
But the problem is..we don't know what the configuration was for runlevel settings before you started taking local action. We are assuming services started out as on for runlevel 5 after your install into runlevel 3 was completed, To narrow down where to look. you'll need to try to reproduce this by starting afresh and doing everything again..watching for which specific action turns off services in runlevel 5. Hell you could have tripped over an obscure rpm trigger or something that calls chkconfig and disables services on package install.
-jef
On Wed, 2008-12-03 at 15:37 -0500, Darryl L. Pierce wrote:
On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
2008/12/3 Jesse Keating jkeating@redhat.com:
This seems to be the interesting part. This... shouldn't happen.
Is his /etc/event.d/rc5 script not firing?
Services such as network and httpd had "off" as their runlevel 5 setting.
Yes, they're off by default. If you just ran 'chkconfig httpd on' when you were in runlevel 3, then it only affects runlevel 3. You have to explicitly tell chkconfig if you want it to affect other runlevels. This is the way chkconfig has always worked.
Jeremy
On 12/03/2008 10:18 PM, Jeremy Katz wrote:
On Wed, 2008-12-03 at 15:37 -0500, Darryl L. Pierce wrote:
On Wed, Dec 03, 2008 at 11:29:13AM -0900, Jeff Spaleta wrote:
2008/12/3 Jesse Keatingjkeating@redhat.com:
This seems to be the interesting part. This... shouldn't happen.
Is his /etc/event.d/rc5 script not firing?
Services such as network and httpd had "off" as their runlevel 5 setting.
Yes, they're off by default. If you just ran 'chkconfig httpd on' when you were in runlevel 3, then it only affects runlevel 3. You have to explicitly tell chkconfig if you want it to affect other runlevels. This is the way chkconfig has always worked.
That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off' and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to on. It behaves like that both on my Desktop running in runlevel 5 (F10) and on a server running level 3 (Centos5).
I always believed the 'chkconfig X on' without specifying the runlevels would turn on the default runlevel specified in the init script because that's the way it seems to behave.
Regards, Dennis
On Thu, 2008-12-04 at 01:36 +0100, Dennis J. wrote:
That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off' and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to on. It behaves like that both on my Desktop running in runlevel 5 (F10) and on a server running level 3 (Centos5).
I always believed the 'chkconfig X on' without specifying the runlevels would turn on the default runlevel specified in the init script because that's the way it seems to behave.
Perhaps it's system-config-services-tui which is ran via the text firstboot which only changes things for the current runlevel. There is definitely some disconnect here.
Dennis J. (dennisml@conversis.de) said:
That's doesn't seem to be right. I've got httpd set to 'on' for runlevels 2,3,4 and 5. Doing a "chkconfig httpd off" sets *all* runlevels to 'off' and then doing a "chkconfig httpd on" sets runlevels 2,3,4 and 5 back to on. It behaves like that both on my Desktop running in runlevel 5 (F10) and on a server running level 3 (Centos5).
I always believed the 'chkconfig X on' without specifying the runlevels would turn on the default runlevel specified in the init script because that's the way it seems to behave.
'on' and 'off' affect 2/3/4/5 if you don't specify a level otherwise. See the man page.
Bill
2008/12/3 Darryl L. Pierce dpierce@redhat.com:
And, even if we don't install X, why should't services toggle their runlevel 5 state?
Did you manually turn services on for runlevel 3 before editting the inittab?
chkconfig --list will give a summary of the runlevel activation settings for each service.
Does chkconfig list the services you are concerned about as being active for runlevel 5?
-jef
On Wed, Dec 03, 2008 at 11:27:03AM -0900, Jeff Spaleta wrote:
2008/12/3 Darryl L. Pierce dpierce@redhat.com:
And, even if we don't install X, why should't services toggle their runlevel 5 state?
Did you manually turn services on for runlevel 3 before editting the inittab?
chkconfig --list will give a summary of the runlevel activation settings for each service.
Does chkconfig list the services you are concerned about as being active for runlevel 5?
See my other email, but no I didn't turn anything off or on. I only turned on httpd and network after I saw they were turned off for 5 after installing X.
On Wed, 2008-12-03 at 15:38 -0500, Darryl L. Pierce wrote:
See my other email, but no I didn't turn anything off or on. I only turned on httpd and network after I saw they were turned off for 5 after installing X.
Given that we use NetworkManager, and that http is off by default, these were most likely off for run level 3, as well as 5. The switch from 3 to have had no effect upon them, they were just plain off.
On Wed, Dec 03, 2008 at 02:02:40PM -0800, Jesse Keating wrote:
Given that we use NetworkManager, and that http is off by default, these were most likely off for run level 3, as well as 5. The switch from 3 to have had no effect upon them, they were just plain off.
Okay, that would explain those being off then. During firstboot I did tell the system that I wanted network and httpd services enabled, so that would explain why it set them for runlevel 3.
On Wed, Dec 03, 2008 at 05:39:28PM -0500, Darryl L. Pierce wrote:
On Wed, Dec 03, 2008 at 02:02:40PM -0800, Jesse Keating wrote:
Given that we use NetworkManager, and that http is off by default, these were most likely off for run level 3, as well as 5. The switch from 3 to have had no effect upon them, they were just plain off.
Okay, that would explain those being off then. During firstboot I did tell the system that I wanted network and httpd services enabled, so that would explain why it set them for runlevel 3.
Hit send to early.
...that would explay why it was set for runlevel 3. Shouldn't it have also set them for runlevel 5?
On Wed, 2008-12-03 at 17:42 -0500, Darryl L. Pierce wrote:
...that would explay why it was set for runlevel 3. Shouldn't it have also set them for runlevel 5?
No. chkconfig service on will only set it for the current runlevel, although the man page doesn't make this obvious.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roland McGrath wrote:
No. chkconfig service on will only set it for the current runlevel,
no, this is not true...
chkconfig cups off
Will result in
[root@localhost ~]# chkconfig cups off [root@localhost ~]# chkconfig cups --list cups 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Enabling the service via
chkconfig cups on
results in:
[root@localhost ~]# chkconfig cups --list cups 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@localhost ~]# chkconfig cups on [root@localhost ~]# chkconfig cups --list cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off
In other word, if you do NOT specify the run levels to change, chkconfig will, by default, "on" or "off" runlevels 2,3,4,5
although the man page doesn't make this obvious.
And in fact, this behaviour *IS* stated in the man page:
By default, the on and off options affect only runlevels 2, 3, 4, and 5, while reset and resetpriorities affects all of the runlevels. The --level option may be used to specify which runlevels are affected.
In fact, it's thoroughly non-obvious, counter-intuitive and makes one wonder what chkconfig is supposed to be good for.
Seems pretty clear to me... Perhaps you haven't read the man page?
All the best,
- -Greg
- -- +---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log)
| Greg Hosler ghosler@redhat.com | +---------------------------------------------------------------------+
Jesse Keating jkeating@redhat.com wrote:
On Wed, 2008-12-03 at 17:42 -0500, Darryl L. Pierce wrote:
...that would explay why it was set for runlevel 3. Shouldn't it have also set them for runlevel 5?
No. chkconfig service on will only set it for the current runlevel, although the man page doesn't make this obvious.
Funny... for instance, /etc/init.d/sendmail contains:
# chkconfig: 2345 80 30
and AFAIK this has always meant "run in levels 2345, start at 80, shut down at 20" and I distinctly remember chkconfig on/off creating/axing the symlinks accordingly.
On Wed, 2008-12-03 at 21:46 -0300, Horst H. von Brand wrote:
No. chkconfig service on will only set it for the current runlevel, although the man page doesn't make this obvious.
Funny... for instance, /etc/init.d/sendmail contains:
# chkconfig: 2345 80 30
and AFAIK this has always meant "run in levels 2345, start at 80, shut down at 20" and I distinctly remember chkconfig on/off creating/axing the symlinks accordingly.
Yeah, I think this is why the man page didn't show it. I was going by Jeremy's info that chkconfig did that, without verifying myself. Whoops.
Horst H. von Brand (vonbrand@inf.utfsm.cl) said:
Funny... for instance, /etc/init.d/sendmail contains:
# chkconfig: 2345 80 30
and AFAIK this has always meant "run in levels 2345, start at 80, shut down at 20" and I distinctly remember chkconfig on/off creating/axing the symlinks accordingly.
Default levels in the initscript are used by 'chkconfig --add', not 'chkconfig [--level XYZ] on/off'
Bill
On Wed, Dec 03, 2008 at 02:56:59PM -0800, Jesse Keating wrote:
No. chkconfig service on will only set it for the current runlevel, although the man page doesn't make this obvious.
Other runlevels are affected even though I didn't specify any.
Darryl L. Pierce wrote:
Not sure if this who to report this to or how to view it, but wanted to share this experience.
I installed F10 x86_64 on a machine for work. I wanted a minimal X11 environment, so I opted to install just WindowMaker and no desktop environment like Gnome. No errors occurred, install completed successfully.
On firstboot I was greeted with the text-mode setup utility to configure firewall, networking, etc. I thought this odd, but went with it. After completing setup, I was in run level 3. Checking I realized no display manager were installed, nor was X. So I installed both.
Here are the issues. Doing a groupinstall for X did not prompt me for or change my default runlevel to 5. So I had to manually edit /etc/inittab to set it to 5. That's when the other issue popped up: no services were configured for runlevel 5. Networking, httpd, etc. all shut down when things booted. X displayed during boot but, when the system went to runlevel 5, everything else shut down.
Shouldn't installing X make runlevel 5 the default?
And, even if we don't install X, why should't services toggle their runlevel 5 state?
Very Bad Things happen when packages mess with files they don't own, so it's not a bug that installing an X server didn't change your default runlevel. It's also not a bug that WindowMaker didn't pull in a display manager, since lightweight window managers are often used remotely on headless servers, which we don't want anaconda configuring for runlevel 5 by default.
The services problem is definitely a bug though.
-- Chris
-
Bill Nottingham -
Chris Snook -
Darryl L. Pierce -
Dennis Jacobfeuerborn -
Gregory Hosler -
Horst H. von Brand -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Roland McGrath