I’ve configured my wpe-webkit-mir-kiosk snap to restart the WPE web process on failures. However, whenever the renderer process crashes, the browser fails to actually reload the page and shows a default crash message to the user. This is not ideal for use cases without a direct input device to trigger a reload.
I could reproduce the crash and when running WPE/cog with G_MESSAGES_DEBUG=allLIBGL_DEBUG=verbose and WAYLAND_DEBUG=1, I see the following error messages around the time of a crash:
Failed to set thread scheduler attributes: Operation not permitted
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /root/snap/wpe-webkit-mir-kiosk/41/.drirc: No such file or directory.
Does the GLib thread scheduler call require any snapd interfaces, or should I file this with WPE developers?
Any hint appreciated
(ping @jdstrand whose interface knowledge helped me in the past )
Hmm, seems the only interface that allows this is docker-support, but it’s unclear to me that this seccomp denial is the cause of the issue, when you reproduce the issue, do you see that seccomp denial show up or was that denial from a “long time ago”?
While the crash still has to reoccur on the initial device, I checked the logs on a secondary one – same entry as well as additional SECCOMP entries with syscall 380 from earlier crashes. The time stamps should be around the time where the WPE renderer process crashed.
Temporarily, can you try adding the plug docker-support to your application and connect it manually (along with the other interfaces you may have connected through store auto-connects), and see if you can still reproduce? if so then we will need to look into how to provide your application access to the sched_setattr syscall, because presumably your application is not docker
I can propose something like this independently of whether this ends up fixing the bug for @tobias unless you already have this on your queue of updates
Sorr for the delay, but while the crash was reproducible just this morning, it has yet to reoccur with the try-mode snap where I added docker-supportwithout connecting it yet. So basically the same snap as before, but with an unconnected interface and in try mode ¯_(ツ)_/¯
Re: @jdstrand 's post: process-control is exactly the interface which I suspected to allow this syscall.
The crash occurred again late yesterday evening, again with SECCOMP audits for syscall sched_setattr (380) in the log. I’ve connected the docker-support interface and restarted the service, now tailing the log, we’ll see if this fixes the issue.
UPDATE
The crash finally occurred again, this time with docker-support connected:
I’m not sure if this is just an info that the WPEWebProcess ran a sys call, which should now be permitted by the docker-support interface, or if this means that WPE still can’t run scheduler_setattr.
no that message means it was really denied, but it’s odd that it was denied and you have docker-support connected, did you add the plug to all the apps that are in your snap?
In my initial test, I just unsquashed a copy of the candidate snap on-device (Raspberry Pi), added docker-support to the browser service’s plugs stanza in meta/snap.yaml and loaded it with snap try. Launchpad remote-build took seemed stuck yesterday, and trying @ogra’s fabrica image is still on the todo list …
Per the snapcraft.yaml of the current candidate revision, my snap only has this service and a second service that restarts the browser when the Wayland socket is deleted.
This morning, I added the plug modifications shown below, ran a fresh remote build and loaded the resulting snap onto a Pi. AFAIK, the global plugs definition shouldn’t be required for services to work?
Expand plug modifications to snapcraft.yaml
plugs:
docker-support:
privileged-containers: true
apps:
browser:
command: bin/desktop-launch $SNAP/bin/launch-wpe
daemon: simple
restart-condition: always
slots: [dbus-cogctl]
plugs:
# Auto-connected
- wayland
- opengl # required for libEGL to work
- network
- network-bind # Remote inspector
- upower-observe
# Manually connected, show up as AppArmor denials but
# basic browsing seems to work fine without
- avahi-observe # zeroconf name resolution
# snappy-debug suggestions
- network-manager
- hostname-control
- process-control
# - browser-support # TODO: Use this if/when we can get rid of preload/desktop-launch
- docker-support
restart-watcher:
command: bin/watcher.sh
daemon: simple
plugs:
- docker-support
Maybe the quick&dirty snap try approach doesn’t apply the change properly?
P.S.:
I’m testing in parallel on two different Raspberry Pi Core installations and an amd64 PC with Core running. On the PC, the current WPE snap has yet to crash at all (showing the exact same page), so I focus testing on the Pi devices. That’s why I can’t build on my amd64 host but have to rely on either LP builders or another local armhf builder
if your existing installation of the snap was already a snap try, then just modifying the plugs of the snap.yaml file after you ran snap try will not be sufficient, but if you run snap try after the change to snap.yaml, then it is certainly picked up. You can confirm whether it is in the profile for your daemon or not definitively by running
Also we did just land the sched_setattr change to process-control so in a few hours you can switch to just using process-control by refreshing to the edge channel of snapd.
I think it was a locally installed snap (snap install --dangerous locally_built_file.snap), and I definitely ran snap tryafter the changes to snap.yaml. In any case, after installing the rebuilt test snap has sched_setattr in its seccomp profile. Now I wait for the crash to reoccur
FYI @ijohnson, @ogra : I finally had some time to come back to this issue; turns out that having sched_setattr helps but the remaining issue comes from a bug in cog (the web view container). It restarts the WPEWebProcess after a crash, but doesn’t properly reload the page. See https://github.com/Igalia/cog/issues/230
)
)
