(This came up for me in Wekan issue #1389)

When I try to install the snap (in Ubuntu 16.04), it gets stuck in Run configure hook of "wekan" snap if present. At this time Wekan service is already up and running, but snapd gives up on the configuration after a (built-in) 5 minute timeout and undoes the installation. (I initially thought the Node process was misbehaving, but I no longer think that’s the case here.)

Wekan snap issue #10 seems like the same problem. I enabled snap debugging as mentioned there, and will attach the result of grep snapd from during the installation attempt here.

While the service is up during the configuration phase, it produces journal log entries as usual and I’m attaching the relevant lines here.

I’ve tried purging and reinstalling snapd, disabling IPv6, turning off Apache and any other services that might be in the way (though none of them have caused issues previously), rebuilding the snap with my previous settings built in but none of it has made any difference.

In addition to my main server, I’ve since reproduced this on my desktop machine, and failed to reproduce it on another desktop and a VM with a fairly clean Ubuntu 16.04 install. The only difference between the reproducing and non-reproducing systems I’ve so far found is an Apparmor denial in /var/log/kern.log:

apparmor="DENIED" operation="open" profile="snap.wekan.mongodb" name="/sys/block/" pid=9478 comm="mongod" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

The systems where Apparmor denies mongodb’s access to /sys/block get stuck at the configure hook, whereas systems that don’t report a denial finish the configuration (and installation) successfully.

I haven’t done any customization of Apparmor rules on any of these that I can remember; it’s pretty much dark arts to me which is why I’ve avoided touching it.

I noticed that the service is up locally during the (non-finishing) configuration phase, and produces journal log entries as usual, I’m attaching the relevant lines here. The gist of it appears to be an ”Error: no hostname or hostnames provided in connection string” from programs/server/node_modules/fibers/future.js:280

I’m unable to reproduce this snap issue in a VM, but so far I’ve failed to pinpoint the curcial difference between the VM and my physical server.

I’ve tried purging and reinstalling snapd, disabling IPv6, turning off Apache and any other services that might be in the way, rebuilding the snap with my previous settings built in but none of it has made any difference.

@xet7 Unfortunately the install now also fails with the same configure hook issue as refresh did:

root@battra:~# snap remove wekan
wekan removed
root@battra:~# snap install wekan
error: cannot perform the following tasks:
- Run configure hook of "wekan" snap if present (run hook "configure": )

(For mongodump, I had to replace/upgrade the Xenial package with mongodb-org-tools from the main MongoDB site, because Xenial’s mongodump 2.6 failed with assertion: 17369 Backing up users and roles is only supported for clusters with auth schema versions 1 or 3, found: 5. With mongodump 3.6.2 I was able to dump the db successfully.)

I came across this old Wekan snap report about the same issue. I enabled snap debugging as mentioned there, and will attach the result of grep snapd from during the installation attempt here.

Should I open a new issue about this, to keep this report on topic?

@xet7 When I try to refresh the snap, it gets stuck in Run configure hook of "wekan" snap if presentwith a node process eating up the CPU. It takes 5 minutes before snapd gives up. Now the service won’t come back up, and revert also fails:

root@battra:~# snap revert wekan
error: cannot perform the following tasks:
- Run configure hook of "wekan" snap if present (run hook "configure": )

For me the double slash regression occurred at 0.62-3-g74877fd (as it did for the reporter in #1405), whereas this edge-to-edge URL issue was already there in 0.60 (but the double slash issue wasn’t). It might not definitely make them completely unrelated, but would at least hint towards it.

Impacted version: 0.60

Server Setup Information:

• Operating System: Ubuntu 16.04
• Deployment Method: snap
• ROOT_URL environment variable (Is there a subfolder?): https://my-domain.com/kan (yes)

Problem description:
A description consisting entirely of a URL that happens to extend from the left edge to the right edge of the description field makes it impossible to edit the description, as clicking anywhere on the viewer lands the click on the URL, which triggers a new browser tab instead of the editor.

Here’s a screenshot of such a URL overlapping the editing area, as highlighted by the inspector in Firefox.

There’s actually a couple of pixels worth of unlinked, clickable editor area at the right edge here, but you need a really steady hand and mouse to hit those pixels.

A workaround seems to be to change the browser zoom level (either way), causing the URL to extend either over to the next line or properly short of the right edge of the first line (turning the rest of the line clickable).

With WP_DEBUG enabled, a non-existing page (404) logs the following PHP error:

Trying to get property of non-object in wp-content/themes/cover2/components/header/header-overlay.php on line 53

I believe this is caused by the $post reference on that line, as $post has not been populated on a 404 page.

V0.55 didn’t fix this unfortunately: my steps to reproduce still produce the unstylized text and not a code block.

tracking: stable
installed: 0.55 (87) 125MB –
refreshed: 2017-11-19 19:51:40 +0200 EET

Perak’s markdown ironically has had one issue reported about a reverse problem: someone had their first line always treated as code block (which was because they had indented the line). No bugs reported about the first line indentation being trimmed off.

@droidmonkey That page seems to have been deleted from the wiki, but I think I found the problem, sort of. I’m using the -proposed repository, where the current proposed snapd-xdg-open (2.28.5) is just a transitional package (pointing back to snapd), as they’ve integrated xdg-open into snapd itself.

If I downgrade snapd-xdg-open back to 0.0.0~16.04 from -updates (which also requires a downgrade of snapd back to 2.27.5), the Open URL function in KeepassXC does work (with the fresh 2.2.2 release at least).

So an upcoming change in these packages will break this, unless they do some more juggling before the packages move from -proposed to -updates.

The issue persists for me in 2.2.1 in Ubuntu 16.04. I can get it to work by removing snad-xdg-open from snapcraft.yaml (effectively reverting PR #1011) before building the snap.