4

I have systemd configured to not clear the terminal before calling getty, and also getty itself is run with the --noclear option, so that my boot messages are left displayed when the login prompt from getty appears at the bottom of the screen.

Well, at least they did until three months ago. Now, what happens is the following. Systemd leaves the boot messages on the screen (as I asked it to) and getty does not clear the screen (as I also instructed it to), but after a few seconds, the screen flickers, the boot messages are gone, and a new login prompt is shown on the top of the screen (actually, the screen flickers some three or four times, as I describe below).

I don't know it this is worth mentioning, but if I don't touch the keyboard, the boot messages get cleared after a few seconds. But if I readily start typing my username as soon as the prompt asks for it, and don't hit enter, there is no clearing.

Respawning

These are some relevant journal lines from during boot:

-- Reboot --
Dec 16 22:46:25 smt-dell systemd[1]: systemd 228 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Dec 16 22:46:25 smt-dell systemd[1]: Created slice system-netctlx2dauto.slice.
Dec 16 22:46:25 smt-dell systemd[1]: Created slice system-getty.slice.
Dec 16 22:46:33 smt-dell systemd[1]: Starting Login Service...
Dec 16 22:46:33 smt-dell systemd[1]: Starting Automatic wireless network connection using netctl profiles...
-- Subject: Unit netctl-auto@wlp3s0.service has begun start-up
Dec 16 22:46:34 smt-dell systemd[1]: Started Getty on tty1.
Dec 16 22:46:34 smt-dell systemd-logind[327]: New seat seat0.
Dec 16 22:46:34 smt-dell systemd[1]: Reached target Login Prompts.
Dec 16 22:46:34 smt-dell systemd[1]: Started Login Service.
Dec 16 22:46:35 smt-dell systemd[1]: Started Automatic wireless network connection using netctl profiles.
Dec 16 22:46:35 smt-dell wpa_actiond[391]: Starting wpa_actiond session for interface 'wlp3s0'
Dec 16 22:46:35 smt-dell systemd[1]: Reached target Network.
Dec 16 22:46:35 smt-dell systemd[1]: Reached target Multi-User System.
Dec 16 22:46:35 smt-dell systemd[1]: Startup finished in 2.630s (kernel) + 12.170s (userspace) = 46.781s.
Dec 16 22:46:39 smt-dell kernel: wlp3s0: authenticated
Dec 16 22:46:39 smt-dell kernel: wlp3s0: associated
Dec 16 22:46:39 smt-dell wpa_actiond[391]: Interface 'wlp3s0' connected to network 'wl-usb'

There is no log of getty respawning (as @JdeBP suspected in the comments).

Timestamps of the visual events

I recorded the boot (on camera) and wrote down all the events. I have the \t, \4, and \6 escape sequences in /etc/issue, which show the current time, IPv4 address, and IPv6 address. (These are for the same boot as the journal lines above, so the timestamps should be compared)

  1. Boot messages are still on the screen. The issue message at the bottom reads:
    • \t: 22:46:35
    • \4: empty
    • \6: empty
  2. The boot messages and the first issue message have been cleared, and the second issue message reads:
    • \t: 22:46:39
    • \4: 192.168.7.119
    • \6: a shortened (::-syntax) IPv6 address
  3. The second issue message has been cleaned, and the third reads:
    • \t: 22:46:41
    • \4: 192.168.7.119
    • \6: a full IPv6 address (all bytes shown explicitly)
  4. Screen cleared for the last time, and the fourth and last issue message:
    • \t: 22:46:42
    • \4: 192.168.7.119
    • \6: the same

Netctl

