3

For 1 week I could not loggin through gdm. I switcht to virtual console to investigate the situation. But whenever I tried to execute a command some system messages appeared and interrupted me. From tty1 till tty6.

The only way to repair my OS was over chroot. How can I avoid this for the next time.

lsb_release -a:

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.7 (jessie)
Release:    8.7
Codename:   jessie

Which process do I have to stop exactly? rsyslog?

Improve this question
4
  • It depends what the messages were. If they were being written to the ttys then it's likely they were coming directly from the kernel. The messages might well have pointed to the reason you couldn't log in via the GUI.
    – roaima
    Mar 1, 2017 at 8:33
  • I can not remember. But the Problem was with unattended upgrade fixes for Kernel came in.
    – user192526
    Mar 1, 2017 at 8:43
  • 1
    It's Debian so you might find them in /var/log/kern.log (or one of the similarly named old files).
    – roaima
    Mar 1, 2017 at 9:00
  • Nothing relevant in kern.log, but in Xorg.log. It was maybe a problem with dkms and nvidia-modul. This is fixed. But what should I stop for the next time to prevent the floating. I'm not excited to chroot for repairing. Stopping display-manager? And Xorg? In this case?
    – user192526
    Mar 1, 2017 at 10:42

1 Answer 1

Reset to default
2

When you are at a console, and logs do not let you work, use the command as sudo/root:

dmesg -n 1

and the logs will stop being shown in the console.

From man dmesg:

   -n, --console-level level
          Set  the level at which printing of messages is done to the con‐
          sole.  The level is a level number or abbreviation of the  level
          name.  For all supported levels see the --help output.

          For  example,  -n  1  or  -n alert prevents all messages, except
          emergency (panic) messages, from appearing on the console.   All
          levels  of  messages  are  still  written to /proc/kmsg, so sys‐
          logd(8) can still be used to control exactly where  kernel  mes‐
          sages  appear.  When the -n option is used, dmesg will not print
          or clear the kernel ring buffer.

If memory does not betray me, 

dmesg -n 0

puts you back having messages in the console once you are finished with your job

rsyslog.conf/syslog-ng.conf can also be changed to stop logging to text/X consoles, though you may want to leave that as by default, as they provide invaluable feedback when you really need it.

Do bear in mind the actual log messages are just output to stdout, and are not going to stdin, so despite you losing meaningful visual feedback, you can still input commands in a go, like the above mentioned dmesg -n 1. Just be sure that when you are typing command by touch on that situation not to use any potentially damaging commands like rm. Stuff happens.

Improve this answer

You must log in to answer this question.