| 17 Feb 2022 |
 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 |
| f0x | oh could be an interesting workaround, ExecStartPost= restart the workers again | 00:37:59 |
| f0x | or use that to start the workers in the first place, maybe | 00:38:18 |
| hexa | my worst idea for this is to use dbus-monitor 😛 | 00:42:23 |
| hexa | # systemctl show -p SubState --value matrix-synapse
start-pre
| 00:55:27 |
| hexa | # systemctl is-active matrix-synapse
activating
| 00:55:54 |
| hexa |
is-active PATTERN…
Check whether any of the specified units are active (i.e. running). Returns an exit code 0 if at least one is active, or non-zero otherwise. Unless --quiet is specified, this will also print the current unit state to standard output
| 00:56:50 |
|  Chuck Winter changed their display name from Chuck Winter to Chuck Winter (vi/vim). | 04:12:09 |
| Chuck Winter changed their display name from Chuck Winter (vi/vim) to Chuck Winter. | 04:20:38 |
|  Milan changed their display name from Milan (they/them) 🏳️⚧️ to Milan. | 10:34:42 |
|  FantasyCookie17 🏳️🌈🏳️⚧️ changed their profile picture. | 12:50:12 |
 @andreas.schraegle:helsinki-systems.de | In reply to @hexa:lossy.network
no dependency resolution when you go systemctl restart matrix-synapse matrix-synapse-worker-client1 [...] you can tell switch-to-configuration to stop and start instead of restart, that might work. | 13:30:55 |
| hexa | I think I have more confidence in a loop with in-active in prestart | 13:34:06 |
