Bug 804158

Summary: systemd: tty is always cleared after logout
Product: [openSUSE] openSUSE Distribution Reporter: Jan Engelhardt <jengelh>
Component: BasesystemAssignee: systemd maintainers <systemd-maintainers>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P1 - Urgent CC: hpj
Version: Leap 15.1   
Target Milestone: Leap 15.1   
Hardware: All   
OS: Linux   
Whiteboard:
Found By: Beta-Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Jan Engelhardt 2013-02-16 13:21:43 UTC
ttys are always cleared after logout, despite --noclear:

ExecStart=-/sbin/agetty --noclear %I 38400 linux

The culprit is:

TTYVTDisallocate=yes

Removing this line brings back the well-known behavior of not clearing the tty.
Comment 1 Jan Engelhardt 2013-02-18 09:54:20 UTC
created request id 155703
Comment 2 Jan Engelhardt 2013-02-18 09:59:31 UTC
*** Bug 721660 has been marked as a duplicate of this bug. ***
Comment 3 Frederic Crozat 2013-02-18 10:02:25 UTC
I've rejected your proposed change, because only tty1 should be "no-clear", not other ttys (since the purpose is to reimplement pre-systemd behaviour). This means shipping a .service different for tty1 than other tty.
Comment 4 Jan Engelhardt 2013-02-18 10:04:58 UTC
pre-systemd behavior was that no ttys were deallocated, IIRC.
Comment 5 Frederic Crozat 2013-02-18 10:12:36 UTC
I just checked on SLES 11 SP2 (based on 11.1) and all ttys but tty1 were deallocated. And I'm convinced the reason for tty1 not being deallocated was to show boot messages.
Comment 6 Jan Engelhardt 2013-02-18 10:44:17 UTC
What SLES does: clear and no-deallocate. Getting this done in systemd is not all that hard IMO, so I have created sr#155714.
Comment 7 Jan Engelhardt 2013-02-18 12:07:22 UTC
>There is no reason to modify getty@.service for implementing tty1 to get --no-clear, please don't touch this file. I prefer we stay as close as possible to upstream (even if people insist on getting --no-clear on tty1)

getty@.service is modified to match the pre-systemd behavior for tty*, which was not to deallocate the VT. (Because once deallocated, /dev/vcs* no longer what was on it)

getty@tty1.service is then subsequently added to implement the pre-systemd tty1 semantics.

>Don't replace macros (%makeinstall) which are doing what is expected to do.

They don't do the same on all distros, which is why %makeinstall is a bad idea.
Comment 8 Frederic Crozat 2013-02-18 12:10:49 UTC
(In reply to comment #7)
> >There is no reason to modify getty@.service for implementing tty1 to get --no-clear, please don't touch this file. I prefer we stay as close as possible to upstream (even if people insist on getting --no-clear on tty1)
> 
> getty@.service is modified to match the pre-systemd behavior for tty*, which
> was not to deallocate the VT. (Because once deallocated, /dev/vcs* no longer
> what was on it)

Except systemd expects on VT deallocation to flushback scrollbuffers (see 6ea832a20700f5282c08c70f38422c6ab290a0b5 ). 

> 
> getty@tty1.service is then subsequently added to implement the pre-systemd tty1
> semantics.
> 
> >Don't replace macros (%makeinstall) which are doing what is expected to do.
> 
> They don't do the same on all distros, which is why %makeinstall is a bad idea.

I'm packaging systemd for openSUSE where this macro has a define value.
Comment 9 Felix Miata 2013-02-18 12:42:35 UTC
duplication was backwards

*** This bug has been marked as a duplicate of bug 721660 ***
Comment 10 Jan Engelhardt 2013-02-18 13:47:37 UTC
>Except systemd expects on VT deallocation to flushback scrollbuffers

Reading through the bugzilla report, the way it looks is that Fedora wanted
that behavior for its distro. systemd itself does not expect it (say, for
finishing a log file or something). But ok.


So how is the changeset supposed to look? We certainly need a
getty@tty1.service, to remove TTYVTDisallocate.

As for getty@.service, having both --noclear and TTYVTDisallocate is a
confusion.
Comment 11 Bernhard Wiedemann 2013-02-18 17:00:14 UTC
This is an autogenerated message for OBS integration:
This bug (804158) was mentioned in
https://build.opensuse.org/request/show/155753 Factory / systemd
Comment 12 Bernhard Wiedemann 2013-04-25 08:00:10 UTC
This is an autogenerated message for OBS integration:
This bug (804158) was mentioned in
https://build.opensuse.org/request/show/173312 Factory / systemd
Comment 13 Olaf Hering 2014-03-05 13:43:42 UTC
This change misses all serial lines.

Please fix that as well!
Comment 14 Jan Engelhardt 2014-03-05 16:21:10 UTC
I cannot reproduce this on factory(13.2). Despite there being no "--noclear" in /usr/lib/systemd/system/serial-getty@.service, I do not get a screen clearing escape code over serial, whereby serial in my case is the PF_LOCAL socket connector for VirtualBox.
Comment 15 Olaf Hering 2014-03-05 16:53:34 UTC
Every sle12 install has this issue. And in the end its about preserving existing, sane behaviour, not so much about tty1.
Comment 16 Dr. Werner Fink 2015-11-12 14:41:44 UTC
12.3 is out of scope
Comment 17 Hans-Peter Jansen 2019-10-22 10:55:54 UTC
After a JeOS installation of Leap 15.1, this issue is back again, despite noclear.conf and agetty --noclear:

$ systemctl status getty@tty1
● getty@tty1.service - Getty on tty1
   Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/getty@tty1.service.d
           └─noclear.conf
   Active: active (running) since Tue 2019-10-22 12:45:02 CEST; 7min ago
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html
 Main PID: 1032 (agetty)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/system-getty.slice/getty@tty1.service
           └─1032 /sbin/agetty -o -p -- \u --noclear tty1 linux

Okt 22 12:45:02 localhost systemd[1]: Started Getty on tty1.

Fun fact: no specific openSUSE release is available in #boo.
Comment 18 Hans-Peter Jansen 2019-10-22 10:56:46 UTC
Scratch the last paragraph. It was asked during commit.
Comment 19 Dr. Werner Fink 2019-10-22 11:06:22 UTC
I can not reproduce this, I see noclear ... maybe you might check you (personal) shell configuration scripts (e.g. ~/.profile , ~/.bashrc, ~/.bash_logout, ...) for lines like

   clear

or

    echo -e "\033u\033c"

or whatsoever
Comment 20 Hans-Peter Jansen 2019-10-22 12:51:44 UTC
Opps, wrong issue.

I thought, this would work for the initial console setup as well (in order to preserve the boot messages, given one uses splash=verbose and omits quiet on kernel cmdline), but obviously, I'm barking at the wrong tree here. 

Any idea on how to preserve the boot messages is still welcomed.

Sorry for the confusion.