Bug 828007

The clearing of the console is done by systemd itself, because the unit asks for it with "TTYVTDisallocate=yes". Just set the option to "no". See "man systemd.exec".

Thanks for quickly responding. However, neither TTYVTDisallocate=no alone (nor TTYReset=no) in /etc/systemd/system/getty.target.wants/getty prevent tty1 from being cleared prior to display of prompt here in F17. Symlinking getty to getty@.service doesn't help either. Including --noclear on the /sbin/agetty line is required as well as TTYVTDisallocate=no, which makes it seem to me like there is something wrong with systemd - it doesn't look like "the clearing of the console is done by systemd" all by itself.

Both programs can clear the console.
With "TTYVTDisallocate=no" you ask systemd not to clear it.
With "/sbin/agetty --noclear" you ask agetty not to clear it.

Agetty defaults to clear (requires --noclear to not clear). Getty accepts the default.
TTYVTDisallocate defaults to no (do not clear), which getty rejects by setting to yes.

So, getty is twice causing clearing to occur. Why is that not a bug? Who that never reads this bug will ever figure out that two independent changes in the same config file are required to prevent tty1 from clearing?

Added --noclear to avoid redundant clearing of the VT:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=3305d6806d428010b1cd2abd716aa1bb7f81311f

So now getty will have two lines set to cause non-default behavior so as to cause tty1 to clear by default. Why not do the opposite instead, by removing --noclear from the /sbin/agetty line, and either restoring TTYVTDisallocate to its default by changing the yes to no, or removing the TTYVTDisallocate line altogether?

How many ordinary tweakers, seeing --noclear on the /sbin/agetty line, and wanting tty1 to clear, will ever discover the cause of the clearing, with the explanation of the abstruse TTYVTDisallocate hidden away in the systemd.exec man page?

Does TTYVTDisallocate even need to exist? Don't all the alternatives to agetty that might be substituted for it in getty clear by default?

Maybe a comment regarding this unintuitive configuration needs to be included in /usr/lib/systemd/system/getty@.service?

