|
Bugzilla – Full Text Bug Listing |
| Summary: | systemd: tty is always cleared after logout | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Jan Engelhardt <jengelh> |
| Component: | Basesystem | Assignee: | 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
created request id 155703 *** Bug 721660 has been marked as a duplicate of this bug. *** 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. pre-systemd behavior was that no ttys were deallocated, IIRC. 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. What SLES does: clear and no-deallocate. Getting this done in systemd is not all that hard IMO, so I have created sr#155714. >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. (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. duplication was backwards *** This bug has been marked as a duplicate of bug 721660 *** >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. This is an autogenerated message for OBS integration: This bug (804158) was mentioned in https://build.opensuse.org/request/show/155753 Factory / systemd This is an autogenerated message for OBS integration: This bug (804158) was mentioned in https://build.opensuse.org/request/show/173312 Factory / systemd This change misses all serial lines. Please fix that as well! 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. Every sle12 install has this issue. And in the end its about preserving existing, sane behaviour, not so much about tty1. 12.3 is out of scope 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. Scratch the last paragraph. It was asked during commit. 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
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. |