Bug 5091 - Boot log messages are shown after the login prompt in text mode
Summary: Boot log messages are shown after the login prompt in text mode
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL: http://dutheil.dyndns-server.com/mage...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-25 15:52 CEST by Andre Dutheil
Modified: 2012-05-02 23:39 CEST (History)
7 users (show)

See Also:
Source RPM: systemd
CVE:
Status comment:


Attachments

Description Andre Dutheil 2012-03-25 15:52:35 CEST
Description of problem:
Boot log messages are shown after the login prompt in text mode

How reproducible:
Mageia-2-beta2-i586-DVD instaled in virtual box 4.1.10 r76836 running on Windows 7 ultimate 64 Bits.

Steps to Reproduce:
1. Install with lxde but do not enable automatic X start, LSB and mariadb.
2. Boot
3. See the result: http://dutheil.dyndns-server.com/mageia-2B-01.html

Hit enter and the login prompt shows up again.
Comment 1 Manuel Hiebel 2012-03-27 01:48:50 CEST
I don't see why this is a bug, you boot whithout, so you don't after X, or do you want the plymouth splash ?

Keywords: (none) => NEEDINFO

Comment 2 Dave Hodgins 2012-03-27 02:29:41 CEST
I agree that it's an annoyance.  When using run level three, you
get the login prompt, and as you are typing in the user name, the
remaining messages make it difficult to see what you're doing.

However, as the only way I can think of to fix this, is to delay
the startup of the getty until after everything else, I'd rather
have the annoyance, as the messages can be ignored.

CC: (none) => davidwhodgins

Comment 3 Manuel Hiebel 2012-03-27 02:44:45 CEST
sorry for my very bad sentence :s
Comment 4 Frank Griffin 2012-03-27 12:21:12 CEST
I think the point is that whatever is writing to tty1 ought to claim that device until it is finished, in the same way that getty does.  That way, getty can start early and just claim tty2 without conflict.  Way back when, the startup stuff used to go to tty12 for exactly this reason, to get it out of the way.

CC: (none) => ftg

