7:56 a.m.
With the switch to upstart, we obviated the need for /etc/inittab (upstart
does not need it, nor read it.)
Initially, we added a quick hack that read /etc/inittab solely to determine
the default runlevel. Based on a bug I filed (#432384), we changed that so
that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
and we'e planning to just remove the inittab file to make things more obvious.
I'm open to better ideas, though - should we ship a trimmed inittab that
contains *only* the initdefault line? Should we introduce a new configuration
flag somewhere else? Does it really matter in the long run?
Bill
8:53 a.m.
Hi.
On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
I'm open to better ideas, though - should we ship a trimmed
inittab
that contains *only* the initdefault line? Should we introduce a new
configuration flag somewhere else? Does it really matter in the long
run?
At the very least leave an inittab file that contains a note that it
is not used anymore. Much better than having to find out the new
structure on your own.
8:57 a.m.
On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
Hi.
On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> I'm open to better ideas, though - should we ship a trimmed inittab
> that contains *only* the initdefault line? Should we introduce a new
> configuration flag somewhere else? Does it really matter in the long
> run?
At the very least leave an inittab file that contains a note that it
is not used anymore. Much better than having to find out the new
structure on your own.
Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
related note where can you configure the starting of mingetty/agettty
processes for serial consoles / text consoles, and where do you override
the default C-A-D handling ?
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:45 a.m.
On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
> Hi.
>
> On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
>
> > I'm open to better ideas, though - should we ship a trimmed inittab
> > that contains *only* the initdefault line? Should we introduce a new
> > configuration flag somewhere else? Does it really matter in the long
> > run?
>
> At the very least leave an inittab file that contains a note that it
> is not used anymore. Much better than having to find out the new
> structure on your own.
Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
related note where can you configure the starting of mingetty/agettty
processes for serial consoles / text consoles, and where do you override
the default C-A-D handling ?
+1
--
Michael
12:24 p.m.
On Thu, 2008-03-27 at 11:45 -0500, Michael E Brown wrote:
On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
> On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
> > Hi.
> >
> > On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> >
> > > I'm open to better ideas, though - should we ship a trimmed inittab
> > > that contains *only* the initdefault line? Should we introduce a new
> > > configuration flag somewhere else? Does it really matter in the long
> > > run?
> >
> > At the very least leave an inittab file that contains a note that it
> > is not used anymore. Much better than having to find out the new
> > structure on your own.
>
> Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
> related note where can you configure the starting of mingetty/agettty
> processes for serial consoles / text consoles,
/etc/event.d/tty[1-6] and /etc/event.d/serial
and where do you override the default C-A-D handling ?
/etc/event.d/control-alt-delete
There should probably be comments in the new /etc/inittab that point
people to these files (and a mention of a reference for event file
syntax). Something like:
# inittab is not used by Upstart.
# This file is provided for informational purposes only.
# CHANGING THIS FILE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# To set the default runlevel, see /etc/sysconfig/init
#
# System initialization is started by /etc/event.d/rcS
#
# Individual runlevels are started by /etc/event.d/rc[0-6]
#
# Ctrl-Alt-Delete is handled by /etc/event.d/control-alt-delete
#
# Terminal gettys (tty[1-6]) are handled by /etc/event.d/tty[1-6]
#
# Documentation on Upstart event handlers can be found here:
# http://upstart.ubuntu.com/getting-started.html
# http://upstart.ubuntu.com/wiki/Stanzas
Optionally you could keep the old inittab junk after the comment, for
historical reasons and/or backwards compatibility for people who want to
install sysvinit.
-w
12:33 p.m.
On Thu, Mar 27, 2008 at 01:24:38PM -0400, Will Woods wrote:
On Thu, 2008-03-27 at 11:45 -0500, Michael E Brown wrote:
> On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
> > On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
> > > Hi.
> > >
> > > On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> > >
> > > > I'm open to better ideas, though - should we ship a trimmed
inittab
> > > > that contains *only* the initdefault line? Should we introduce a new
> > > > configuration flag somewhere else? Does it really matter in the long
> > > > run?
> > >
> > > At the very least leave an inittab file that contains a note that it
> > > is not used anymore. Much better than having to find out the new
> > > structure on your own.
> >
> > Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
> > related note where can you configure the starting of mingetty/agettty
> > processes for serial consoles / text consoles,
/etc/event.d/tty[1-6] and /etc/event.d/serial
> and where do you override the default C-A-D handling ?
/etc/event.d/control-alt-delete
There should probably be comments in the new /etc/inittab that point
people to these files (and a mention of a reference for event file
syntax). Something like:
This information should be in the man pages for init. The current upstart
man page doesn't cover any of this stuff
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
12:41 p.m.
On Thu, Mar 27, 2008 at 05:33:08PM +0000, Daniel P. Berrange wrote:
On Thu, Mar 27, 2008 at 01:24:38PM -0400, Will Woods wrote:
>
> On Thu, 2008-03-27 at 11:45 -0500, Michael E Brown wrote:
> > On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
> > > On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
> > > > Hi.
> > > >
> > > > On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> > > >
> > > > > I'm open to better ideas, though - should we ship a trimmed
inittab
> > > > > that contains *only* the initdefault line? Should we introduce a
new
> > > > > configuration flag somewhere else? Does it really matter in the
long
> > > > > run?
> > > >
> > > > At the very least leave an inittab file that contains a note that it
> > > > is not used anymore. Much better than having to find out the new
> > > > structure on your own.
> > >
> > > Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
> > > related note where can you configure the starting of mingetty/agettty
> > > processes for serial consoles / text consoles,
>
> /etc/event.d/tty[1-6] and /etc/event.d/serial
>
> > and where do you override the default C-A-D handling ?
>
> /etc/event.d/control-alt-delete
>
> There should probably be comments in the new /etc/inittab that point
> people to these files (and a mention of a reference for event file
> syntax). Something like:
This information should be in the man pages for init. The current upstart
man page doesn't cover any of this stuff
I've added this bug to request man page docs for configuration
https://bugzilla.redhat.com/show_bug.cgi?id=439245
IMHO, this should be a release blocker since it is a major change in the
distro that will trip up users familiar with old style init configuration.
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
7:54 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel P. Berrange wrote:
On Thu, Mar 27, 2008 at 01:24:38PM -0400, Will Woods wrote:
> On Thu, 2008-03-27 at 11:45 -0500, Michael E Brown wrote:
>> On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
>>> On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
>>>> Hi.
>>>>
>>>> On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
>>>>
>>>>> I'm open to better ideas, though - should we ship a trimmed
inittab
>>>>> that contains *only* the initdefault line? Should we introduce a new
>>>>> configuration flag somewhere else? Does it really matter in the long
>>>>> run?
>>>> At the very least leave an inittab file that contains a note that it
>>>> is not used anymore. Much better than having to find out the new
>>>> structure on your own.
>>> Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
>>> related note where can you configure the starting of mingetty/agettty
>>> processes for serial consoles / text consoles,
> /etc/event.d/tty[1-6] and /etc/event.d/serial
>
>> and where do you override the default C-A-D handling ?
> /etc/event.d/control-alt-delete
>
> There should probably be comments in the new /etc/inittab that point
> people to these files (and a mention of a reference for event file
> syntax). Something like:
This information should be in the man pages for init. The current upstart
man page doesn't cover any of this stuff
Dan.
+1
Being an old UNIX hacker that is familiar with traditional init behavior, I was quite
confused when my console login disappeared and my laptop booted into GDM. It took me
quite a bit of digging to finally understand the startup logic for upstart (at least
I *think* I understand it). Might be a good idea to put some sort of blurb in the
init(8) manpage that tells how events get propagated.
As I understand it, everything in the current setup (runlevel emulation) keys from
the "start on startup" phrase in rcS. Maybe a comment in rcS that all the
runlevel
stuff starts there?
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfuPAcACgkQHyuj/+TTEp2JPQCghCs2O70spDZ7bHVLoMISe/lD
3p8An0opP0dCiii+hDzghHPBypxL0mgn
=s6ou
-----END PGP SIGNATURE-----
12:34 p.m.
On Thu, 2008-03-27 at 13:24 -0400, Will Woods wrote:
On Thu, 2008-03-27 at 11:45 -0500, Michael E Brown wrote:
> On Thu, Mar 27, 2008 at 01:57:08PM +0000, Daniel P. Berrange wrote:
> > On Thu, Mar 27, 2008 at 02:53:31PM +0100, Ralf Ertzinger wrote:
> > > Hi.
> > >
> > > On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> > >
> > > > I'm open to better ideas, though - should we ship a trimmed
inittab
> > > > that contains *only* the initdefault line? Should we introduce a new
> > > > configuration flag somewhere else? Does it really matter in the long
> > > > run?
> > >
> > > At the very least leave an inittab file that contains a note that it
> > > is not used anymore. Much better than having to find out the new
> > > structure on your own.
> >
> > Yes, it should have a comment pointing to /etc/sysconfig/init. And on a
> > related note where can you configure the starting of mingetty/agettty
> > processes for serial consoles / text consoles,
# Documentation on Upstart event handlers can be found here:
# http://upstart.ubuntu.com/getting-started.html
# http://upstart.ubuntu.com/wiki/Stanzas
I'd personally prefer to have some man pages to read, rather than (or in
addition to) external URLs. Is there a man page which documents upstart
in general? (man upstart?). And do these man pages include the
information you just put into /etc/inittab? It would be ironic if the
most useful documentation on upstart could be found in /etc/inittab.
David
12:39 p.m.
On Thu, 2008-03-27 at 13:34 -0400, David Mansfield wrote:
> # Documentation on Upstart event handlers can be found here:
> # http://upstart.ubuntu.com/getting-started.html
> # http://upstart.ubuntu.com/wiki/Stanzas
>
I'd personally prefer to have some man pages to read, rather than (or in
addition to) external URLs. Is there a man page which documents upstart
in general? (man upstart?). And do these man pages include the
information you just put into /etc/inittab? It would be ironic if the
most useful documentation on upstart could be found in /etc/inittab.
There aren't man pages for these things yet, or I'd have linked to them.
I'm sure there would be a lot of *very* grateful people (myself
included) if you were to write some basic man pages for these things...
upstart's init(8) page mentions that it reads files from /etc/event.d
and doesn't talk abut inittab at all. But that doesn't really provide
all the information you'd want.
-w
6:12 a.m.
On 27/03/2008, Will Woods <wwoods(a)redhat.com> wrote:
There should probably be comments in the new /etc/inittab that
point
people to these files. Something like:
# inittab is not used by Upstart.
# To set the default runlevel, see /etc/sysconfig/init
# System initialization is started by /etc/event.d/rcS
# Individual runlevels are started by /etc/event.d/rc[0-6]
# Ctrl-Alt-Delete is handled by /etc/event.d/control-alt-delete
# Terminal gettys (tty[1-6]) are handled by /etc/event.d/tty[1-6]
+1
10:20 a.m.
On Thu, Mar 27, 2008 at 7:53 AM, Ralf Ertzinger <fedora(a)camperquake.de> wrote:
Hi.
On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
> I'm open to better ideas, though - should we ship a trimmed inittab
> that contains *only* the initdefault line? Should we introduce a new
> configuration flag somewhere else? Does it really matter in the long
> run?
At the very least leave an inittab file that contains a note that it
is not used anymore. Much better than having to find out the new
structure on your own.
Dear god yes.. and we will probably still have every sysadmin, book,
and out-of-fedora package that places stuff in /etc/inittab for serial
ports, etc yell every 2 seconds on fedora-list(a)redhat.com, etc that
Fedora-9 borked their setup.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
10:35 a.m.
Stephen John Smoogen wrote:
On Thu, Mar 27, 2008 at 7:53 AM, Ralf Ertzinger
<fedora(a)camperquake.de> wrote:
> Hi.
>
>
> On Thu, 27 Mar 2008 08:56:40 -0400, Bill Nottingham wrote:
>
> > I'm open to better ideas, though - should we ship a trimmed inittab
> > that contains *only* the initdefault line? Should we introduce a new
> > configuration flag somewhere else? Does it really matter in the long
> > run?
>
> At the very least leave an inittab file that contains a note that it
> is not used anymore. Much better than having to find out the new
> structure on your own.
>
>
Dear god yes.. and we will probably still have every sysadmin, book,
and out-of-fedora package that places stuff in /etc/inittab for serial
ports, etc yell every 2 seconds on fedora-list(a)redhat.com, etc that
Fedora-9 borked their setup.
+1, it is an issue... Most often people switch to another distro in such
cases :(
Whether it is possible to save /etc/inittab, as an additional "legacy"
config file? Perhaps it could be fine to have some special "service"
under upstart, which read the /etc/inittab (if present) and perform all
the tasks which are still defined in the old sysv way...
~buc
http://www.fedoraproject.org/wiki/DmitryButskoy
10:46 a.m.
Dmitry Butskoy (buc(a)odusz.so-cdu.ru) said:
Whether it is possible to save /etc/inittab, as an additional
"legacy"
config file? Perhaps it could be fine to have some special "service" under
upstart, which read the /etc/inittab (if present) and perform all the tasks
which are still defined in the old sysv way...
That would mean attempting to figure out what things in the old
/etc/inittab were sysadmin-modified/added, and which ones weren't.
That seems fraught with failure.
Bill
12:47 p.m.
On Thu, Mar 27, 2008 at 7:46 AM, Bill Nottingham <notting(a)redhat.com> wrote:
That would mean attempting to figure out what things in the old
/etc/inittab were sysadmin-modified/added, and which ones weren't.
That seems fraught with failure.
You mean like how we use to mark up fstab.......
-jef
8:55 a.m.
On Thu, 2008-03-27 at 08:56 -0400, Bill Nottingham wrote:
Initially, we added a quick hack that read /etc/inittab solely to
determine
the default runlevel. Based on a bug I filed (#432384), we changed that so
that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
and we'e planning to just remove the inittab file to make things more obvious.
I'm open to better ideas, though - should we ship a trimmed inittab that
contains *only* the initdefault line? Should we introduce a new configuration
flag somewhere else? Does it really matter in the long run?
Well, if it's going to go/not be used, then we need to fix at least
anaconda and livecd-creator to write things elsewhere. In which case,
it'd be nice if /etc/inittab goes away too so that we can key behavior
accordingly
Jeremy
9:07 a.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
Initially, we added a quick hack that read /etc/inittab solely to
determine
the default runlevel. Based on a bug I filed (#432384), we changed that so
that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
and we'e planning to just remove the inittab file to make things more obvious.
I'm open to better ideas, though - should we ship a trimmed inittab that
contains *only* the initdefault line? Should we introduce a new configuration
flag somewhere else? Does it really matter in the long run?
If upstart doesn't read it, I'd say don't try to have a hack that has
something else parse it and configure upstart. However, /etc/inittab is
a long-time configuration file for Unix-like systems, so it would be
good to have an /etc/inittab that contains comments that point to the
new location for the configuration options (e.g. default runlevel,
console terminal configuration, etc.).
You could have a big "### THIS FILE IS OBSOLETE ###" at the top, and
anaconda, etc. could key off that line (and/or whether the file has any
non-comment lines in it).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:10 a.m.
Some software (Notably IBM's TSM client) writes to inittab for startup:
tsm:23:once:/opt/tivoli/tsm/client/ba/bin/dsmc schedule >/dev/null 2>&1
Its gross, but its a potential gotcha to watch out for...
Brian
On Thu, 2008-03-27 at 09:07 -0500, Chris Adams wrote:
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
> Initially, we added a quick hack that read /etc/inittab solely to determine
> the default runlevel. Based on a bug I filed (#432384), we changed that so
> that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
> and we'e planning to just remove the inittab file to make things more obvious.
>
> I'm open to better ideas, though - should we ship a trimmed inittab that
> contains *only* the initdefault line? Should we introduce a new configuration
> flag somewhere else? Does it really matter in the long run?
If upstart doesn't read it, I'd say don't try to have a hack that has
something else parse it and configure upstart. However, /etc/inittab is
a long-time configuration file for Unix-like systems, so it would be
good to have an /etc/inittab that contains comments that point to the
new location for the configuration options (e.g. default runlevel,
console terminal configuration, etc.).
You could have a big "### THIS FILE IS OBSOLETE ###" at the top, and
anaconda, etc. could key off that line (and/or whether the file has any
non-comment lines in it).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:30 p.m.
Brian Wheeler wrote:
Some software (Notably IBM's TSM client) writes to inittab for
startup:
tsm:23:once:/opt/tivoli/tsm/client/ba/bin/dsmc schedule >/dev/null 2>&1
Its gross, but its a potential gotcha to watch out for...
Brian
Already found (and fixed) one or two of these. Frankly we're better off
fixing them.
--CJD
On Thu, 2008-03-27 at 09:07 -0500, Chris Adams wrote:
> Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
>
>> Initially, we added a quick hack that read /etc/inittab solely to determine
>> the default runlevel. Based on a bug I filed (#432384), we changed that so
>> that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
>> and we'e planning to just remove the inittab file to make things more
obvious.
>>
>> I'm open to better ideas, though - should we ship a trimmed inittab that
>> contains *only* the initdefault line? Should we introduce a new configuration
>> flag somewhere else? Does it really matter in the long run?
>>
> If upstart doesn't read it, I'd say don't try to have a hack that has
> something else parse it and configure upstart. However, /etc/inittab is
> a long-time configuration file for Unix-like systems, so it would be
> good to have an /etc/inittab that contains comments that point to the
> new location for the configuration options (e.g. default runlevel,
> console terminal configuration, etc.).
>
> You could have a big "### THIS FILE IS OBSOLETE ###" at the top, and
> anaconda, etc. could key off that line (and/or whether the file has any
> non-comment lines in it).
>
> --
> Chris Adams <cmadams(a)hiwaay.net>
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
>
>
9:09 a.m.
Bill Nottingham wrote:
With the switch to upstart, we obviated the need for /etc/inittab
(upstart
does not need it, nor read it.)
Initially, we added a quick hack that read /etc/inittab solely to determine
the default runlevel. Based on a bug I filed (#432384), we changed that so
that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
and we'e planning to just remove the inittab file to make things more obvious.
I suggested on fedora-test-list to just rename it to inittab.rpmsave
because there might be customizations in that file that the admin wants to
preserve/adopt. Appending ".rpmsave" has the following benefits:
1) It makes clear that this file is not interpreted by the tools that would
usually use the original version of that file.
2) It's still there so any special information in that file can be
preserved by the admin.
3) ".rpmsave" is a known postfix for stale/outdated files after an update
so any tools or scripts the admin uses to deal with them will do the right
thing(tm).
Regards,
Dennis
5:32 a.m.
On Thu, 2008-03-27 at 15:09 +0100, Dennis Jacobfeuerborn wrote:
Bill Nottingham wrote:
> With the switch to upstart, we obviated the need for /etc/inittab (upstart
> does not need it, nor read it.)
>
> Initially, we added a quick hack that read /etc/inittab solely to determine
> the default runlevel. Based on a bug I filed (#432384), we changed that so
> that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
> and we'e planning to just remove the inittab file to make things more obvious.
I suggested on fedora-test-list to just rename it to inittab.rpmsave
because there might be customizations in that file that the admin wants to
preserve/adopt. Appending ".rpmsave" has the following benefits:
/etc/inittab is already marked as %config(noreplace) which would leave
the new file as .rpmnew on updates of the initscripts package or (in the
case of the file moving to another package, e..g upstart) possibly
as .rpmsave or .rpmorig -- we should verify that and plan accordingly,
perhaps we need some anaconda hacks to make upgrades go smoothly here?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:19 a.m.
Bill Nottingham <notting <at> redhat.com> writes:
I'm open to better ideas, though - should we ship a trimmed
inittab that
contains *only* the initdefault line? Should we introduce a new configuration
flag somewhere else? Does it really matter in the long run?
I think the hack to parse inittab for initdefault is a better solution because
it's backwards-compatible. What do we gain from inventing a new file with a new
setting when we can just use the existing one?
Kevin Kofler
9:28 a.m.
On Thu, Mar 27, 2008 at 9:19 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Bill Nottingham <notting <at> redhat.com> writes:
> I'm open to better ideas, though - should we ship a trimmed inittab that
> contains *only* the initdefault line? Should we introduce a new configuration
> flag somewhere else? Does it really matter in the long run?
I think the hack to parse inittab for initdefault is a better solution because
it's backwards-compatible. What do we gain from inventing a new file with a new
setting when we can just use the existing one?
Because people might think that you could continue to use inittab for
other purposes.
IMHO, inittab should be read by the upstart %pre script to configure
whether GDM is started and maybe some other settings but otherwise it
should be ignored. If we're going to go whole-hog with upstart we
should be working on eliminating the notion of runlevels anyway.
Jeff
4:36 p.m.
Is there a way to pass the runlevel to the kernel like with old sysvinit?
Passing "3" to the kernel commandline would lt it boot runlevel 3 (no gdm/X).
Will this still work with upstart?
4:40 p.m.
On Sat, Mar 29, 2008 at 10:36 PM, drago01 <drago01(a)gmail.com> wrote:
Is there a way to pass the runlevel to the kernel like with old
sysvinit?
Passing "3" to the kernel commandline would lt it boot runlevel 3 (no gdm/X).
Will this still work with upstart?
just tested seems to work fine.
9:26 a.m.
Bill Nottingham (notting(a)redhat.com) said:
With the switch to upstart, we obviated the need for /etc/inittab
(upstart
does not need it, nor read it.)
Initially, we added a quick hack that read /etc/inittab solely to determine
the default runlevel. Based on a bug I filed (#432384), we changed that so
that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
and we'e planning to just remove the inittab file to make things more obvious.
I'm open to better ideas, though - should we ship a trimmed inittab that
contains *only* the initdefault line? Should we introduce a new configuration
flag somewhere else? Does it really matter in the long run?
OK, upon further consideration:
- We're still supporting SysV runlevels in F9
- Given that, we need to support people who customize it beyond 3 and 5
- Rather than invent a new file/key for that (as GRAPHICAL= doesn't cut it), it
probably makes sense to just leave it in inittab for now, and revisit when we've
done more migration
Hence, I'll flip things back in event-compat-sysv, and anaconda - the 'id:'
line in inittab will be read for the default runlevel. (If it's not there,
it will default to 3.)
initscripts with an appropriately neutered inittab with commentary will
show up at some point today. man pages for upstart event syntax will
follow.
All clear as mud?
Bill
2:35 p.m.
Bill Nottingham wrote:
Bill Nottingham (notting(a)redhat.com) said:
> With the switch to upstart, we obviated the need for /etc/inittab (upstart
> does not need it, nor read it.)
>
> Initially, we added a quick hack that read /etc/inittab solely to determine
> the default runlevel. Based on a bug I filed (#432384), we changed that so
> that the key for runlevel 3 vs. runlevel 5 is GRAPHICAL in /etc/sysconfig/init,
> and we'e planning to just remove the inittab file to make things more obvious.
>
> I'm open to better ideas, though - should we ship a trimmed inittab that
> contains *only* the initdefault line? Should we introduce a new configuration
> flag somewhere else? Does it really matter in the long run?
OK, upon further consideration:
- We're still supporting SysV runlevels in F9
- Given that, we need to support people who customize it beyond 3 and 5
- Rather than invent a new file/key for that (as GRAPHICAL= doesn't cut it), it
probably makes sense to just leave it in inittab for now, and revisit when we've
done more migration
Hence, I'll flip things back in event-compat-sysv, and anaconda - the 'id:'
line in inittab will be read for the default runlevel. (If it's not there,
it will default to 3.)
initscripts with an appropriately neutered inittab with commentary will
show up at some point today. man pages for upstart event syntax will
follow.
All clear as mud?
what happened with the respawn lines?
is there anything similar in upstart? with normal services in init.d/
it's not possible.
--
Levente "Si vis pacem para bellum!"
2:55 p.m.
Bill Nottingham wrote:
Farkas Levente (lfarkas(a)bppiac.hu) said:
> what happened with the respawn lines?
Not sure what you mean? upstart supports respawning services.
that's enough, thanks. just another question will rhel switch to upstart
in rhel 6 or even earlier eg. 5.3?
--
Levente "Si vis pacem para bellum!"
5866
days inactive
5874
days old
30 comments
22 participants
participants (22)
-
Andy Burns -
Bill Nottingham -
Brian Wheeler -
Casey Dahlin -
Chris Adams -
Clark Williams -
Daniel P. Berrange -
David Mansfield -
Dennis Jacobfeuerborn -
Dmitry Butskoy -
drago01 -
Farkas Levente -
Jef Spaleta -
Jeffrey Ollie -
Jeremy Katz -
Jesse Keating -
Kevin Kofler -
Michael E Brown -
Nils Philippsen -
Ralf Ertzinger -
Stephen John Smoogen -
Will Woods