Bug 67114 - systemd-205: output from starting services messing up tty1 console
Summary: systemd-205: output from starting services messing up tty1 console
Status: RESOLVED WONTFIX
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-20 10:03 UTC by Pacho Ramos
Modified: 2013-07-26 20:28 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg.service (184 bytes, text/plain)
2013-07-26 08:04 UTC, Egor Y. Egorov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos 2013-07-20 10:03:14 UTC
Currently, when I boot, I see that some messages are still being shown even if login prompt is already shown:

This is belkin4.unknown_domain (Linux x86_64 3.9.9-gentoo) 12:52:45

belkin4 login: bbswitch: version 0.7
bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
bbswitch: detected an Optimus _DSM function
bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[drm] Module unloaded
bbswitch: disabling discrete graphics
pci 0000:01:00.0: Refused to change power state, currently in D0
pci 0000:01:00.0: power state changed by ACPI to D3cold
         Starting Manage, Install and Generate Color Profiles...
[  OK  ] Started GNOME Display Manager.
[  OK  ] Started Manage, Install and Generate Color Profiles.
EXT4-fs (sda6): re-mounted. Opts: commit=600

From my point of view, messages should stop trashing tty1 when getty is launched
Comment 1 Zbigniew Jedrzejewski-Szmek 2013-07-20 15:39:43 UTC
Those are kernel messages. You can turn them off by passing quiet or console_loglevel=5 on the kernel commandline.

We might actually want to do that automatically, maybe by invoking dmesg -n in the getty unit. Thoughts, anyone?
Comment 2 Kay Sievers 2013-07-20 16:39:50 UTC
So far we are very careful with messing with the defaults of the kernel.

People have different expectations and configure their kernel to that, and
unless we have a really good reason, we should leave these setting alone.

There is CONFIG_DEFAULT_MESSAGE_LOGLEVEL= in the kernel compile-time config,
that should be changed if we are sure we want a different default.

The kernel's log behavior is controlled by:
  /proc/sys/kernel/printk
see:
  man 5 proc
Comment 3 Pacho Ramos 2013-07-20 18:30:52 UTC
But, isn't systemd able to redirect that messages to journalctl or filter them? (kernel would still show the messages but they would be put in journalctl, that is what probably most people will prefer instead of losing the messages completely)
Comment 4 Zbigniew Jedrzejewski-Szmek 2013-07-20 18:35:12 UTC
(In reply to comment #3)
> But, isn't systemd able to redirect that messages to journalctl or filter
> them? (kernel would still show the messages but they would be put in
> journalctl, that is what probably most people will prefer instead of losing
> the messages completely)
Yes, but putting messages in the kernel log buffer is independent. Here we're only talking about the output that kernel is doing to the kernel console.
Comment 5 Kay Sievers 2013-07-20 18:38:50 UTC
The kernel's use of the console is entirely unrelated to what it stored
in the kernel log buffer (the stuff you see with dmesg) or what is imported
into the journal (the kernel stuff journalctl shows).

The messages will always end up in the kernel buffer and the journal, even
when the output is suppressed from the console. There is no re-direct, or
anything needed, systemd does not need to read the console, it's all in the
kernel log buffer anyway.

Note: The way the kernel puts stuff to the console and the default level of
showing almost everything comes from a time where it was exciting that the
kernel booted at all on a box, and Linux was used by people who ran their
self-compiled kernels and were happy that they could watch it doing its job. :)
Comment 6 Pacho Ramos 2013-07-20 18:39:47 UTC
No idea how openRC is able to filter that messages then :|
Comment 7 Kay Sievers 2013-07-20 18:44:26 UTC
It probably writes to:
  /proc/sys/kernel/printk
at bootup and just disables the kernel messages at the console, there is no
specific filtering of messages besides the log-level, right?
Comment 8 Kay Sievers 2013-07-20 18:48:29 UTC
OpenRC runs 'dmesg' to set the level:
  dmesg_level="1"
  dmesg -n$dmesg_level

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob;f=init.d/dmesg.in;hb=HEAD
Comment 9 Pacho Ramos 2013-07-20 18:53:35 UTC
Was just asking for that in #openrc IRC channel ;)
Comment 10 Lennart Poettering 2013-07-26 01:52:00 UTC
There isn't anything to fix in systemd here. If you want to get rid of these messages then boot with "quiet" on the kernel command line or drop in a /etc/sysctl.d/ snippet that fiddles with the "kernel.printk" variable. But systemd shouldn't do anything like that by default I am sure. This should be kernel configuration, boot-time configuration or user configuration, but not systemd overrides.
Comment 11 redneb 2013-07-26 07:13:23 UTC
How about doing what openrc does? That is, add a unit that calls dmesg -n4 or so at a very early point in the boot process. This way systemd would behave the same way no matter how the kernel was configured.
Comment 12 Egor Y. Egorov 2013-07-26 07:48:01 UTC
egorov-ey ~ # cat /etc/{conf,init}.d/dmesg
# Sets the level at which logging of messages is done to the
# console.  See dmesg(1) for more info.
dmesg_level="1"
#!/sbin/runscript
# Copyright (c) 2007-2008 Roy Marples <roy@marples.name>
# Released under the 2-clause BSD license.

description="Set the dmesg level for a cleaner boot"

depend()
{
        before dev modules
        keyword -lxc -prefix -vserver
}

start()
{
        if [ -n "$dmesg_level" ]; then
                dmesg -n$dmesg_level
        fi
}
egorov-ey ~ # ls -l /etc/runlevels/sysinit/dmesg
lrwxrwxrwx 1 root root 17 мая   10  2012 /etc/runlevels/sysinit/dmesg -> /etc/init.d/dmesg
egorov-ey ~ #
Comment 13 Egor Y. Egorov 2013-07-26 07:51:20 UTC
I'm sorry, did not notice the comment #8
Comment 14 Egor Y. Egorov 2013-07-26 08:04:25 UTC
Created attachment 83017 [details]
dmesg.service

Simpe fix for me.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.