Systemd error message gets printed over Yuigreet interface

[gnull]

The systemd-networkd-wait-online service often fails on my machine on startup. When it does so, Systemd writes

systemd[1]: Failed to start Wait for Network to be Configured.

to the system journal and that gets printed to some of the consoles (not sure which ones and how it works). If this happens when I'm in Tuigreet, the messages gets printed right over the Tuigreed interface. In my case the message fills the password field (that's where the cursor is).

Could Tuigreet somehow disable printing of system log messages to the console it works in? (And maybe reenable it when Tuigreet quits.)

I'm using tuigreet 0.7.3 running Archlinux.

[UltraBlackLinux]

You should generalise this: All of grub bleeds into tuigreet, for me a few of the bottom grub lines cover parts of tuigreet.

[gnull]

There's a chance this is not an issue for tuigreet, since it's logger daemons that are writing stuff to console. Users probably need to configure their systemd-journald to stop writing messages to console. After some quick googling, I couldn't find a way to disable the messages on just one specific console.

I would be nice though to have a paragraph in tuigreet docs explaining this.

[UltraBlackLinux]

I am facing this overflow issue since I removed the quiet option from grub. I really value seeing a log, so I won't disable that. I hope it can be fixed somehow.

[gnull]

I think I found a way to fix this. Do

[terminal]
# The VT to run the greeter on. Can be "next", "current" or a number
# designating the VT.
vt = next

in your greetd (not tuigreet) config. I can't reproduce the issue since I did this (but I don't have a reliable way of reproducing it, so I don't know how much that's worth).

I suspect that tty1 is the only one getting those error messages printed to it. So putting greetd on another tty might solve the problem.

Ivan

[Occhioverde]

Personally, I am afraid that this change in Greetd's configuration does not really solve the problem.

My /etc/greetd/config.toml file is something like

[terminal]
vt = "next"

[default_session]
command = "tuigreet --remember --time --issue --asterisks --cmd sway"
user = "greeter"

while this is what Tuigreet looks like when I boot without the kernel quiet parameter:

[gnull]

You're right. I just saw some error messages with vt = "next" and quiet in kernel parameters. So the issue still exists.

[apognu]

I feel you, and I have the same issue from time to time. Unfortunately, I have no idea if and how this could be solved, the same issue happens to me with any console program I invoke.

Short of rewriting the whole screen, including whitespace, at every frame, I don't see a solution.

If anyone has an idea within the scope of tuigreet, I'm all ears, but for now, I'm blank. A root program, if it wants to write on a tty, will write on a tty, there is little I can do.

[UltraBlackLinux]

It might be worth looking at ly. They are kinda doing the same thing as tuigreet but different, and they don't have the problem described here.

I have no experience in using C, but you might be able to find what updates their screen. My best guess currently is the very bottom of the file

[foopsss]

I followed a suggestion given on Arch forums and the log messages on tuigreet seem to be gone.

Basically, redirect all the logs to a different TTY than the one you are using to boot tuigreet.

EDIT: after a reboot, the issue was still there with this method.

[gnull]

Lucas,

Do the journald messages still go away when you remove quiet kernel commandline argument? (I.e. remove it from /etc/default/grub, do grub-mkconfig and reboot.)

For me, the above still produces the messages over tuigreet interface. Although with quiet set I don't see anything (maybe I haven't testing it enough).

Ivan

[Occhioverde]

