View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010318 | Taler | deployment and operations | public | 2025-08-31 17:55 | 2026-09-19 14:41 |
| Reporter | Christian Grothoff | Assigned To | Florian Dold | 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 | feature | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 1.0 | ||||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0010318: systemd service supervision gives up too quickly | ||||
| Description | I don't think it's a good idea for our systemd units to just give up after just a few minutes. We need to fix them; the same issue probably applies to other systemd units as well. I recall we used some super weird "wait for $X seconds on certain failure types" to trick systemd into hopefully doing the right thing, we need to re-view that as well. In general, systemd should probably never give up, at best reduce the frequency of re-trying. Naturally, we should still see that the services failed / receive a notification in monitoring! | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0010406 | informing | Florian Dold | Taler | review systemd restart policies for all components |
| ACK, I look into this w/ high prio. | |
| => DD102. | |
| Fixed across all relevant (i.e. packaged by packaging/ng) components. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-08-31 17:55 | Christian Grothoff | New Issue | |
| 2025-08-31 17:55 | Christian Grothoff | Status | new => assigned |
| 2025-08-31 17:55 | Christian Grothoff | Assigned To | => vecirex |
| 2025-09-27 18:07 | Christian Grothoff | Target Version | 1.1 => 1.2 |
| 2025-09-27 18:17 | Christian Grothoff | Target Version | 1.2 => 1.3 |
| 2025-09-28 17:14 | vecirex | Note Added: 0026052 | |
| 2025-11-28 19:53 | Christian Grothoff | Target Version | 1.3 => 1.4 |
| 2026-01-20 15:50 | Florian Dold | Relationship added | duplicate of 0010406 |
| 2026-01-25 14:54 | Christian Grothoff | Target Version | 1.4 => 1.5 |
| 2026-02-22 13:53 | Christian Grothoff | Priority | urgent => high |
| 2026-02-22 13:53 | Christian Grothoff | Target Version | 1.5 => 1.7 |
| 2026-02-22 13:53 | Christian Grothoff | Status | assigned => implementing |
| 2026-09-02 23:43 | Florian Dold | Assigned To | vecirex => Florian Dold |
| 2026-09-03 00:07 | Florian Dold | Note Added: 0029834 | |
| 2026-09-08 19:29 | Florian Dold | Status | implementing => informing |
| 2026-09-08 19:29 | Florian Dold | Resolution | open => duplicate |
| 2026-09-08 19:29 | Florian Dold | Note Added: 0029927 | |
| 2026-09-16 07:55 | vecirex | Status | informing => closed |
| 2026-09-19 14:41 | Christian Grothoff | Fixed in Version | => 1.6 |
| 2026-09-19 14:41 | Christian Grothoff | Target Version | 1.7 => 1.6 |