View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008637 | Taler | exchange | public | 2024-03-13 17:38 | 2024-04-15 19:32 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | 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 | no change required | ||
| Target Version | 0.10 | Fixed in Version | 0.10 | ||
| Summary | 0008637: weird logs during exchange Debian package upgrade | ||||
| Description | Not sure if that is expected or if we're doing something wrong with setting up the systemd units. Setting up taler-exchange (0.9.4-2) ... taler-exchange-aggregator.service is a disabled or a static unit not running, not starting it. taler-exchange-closer.service is a disabled or a static unit not running, not starting it. taler-exchange-expire.service is a disabled or a static unit not running, not starting it. taler-exchange-httpd.service is a disabled or a static unit not running, not starting it. taler-exchange-httpd.socket is a disabled or a static unit not running, not starting it. taler-exchange-secmod-cs.service is a disabled or a static unit not running, not starting it. taler-exchange-secmod-eddsa.service is a disabled or a static unit not running, not starting it. taler-exchange-secmod-rsa.service is a disabled or a static unit not running, not starting it. taler-exchange-transfer.service is a disabled or a static unit not running, not starting it. taler-exchange-wirewatch.service is a disabled or a static unit not running, not starting it. | ||||
| Tags | No tags attached. | ||||
| Well, we very explicitly configured the Debian package to NOT start the services, so this is very much expected. The reason is that we expect the admin to first set up or migrate the DB manually and THEN restart the services. | |
| But the services *are* running, that's why I think the logs are confusing. | |
| Maybe this is just a "false positive warning" because the *target* is indeed enabled, while the individual services units are not enabled? | |
| I've checked, this seems to be perfectly normal given that we explicitly do dh_installsystemd with --no-start, --no-enable, --no-stop-on-upgrade. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-13 17:38 | Florian Dold | New Issue | |
| 2024-03-13 17:38 | Florian Dold | Status | new => assigned |
| 2024-03-13 17:38 | Florian Dold | Assigned To | => Christian Grothoff |
| 2024-03-13 19:18 | Christian Grothoff | Note Added: 0021902 | |
| 2024-03-13 19:18 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-03-13 19:18 | Christian Grothoff | Status | assigned => feedback |
| 2024-03-13 19:34 | Florian Dold | Note Added: 0021903 | |
| 2024-03-13 19:35 | Florian Dold | Note Added: 0021904 | |
| 2024-03-13 19:35 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-04-08 17:45 | Christian Grothoff | Status | feedback => informing |
| 2024-04-08 17:45 | Christian Grothoff | Resolution | open => fixed |
| 2024-04-08 17:45 | Christian Grothoff | Note Added: 0022158 | |
| 2024-04-08 17:45 | Christian Grothoff | Resolution | fixed => no change required |
| 2024-04-08 17:45 | Christian Grothoff | Fixed in Version | => 0.10 |
| 2024-04-15 19:32 | Christian Grothoff | Status | informing => closed |