Finally, after reading lots of threads and trying out different possible solutions, I found out that SystemD stops printing its status messages (like it was started with the quiet parameter) upon receiving SIGRTMIN+21 and then restarts doing it when a SIGRTMIN+20 signal is sent (Source: https://man.archlinux.org/man/systemd.1#SIGNALS).

So I created a file named /usr/lib/systemd/system/greetd.service.d/00-nobleed.conf, I pasted into it the following content and restarted my machine:

[Service]
ExecStartPre=kill -SIGRTMIN+21 1
ExecStopPost=kill -SIGRTMIN+20 1

Thanks to this modification, SystemD stops printing its log before launching greetd (and tuigreet along with it) restarting it only after the login screen is closed.

I'm not entirely sure that this solution can stop error messages too from being printed over tuigreet, but for now this is the best workaround I was able to find.

[foopsss]

Lucas,

Do the journald messages still go away when you remove quiet kernel commandline argument? (I.e. remove it from /etc/default/grub, do grub-mkconfig and reboot.)

For me, the above still produces the messages over tuigreet interface. Although with quiet set I don't see anything (maybe I haven't testing it enough).

Ivan

Hello.

It seems I rushed a bit with my first comment, because the log messages came back after a full reboot with the workaround I posted before. My apologies.

I also tried what you asked me to do. After three reboots, I've seen no log messages over the tuigreet prompt every time I tried to log in. However, I did not have the quiet flag set in my GRUB config before.

I'll wait a few more days, and, if the log messages come again, I'll try the workaround proposed by occhioverde and report back.

My tuigreet version is 0.7.2. Cheers.

[DotIN13]

I tried @Occhioverde's solution and it seemed to have worked. The logs and errors are gone now, will report again if it comes back.

EDIT: @foopsss's suggestion I also tried, but no luck though.

[Lorilandly]

@apognu What about adding an option, for example by pressing F5, to allow user to manually update the screen? Screen bleeding is a common issue for tui applications, and many solves it by allowing a manual update, e.g., vim refresh the screen with CTL_L.

[e-l-i-j-a-h]

I'm having a similar issue. I'll try the fixes above and see if they work.

[DotIN13]

I tried @Occhioverde's solution and it seemed to have worked. The logs and errors are gone now, will report again if it comes back.

EDIT: @foopsss's suggestion I also tried, but no luck though.

After sometime, I reverted the changes from @Occhioverde's solution as I happened needed to check the systemd logs at the login screen as my system won't boot into desktop environment. So I had to boot into a livecd and delete the lines in the service file. I guess it's just hard to get them all, debuggability and cleanliness.

[Yakkhini]

Here is a more elegant way to fix this problem. Inspired by @UltraBlackLinux and I checked ly's repo to find how did they fix this issue. In #4ab41f0 I found that they just change service file with "Type = idle".

In getty - ArchWiki, 2.3.1, a small tip point out how it works:

The option Type=idle found in the default [email protected] will delay the service startup until all jobs (state change requests to units) are completed in order to avoid polluting the login prompt with boot-up messages. When starting X automatically, it may be useful to start [email protected] immediately by adding Type=simple into the drop-in file. Both the init system and startx can be silenced to avoid the interleaving of their messages during boot-up.

—— Tip, 2.3.1, getty - ArchWiki

Then I add a new line "Type=idle" in greetd.service file.

And tuigreet looks fine after restart.

[octvs]

And tuigreet looks fine after restart.

I wonder if I'm alone in this, but this doesn't solve the issue for me.

I saw the exact error msgs as @literal-line above.

Edit: I don't think it is related to this issue but I got it fixed with setting up the silent boot.

[paulolieuthier]

Setting Type=idle in greetd.service file gets rid of Systemd logs, but there is still log from the kernel. What fixed it for me was to reduce the kernel log level, as explained here: https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console.

[sjcobb2022]

I found this config from some thread on reddit. For working with NixOS.

Here is the original post. I've been using it in my config and it works like a charm.

  # this is a life saver.
  # literally no documentation about this anywhere.
  # might be good to write about this...
  # https://www.reddit.com/r/NixOS/comments/u0cdpi/tuigreet_with_xmonad_how/
  systemd.services.greetd.serviceConfig = {
    Type = "idle";
    StandardInput = "tty";
    StandardOutput = "tty";
    StandardError = "journal"; # Without this errors will spam on screen
    # Without these bootlogs will spam on screen
    TTYReset = true;
    TTYVHangup = true;
    TTYVTDisallocate = true;
  };