Comment 5 Dave Hodgins 2012-03-28 01:16:35 CEST
(In reply to comment #4)
> I think the point is that whatever is writing to tty1 ought to claim that
> device until it is finished, in the same way that getty does.  That way, getty
> can start early and just claim tty2 without conflict.  Way back when, the
> startup stuff used to go to tty12 for exactly this reason, to get it out of the
> way.

Although it's pretty difficult to test, I'm pretty sure that
if you press alt+ctrl+f2 after the login prompt appears on
tty1, but before the other messages show up, then those messages
will show up on tty2.  I.E. whatever the currently active
text tty is.
Comment 6 Andre Dutheil 2012-03-28 04:33:21 CEST
(In reply to comment #5)
> (In reply to comment #4)
> > I think the point is that whatever is writing to tty1 ought to claim that
> > device until it is finished, in the same way that getty does.  That way, getty
> > can start early and just claim tty2 without conflict.  Way back when, the
> > startup stuff used to go to tty12 for exactly this reason, to get it out of the
> > way.
> 
> Although it's pretty difficult to test, I'm pretty sure that
> if you press alt+ctrl+f2 after the login prompt appears on
> tty1, but before the other messages show up, then those messages
> will show up on tty2.  I.E. whatever the currently active
> text tty is.
You are right. Tested with alt+ctrl+f12 and some more messages were shown:

See result: http://dutheil.dyndns-server.com/mageia-2B-01.html

tty1 login remains clean.
Comment 7 Andre Dutheil 2012-03-28 04:36:18 CEST
The correct link is http://dutheil.dyndns-server.com/mageia-2B-02.html
Comment 8 Andre Dutheil 2012-03-28 04:38:54 CEST
Reviewing the last image I just found that the messages are mixed portuguese and english. Install was done choosing brazilian portuguese language.
Comment 9 Marja Van Waes 2012-04-14 23:04:13 CEST
The mixed language is a different issue, for the messages of some programs there is no  Brazilian Portuguese translation available, so they are given in English. 

Reading the comments about the cause of the messages at the login prompt, the solution that will give more delay and the good workaround, I think this bug should be closed as WONTFIX

Do you agree?

Keywords: NEEDINFO => (none)
CC: (none) => marja11

Comment 10 Felix Miata 2012-05-02 03:06:42 CEST
(In reply to comment #9)
> I think this bug should be closed as WONTFIX

> Do you agree?

No. Login prompt on tty1 should be delayed until init process is done writing there.

CC: (none) => mrmazda

Comment 11 Marja Van Waes 2012-05-02 08:53:18 CEST
We don't have a maintainer for the package, so cc'ing two committers.

CC: (none) => mageia, tmb
Source RPM: (none) => initscripts

Comment 12 Dave Hodgins 2012-05-02 08:57:33 CEST
(In reply to comment #10)
> (In reply to comment #9)
> > I think this bug should be closed as WONTFIX
> 
> > Do you agree?
> 
> No. Login prompt on tty1 should be delayed until init process is done writing
> there.

I strongly disagree.
Comment 13 Marja Van Waes 2012-05-02 09:48:50 CEST
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > I think this bug should be closed as WONTFIX
> > 
> > > Do you agree?
> > 
> > No. Login prompt on tty1 should be delayed until init process is done writing
> > there.
> 
> I strongly disagree.

Is initscripts the correct package, btw? If it should be systemd or sysvinit or even something else, please change it.
Comment 14 Colin Guthrie 2012-05-02 10:20:42 CEST
It should really be systemd. Corrected that.

FWIW, I'm now somewhat split regarding this issue. Part of me would like a login prompt ASAP and thus delaying until after all default target jobs are complete would be in many ways unnecessary (we currently delay them until a specific service (systemd-user-sessions) is ready, thus ensuring that e.g. NSS is available for remote user lookup, NFS mounts are available for $HOME etc. but there is typically no real reason to wait for e.g. httpd to finish starting before logging in.

However, on reflection, I'm actually not that bothered about tty login availability speed. Sure it's "nice", but it's certainly not a requirement per-se. Arguably it's also a nice indicator to know that when the TTY is ready, the system has finished booting. Obviously this does NOT apply to graphical logins which should be shown as soon as possible. Here perceived speed really does matter.

Anyway, upstream have now added support for "idle" units are are using them for getty's which solve this problem: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2b6878955b1f77ea1fa87b502b13d5dbefc57f6

I see no specific reason not to follow that and sysadmins are welcome to create their own getty@.service file and place it in /etc/systemd/system if they prefer a different approach (e.g. adding "ExecStartPre=-/bin/kill -53 1" to the current getty@.target should tell systemd to stop outputting status messages to the console and thus prevent leakage over the login prompts).

So there are fixes for both problems. I prefer to take the upstream approach whenever necessary, but I'm not sure I'll be able to backport it easily due to upstream tree changes and without pulling in a lot of other commits that I'd rather not have to test etc. at this stage in the game. So I think the kill approach is maybe the better one for mga2 with a transition to whatever upstream provides later.

As sysadmins will ultimately have control, I think this is the most sensible compromise. Does everyone agree?

Source RPM: initscripts => systemd

Comment 15 Sander Lepik 2012-05-02 10:29:07 CEST
(In reply to comment #14)
> Does everyone agree?
Sounds like a reasonable way to go.

CC: (none) => sander.lepik

Comment 16 Colin Guthrie 2012-05-02 10:49:42 CEST
In that case can someone affected please try adding:

ExecStartPre=-/bin/kill -55 1

to their:
/lib/systemd/system/getty@.service

file and rebooting to see if the problem is solved?

Cheers
Comment 17 Dave Hodgins 2012-05-02 20:24:05 CEST
I've tested with the kill, and it works.  Looks like a good approach
to me.
Comment 18 Colin Guthrie 2012-05-02 23:39:09 CEST
OK, I've added this fix to the latest systemd package.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


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