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

[Andy Lutomirski]

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.

>
> 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 (!).

Ideally, I think that setfont would just stop retrying on failure.  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.

--Andy