| 17 Feb 2022 |
 f0x | I was also wondering if there's a nice way to expose default blocks of routes, so you don't have to configure them all yourself | 21:05:38 |
| f0x | but just include workers.routes.client or whatever | 21:05:51 |
 Dandellion | In reply to @hexa:lossy.network
Dandellion, Sumner Evans TIL: https://gist.github.com/artizirk/e1793e28da16a48b41672d126b44e7a6 An opinionated module can use nginx maps like this | 21:06:31 |
| Dandellion | I think the plan would generally be to just do matrix.workers.federation_reciever = 2 and such to have the module system enumerate ports and generate nginx routes and whatever else is needed | 21:07:47 |
| f0x | that would be really nice yeah | 21:08:51 |
 hexa | Or a list of ports to bind to | 21:10:13 |
| hexa | workers and secret handling are the next big steps in this module | 21:15:48 |
| hexa | I imagine the map mostly as a concatStringsSep with rules being optional in relation to the worker count for the relevant path | 21:17:28 |
| hexa | haven't checked whether our nginx module supports maps natively | 21:17:44 |
| Dandellion | it does not | 21:17:52 |
| Dandellion | after you posted it I simply added it to my services.nginx.commonHttpConfig | 21:18:32 |
| hexa | and using such a map allows it to be maintainable for us | 21:18:34 |
| hexa | since we can just c/p the patterns from the documentation | 21:18:48 |
| hexa | and for ajs124 we enable pcre jit by default | 21:28:20 |
| hexa | 2022-02-17 23:43:34,351 - root - 349 - WARNING - main - ***** STARTING SERVER *****
2022-02-17 23:43:34,352 - root - 350 - WARNING - main - Server /nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/bin/synapse_worker version 1.52.0
2022-02-17 23:43:34,352 - root - 351 - INFO - main - Server hostname: lossy.network
2022-02-17 23:43:34,352 - root - 352 - INFO - main - Instance name: client1
2022-02-17 23:43:34,352 - synapse.server - 313 - INFO - main - Setting up.
2022-02-17 23:43:34,377 - synapse.storage.databases - 65 - INFO - main - [database config 'master']: Checking database server
2022-02-17 23:43:34,380 - synapse.storage.databases - 68 - INFO - main - [database config 'master']: Preparing for databases ['main', 'state']
2022-02-17 23:43:34,381 - synapse.storage.prepare_database - 116 - INFO - main - ['main', 'state']: Checking existing schema version
2022-02-17 23:43:34,385 - synapse.storage.prepare_database - 120 - INFO - main - ['main', 'state']: Existing schema is 67 (+0 deltas)
2022-02-17 23:43:34,385 - synapse.app._base - 194 - ERROR - main - Exception during startup
Traceback (most recent call last):
File "/nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/lib/python3.9/site-packages/synapse/app/generic_worker.py", line 491, in start
hs.setup()
File "/nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/lib/python3.9/site-packages/synapse/server.py", line 315, in setup
self.datastores = Databases(self.DATASTORE_CLASS, self)
File "/nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/lib/python3.9/site-packages/synapse/storage/databases/__init__.py", line 73, in __init__
prepare_database(
File "/nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/lib/python3.9/site-packages/synapse/storage/prepare_database.py", line 137, in prepare_database
_upgrade_existing_database(
File "/nix/store/rp1cyyj9sbwq8xf41d334wxhlh5i2rvl-matrix-synapse-1.52.0/lib/python3.9/site-packages/synapse/storage/prepare_database.py", line 360, in _upgrade_existing_database
raise UpgradeDatabaseException(
synapse.storage.prepare_database.UpgradeDatabaseException: Expected database schema version 68 but got 67: run the main synapse process to upgrade the database schema before starting worker processes.
**********************************************************************************
Error during initialisation:
Expected database schema version 68 but got 67: run the main synapse process to upgrade the database schema before starting worker processes.
| 23:43:53 |
| 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 |
