xbrlapi causes long delay in GUI login

[Scoot Lee]

Ubuntu 22.04.3 LTS
xbrlapi 6.4-4ubuntu3

After logging in to the GUI, there is a delay of over 2 minutes before the desktop environment loads (screen will be black with a mouse cursor)

This is caused by /etc/X11/Xsession.d/90xbrlapi

The script runs xbrlapi, which hangs for 2 minutes or so, presumably because it is trying to connect to a BrlAPI server that doesn't exist on my machine.

I guess this packages was installed by orca, because I did not directly install it myself and I don't need it.

Did not happen before 22.04

Others have this issue:
https://askubuntu.com/questions/1448501/ubuntu-22-04-1-lts-very-long-x-session-login-due-to-90xbrlapi

[Scoot Lee (scootley)]

Note that if the network is not connected during the login process, then there is no delay, perhaps because xbrlapi fails immediately in that scenario? But if I am connected to a network before login, the issue of the delay due to xbrlapi occurs. This is specifically with X and not Wayland.

[Samuel thibault (samuel-thibault)]

This is very surprising: what xbrlapi tries to connect to by default is a local socket in /var/lib/BrlAPI/0 so that should be completely independent from TCP/IP networking configuration, and should be either succeeding or failing immediately.

Just to be sure: Does /var/lib/BrlAPI/0 exist? Is brltty running on your system? If you have a brltty daemon running it'd be useful to check for its logs.

Perhaps you can log into a text console and run strace on the stuck xbrlapi command:

    strace -p $(pidof xbrlapi)

so we get to know what it is stuck on.

[Scoot Lee (scootley)]

(Sorry for the delay. Launchpad emails were in my spam)

The directory /var/lib/BrlAPI/ exists, but /var/lib/BrlAPI/0 does not exist.
brltty is not running on my system

strace output is below. my system has functional IPV4 and IPV6

strace: Process 2184 attached
connect(3, {sa_family=AF_INET6, sin6_port=htons(4101), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out)

<line above is where it is stuck for a couple minutes before getting ETIMEDOUT>

close(3) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096) = 0
close(3) = 0
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.utf8/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en/LC_MESSAGES/brltty.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/sha...

[Samuel thibault (samuel-thibault)]

Ok, I better understand why this has never shown up in most situations.

> my system has functional IPV4 and IPV6

Well, it still behaves oddly on the ip6-localhost case:

> connect(3, {sa_family=AF_INET6, sin6_port=htons(4101), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out)

That's really not supposed to time out, and rather just immediately return a "connection refused". Do you have some firewall rules on the lo interface? I'm surprised that this doesn't pose troubles to other system-/session-wide daemons.

[Scoot Lee (scootley)]

Yes you're right it is abnormal.
What's going on is that I had set the sysctl parameter net.ipv6.conf.lo.disable_ipv6=1, which of course disables the IPv6 loopback.

But it exhibits a curious behavior where if there is an active IPv6 regular (non-loopback) interface with an IPv6 address and network connection, then connection attempts to ::1 seem to hang and timeout, but if there is no active IPv6 at all, then connections to ::1 will instantly fail with a "cannot assign requested address".

I guess this didn't work this way before 22.04.
There are no IPv6 firewall rules for the loopback.
I haven't seen any other daemons with issues from this. Maybe they are using IPv4 for loopback?

[Samuel thibault (samuel-thibault)]

> if there is an active IPv6 regular (non-loopback) interface with an IPv6 address and network connection, then connection attempts to ::1 seem to hang and timeout

Probably it uses the default route to send packets to ::1, which is deemed not to receive any response.

> I haven't seen any other daemons with issues from this. Maybe they are using IPv4 for loopback?

Probably

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.