Thanks to a recent bug (in netctl, or wpa_supplicant, or wpa_actiond, I don't know), I discovered that when netctl-auto is disabled, there is no clearing of the boot messages, nor any re-displaying of the issue message. When I fixed the bug, the boot messages started getting cleared again. When I manually disable netctl-auto, there is no clearing of the screen, and when I enable it again, the screen gets cleared several times, as explained above.

Question

If it's not clear, my question is: why on Earth would netctl cause the screen to be cleared and the issue message to be displayed again? And is it possible to disable this behavior?

Relevant links

I have also asked this question on the Arch Linux forums.

fonini
  • 324
  • What distro are you using? Which are the services that configure your network? Is it possible, that the change in network configuration triggers a restart of services that allow logon? – Bananguin Dec 16 '15 at 07:12
  • archlinux. The network is configured by netctl-auto. I really don't think netctl restarts anything when network state changes. There is no need to, and arch is pretty minimalistic when it comes to this kind of thing. – fonini Dec 16 '15 at 07:16
  • 1
    Yet another way in which the world wants you to clean your screen. You should [edit] your question with the systemctl status of the TTY login service for your virtual terminal. – JdeBP Dec 16 '15 at 07:45
  • The question you link only lists common reasons for which the screen might be getting cleared. It couldn't be a logout script, because it happens before the first login. It also isn't a "clear terminal" escape sequence in /etc/issue. I do have --noclear and TTYVTDisallocate=no in my unit files (and indeed, systemd does not clear the boot messages right after boot -- there's a delay). – fonini Dec 16 '15 at 11:32
  • All of those timestamps in the output: when are they in relation to your system bootstrap? Looking at logs; checking timestamps; checking status info. This is how one debugs such things on a systemd operating system. This is what you need to put into a question. It is how you determine whether your basic assertion that systemd is respawning getty is even true in the first place, and demonstrate it to the world. After all, if your system bootstrapped at 09:17, it's false. systemd records what was spawned when. Show that to answerers. – JdeBP Dec 16 '15 at 14:30
  • @JdeBP I think you're right. I couln't find any sign of respawning in the jounal. I thought that the only way for getty to rewrite the issue message and display a new login prompt was this respawn thing. – fonini Dec 17 '15 at 02:12
  • you dont have to use a getty. i sometimes use kmscon - i like it much better. but anyway, i would think if there were some clear or whatever being sent you could track it in /dev/vcsa. you might want to start up a backgrounded cat of that before your getty and have a look at all of the escapes that are running. you might also want to have a look at what is going on with PAM and loginctl - systemd does a lot of weird, unnecessary stuff a lot of the time, unfortunately. maybe its your video driver? an efi system will switch buffers right around then - from EFI to VGA. – mikeserv Dec 17 '15 at 02:26
  • @mikeserv I tried this vcsa thing (had never heard of it). I substituted -/sbin/agetty --noclear %I $TERM for a script that runs cat /dev/vcsa >/root/cat-dev-vcsa & exec /sbin/agetty "$@", but I don't know if that's what you meant. The /root/cat-dev-vcsa is truncated and really hard to parse, I can't find any clear-terminal sequences in it. Also, when getty is called through this script, it shows the /etc/issue message, but I can't login (after I type my password, it just shows me the issue message and login prompt again). – fonini Dec 20 '15 at 05:19
  • But anyay, now I'm pretty sure it's caused by netctl. When netctl-auto is disabled, the boot messages are left on the screen. – fonini Dec 20 '15 at 05:20
  • @fonini - guess you found it then. – mikeserv Dec 20 '15 at 05:37

1 Answers1

0

I found something like this.. after adding --noclear to getty@tty1.service, I had to recreate the initramfs

[Service]
TTYVTDisallocate=no
ExecStart=
ExecStart=-/usr/bin/agetty --autologin root --noclear %I $TERM

then...

mkinitcpio -g /boot/initramfs-linux.img

Boot screen no longer clears.

Scott - Слава Україні
  • 10,519
Jason Godsey
  • 1
  • According to the Arch Wiki, --noclear is already the default, which is easy to confirm in one's system by inspecting the output of systemctl cat getty@tty1. Also, I believe that mkinitcpio runs everytime I update the kernel, so if this would have worked for me, it should have been working for some time hehe. – fonini Mar 13 '18 at 22:51