-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Home
UPDATE users SET admin = 1 WHERE name = '@foo:bar.com'
Run this sql query on your db:
SELECT * FROM destinations;
Run this sql query on your db:
SELECT DISTINCT split_part(state_key, ':', 2)
FROM current_state_events AS c
INNER JOIN room_memberships AS m USING (room_id, event_id)
WHERE room_id = '!cURbafjkfsMDVwdRDQ:matrix.org' AND membership = 'join';
SELECT NAME from users;
See https://github.com/matrix-org/synapse/blob/master/README.rst#password-reset
Deleting your database is unlikely to make anything better.
It's easy to make the mistake of thinking that you can start again from a clean slate by dropping your database, but things don't work like that in a federated network: lots of other servers have information about your server.
For example: other servers might think that you are in a room, your server will think that you are not, and you'll probably be unable to interact with that room in a sensible way ever again.
In general, there are better solutions to any problem than dropping the database. Come and seek help in https://matrix.to/#/#synapse:matrix.org.
There are two exceptions when it might be sensible to delete your database and start again:
- You have never joined any rooms which are federated with other servers. For instance, a local deployment which the outside world can't talk to.
- You are changing the
server_name
in the homeserver configuration. In effect this makes your server a completely new one from the point of view of the network, so in this case it makes sense to start with a clean database. (In both cases you probably also want to clear out the media_store.)
Using the following curl command:
curl -H 'Authorization: Bearer <access-token>' -X DELETE https://matrix.org/_matrix/client/r0/directory/room/<room-alias>
<access-token> - can be obtained in riot by looking in the riot settings, down the bottom is: Access Token:<click to reveal>
<room-alias> - the room alias, eg. #my_room:matrix.org this possibly needs to be URL encoded also, for example %23my_room%3Amatrix.org
Synapse tags each log line according to the HTTP request it is processing. When it first receives a request, it logs a line containing the words Received request:
. For example:
2019-02-14 22:35:08,022 - synapse.access.http.8008 - 233 - INFO - GET-37 - ::1 - 8008 - Received request: GET /_matrix/client/r0/sync
Once it finishes processing the request, it logs another line with the words Processed request:
. For example:
2019-02-14 22:35:08,196 - synapse.access.http.8008 - 302 - INFO - GET-37 - ::1 - 8008 - {@richvdh:localhost} Processed request: 0.173sec/0.001sec (0.002sec, 0.000sec) (0.027sec/0.026sec/2) 687B 200 "GET /_matrix/client/r0/sync HTTP/1.1" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36" [0 dbevts]"
Here we can see that the request has been tagged with GET-37
. (The tag depends on the method of the HTTP request, so might start with GET-
, PUT-
, POST-
, OPTIONS-
or DELETE-
.) So to find all lines corresponding to this request, we can do:
grep 'GET-37 ' homeserver.log
If you want to paste that output into a github issue, please remember to surround it with triple-backticks (```) to make it legible (see https://help.github.com/en/articles/basic-writing-and-formatting-syntax#quoting-code).
The log format can vary slightly depending on your log configuration, but here is a breakdown of the example above:
-
2019-02-14 22:35:08,196
: date/time when we finished processing the request -
synapse.access.http.8008
: logger name. For 'Received'/'Processed' lines, the logger name issynapse.access.http.
plus the TCP port that the request came in on -
302
: the line number where the request was logged. Useless for 'Received'/'Processed' lines. -
INFO
: the log level. AlwaysINFO
for 'Received'/'Processed' lines. -
GET-37
: the request tag -
::1
: the client IP address -
8008
: the TCP port where the request came in (again) -
{@richvdh:localhost}
: if the request came from an authenticated user or server, their user id or server_name. Processed request:
-
0.173sec/0.001sec
:- time between the request arriving and synapse finishing its processing of it (the "processing time").
- time between synapse finishing its processing of the request and the response being sent to the client: ie, the time taken to stream the response to the client. Note that this may be negative if the client dropped the connection before synapse finished processing the request.
-
(0.002sec, 0.000sec)
: user- and system- cpu time spent processing this request. -
(0.027sec/0.026sec/2)
:- time spent waiting for a connection to the database during this request (the "database scheduling time"). (Note that this may be higher than the request processing time, since synapse may make several database requests in parallel, each of which contributes to this scheduling time.)
- time spent running database transactions, excluding scheduling time (the "database transaction time"). (Again, may be higher than the request processing time).
- the number of database transactions performed.
-
687B
: the length of the response body (687 bytes, in this case). -
200
: the HTTP response code. Followed by an exclamation mark (!
) if the client dropped the connection before we sent the response. -
"GET /_matrix/client/r0/sync HTTP/1.1"
: the http request line, including the path of the requested url. -
"Mozilla/5.0 ..."
: the user-agent of the client. -
[0 dbevts]
: the number of Matrix events which were fetched from the database to fulfil this request.
select room_id, count(*) as num_rows from state_groups_state group by room_id order by num_rows desc limit 10;