[systemd-devel] systemd-vconsole-setup fails very slowly

[Kay Sievers]

On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers <kay at vrfy.org> wrote:
>> On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>>> On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>>>> On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
>>>> <lennart at poettering.net> wrote:
>>>>> On Wed, 21.01.15 19:15, Andy Lutomirski (luto at amacapital.net) wrote:
>>>>>
>>>>>> Hi all-
>>>>>>
>>>>>> When running virtme (a simple vm gadget) on Fedora 21, the slowest
>>>>>> part of bootup by far appears to be systemd-vconsole-setup:
>>>>>>
>>>>>> # time /usr/lib/systemd/systemd-vconsole-setup
>>>>>> putfont: PIO_FONT trying ...
>>>>>> ...................
>>>>>> setfont: putfont: 512,8x16:  failed: -1
>>>>>> putfont: PIO_FONT: Invalid argument
>>>>>> /usr/bin/setfont failed with error code 71.
>>>>>
>>>>> setfont is not part of systemd, we just invoke it. If that fails, this
>>>>> is a problem somewhere between the VM, the kernel and console-tools.
>>>>>
>>>>
>>>> Aha -- I missed that systemd-vconsole-setup calls setfont.  I can
>>>> trigger the same problem by just typing setfont.  For whatever reason,
>>>> my other Fedora 21 computer only has this problem if I type setfont
>>>> and not if I run systemd-vconcole-setup.
>>>>
>>>>> My uneducated guess is that your virtual machine boots up with a
>>>>> non-graphical console, and the tool thus tries to upload the fonts
>>>>> into the good old VGA hw text mode glyph tables, and qemu is very slow
>>>>> at that... Or something like that.
>>>>
>>>> setfont is doing this:
>>>>
>>>> nanosleep({0, 250000000}, NULL)         = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)            = -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)                        = 1
>>>> nanosleep({0, 250000000}, NULL)         = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)            = -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)                        = 1
>>>> nanosleep({0, 250000000}, NULL)         = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)            = -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)                        = 1
>>>> nanosleep({0, 250000000}, NULL)         = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)            = -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)                        = 1
>>>> nanosleep({0, 250000000}, NULL)         = 0
>>>> ioctl(3, PIO_FONT, 0xfbc010)            = -1 EINVAL (Invalid argument)
>>>> write(2, ".", 1.)                        = 1
>>>>
>>>> This thing has only a serial console:
>>>>
>>>> # cat /proc/consoles
>>>> ttyS0                -W- (EC   a)    4:64
>>>>
>>>> setfont does this:
>>>>
>>>>         /* we allow ourselves to hang here for ca 5 seconds, xdm may
>>>> be playing tricks on us. */
>>>>         while ((loop++ < 20) && (i = ioctl(fd, PIO_FONT, buf)))
>>>>           {
>>>>             if (loop <= 1)
>>>>               fprintf(stderr, "putfont: PIO_FONT trying ...\n");
>>>>             else
>>>>               fprintf(stderr, ".");
>>>>             usleep(250000);
>>>>           }
>>>>         fprintf(stderr, "\n");
>>>>
>>>> Alexey, would it make sense to remove this loop or to add a way to turn it off?
>>>
>>> Ping, everyone?
>>>
>>> This issue still exists.  AFAICT systemd is relying on a really old
>>> tool, that that really old tool (setfont) is sometimes delaying boot
>>> by a very large amount.  Can we either fix the tool (Alexey) or stop
>>> using it (systemd people)?
>>
>> Hmm, why is the "vm gadget" you run configuring a custom console font
>> at all? If there is no custom font specified in t he config, systemd
>> will not run setfont.
>
> It's not intentionally configuring a custom font, but it might be
> inheriting Fedora's settings.

Ideally, /etc/vconsole.conf does not even exist in a default setup. It
is only needed for foreign language keyboard support or more exotic
font requirements.

>> Or did you mean to have vconsole-setup detect that it should not even
>> try to run setfont? Not sure how to find that out.
>>
>> I don't really see how vconsole-setup could get rid of calling setfont
>> from systemd, it is needed in many setups.
>
> vconsole-setup could set the font itself instead of using setfont if
> setfont can't be configured or fixed not to keep retrying for five
> seconds (!).

It is a rather complex logic which would need to be duplicated in
systemd. We so far have avoided it, because the kernel VC font and
keymaps are so conceptually limited, that it does not really make
sense to build a modern system on top of it.

If systemd gets advanvced console support with systemd-consoled,
we need full unicode support, high-dpi display support, display hotplug,
..., all things the kernel's vc stuff will never give us. That is why we rely
on setfont and loadkeys for now.

> Ideally, I think that setfont would just stop retrying on failure.

Right, that sounds like a simple and sensible fix.

> Or
> perhaps all of this could go through udev or some other mechanism that
> doesn't try to set the font until the device actually exists.  But the
> console system is weird and may be that's hard.

The devices should be always there, /dev/tty1-15. It looks like the
driver behind the ttys seems not to accept the font and return EINVAL.
Not sure if udev could make a difference here.

Do you have an idea why the VM does not accept the custom font? If
that is something obvious, and we can detect it, we could make
vconsole-setup check for it. But then again, fixing setfont seems like
the obvious fix here.

Kay