View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010717 | Taler | deployment and operations | public | 2025-12-04 10:19 | 2025-12-11 23:58 |
| Reporter | Florian Dold | Assigned To | vecirex | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Summary | 0010717: weblate does not send emails anymore | ||||
| Description | There's something broken with our weblate setup, emails for changing passwords aren't sent anymore. | ||||
| Tags | No tags attached. | ||||
| See infra chat: no weblate-notify worker can be found running, last sign of mail sent: Nov 17; more permissions needed on that server to attempt try-restart and then restart the celery-weblate.service systemd unit which should incite all needed workers when started; they can be seen here: weblate@firefly:/etc/systemd/system$ cat /etc/default/celery-weblate | grep queues CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \ --queues:notify=notify --prefetch-multiplier:notify=10 \ --queues:memory=memory --prefetch-multiplier:memory=10 \ --queues:translate=translate --prefetch-multiplier:translate=4 \ --concurrency:backup=1 --queues:backup=backup --prefetch-multiplier:backup=2" weblate@firefly:/etc/systemd/system$ | |
| I increased prio on this ticket as we need weblate functional to progress with 0010630. | |
| @vecirex: I've restarted the service (a few days ago) and e-mails seem to be working again. Do we know *why* it stopped working? | |
| Nice, thanks: @stefan confirms it to work for all things needed, so closing this. And: No, I couldn't find any sensible log info (at least not with the $USER I have). But yeah, as said above: if this happens again, we should investigate; I could just see that resource consumption was quite high (up to 12G of RAM) at some point in time, acc. to systemctl's status info. | |
| Closing, but we can reopen if it happens again. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-04 10:19 | Florian Dold | New Issue | |
| 2025-12-04 10:19 | Florian Dold | Status | new => assigned |
| 2025-12-04 10:19 | Florian Dold | Assigned To | => vecirex |
| 2025-12-04 14:42 | sebasjm | Relationship added | related to 0010715 |
| 2025-12-05 17:01 | vecirex | Assigned To | vecirex => Florian Dold |
| 2025-12-05 17:01 | vecirex | Priority | normal => high |
| 2025-12-05 17:01 | vecirex | Status | assigned => feedback |
| 2025-12-05 17:01 | vecirex | Note Added: 0026790 | |
| 2025-12-05 17:02 | vecirex | Note Added: 0026791 | |
| 2025-12-05 17:06 | sebasjm | Relationship added | related to 0010630 |
| 2025-12-08 11:28 | Florian Dold | Note Added: 0026816 | |
| 2025-12-08 11:28 | Florian Dold | Assigned To | Florian Dold => vecirex |
| 2025-12-09 11:07 | vecirex | Note Added: 0026838 | |
| 2025-12-09 11:07 | vecirex | Status | feedback => closed |
| 2025-12-09 11:07 | vecirex | Resolution | open => fixed |
| 2025-12-09 11:07 | vecirex | Note Added: 0026839 | |
| 2025-12-11 23:58 | vecirex | Relationship replaced | child of 0010630 |