| 18 Feb 2022 |
 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 |
|  Chinchilla Wetreat changed their display name from Chuck Winter to Chuck Winter (vi/vim). | 04:12:09 |
| Chinchilla Wetreat 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 |
| hexa | Wondering when exactly systemd handles dependencies, possibly inside targets? | 13:35:05 |
| @andreas.schraegle:helsinki-systems.de | das_j isn't here, he might be able to tell you | 13:37:56 |
| hexa | a quick brainstorming how worker definitions could be looking: https://md.darmstadt.ccc.de/synapse-at-work?both | 22:57:50 |
| hexa | more input welcome | 22:57:56 |
| hexa | * more input very welcome | 22:57:58 |
| f0x | added some more assertions | 23:43:07 |
| f0x | I think it would be great to support both option designs, perhaps make them mutually exclusive though | 23:44:23 |
| f0x | we would also need some way of handling the load balancing considerations when having multiple sync or federationReceiver workers | 23:46:46 |
| f0x | im considering writing some kind of proxy to handle the access token parsing for efficient /sync loadbalancing, because doing that in pure nginx became impossible with the new temporary tokens afaik | 23:52:57 |
| f0x | https://github.com/sandhose/matrix-doc/blob/sandhose/msc/refresh-token/proposals/2918-refreshtokens.md these are entirely opaque whereas the old (long) access tokens actually encoded the MXID | 23:57:27 |
| f0x | so you would need to do an http request or database access to figure out who the token is for | 23:57:41 |
| 19 Feb 2022 |
| hexa | In reply to @f0x:pixie.town
we would also need some way of handling the load balancing considerations when having multiple sync or federationReceiver workers ideally yes, but until that is possible we should resort to simpler measure, like hashing the src address of incoming requests | 01:07:27 |
