pactl: error while loading shared libraries: libpulsecommon-13.99.so: cannot open shared object file: No such file or directory
and for Webkit2GTK
Unable to fork a new child process: Failed to execute child process ?/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess? (No such file or directory)
Trace/breakpoint trap (core dumped)
Running a find / -name "libpulsecommon-13.99.so" returns
adding extensions: [gnome-3-38] to the app section gets the program to launch but I always get errors when the program tries to access pulseaudio via pactl like Failed to get module information: Access denied
to the app section gives me Connection failure: Connection refused and pa_context_connect() failed: Connection refused and the the WebViewGTK error mentioned at the top persists
Besides that I’m not sure if running pactl inside a snap qualifies it for a classic confinement as per
take a look at this snippet from the desktop-launch scripts:
# Make PulseAudio socket available inside the snap-specific $XDG_RUNTIME_DIR
if [ -n "$XDG_RUNTIME_DIR" ]; then
pulsenative="pulse/native"
pulseaudio_sockpath="$XDG_RUNTIME_DIR/../$pulsenative"
if [ -S "$pulseaudio_sockpath" ]; then
export PULSE_SERVER="unix:${pulseaudio_sockpath}"
fi
fi
(and indeed you need to make sure that a pulseaudio daemon is running on the system)
When adding the gnome extension I don’t need the layout, the UI works in this case. But it prints this at the start and takes a lot longer to launch:
Warning: Schema “org.gnome.system.locale” has path “/system/locale/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy” has path “/system/proxy/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.http” has path “/system/proxy/http/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.https” has path “/system/proxy/https/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.ftp” has path “/system/proxy/ftp/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.socks” has path “/system/proxy/socks/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Also I still get Failed to get module information: Access denied for each pactl command.
Furthermore I’m not sure if the gnome-3-38 should be used in production since it’s labeled as experimental here:
I tried but it didn’t help. So I guess the gnome extension is the way to go since I got farther with it. I described the problems with it in my reply above.
You’re likely accessing more than the audio-playback interface allows when using pactl, so you might need to add and connect (it’s not automatic) the pulseaudio plug.
The thing is that we load PulseAudio modules (via pactl load-module) and I noticed currently just that fails inside the snap. Listing something via pactl list works.
The - value in slot column means it’s declared, but it isn’t connected, try
sudo snap connect soundux:pulseaudio :pulseaudio
If this fixes the problem, your users will have to run that themselves manually when they install the snap OR you’d have to apply for an auto connection from the store to do it for them.
Running the pactl load-module commands like pactl load-module module-null-sink ... on the host system works. $SNAP/usr/bin/pactl is used here but we use just pactl. Maybe we have to use it like that too?
The module-snap-policy Pulse Audio module found on Ubuntu systems detects when the client is running with snap confinement, and applies various restrictions. In particular, it denies loading and unloading of modules:
As Pulse Audio modules are run within the daemon process outside of the sandbox, it is not safe to give a sandboxed application the ability to control how they run.
The restrictions are implemented within the pulseaudio daemon, so the “access denied” error is not down to the path of the pactl executable.
You’re right. It looks like the patches I provided were refactored a bit by the security team, and we did in fact fix the “module loading by classic snaps” problem, as outlined in bug #1886854.
