Initial install of hello-world does not communicate - receives timeout

I am brand new to Snap.

New install of snapd on RHEL 8.10. Working to get a CyberArk component installed. With a CyberArk Consultant, we verified the network Requirements (References in comment)

To install Snap, we followed this process from http://docs.cyberark.com/remote-access-standard/latest/en/content/installation/connectorsprerequisites.htm - Under the RedHAt v8 section:

  1. sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
  2. sudo yum install snapd -y
  3. sudo systemctl enable --now snapd.socket
  4. sudo ln -s /var/lib/snapd/snap /snap
  5. sudo snap install hello-world

This is where we stop. Out firewall/proxy teams are not seeing any traffic from our server outbound, and I cannot find any logging on the host that indicates the problem.

Can someone explain to me what is happening at this point of attempting to install hello-world? Where should it be reaching to? How can I validate my environment is configured correctly?

Our company runs Satellite for updates, so I don’t have any other resources to turn to internally for assistance.

Links for reference

https://docs.cyberark.com/remote-access-standard/latest/en/content/installation/prerequisitenetworkrequirement.htm

https://snapcraft.io/docs/network-requirements)

Here are some of the results from our system:


[<UserName>@<ServerName> ~]$ sudo snap install hello-world
error: cannot communicate with server: timeout exceeded while waiting for response
[<UserName>@<ServerName> ~]$ sudo snap --version
snap    2.68.3-0.el8
snapd   unavailable
series  -
[<UserName>@<ServerName> ~]$ sudo journalctl -u snapd
-- Logs begin at Wed 2025-04-23 14:43:17 CDT, end at Wed 2025-04-30 09:44:53 CDT. --
Apr 23 14:52:12 <ServerName> systemd[1]: Starting Snap Daemon...
Apr 23 14:52:12 <ServerName> snapd[9562]: overlord.go:284: Acquiring state lock file
Apr 23 14:52:12 <ServerName> snapd[9562]: overlord.go:289: Acquired state lock file
Apr 23 14:52:12 <ServerName> snapd[9562]: daemon.go:250: started snapd/2.68.3-0.el8 (series 16; classic; devmode) rhel/8.10 (amd64) linux/>
Apr 23 14:52:12 <ServerName> snapd[9562]: daemon.go:353: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 23 14:52:12 <ServerName> snapd[9562]: backends.go:91: AppArmor status: apparmor not enabled
Apr 23 14:52:12 <ServerName> snapd[9562]: helpers.go:159: error trying to compare the snap system key: system-key missing on disk
Apr 23 14:52:12 <ServerName> systemd[1]: Started Snap Daemon.
Apr 23 14:52:12 <ServerName> snapd[9562]: api_snaps.go:467: Installing snap "hello-world" revision unset
Apr 24 14:30:46 <ServerName> systemd[1]: Stopping Snap Daemon...
Apr 24 14:30:46 <ServerName> snapd[9562]: main.go:171: Exiting on terminated signal.
Apr 24 14:32:16 <ServerName> systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
Apr 24 14:32:16 <ServerName> systemd[1]: snapd.service: Killing process 9562 (snapd) with signal SIGKILL.
Apr 24 14:32:16 <ServerName> systemd[1]: snapd.service: Main process exited, code=killed, status=9/KILL
Apr 24 14:32:16 <ServerName> systemd[1]: snapd.service: Failed with result 'timeout'.
Apr 24 14:32:16 <ServerName> systemd[1]: Stopped Snap Daemon.
Apr 24 14:32:16 <ServerName> systemd[1]: snapd.service: Triggering OnFailure= dependencies.
Apr 24 14:33:33 <ServerName> systemd[1]: Starting Snap Daemon...
Apr 24 14:33:33 <ServerName> snapd[580995]: overlord.go:284: Acquiring state lock file
Apr 24 14:33:33 <ServerName> snapd[580995]: overlord.go:289: Acquired state lock file
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 1...
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 2...
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 3...
Apr 24 14:33:33 <ServerName> snapd[580995]: daemon.go:250: started snapd/2.68.3-0.el8 (series 16; classic; devmode) rhel/8.10 (amd64) linu>
Apr 24 14:33:33 <ServerName> snapd[580995]: daemon.go:353: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 24 14:33:33 <ServerName> snapd[580995]: backends.go:91: AppArmor status: apparmor not enabled
Apr 24 14:33:33 <ServerName> systemd[1]: Started Snap Daemon.


[<UserName>@<ServerName> ~]$ sudo systemctl status snapd

â—Ź snapd.service - Snap Daemon
   Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2025-04-24 14:33:33 CDT; 5 days ago
 Main PID: 580995 (snapd)
    Tasks: 9 (limit: 48811)
   Memory: 16.1M
   CGroup: /system.slice/snapd.service
           └─580995 /usr/libexec/snapd/snapd

