Systemd should write to all consoles during startup

[telyn]

Is your feature request related to a problem? Please describe.
Systemd only outputs to /dev/console - which (per the linux documentation) only writes to the final console listed on the kernel command line.

This was previously brought up in #3403 which was closed when some users reported that systemd was outputting to all consoles (which later turned out to be plymouth working around the issue). To make sure this issue is still happening I built a systemd image using mkosi --kernel-command-line 'console=ttyS0 console=tty1' and ran it under VirtualBox. The output is below - ttyS0 on the left, tty1 on the right. As you can see only the initial messages with dmesg-style timestamps are getting output, and not the [ OK ] Listening on udev Kernel Socket. stuff.

Where I work we have a control panel which our customers use to create and administer their virtual servers. They may specify a script to run on first boot-up of their server. Under systemd-based distros the output from their scripts is only output to the serial console - but our panel only supports the graphical console. We'd like our customers to be able to see it on both. Under upstart-based distros (i.e. old-but-still-supported Ubuntus) we see the output on both consoles - and it seems there is a patch in Debian to support this on sysvinit (see debian bug #181756) - though we do not have any images with sysvinit out of the box at the moment.

Describe the solution you'd like
The set of consoles that dependency startup state and output is sent to should be configurable either by the kernel command line or in the systemd-system.conf (or similar). I haven't been able to find any mention of this configuration and a tiny dive into the systemd source made it seem hardwired to /dev/console.

Describe alternatives you've considered
There are some workarounds - per #3403 it seems that plymouth mirrors output on /dev/console to all other consoles, and I shall be writing a workaround in our script which calls customer firstboot scripts to tee the output to all consoles.

[poettering]

It appears to me this is better fixed in the kernel, i.e. that /dev/console does this multiplexing on its own instead of faking this from userspace. I mean we support StandardOutput=tty with a default of TTYPath=/dev/console, and if that ever should work correctly with what you are asking for then /dev/console has to implement the multiplexing anyway.

Hence: have you asked the kernel folks for this? given that the kernel already has some multiplexing code (as it copies kmsg to all ttys specified on the kernel cmdline iirc) adding this to the kernel shouldn't be too much new code...

I'll leave this open, but I am not convinced it would be the right approach to teach each and every userspace app that wants to access /dev/console manual multiplexing, but instead just fix this in the kernel

[sourcejedi]

it seems there is a patch in Debian to support this on sysvinit (see debian bug #181756)

The linked patch is to bootlogd. This is an optional program, which uses the same console redirection feature as plymouth.

Under upstart-based distros (i.e. old-but-still-supported Ubuntus) we see the output on both consoles.

I believe plymouth is required by key parts of upstart.

---

If we changed to write to all consoles by default, we'd interfere with plymouth. Right now we write to /dev/console, plymouth intercepts it by using TIOCCONS to redirect that to a PTY.

The configuration option that you are asking for, seems to be to install plymouth or equivalent. You won't mind the disk space or the boot time too much.

I don't see an argument made here for duplicating this option inside systemd. Adding a new option in itself would arguably be the most intrusive part.

The traditional way works. I think it's just that plymouth is a bit mysterious. There's documentation for the rest of it.

It appears to me this is better fixed in the kernel, i.e. that /dev/console does this multiplexing on its own

I don't think so. The second of the two uses for /dev/console is "single user mode" (emergency.target etc). The default console=tty0 really wants to provide direct access to tty0. E.g. you can run a text editor, and it can know the correct terminal dimensions.

At least, I'm assuming that's the problem that I run into, every time I try to use a text editor on a linux serial console.

[grawity]

I think it's just that plymouth is a bit mysterious.

I think that might be part of the problem... Does Plymouth have a text-only mode? And I recall it had a delay before showing the boot screen (so that fast boots won't be interrupted), are its console redirection features affected by this?

E.g. you can run a text editor, and it can know the correct terminal dimensions. At least, I'm assuming that's the problem that I run into, every time I try to use a text editor on a linux serial console.

No, sounds like your problem is just that serial console doesn't have a way of reporting dimensions to begin with. (Take a look at stty size, it'll probably show 0x0.)

You have to use something like xterm's resize that attempts to inquire them from the local terminal via escape codes; otherwise programs will just assume 80x25. (And they can't just automatically do what 'resize' does, because they're told the serial console is TERM=vt220, which didn't support those inquiry codes – it had a fixed physical size.)

But you did discover another problem – if the same /dev/console is duplicated to multiple terminals, I'm not sure what happens if a program outputs one inquiry escape code and all the terminals send multiple responses... For that matter, weird things will happen with just about any escape code if some outputs support it and others do not.

[sourcejedi]

Does Plymouth have a text-only mode?

It supports an ascii splash, but I don't think that's what you meant :-).

You should be able to start in "details mode" with no splash, by booting without splash or rhgb on the kernel command line. This is different from plymouth.enable=0.

I recall it had a delay before showing the boot screen (so that fast boots won't be interrupted), are its console redirection features affected by this?

Good question. From search (mostly Arch Wiki :-), I think ShowDelay is only about drawing the graphics. I don't think it should affect the console redirection.

---

No, sounds like your problem is just that serial console doesn't have a way of reporting dimensions to begin with. (Take a look at stty size, it'll probably show 0x0.)

There is some non-zero size, which gets guessed as a default by something. But the GUI terminals that I use are often not set to the expected default size :-). And it seems the size needs to match exactly.

But you did discover another problem – if the same /dev/console is duplicated to multiple terminals, I'm not sure what happens if a program outputs one inquiry escape code and all the terminals send multiple responses...

Terminal multiplexers do handle that :-P. But yes, that sounds like another way to see the problem.

I would not try asking the Linux kernel to implement (or accept patches to implement) tmux / screen.

[poettering]

I think that might be part of the problem... Does Plymouth have a text-only mode? And I recall it had a delay before showing the boot screen (so that fast boots won't be interrupted), are its console redirection features affected by this?

Yes, it has a text-only mode. If you drop "rhgb" from the kernel cmdline, then it uses that, and only shows you the console, but will still hook into it.