Thank you for the report. We will check this out.

There should never be a link /usr/libexec/snapd -> /usr/lib/snapd. Can you post the actual error message, which snap is causing this and what is the actual distro you are using snapd from EPEL on?

Things seem to be just fine on CentOS 7:

google:centos-7-64 .../mini/hello# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core) 
google:centos-7-64 .../mini/hello# rpm -qa \*snapd\*                                                                                                                          
snapd-2.39.2-1.el7.x86_64                                                              
snapd-selinux-2.39.2-1.el7.noarch
Hello World!
google:centos-7-64 .../mini/hello# snap install test-snapd-tools
test-snapd-tools 1.0 from Canonical✓ installed
google:centos-7-64 .../mini/hello# test-snapd-tools.cmd echo foo
foo
google:centos-7-64 .../mini/hello# snap install lxd
lxd 3.14 from Canonical✓ installed
google:centos-7-64 .../mini/hello# lxd init --auto
google:centos-7-64 .../mini/hello# lxc list
To start your first container, try: lxc launch ubuntu:18.04

+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
google:centos-7-64 .../mini/hello#

# yum install snapd
....
Installed:
  snapd.x86_64 0:2.39.2-1.el7                                                                                                     

Dependency Installed:
  snap-confine.x86_64 0:2.39.2-1.el7   snapd-selinux.noarch 0:2.39.2-1.el7  
  squashfuse.x86_64 0:0.1.102-1.el7    squashfuse-libs.x86_64 0:0.1.102-1.el7  

Complete!
# snap install helloworld
error: cannot communicate with server: Post http://localhost/v2/snaps/helloworld: dial unix /run/snapd.socket: connect: no such file or directory
# systemctl start snapd
Job for snapd.service failed because the control process exited with error code. See "systemctl status snapd.service" and "journalctl -xe" for details.
# systemctl status snapd.service
● snapd.service - Snappy daemon
   Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Wed 2019-07-03 19:33:34 EDT; 19s ago
  Process: 25980 ExecStart=/usr/libexec/snapd/snapd (code=exited, status=1/FAILURE)
 Main PID: 25980 (code=exited, status=1/FAILURE)
...
# systemctl status snapd.socket
● snapd.socket - Socket activation for snappy daemon
   Loaded: loaded (/usr/lib/systemd/system/snapd.socket; disabled; vendor preset: disabled)
   Active: active (listening) since Wed 2019-07-03 19:33:33 EDT; 1min 4s ago
   Listen: /run/snapd.socket (Stream)
           /run/snapd-snap.socket (Stream)
...
...
# /usr/libexec/snapd/snapd
AppArmor status: apparmor not enabled
cannot run daemon: cannot obtain snap-seccomp version information: fork/exec /usr/lib/snapd/snap-seccomp: no such file or directory
#

Which distro is this? Please post the contents of /etc/os-release.

This is private CentOS derivative and /etc/os-release does not say ID=fedora which snap patch https://github.com/snapcore/snapd/commit/fbfee0ea2b7c43de58b2091ee231cc988a9ef925 expects.
Why would EPEL provided snap package perform completely unnecessary /etc/os-release lookup when EPEL packages are built exclusively for RHEL and its derivatives?

Only some snapd components can be configured at build time. Other bits rely on run-time detection. Hopefully, we'll be able to do away with the run time mechanism in the future, but currently we rely on some of the basic distro setup to figure out things right.

Fedora, and other distributions sharing the same layout, commonly use /usr/libexec/<packagename> as the location of package specific internal tools. The fact that these distributions are alike to certain extent, is expressed by setting ID_LIKE=".. fedora .." in /etc/os-release. RHEL, CentOS and Amazon Linux 2 already do that. if your distro has not diverged too much, would you consider adding it too?

I understand that generic snapd may need to do some run-time detection but EPEL compiled exclusively for well known RHEL/CentOS layout there is no need to do any kind of run-time OS lookup whatsoever.
Your workaround worked, copied ID_LIKE line from CentOS and snapd started. But please consider eliminating run-time lookup in EPEL packages. Thank you.

(In reply to Eugene Kanter from comment #7)
> I understand that generic snapd may need to do some run-time detection but
> EPEL compiled exclusively for well known RHEL/CentOS layout there is no need
> to do any kind of run-time OS lookup whatsoever.
> Your workaround worked, copied ID_LIKE line from CentOS and snapd started.
> But please consider eliminating run-time lookup in EPEL packages. Thank you.

I don't think we can reasonably do so. Snapd is primarily written in Go, and Go's ability to handle compile-time conditionals is pretty poor. The reason snapd has so many runtime conditionals is because the language and tooling makes it pretty difficult to do otherwise.

I simply meant to say that that EPEL package should apply a patch to eliminate any run-time conditionals.

For example EPEL package spec file defines directory structure at build time

--with-snap-mount-dir=%{_sharedstatedir}/snapd/snap

and thus spec file should patch snapd code to match package directory structure without a need for run-time lookup.

The philosophy of upstream is that they want to move away from compile time checks to runtime checks as code is converted from C to Go, for the reason outlined earlier. It is unlikely I will be able to convince them otherwise, and I'm not sure I want to, as doing so would inhibit things like having a Fedora based core snap running on non-RH/Fedora systems.