Bug 828007 - --noclear on /sbin/agetty line in getty@.service/getty@tty1.service is ignored
--noclear on /sbin/agetty line in getty@.service/getty@tty1.service is ignored
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-03 21:03 EDT by Felix Miata
Modified: 2012-06-20 15:24 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-04 06:52:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Felix Miata 2012-06-03 21:03:44 EDT
Description of problem:
Cannot prevent clearing of boot messages on tty1 before login prompt appears, like used to be simple to do by adding --noclear to 1:2345:respawn:/sbin/mingetty tty1 line in /etc/inittab.

To Reproduce:
1.boot with '3 splash=verbose vga=794 video=1152x864@60' included on & 'quiet rhgb' excluded from cmdline
2.cd /etc/systemd/system/getty.target.wants
3.replace getty@tty1.service symlink with copy of getty@.service from /usr/lib/systemd/system/
4.s/ExecStart=-/sbin/agetty %I 38400/sbin/agetty --noclear %I 38400/ in getty@tty1.service
5.(optional) cp getty@tty1.service getty@.service
6.reboot
 
Actual results:
1-boot messages on tty1 disappear before login prompt appears

Expected results:
1-all boot messages able to fit above login prompt on tty1 remain visible

Additional info:
1.putting --noclear after %I 38400 doesn't work either.
2.agetty man page text: "--noclear Do not clear the screen before prompting for the login name (the screen is normally cleared)."
3.cf bug 791098, which this might depend on
Comment 1 Michal Schmidt 2012-06-04 06:52:09 EDT
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".
Comment 2 Felix Miata 2012-06-04 08:41:47 EDT
Thanks for quickly responding. However, neither TTYVTDisallocate=no alone (nor TTYReset=no) in /etc/systemd/system/getty.target.wants/getty@tty1.service prevent tty1 from being cleared prior to display of prompt here in F17. Symlinking getty@tty1.service 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.
Comment 3 Michal Schmidt 2012-06-04 10:47:49 EDT
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.
Comment 4 Felix Miata 2012-06-04 13:33:24 EDT
Agetty defaults to clear (requires --noclear to not clear). Getty@tty1.service accepts the default.
TTYVTDisallocate defaults to no (do not clear), which getty@tty1.service rejects by setting to yes.

So, getty@tty1.service 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?
Comment 5 Michal Schmidt 2012-06-06 05:39:16 EDT
Added --noclear to avoid redundant clearing of the VT:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=3305d6806d428010b1cd2abd716aa1bb7f81311f
Comment 6 Felix Miata 2012-06-06 08:03:49 EDT
So now getty@tty1.service 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@tty1.service clear by default?

Maybe a comment regarding this unintuitive configuration needs to be included in /usr/lib/systemd/system/getty@.service?
Comment 7 Michal Schmidt 2012-06-06 08:56:02 EDT
(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@tty1.service 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.
Comment 8 Felix Miata 2012-06-06 09:22:39 EDT
(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.
Comment 9 Fedora Update System 2012-06-12 20:14:47 EDT
systemd-44-13.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-13.fc17
Comment 10 Felix Miata 2012-06-15 10:35:10 EDT
I installed systemd-44-14 and systemd-sysv-44-14 from updates testing, modified the new /etc/systemd/system/getty@.service -> getty@tty1.service with TTYVTDisallocate=no, but still tty1 clears on boot. :-(
Comment 11 Michal Schmidt 2012-06-15 10:48:25 EDT
Did you do "systemctl daemon-reload" or reboot after modifying the unit file?
Comment 12 Felix Miata 2012-06-15 11:10:16 EDT
multiple reboots with same disappointing result
Comment 13 Michal Schmidt 2012-06-15 11:21:07 EDT
(In reply to comment #10)
> modified the new /etc/systemd/system/getty@.service -> getty@tty1.service

What exactly do you mean by this notation? Which file is a symlink to where? And which files did you edit?
Comment 14 Felix Miata 2012-06-15 11:32:35 EDT
I copied the new getty@.service from /usr/lib/systemd/system to /etc/systemd/system, changed its name to getty@tty1.service, made the edit, rebooted.
Comment 15 Michal Schmidt 2012-06-15 11:39:05 EDT
Hm, the method works for me.

What do you get from this command?:

 systemctl show -p ActiveState -p FragmentPath -p TTYVTDisallocate \
   getty@tty1.service
Comment 16 Michal Schmidt 2012-06-15 11:44:52 EDT
An alternative method, which also works for me, is saving this small file as /etc/systemd/system/getty@tty1.service :

.include /lib/systemd/system/getty@.service
[Service]
TTYVTDisallocate=no
Comment 17 Felix Miata 2012-06-15 12:11:28 EDT
(In reply to comment #15)
> What do you get from this command?:
 
> systemctl show -p ActiveState -p FragmentPath -p TTYVTDisallocate \
> getty@tty1.service

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@tty1.service :
 
> .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@tty1.service

Still tty1 is clearing on boot.
Comment 18 Michal Schmidt 2012-06-15 17:28:12 EDT
(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@tty1.service

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@tty1.service

/etc/systemd/system/getty.target.wants:
total 0
lrwxrwxrwx. 1 root root 34 Jun 15 23:20 getty@tty1.service -> /lib/systemd/system/getty@.service
Comment 19 Felix Miata 2012-06-15 18:28:09 EDT
(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@tty1.service

# 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@tty1.service -> /etc/systemd/system/getty.target.wants/getty@tty1.service
Comment 20 Michal Schmidt 2012-06-17 15:48:15 EDT
I think you either misread what I wrote, or misunderstood what I meant by "/{lib,etc}". All my customizations are under /etc.
Comment 21 Felix Miata 2012-06-18 19:55:34 EDT
(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@tty1.service -> /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.
Comment 22 Michal Schmidt 2012-06-19 03:46:07 EDT
(In reply to comment #21)
> /etc/systemd/system/getty.target.wants:
> total 0
> lrwxrwxrwx. 1 root root 34 Jun 15 23:20 getty@tty1.service ->
> /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.
Comment 23 Fedora Update System 2012-06-20 15:24:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.