Bug 1957469 - dnf hangs on updating repositories when it can't resolve them
Summary: dnf hangs on updating repositories when it can't resolve them
Keywords:
Status: CLOSED COMPLETED
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 36
Hardware: Unspecified
OS: Linux
low
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-05 20:04 UTC by наб
Modified: 2023-04-25 17:21 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-04-25 17:21:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description наб 2021-05-05 20:04:12 UTC
Description of problem:
When updating repositories with broken resolv.conf, dnf hangs permanently in the spinner:
[root@tarta /]# yum whatprovides '/usr/lib/kernel/install.d/*'
Fedora 34 openh264 (From Cisco) - x86_64                               [                  ===                                             ] ---  B/s |   0  B     --:-- ETA

This spun for a while but made no progress, so I checked the open files, and this log said enough:
nabijaczleweli@tarta:~$ cat /home/nabijaczleweli/uwu/3b69a51ab129268ab337a8eda600699b02d8b274ff5edf7f3aaa7cae98a565ec/layer/var/log/dnf.log
2021-05-05T17:48:51+0000 INFO --- logging initialized ---
2021-05-05T17:48:51+0000 DDEBUG timer: config: 3 ms
2021-05-05T17:48:51+0000 DDEBUG Cleaning up.
2021-05-05T17:49:10+0000 INFO --- logging initialized ---
2021-05-05T17:49:10+0000 DDEBUG timer: config: 3 ms
2021-05-05T17:49:10+0000 DEBUG YUM version: 4.6.1
2021-05-05T17:49:10+0000 DDEBUG Command: yum whatprovides /usr/lib/kernel/install.d/*
2021-05-05T17:49:10+0000 DDEBUG Installroot: /
2021-05-05T17:49:10+0000 DDEBUG Releasever: 34
2021-05-05T17:49:10+0000 DEBUG cachedir: /var/cache/dnf
2021-05-05T17:49:10+0000 DDEBUG Base command: whatprovides
2021-05-05T17:49:10+0000 DDEBUG Extra commands: ['whatprovides', '/usr/lib/kernel/install.d/*']
2021-05-05T17:49:10+0000 DEBUG User-Agent: constructed: 'libdnf (Fedora 34; container; Linux.x86_64)'
2021-05-05T17:49:10+0000 DEBUG repo: downloading from remote: fedora-cisco-openh264
2021-05-05T17:49:20+0000 DEBUG error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] (https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64).
2021-05-05T17:49:32+0000 DEBUG error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] (https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64).
2021-05-05T17:49:42+0000 DEBUG error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] (https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64).
2021-05-05T17:49:52+0000 DEBUG error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] (https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64).
2021-05-05T17:50:02+0000 DEBUG error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] (https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-34&arch=x86_64).

Restarting after setting resolv.conf to something valid (and not "# Generated by NetworkManager", "nameserver 192.168.122.1") did allow it to proceed.

Version-Release number of selected component (if applicable):
dnf-0:4.6.1-1.fc34.noarch


How reproducible:
Easily


Steps to Reproduce:
1. wget https://ftp.icm.edu.pl/pub/Linux/fedora/linux/releases/34/Container/x86_64/images/Fedora-Container-Base-34-1.2.x86_64.tar.xz
2. Extract it and layer.tar beneath it
3. chroot layer
4. yum whatprovides '/usr/lib/kernel/install.d/*'


Actual results:
See above.


Expected results:
An error, maybe? I'd expect some sort of update for the user beyond an all-0 spinner.

Comment 1 Ben Cotton 2022-05-12 16:30:32 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 2 наб 2022-05-12 19:28:44 UTC
Not fixed in Fedora 36, only masked because it ships w/o /etc/resolv.conf, so glibc nss-dns defaults to searching in 127.0.0.1:53:
  if (__glibc_unlikely (nameserver_list_size (&parser->nameserver_list) == 0))
    {
      const struct sockaddr **p
        = nameserver_list_emplace (&parser->nameserver_list);
      if (p == NULL)
        return false;
      *p = allocate_address_v4 (__inet_makeaddr (IN_LOOPBACKNET, 1),
                                NAMESERVER_PORT);
      if (*p == NULL)
        return false;
    }

Adding a dummy /etc/resolv.conf via
  echo nameserver 192.111.111.111 > etc/resolv.conf
still sleeps forever.

However, running in a blank netns or on a host w/o a resolver correctly fails fast:
  [root@zoot2 /]# yum whatprovides /dupa
  Fedora 36 - x86_64                              0.0  B/s |   0  B     00:00
  Errors during downloading metadata for repository 'fedora':
    - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]
  Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]

Comment 3 Ben Cotton 2023-04-25 16:42:22 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 4 наб 2023-04-25 17:21:11 UTC
Can no longer repro in a 37 chroot :)


Note You need to log in before you can comment on or make changes to this bug.