(In reply to comment #6)
> Why not do the opposite instead, by removing --noclear from the /sbin/agetty
> line, and either restoring TTYVTDisallocate to its default by changing the yes
> to no, or removing the TTYVTDisallocate line altogether?

VT disallocation is a stronger operation that clearing. And vt_disallocate() in systemd falls back to clearing if disallocation cannot be performed for some reason.

> How many ordinary tweakers, seeing --noclear on the /sbin/agetty line, and
> wanting tty1 to clear, will ever discover the cause of the clearing, with
> the explanation of the abstruse TTYVTDisallocate hidden away in the
> systemd.exec man page?

Did you look at the git commit I linked to? There is a comment above the ExecStart line:
# the VT is cleared by TTYVTDisallocate

> Does TTYVTDisallocate even need to exist?

We could live without it, but it's nice to have and it's already there.

> Don't all the alternatives to agetty that might be substituted for it in
> getty clear by default?

I don't know and I don't care. I am not interested in alternatives to util-linux. We're unifying the OS platform, not supporting pointless differences. Whoever is substituting other software for agetty in the unit file can modify the value of TTYVTDisallocate too if really necessary.

(In reply to comment #7)
> Did you look at the git commit I linked to? There is a comment above the
> ExecStart line:
> # the VT is cleared by TTYVTDisallocate
 
As a non-programmer, I usually find patches incomprehensible, so am not in the habit of looking at them. This is one of the unusual cases where doing so would have precluded any need to comment or question further.

systemd-44-13.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-13.fc17

I installed systemd-44-14 and systemd-sysv-44-14 from updates testing, modified the new /etc/systemd/system/getty@.service -> getty with TTYVTDisallocate=no, but still tty1 clears on boot. :-(

Did you do "systemctl daemon-reload" or reboot after modifying the unit file?

multiple reboots with same disappointing result

(In reply to comment #10)
> modified the new /etc/systemd/system/getty@.service -> getty

What exactly do you mean by this notation? Which file is a symlink to where? And which files did you edit?

I copied the new getty@.service from /usr/lib/systemd/system to /etc/systemd/system, changed its name to getty, made the edit, rebooted.

Hm, the method works for me.

What do you get from this command?:

 systemctl show -p ActiveState -p FragmentPath -p TTYVTDisallocate \
   getty

An alternative method, which also works for me, is saving this small file as /etc/systemd/system/getty :

.include /lib/systemd/system/getty@.service
[Service]
TTYVTDisallocate=no

(In reply to comment #15)
> What do you get from this command?:
 
> systemctl show -p ActiveState -p FragmentPath -p TTYVTDisallocate \
> getty

ActiveState=active
FragmentPath=/usr/lib/systemd/system/getty@.service
TTYVTDisallocate=yes

To be clear, there is purposely no longer any symlink between /usr/lib/systemd/system and /etc/systemd/system/getty.target.wants.

(In reply to comment #16)
> An alternative method, which also works for me, is saving this small file as
> /etc/systemd/system/getty :
 
> .include /lib/systemd/system/getty@.service
> [Service]
> TTYVTDisallocate=no

I tried the comment 16 suggestion after emptying /etc/system/systemd/getty.target.wants and recreating the symlink in it to /usr/lib/systemd/system/getty@service.
# ls -l /etc/systemd/system/getty.target.wants 
lrwxrwxrwx 1 root root 38 Jun 15 11:58 getty@.service -> /usr/lib/systemd/system/getty@.service
-rw-r--r-- 1 root root 78 Jun 15 12:00 getty

Still tty1 is clearing on boot.

(In reply to comment #17)
> FragmentPath=/usr/lib/systemd/system/getty@.service

This shows that the original unit file is used.

> # ls -l /etc/systemd/system/getty.target.wants 
> lrwxrwxrwx 1 root root 38 Jun 15 11:58 getty@.service ->
> /usr/lib/systemd/system/getty@.service
> -rw-r--r-- 1 root root 78 Jun 15 12:00 getty

That's not right. The *.target.wants/ directories should not contain unit files, only symlinks to them. Unit files should go into /{lib,etc}/systemd/system/, not in the deeper subdirectories.

This is how I have it now:

$ ls -l /etc/systemd/system/getty*
-rw-r--r--. 1 root root   74 Jun 15 23:22 /etc/systemd/system/getty

/etc/systemd/system/getty.target.wants:
total 0
lrwxrwxrwx. 1 root root 34 Jun 15 23:20 getty -> /lib/systemd/system/getty@.service

(In reply to comment #18)
>The *.target.wants/ directories should not contain unit
> files, only symlinks to them. Unit files should go into
> /{lib,etc}/systemd/system/, not in the deeper subdirectories.
 
By what definition or standard? /etc was made for global customization/configuration files, not the directories whose content is controlled by package management systems. http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION

Rather than doing as in comment 18, I tried the following, which is working without making any changes to existing files outside of the /etc tree:
# ls -l /etc/systemd/system/getty.target.wants
-rw-r--r-- 1 root root 1571 Jun 15 18:07 getty

# ls -l /usr/lib/systemd/system/gett*
-rw-r--r-- 1 root root 1572 Jun 14 18:17 /usr/lib/systemd/system/getty@.service
-rw-r--r-- 1 root root  353 Jun 14 18:17 /usr/lib/systemd/system/getty.target
lrwxrwxrwx 1 root root   57 Jun 15 18:07 /usr/lib/systemd/system/getty -> /etc/systemd/system/getty.target.wants/getty

I think you either misread what I wrote, or misunderstood what I meant by "/{lib,etc}". All my customizations are under /etc.

(In reply to comment #20)
> All my customizations are under /etc.

You may have been in /etc/systemd/system/gettyy.target.wants/ when you wrote your change, but (from comment 18):

/etc/systemd/system/getty.target.wants:
total 0
lrwxrwxrwx. 1 root root 34 Jun 15 23:20 getty -> /lib/systemd/system/getty@.service

says what you changed by editing the content of a symlink was /lib/systemd/system/getty@service, the original file (via another symlink, actually /usr/lib/systemd/system/getty@service). That means when I backup /etc and later need to restore it, I'll be restoring a symlink, which may or may not result in the content of the original in /usr/lib... being available via the symlink, depending on whether the original in /usr/lib... has been altered in the mean time or backed up and restored in conjunction with the /etc backup/restore process. I see this as a FHS violation. Maybe I see it wrong, but that's how I see it nevertheless.

(In reply to comment #21)
> /etc/systemd/system/getty.target.wants:
> total 0
> lrwxrwxrwx. 1 root root 34 Jun 15 23:20 getty ->
> /lib/systemd/system/getty@.service
> 
> says what you changed by editing the content of a symlink was
> /lib/systemd/system/getty@service, the original file (via another symlink,
> actually /usr/lib/systemd/system/getty@service).

No, I did no such thing. My /usr/lib/systemd/system/getty@.service is unmodified. "rpm -V systemd" is silent.

systemd-44-14.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.