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

[Andy Lutomirski]

On Apr 1, 2015 12:56 PM, "Kay Sievers" <kay at vrfy.org> wrote:
>
> 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.

Too bad no one from the kbd list has replied :(

>
> > 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.

I assume it's because the VM has no graphical console at all.

--Andy