0

Server is AlmaLinux 8.5 (converted from CentOS).

I had been doing some work to add a new web site which included the usual dnf update and also installing php81-php-fpm and some associated packages. All went well until I tried to set up a new SSL certificate with Certbot.

The certbot command simply hangs. There was evidence in the logs that it had successfully run a renew cycle within the previous 24 hours, and the server had been rebooted after the updates (which included a kernel update).

Further investigation revealed that the snap command (Certbot having been installed with it) also hangs. Specifically snap help works but even snap version hangs. I suspect this may be behind the certbot hangs. Snappy version is 2.53.4.

I cannot find any Snappy-specific logs and messages doesn't show anything obvious. I have also confirmed snapd.service is running.

I rebooted the server again and inspected messages and these were the snap entries. Maybe that last entry relates to the issue?

Dec 27 20:31:54 zkarj-alma01 systemd[1]: Starting Socket activation for snappy daemon.
Dec 27 20:31:54 zkarj-alma01 systemd[1]: Started Timer renew for snap application certbot.renew.
Dec 27 20:31:54 zkarj-alma01 systemd[1]: Listening on Socket activation for snappy daemon.
Dec 27 20:32:26 zkarj-alma01 systemd[1787]: Listening on REST API socket for snapd user session agent.
Dec 27 20:34:15 zkarj-alma01 systemd[1]: Started snap.certbot.certbot.210f1e08-0000-45c6-8927-a0252806888f.scope.
Dec 27 20:34:16 zkarj-alma01 snapd[1910]: AppArmor status: apparmor not enabled
Dec 27 20:34:16 zkarj-alma01 snapd[1910]: daemon.go:242: started snapd/2.53.4-1.el8 (series 16; classic; devmode) almalinux/8.5 (amd64) linux/4.18.0-348.7.1.el8_5.x86_.
Dec 27 20:34:16 zkarj-alma01 snapd[1910]: daemon.go:335: adjusting startup timeout by 45s (pessimistic estimate of 30s plus 5s per snap)
Dec 27 20:34:16 zkarj-alma01 dbus-daemon[776]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.71' (uid=0 pid=1910 comm="/usr/libexec/snapd/snapd " label="system_u:system_r:snappy_t:s0")
Dec 27 20:34:25 zkarj-alma01 systemd[1]: snap.certbot.certbot.210f1e08-0000-45c6-8927-a0252806888f.scope: Succeeded.
Dec 27 20:35:01 zkarj-alma01 systemd[1954]: Listening on REST API socket for snapd user session agent.
Dec 27 20:35:12 zkarj-alma01 systemd[1954]: Closed REST API socket for snapd user session agent.

Any help or suggestions appreciated.

Improve this question

1 Answer 1

Reset to default
0

Posted this in the Let's Encrypt forum as well, even though it seemed like a Snappy issue. A user there pointed me here:

https://forum.snapcraft.io/t/snapd-unavailable-red-hat-enterprise-linux/28004/2

A version of those steps did cure the problem, though not permanently. I hope the new version currently in testing (2.54.1) will provide a permanent solution.

Improve this answer
1
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Dec 29, 2021 at 5:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .