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.


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:
    • \6: a shortened (::-syntax) IPv6 address
  3. The second issue message has been cleaned, and the third reads:
    • \t: 22:46:41
    • \4:
    • \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:
    • \6: the same


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.


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.

  • 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 7: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 7: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 7: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

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

ExecStart=-/usr/bin/agetty --autologin root --noclear %I $TERM


mkinitcpio -g /boot/initramfs-linux.img

Boot screen no longer clears.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.