Running the latest kdenlive 21.08 snap on kubuntu 21.04 with nvidia GPU, I cannot render any projects, as the dialog sits at a waiting state forever.
* CREATED JOB WITH ARGS: ("/snap/kdenlive/39/usr/bin/melt-7", "/tmp/kdenlive-eYAlDK.mlt", "/home/sbutcher/Videos/Kdenlive/pytorch2.wav", "-pid:161521", "-out", "11649")
starting kdenlive_render process using: "/snap/kdenlive/39/usr/bin/kdenlive_render"
Qt: Session management error: Could not open network socket
dbus[161834]: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file ../../../dbus/dbus-message.c line 1366.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
So I installed this snap since I was asked to take a look at it, and I can reproduce not being able to render anything and I see a bunch of system journal denials, it appears that a whole bunch of paths for some reason are being resolved as /snap/core20/current/lib/foo/… instead of just being accessed directly as /lib/foo/… so someone should look into why this snap seems to be trying to defeat the mount namespace and reach into the core20 snap directly. If I were to guess, I would guess that this snap used to be classic and has code that is doing it this way because that’s the thing to do for classic snaps (or it is incorrectly borrowing code from another classic snap that does it correctly this way).
Also I see some denials that would be resolved by adding hardware-observe plug to the snap, which makes sense to me since it’s a rendering snap that probably needs to know about the hardware it is running on.
There are also denials for /etc/xdg/menus and /etc/xdg/menus/applications-merged, but I think maybe this is just indicative of not having the right set of snap specific XDG env variables defined?
There are also some paths we don’t seem to have support for anywhere that we might need to add in snapd mainly:
/proc/sys/kernel/core_pattern <- this probably could be added to the default template I think, it makes sense for snaps to be able to read their own core dumps since core dumps get put in the snaps current working directory, but this denial is probably harmless for now, just less debugging is possible
/var/lib/snapd/hostfs/usr/lib/x86_64-linux-gnu/libOpenGL.so.0.0.0 <- this one needs to be added to the opengl interface, seems we added it to snap-confine mounts, but not to the corresponding snapd opengl interface
Finally there are a number of D-Bus denials for the following things:
Oh also there are two seccomp denials for sched_setattr and setpriority, neither of which are likely to be granted to this snap since they are considered somewhat privileged and we currently lack the ability to do fine grained pid filtering for syscalls in seccomp to limit the pids that a snap can use syscalls with to only their own snap cgroup.
Thanks for having a look. I agree, the kdenlive_render supporting binary seems to be crashing when it tries to load /snap/core20/usr/lib/libacl.0 instead of /usr/lib/libacl.0 (I’m paraphrasing). I don’t know why it would do that. I’ll keep playing around to see if anything helps.
Probably not. I’m just pointing out the reason for those denials. The loader tries the rpath first, and thus we get a denial.
The render queue problem seems related to this:
starting kdenlive_render process using: "/snap/kdenlive/39/usr/bin/kdenlive_render"
Qt: Session management error: Could not open network socket
No org.kde.JobViewServer registered, trying to start kuiserver
Failed to start kuiserver
Ah very insightful, this seems to imply that the kde-frameworks-5-qt-5-15-3-core20 snap is built incorrectly, I’m not sure why it was built such that the dynamic libraries there have rpath setup to look in /snap/core20/current/… unless that content snap was built to be consumed by classic snaps somehow?
Do you see any journal denials on your system when this happens? I don’t see this message on the terminal when I tried testing kdenlive last week by just doing snap run kdenlive
I think it’s a dbus permission problem. If you install with devmode and set QDBUS_DEBUG=1, you can see the working communication between kdenlive_render and kdenlive.
I think it fails here:
QDBusConnectionPrivate(0x7f52e0003c00) sending message: QDBusMessage(type=MethodCall, service="org.freedesktop.DBus", path="/org/freedesktop/DBus", interface="org.freedesktop.DBus", member="ListNames", signature="", contents=() )
QDBusConnectionPrivate(0x7f52e0003c00) got message reply: QDBusMessage(type=Error, service="org.freedesktop.DBus", error name="org.freedesktop.DBus.Error.AccessDenied", error message="An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.286\" (uid=1001 pid=68175 comm=\"/snap/kdenlive/x4/usr/bin/kdenlive_render /snap/kd\" label=\"snap.kdenlive.kdenlive (enforce)\") interface=\"org.freedesktop.DBus\" member=\"ListNames\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.DBus\" (bus)", signature="s", contents=("An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.286" (uid=1001 pid=68175 comm="/snap/kdenlive/x4/usr/bin/kdenlive_render /snap/kd" label="snap.kdenlive.kdenlive (enforce)") interface="org.freedesktop.DBus" member="ListNames" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)") )
which means it probably needs the system-observe interface. I tried and this seems to solve the problem. Is that an interface that makes sense for a video editor, and would autoconnect be granted?
Yes I think system-observe is reasonable to be granted auto-connection for a video editor, if one of the snap collaborators can add system-observe to the snap and then start a forum topic in #store-requests for auto-connection we can get that moving.
I’m still very confused why the qt content snap has these rpaths set like that, it probably needs to be looked at more
From: Jonathan Riddell jr@jriddell.org
Date: Tue, 9 Feb 2021 10:52:34 +0000
Subject: [PATCH] enable patchelf as we can not do the hack of patchelf
manually as we did in core18 (see Rakefile) cos now snapcraft is installed as
a readonly snap
(ark instead of kdenlive).
Sorry. See