Install/refresh stuck at configure hook #25
Comments
|
This usually happens on old Ubuntu and Snap versions. On my Ubuntu 17.10 based Pop!_OS reinstall of snap works. About snap in general, I still don't know is it possible to install multiple copies of Wekan to same computer with Ubuntu Snap. It is possible with Docker. |
|
I went ahead and reported this on Launchpad, we'll see if anyone there has any ideas. A new SRU (2.30) of snapd also seems to be in the works, but no release as of yet. |
|
Just a minor "no update" update: SRU 2.31 of snapd arrived via -proposed, but did not resolve this issue unfortunately. |
|
Thanks for update and keeping looking at it ! |
|
Over at Launchpad, Jamie Strandboge had this to say: "As for install/refresh getting stuck, it seems that the wekan hooks aren't exiting so snapd has no choice but to wait a while then timeout. At this point, this seems like the issues are in the wekan snap: it needs to plug hardware-observe and needs to handle error conditions better in the hooks so the exit." |
|
I created pull request with has apart of other things also hook rework, so once this lands, test from edge channel before it is promoted to stable... |
|
Still no fix I'm afraid, but watching I tried tweaking the hook by replacing There's also an 'error running snapctl: unknown service: "caddy-service"' line in syslog, but this seems to occur just alike on systems where the installation does not get stuck, so I'm not sure if it's relevant. |
|
Do you have ideas how to fix this? |
|
@uusijani I will need more info here, as where it's getting stacked is quite unusual
I just created pull request removing error you mentioned, anyway this was non blocking error so it should not affect your case. |
|
@kubiko Thanks for taking a look! I have two systems affected by this, both running Ubuntu 16.04[.3] LTS desktop and both tracking the core snap, with the following specifics: Server (though with Ubuntu desktop installed)This system is running stock 16.04 (no -proposed or HW) and Apache doing proxying. I had previously installed the snap on this system, set my root-url and changed the port to 3333 (IIRC), and it was running fine when the issue occurred sometime around the January 15th refresh. I've since removed the snap along with the settings so the attempts on this system should in theory be clean installs. Main desktopThis system has the -proposed repository enabled and the HWE stack installed, no proxy. I've only ever attempted to install Wekan on this system after the issue occurred on the other system, and it has never succeeded (so in that sense it's a clean install... attempt anyway). Since the issue with Wekan occurred, I've tried installing other snaps (on both systems) and they all work just fine. If there's anything else you need or something I missed, please let me know and I'll be happy to provide. I'm fairly sure it's a matter of some configuration these two systems happen to have, and the Wekan snap issue is mainly just that of it not failing gracefully under the circumstances and leaving me in the dark about the exact cause. |
|
Wekan is different only that is uses snap set key/value feature, which not many other snaps use. And from what you shared you are getting blocked when configure hook calls "snapctk get " which is fairly generic call and it should really block there. |
|
I did a moment ago make Wekan Snap-only release 2018-02-23 revision 128 with Wekan 0.76-26-g435501f that includes Snap-specific service life cycle improvements, Wekan help text changes and tweaks. Non-snap changes are also at Docker quay latest tag. |
|
@kubiko Output from |
|
@stolowski any idea what could be causing this? It seems like that configure hook gets stacked when calling 'snapctl get' |
|
And now, suddenly, it just works again. Darn it, I was hoping to catch the exact cause. Unless you guys already found and fixed it? What's changed on my end since I posted the last comment a week ago is the core snap updating from 4017 to 4110. |
|
I did push new Wekan version earlier today. Yes there has been snap fixes to Wekan, unless this is a Heisenbug. |
|
@xet7 Alright, here's hoping those fixes hit the spot! Thanks a lot. |
|
@uusijani I have made some changes to the install and configure hook as there was problem with services not starting properly. Long story short, there was happening race when I was trying to mingle with services but snap itself was still in process of installation. You can see this in your logs with text "change in progress" |
|
@kubiko That's good to hear, gives me confidence in running the snap on my main server again (instead of the VM). Thanks again guys! |
|
I just arrived at this problem. Plz help me. |
|
How is novnc related to Wekan? |
(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 snapdfrom 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: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.
The text was updated successfully, but these errors were encountered: