I noticed my mongodb.log has grown pretty large:
root@battra:~# ls -lh /var/snap/wekan/common/mongodb.log
-rw-r--r-- 1 root root 3,1G touko 4 21:14 /var/snap/wekan/common/mongodb.log
The first lines in the log are timestamped 2018-03-02T16:39:44.754+0200.
Should the log rotate automatically, but doesn’t for some reason? Alternatively, should I truncate it manually (and if so, how)? I have no use for the logs apart from the occasional bug reports here, so even losing all of it is fine.
There are no related mongodb settings keys AFAICS. (And sorry if this is unrelated to snap packaging, it was just a guess on my part.)
Server Setup Information:
- Wekan version: 2.65
- Operating System: Ubuntu 16.04
- Deployment Method: snap
- Http frontend if any: Apache 2.4
(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
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.