| 17 Feb 2022 |
 hexa | cc Dandellion | 23:43:56 |
| hexa | the startup order in your module … needs work 😀 | 23:44:08 |
 Dandellion | doesn't it just, resolve itself with the autorestart :P | 23:44:36 |
| Dandellion | but yes, it does | 23:44:54 |
| hexa | systemd[1]: matrix-synapse-worker-client1.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: matrix-synapse-worker-client1.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Synapse Matrix Worker.
systemd[1]: matrix-synapse-worker-client1.service: Consumed 3.602s CPU time, no IP traffic.
| 23:45:12 |
| hexa | nope, didn't | 23:45:14 |
| Dandellion | huh, I think it needs to wait for the main synapse to actually run the migration as well, I'm not quite sure how to wait for a healthy signal like that | 23:46:27 |
 f0x | In reply to @hexa:lossy.network
the startup order in your module … needs work 😀 the way my module + the synapse systemd docs do it is setting after = ["matrix-synapse.service"] on all the workers | 23:46:31 |
| f0x | In reply to @dandellion:dodsorf.as
huh, I think it needs to wait for the main synapse to actually run the migration as well, I'm not quite sure how to wait for a healthy signal like that oh, hmmm | 23:46:44 |
| hexa | this module does the same 🙂 | 23:46:47 |
| hexa | usually type notify ig | 23:46:59 |
| hexa | so maybe synapse signaled successful startup too early | 23:47:33 |
| f0x | i wonder if that's an upstream issue then, at the least with the synapse systemd docs | 23:48:27 |
| 18 Feb 2022 |
| hexa | yep, wondering the same | 00:06:41 |
| hexa |
Behavior of notify is similar to exec; however, it is expected that the service sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent.
| 00:07:10 |
| hexa | https://www.freedesktop.org/software/systemd/man/systemd.service.html | 00:07:13 |
| hexa |
Feb 17 23:43:37 ganymede systemd[1]: Started Synapse Matrix homeserver.
Feb 17 23:43:38 ganymede synapse[2214287]: synapse.storage.background_updates: [background_updates-0] Starting background schema updates
| 00:13:18 |
| hexa | collecting the complete logs, bear with me | 00:14:13 |
| Dandellion | seems a little weird to be doing schema upgrades as a "low priority" task in the background if they block worker | 00:14:36 |
| Dandellion | * seems a little weird to be doing schema upgrades as a "low priority" task in the background if they block workers | 00:14:37 |
| hexa | https://paste.lossy.network/47VNOW2GQYJRORRQOEHVDNMXSE | 00:15:19 |
| hexa | I know what this is 😭 | 00:16:05 |
| hexa | no dependency resolution when you go systemctl restart matrix-synapse matrix-synapse-worker-client1 [...] | 00:17:56 |
| Dandellion | and I assume that's what nixos-rebuild does | 00:18:21 |
| hexa | bingo | 00:18:26 |
| hexa | so we'll likely need a prestart script that waits for matrix-synapse to be ready 🙂 | 00:18:32 |
| Dandellion | I think I actually came to this conclusion a year ago when you mention it | 00:18:47 |
| Dandellion | 😬 | 00:19:05 |
| hexa | yeah, so much knowledge gets lost over time | 00:19:13 |
| f0x | In reply to @hexa:lossy.network
no dependency resolution when you go systemctl restart matrix-synapse matrix-synapse-worker-client1 [...] that's cursed... | 00:35:53 |
