Setting the default runlevel from inittab is a long-standing behavior. Even upstart does not disrupt this. Making this file continue to work will reduce transition pain. I suggest this behavior: - If /etc/inittab exists and contains an initdefault line, the default target will be set accordingly. - any other non-comment, non-blank lines in /etc/inittab will be logged as warnings. This leaves a migration path (ditch the file completely) while maintaining some backwards compatibility. For a number of releases, the file can continue to exist with a warning in the comments and the release notes, and then eventually it can go away.
inittab was discussed extensively in the email thread starting here: http://lists.fedoraproject.org/pipermail/devel/2010-July/138893.html
Thanks Michal. I didn't remember that particular branch of that long thread. I've read some of the discussion just now, and I see several people making suggestions similar to the above. There's extensive discussion, but no real conclusion is reached. I see Lennart was not convinced back then, but I think that he has come around a little bit in general on the issue of supporting some legacy syntax for the purposes of backwards compatibility during the transition. It's a relatively small thing to do, and one pragmatic way to look at it is: do we want to encourage even more threads arguing about the merits of legacy vs. progress, or should we just implement a forward-looking compatibility option and move on?
What do you mean by 'will be set'? What do you do if default.target exists, and inittab is different? (The reason that upstart still read inittab was because it didn't have a native setting location for the default boot target.)
(In reply to comment #3) > What do you mean by 'will be set'? What do you do if default.target exists, and > inittab is different? If it exists, the inittab initdefault should override default.target. Perhaps to maintain consistency, it should even cause the default target link to be changed. Note that I'm not commenting on whether the inittab file we ship should contain an initdefault line or just a short paragraph explaining the new system. In fact, I lean slightly to the latter. But if someone *does* put something in there, make it work. > (The reason that upstart still read inittab was because it didn't have a native > setting location for the default boot target.) Arguably, /etc/inittab *is* its native setting location for the default boot target.
I see little reason to repeat this discussion here. I'd rather do real work than repeating all discussions multiple times at different places. The result of the last discussion is that we now read initdefault on package installation. And we already have support in the %post script of the rpm to read the old initdefault setting from the inittab and apply the respective config change to systemd -- since quite some time. I have no plans to deobselete stuff that Upstart had already long obsoleted. Sorry. Closing.
(In reply to comment #5) > I see little reason to repeat this discussion here. I'd rather do real work > than repeating all discussions multiple times at different places. Ok. You are welcome to have (or ignore, and appear haughty, as the case may be) this discussion over and over again once systemd is widely deployed rather than making a small change now. > The result of the last discussion is that we now read initdefault on package > installation. And we already have support in the %post script of the rpm to > read the old initdefault setting from the inittab and apply the respective > config change to systemd -- since quite some time. That keeps from horribly breaking things on upgrade, which is better than nothing. But it isn't user-friendly behavior. > I have no plans to deobselete stuff that Upstart had already long obsoleted. > Sorry. Closing. As Bill says in comment #3, this statement is not true. Upstart does not obsolete this behavior -- in fact, it is the only supported config file for setting the default runlevel. I am changing the resolution of this bug from NEXTRELEASE to WONTFIX, as your comment indicates that you're deciding not to fix the issue, not that you're fixing it for the next release.
Shouldn't /etc/inittab comments be updated to reflect the current state? The comments there now are misleading and points to conf files in /etc/init which are from upstart.
As long as upstart is still supported, sort of hard to have both in one file.
Yes, will have to remember to change the comments if systemd obsoletes upstart in the near future. Do you want me to file it against initscripts?
Sure.
There's already a patch for the inittab blurb, which I sent to Bill. As I understood Bill he wanted to apply it after the beta when the adoption of systemd as default is clear.
Hey, I don't care if it moves, but for God's sake, put a comment in /etc/inittab saying exactly where in the hell it moved to. I've just read all the comments in this bugzilla, and I still have no idea where it lives (other than a file possibly named default.target that exists in some directory somewhere :-).
For posterity, refer to http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions