I’ve reverted my live server back to 6.09 (and locked it there) for now.

On the testing VM I started from scratch: I deleted all existing data and reinstalled the 10.02 snap. Right after installing it’s working fairly normally, no noticeable slowdown, and ferretdb is down in double- or even single digits of CPU percentage.

I then exported my main working board from the live system (as JSON, 11 MB) and imported it into the VM installation. There was some noticeable slowdown right after, but eventually it settled back into working normally (i.e. no tangible slowdown).

But ferretdb’s CPU usage began to climb, until it was again using more than 160 % of the CPU.

Since then, I’ve tried to isolate the triggering cause from the import (if any), but no luck so far.

The only possibly relevant messages I’ve seen in the log during this were:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added to [Gzip]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [ServerResponse]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

Bug Description

With the snap update from 9.98 → 9.99, we’ve made some progress: Wekan now responds to requests from the proxy (thanks to xet7’s rapid fixes in #6476).

Instead, with 9.99 and now 10.00, it seems I’m hitting the performance issues others have reported (#6467, #6474) earlier.

My physical server is only a dual-core Pentium G630, but it does have 16 GB of RAM, and I’m the sole user of my Wekan instance, so it’s not a huge deployment. Then again, I have been running Wekan for years by this point, so there’s quite a lot of accumulated history tucked away in the archives.

I have a VM running another Wekan instance for testing purposes (with a setup cloned from the main server some time ago), and it’s affected by the same performace issues despite running with 4 virtual cores sliced from my main desktop’s more modern Core i7-8700 CPU.

Symptoms

Running top on the server shows ferretdb constantly using more than 100 % of the CPU.

Symptoms on the client side are varied. Only loading the login dialog seems to work without any delay; any problems occurring thereafter, as listed below, may or may not appear, probably because this is a performance issue, so it depends on how well/poorly the backend is doing.

Clicking the ”Sign In” button seemingly does nothing: no visible reaction, nothing in the browser console.

Logs from the server (journalctl -xeu snap.wekan.wekan) do show this though:

sqlite-busy.log

Occasionally the same error is shown on the login screen (in the browser).

After a couple of minutes, another previously reported issue (#6380): all fields aside from the language selector disappear from the login screen. A couple more minutes, and the username and password fields reappear, along with ”Authentication method”, with an empty dropdown menu (i.e. no options to choose from).

A few more minutes (and clicking the still seemingly non-functional Sign In button), and the main screen with my boards appears. I select one of them, and, after being stuck loading it for maybe half an hour (with only the header bar and the loading indicator dot animation visible), it then just says ”Page not found” where the board contents should be.

With 10.00 freshly installed, although perhaps just due to the fresh restart, the login appeared snappier, and I was able to get to the board, although it was still missing at all the attachments and my avatar. Later attempts to login (in a new browser window) seem just as slow as before.

Steps to Reproduce

1. update snap from 6.09 to 9.99/10.00

Relevant Logs

Additional Context

I have one tab with the same board open from before the recent updates, so still displaying the old UI, and (somewhat curiously) it doesn’t appear to suffer from any slowdown. This could just be that it’s already loaded all of what the new tab tried to get from the DB. Alternatively, it’s not connected to the backed at all, despite not showing the usual warning, because any testing changes I make there don’t show up on the new UI (when I can get to the board).

Bug Description

Yesterday’s 9.95 had rendered Wekan (installed as a snap) inoperable, but from others’ issue reports and comments here I decided to wait until the fixes for those had been released.

With 9.98 now installed, the Wekan service itself seemingly starts without issues, but Apache (which is what I’m using for a proxy) still can’t connect to it:

http: attempt to connect to 127.0.0.1:3333 (127.0.0.1:3333) failed

Indeed, a netstat command confirms that port 3333 (which is what I’ve set Wekan’s port to) is not open.

My settings and output from snap info are below. I set debug=true, hoping to get more details, but it didn’t do anything.

Attached is all that journalctl -xeu snap.wekan.wekan.service logs for the service upon startup.

wekan.log

Steps to Reproduce

1. have Wekan snap 6.09
2. snap set wekan port=3333
3. have the snap update to 9.98

Relevant Logs

    # snap get wekan
    Key                         Value
    database                    ferretdb
    debug                       true
    mail-from                   Wekan <wekan.battra@[REDACTED DOMAIN]>
    mail-url                    smtp://127.0.0.1:25
    port                        3333
    richer-card-comment-editor  false
    root-url                    https://[REDACTED DOMAIN]/kan

    # snap info wekan
    name:      wekan
    summary:   Open-Source kanban
    publisher: Lauri Ojansivu (xet7)
    store-url: https://snapcraft.io/wekan
    contact:   support@wekan.team
    license:   MIT
    description: |
      WeKan is an Open-Source and collaborative kanban board application.
      
      Whether you’re maintaining a personal todo list, planning your holidays with some friends, or
      working in a team on your next revolutionary idea, Kanban boards are an unbeatable tool to keep
      your things organized. They give you a visual overview of the current state of your project, and
      make you productive by allowing you to focus on the few items that matter the most.
      Depending on target environment, some configuration settings might need to be adjusted.
      For full list of configuration options call:
      $ wekan.help
      
      Note: At https://snapcracft.io/wekan video 2023-12-08, after Meteor News, WeKan Interview starts
      at 22min 22sec.
    commands:
      - wekan.database
      - wekan.database-backup
      - wekan.database-list-backups
      - wekan.database-restore
      - wekan.help
      - wekan.maintenance
      - wekan.migrate
    services:
      wekan.caddy:    simple, disabled, inactive
      wekan.ferretdb: simple, enabled, active
      wekan.mongodb:  simple, disabled, inactive
      wekan:          simple, enabled, active
    snap-id:      jtpboSYvTCEyHoutkkRo1SI9ioSMOUb3
    tracking:     latest/stable
    refresh-date: tänään 02:03 EEST
    channels:
      latest/stable:    9.98 2026-07-17 (3457) 393MB -
      latest/candidate: 9.98 2026-07-17 (3457) 393MB -
      latest/beta:      9.98 2026-07-17 (3457) 393MB -
      latest/edge:      9.98 2026-07-17 (3457) 393MB -
    installed:          9.96            (3451) 393MB -

Additional Context

No response

Thanks. I had hoped for either some correlation with my history.log, or something connected to drawing/rendering the desktop, but nothing jumps out from those, alas. The nvidia/libnvidia-* ones from the 23rd would be the obvious suspect, except you had already posted about the problems (above) when those packages were getting installed.

The apparmor denials for Firefox seem to be a known issue. I don’t use Firefox (and back when I did, I used the Mozilla PPA version instead of the snap), but I suspect they’re not related to the freeze. At least not unless you’re running particularly low on memory.

After last night’s refresh I’m now running 2024.10.4. Attempting to update Nordpool, fmi-hass-custom and pytapo fail with:

Unable to install package nordpool==0.4.2: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)
Unable to install package fmi-weather-client==0.4.0: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)
Unable to install package pytapo==3.3.32: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)

It’s apparently due some changes in core, as some people running HA inside a customized Docker have also suffered this.

In the previous latest/stable, updating Nordpool and FMI weather client failed with errors about pip’s version, so I had reverted those back to their earlier versions and put off retrying the updates until now. Pytapo could be a dependency of Tapo Camera Control, which also updated recently.

I can already guess the answer to this is ”no, because of how snap works”, but would it be possible for Wekan (installed as a snap) to use mongodb tools already installed on the host system? The reason I’m asking is that I’m running Unifi’s network application on the same non-AVX-capable host, and the installation script for it has added a mongodb repository patched to work without AVX, so that’s already covered.

Yeah, still not working for me either. Restarting HA snap just results in the same traceback getting logged as before.

Settings > Devices & services > HACS shows it’s up to date (or at least at that same version, 1.34.0). I can’t find a ”Configuration” or ”HACS update” view under the HACS service, only the one with related Service info, Automations and so on (possibly because HACS is ”Not loaded”, which is the issue).

I don’t know if the host system has any bearing on this, but mine is running Ubuntu 20.04, and I’ll happily provide any other info if needed.

There’s a bug report about this on Launchpad.

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

• Did you test in newest Wekan?: 5.90
• Did you configure root-url correctly so Wekan cards open correctly? yes
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Http frontend if any: Apache
• What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
2. Open a card in Wekan.
3. Select + from the Attachments section.
4. Select ”Computer” from the popup.
5. Select example.json.
6. With the JSON file now attached to the card, select to ”Download” it.
7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

• Deleting the attachment seems to work.
• The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Since recently, editing the description takes two clicks instead of just one. The first click turns the content into a textbox, but it remains unfocused until I click it again.

Issue

Server Setup Information:

• Did you test in newest Wekan?: yes
• For new Wekan install, did you configure root-url correctly so Wekan cards open correctly? yes
• Wekan version: 4.49
• Meteor version: 2.0-beta.4
• Node version: 12.19.0
• MongoDB version: 3.2.22
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Http frontend if any: Apache
• What webbrowser version are you using? Both Firefox 82.0.2 and Chrome 86.0.4240.183 equally affected.
• If using Snap, what does show command sudo snap logs wekan.wekan? nothing

Problem description:
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.

Steps to reproduce:

1. Open a card
2. Click on the description once

What I expect to happen:
For the description to have focus (i.e. cursor, to be able to type)

What happens instead:
The description textbox remains unfocused and I can not type into it

Console log contents

site.webmanifest:1 GET https://my-domain.com/site.webmanifest 404 (Not Found)
site.webmanifest:1 Manifest: Line: 1, column: 1, Syntax error.
A bad HTTP response code (404) was received when fetching the script.
mZLgcqMWYXM4o7dmL:1 Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://my-domain.com/') with script ('https://my-domain.com/pwa-service-worker.js'): A bad HTTP response code (404) was received when fetching the script.

It seems to refer to to paths in the domain root, whereas my root-url has the path https://my-domain.com/kan. Not sure if that’s related to the issue or not.