Edit: An example config for arch. I actually haven't tested this one but based on other systemd configs i've seen it should work.

# /etc/systemd/system/greetd.d/no_spam.conf
[Service]
Type = "idle"
StandardOutput = "tty"
# Without this errors will spam on screen
StandardError = "journal"
# Without these bootlogs will spam on screen
TTYReset = true
TTYVHangup = true
TTYVTDisallocate = true

The arch wiki says systemctl edit unit --drop-in=drop_in_name is the easiest way to create new configs for your systemd

[farbeiza]

As an idea, why not making ESC key clear and redraw the whole screen?

[Chess3D]

I was having the same problem in Arch and fixed it using by adding the below systemd config with systemctl edit greetd --drop-in=quite

# /etc/systemd/system/greetd.service.d/quite.conf
[Unit]
[email protected]

[Service]
Type=idle
StandardInput=tty
TTYPath=/dev/tty2
TTYReset=yes
TTYVHangup=yes

[apognu]

A comment on Reddit seems to have had some luck with these systemd directives in the greetd service:

Type=idle
StandardInput=tty
StandardOutput=tty
StandardError=journal
TTYReset=true
TTYVHangup=true
TTYVTDisallocate=true

I can't really reproduce the issue on my systems, but if someone wants to give it a try, have at it.

[sjcobb2022]

A comment on Reddit seems to have had some luck with these systemd directives in the greetd service:

Type=idle
StandardInput=tty
StandardOutput=tty
StandardError=journal
TTYReset=true
TTYVHangup=true
TTYVTDisallocate=true

I can't really reproduce the issue on my systems, but if someone wants to give it a try, have at it.

This is what I have in my system config. It works very well and I do not have any spam on my screen.

[deviantsemicolon]

I found this config from some thread on reddit. For working with NixOS.

Here is the original post. I've been using it in my config and it works like a charm.

  # this is a life saver.
  # literally no documentation about this anywhere.
  # might be good to write about this...
  # https://www.reddit.com/r/NixOS/comments/u0cdpi/tuigreet_with_xmonad_how/
  systemd.services.greetd.serviceConfig = {
    Type = "idle";
    StandardInput = "tty";
    StandardOutput = "tty";
    StandardError = "journal"; # Without this errors will spam on screen
    # Without these bootlogs will spam on screen
    TTYReset = true;
    TTYVHangup = true;
    TTYVTDisallocate = true;
  };

Edit: An example config for arch. I actually haven't tested this one but based on other systemd configs i've seen it should work.

# /etc/systemd/system/greetd.d/no_spam.conf
[Service]
Type = "idle"
StandardOutput = "tty"
# Without this errors will spam on screen
StandardError = "journal"
# Without these bootlogs will spam on screen
TTYReset = true
TTYVHangup = true
TTYVTDisallocate = true

The arch wiki says systemctl edit unit --drop-in=drop_in_name is the easiest way to create new configs for your systemd

the nix thing works perfectly. thank you so much

[medv]

This is one of the greatest solutions I've ever seen. The source is a lonely comment sourcing another post. That post is a 0 upvote question by someone new to linux.

And now our tuigreet is fixed.

[tmccombs]

Is there any chance this could merged into greetd?

Or maybe have tuigreet send the signals described in https://github.com/apognu/tuigreet/issues/68#issuecomment-1192683029 to systemd as part of tuigreet itself?

[apognu]

I do not think this should be the responsibility of tuigreet to do that, unfortunately.

[sjcobb2022]

It should be the responsibility of the packaging system (e.g. AUR or nixpkgs), correct @apognu?

[apognu]

In my opinion, yes. But one precision: the responsibility of the package that actually starts a service, so in our case greetd. ŧuigreet. The issue there is that greetd needs to cater to a lot of greeters.

I could add a drop-in systed override for greetd in our package to include the aforementioned directives, but I do not know how I feel that installing service B actively changes system configuration for service A. Happy to discuss, though.