Apr 24 14:33:33 <ServerName> systemd[1]: Starting Snap Daemon...
Apr 24 14:33:33 <ServerName> snapd[580995]: overlord.go:284: Acquiring state lock file
Apr 24 14:33:33 <ServerName> snapd[580995]: overlord.go:289: Acquired state lock file
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 1...
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 2...
Apr 24 14:33:33 <ServerName> snapd[580995]: patch.go:64: Patching system state level 6 to sublevel 3...
Apr 24 14:33:33 <ServerName> snapd[580995]: daemon.go:250: started snapd/2.68.3-0.el8 (series 16; classic; devmode) rhel/8.10 (amd64) linu>
Apr 24 14:33:33 <ServerName> snapd[580995]: daemon.go:353: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Apr 24 14:33:33 <ServerName> snapd[580995]: backends.go:91: AppArmor status: apparmor not enabled
Apr 24 14:33:33 <ServerName> systemd[1]: Started Snap Daemon.

Have you tried restarting the snapd service or the socket?

Since you mentioned a proxy, have you set http_proxy & https_proxy in the snapd’s environment? You can run snap debug connectivity to check whether the snap store can be reached.

1 Like

Yes, we have rebooted the server, stopped and restarted the service, and uninstalled/reinstalled the service.

Do you use a proxy? Have you tried the command I suggested in my previous comment?

And the good times roll…

[@ ~]$ snap debug connectivity

error: cannot communicate with server: timeout exceeded while waiting for response

For the proxy topic, in our environment, servers only sit behind our firewall, workstations are funneled through the proxy. One of our Linux admins recommended that we have the proxy team put in a bypass. Our proxy team has not seen any instances of our server’s IP address in any of their logs.

I will look into setting the proxy in the environment, just to make sure.

Update - Since posting this:

Not sure what is occurring, but on another thread, I saw a reference to downloading hello-world, so I ran the following:

[vpamadmin@plzlxpvvpcon1 ~]$ snap download hello-world

Fetching snap “hello-world”

Fetching assertions for “hello-world”

Install the snap with:

 snap ack hello-world_29.assert

 snap install hello-world_29.snap

So I can download a snap, but I cannot install a snap…

The handling of snap download works separately from any other snap command, it is a distinct and separate implementation (which causes other issues too) so you can not really compare its behavior to something like snap install or snap refresh which both use some internal way in snapd to handle the download while snap download is actually implemented directly in the snap command itself without the need to talk to the snapd server…

1 Like

Have you set http_proxy or https_proxy in snapd service environment then?

No, still trying to figure out how to do that correctly.

https://snapcraft.io/docs/system-options#heading--proxy

1 Like

I believe alternative method to what @ogra suggested is to have a look at the snapd.service definition (systemctl cat snapd.service), there should be an Environment=... entry, which IIRC on Fedora/RHEL/CentOS references /etc/sysconfig/snapd. Then edit that file, add http_proxy & https_proxy entries, which are generally recognized as proxy settings by most programs (that’s likely why snap download worked for you, I’m guessing you already have those in your env. The entries should look like so:

http_proxy=<your-proxy>
https_proxy=<your-proxy>

save it, run systemctl restart snapd.service, verify with snap debug connectivity.

Thanks for all of the feedback and suggestions. I really appreciate your time.

I ran with @ogra proposed option first, and attempted the snap system proxy command, this resulted in a timeout error.

So then I edited my /etc/sysconfig/snapd file and restarted the service as described by @mborzecki1

These are the entries in my snapd, proxy team verified the addresses are the same for both. I tried it with and without the ports, received the same result.

SNAP_REEXEC=0
http_proxy=http://proxy.removed.com:8080
https_proxy=http://proxy.removed.com:8080
[snapd]$ sudo systemctl restart snapd.service
[snapd]$ sudo systemctl status snapd.service
â—Ź  snapd.service - Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2025-05-08 14:10:58 CDT; 45s ago
 Main PID: 1430767 (snapd)
    Tasks: 9 (limit: 48811)
   Memory: 10.4M
   CGroup: /system.slice/snapd.service
           └─1430767 /usr/libexec/snapd/snapd

May 08 14:10:58 <ServerName> systemd[1]: Starting Snap Daemon...
May 08 14:10:58 <ServerName> snapd[1430767]: overlord.go:284: Acquiring state lock file
May 08 14:10:58 <ServerName> snapd[1430767]: overlord.go:289: Acquired state lock file
May 08 14:10:58 <ServerName> snapd[1430767]: daemon.go:250: started snapd/2.68.3-0.el8 (series 16; classic; devmode) rhel/8.10 (amd64) lin>
May 08 14:10:58 <ServerName> snapd[1430767]: daemon.go:353: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
May 08 14:10:58 <ServerName> snapd[1430767]: backends.go:91: AppArmor status: apparmor not enabled
May 08 14:10:58 <ServerName> systemd[1]: Started Snap Daemon.
[snapd]$
[[snapd]$ snap debug connectivity
error: cannot communicate with server: timeout exceeded while waiting for response