| 17 Jan 2020 |
 TravisR | it shouldn't default to DEBUG ever, but it should default to INFO | 20:04:42 |
 grin | In reply to @travis:t2l.io
it shouldn't default to DEBUG ever, but it should default to INFO Yes, but right now DEBUG is called "INFO" in Synapse-universe. ☹︎ | 20:08:25 |
| grin | I have 4 days of logs, totalling about 4 GB. Compressed, mostly. | 20:08:47 |
| TravisR | not at all, far from it. If you turn on DEBUG you'll see about 10x the logging. | 20:09:05 |
| grin | At INFO level. Not DEBUG. | 20:09:07 |
| grin | We call that TRACE in wonderland here around. | 20:09:26 |
 richvdh | Look. I don't agree that synapse logs too much. What I have a problem with is that it nobody has come up with a solution to this other than effectively turning off the logging, and the people that think that is a good idea aren't the people that are on the firing line for supporting the application | 20:09:39 |
| richvdh | Sorry, I *do* agree that | 20:09:57 |
| richvdh | Also, I am in a bad mood and should step away. | 20:11:26 |
| grin | richvdh: I think we all see your point. Our point is, that a general distro shall ship programs with non-debug logging, or phrasing it diffrently to log very limited amount of information, which is not for error inspection ("debugging") but to follow normal everyday life of the server. If the admin needs error diagnosis s/he shall be able to set DEBUG level. This is the approach on distro level. | 20:11:56 |
| grin | I absolutely support that the admin could set debug level as easy and fast as possible. | 20:12:19 |
| grin | Maybe even being asked at install time, if we want to be extremely nice to the hardworking NV people. | 20:12:48 |
| grin | And why wouldn't we? | 20:12:59 |
| grin | It's just not expected that a default install fills up the disk without specific request to do so. | 20:13:30 |
| grin | Most of the servers log the way (by default) that it is absolutely useless for debugging: if there's a problem you have to raise the loglevel. I'd mention CUPS here since it happens periodically here. | 20:14:28 |
| grin | (I mean on my server.) | 20:14:57 |
| grin | An as I've mentioned in the wee hours in the morning if we set sane, size based rotation then the logs will not cove more than a few seconds of the error state of the server. | 20:16:11 |
| grin | Been there, done that. | 20:16:25 |
| 18 Jan 2020 |
|  joseichiban joined the room. | 14:13:52 |
 andrewsh | richvdh:
2020-01-18 12:10:59,460 - synapse.federation.transport.server - 154 - INFO - PUT-13865- Request from archlinux.org
2020-01-18 12:10:59,467 - synapse.federation.transport.server - 389 - INFO - PUT-13865- Received txn 1578775294954 from archlinux.org. (PDUs: 0, EDUs: 1)
2020-01-18 12:10:59,485 - synapse.access.https.8448 - 302 - INFO - PUT-13865- 2a01:4f8:c2c:a43e::1 - 8448 - {archlinux.org} Processed request: 0.028sec/0.001sec
(0.006sec, 0.003sec) (0.003sec/0.014sec/3) 12B 200 "PUT /_matrix/federation/v1/send/1578775294954 HTTP/1.1" "Synapse/1.8.0" [0 dbevts]
I believe just one of the two would be enough, wouldn’t it?
| 14:34:38 |
| andrewsh | 2020-01-18 12:10:59,706 - synapse.storage.TIME - 347 - INFO - - Total database time: 0.202% {set_received_txn_response(1): 0.086%, _prune_old_user_ips(2): 0.059
%, get_received_txn_response(1): 0.027%}
2020-01-18 12:11:04,036 - synapse.metrics - 462 - INFO - - Collecting gc 1
I would switch off both
| 14:35:14 |
| andrewsh | 2020-01-18 13:06:46,004 - synapse.http.federation.well_known_resolver - 234 - INFO - PUT-14110- Fetching https://matrix.org/.well-known/matrix/server
2020-01-18 13:06:46,219 - synapse.http.federation.well_known_resolver - 185 - INFO - PUT-14110- Error parsing well-known for b'matrix.org': Non-200 response 404
2020-01-18 13:06:46,249 - synapse.http.federation.matrix_federation_agent - 242 - INFO - PUT-14110- Connecting to matrix-federation.matrix.org.cdn.cloudflare.ne
t:8443
ditto
| 14:37:32 |
| andrewsh | how about raising the level for synapse.federation.transport.server, synapse.storage.TIME and synapse.http.federation.well_known_resolver to WARN? | 14:39:14 |
| andrewsh | also synapse.metrics | 14:39:36 |
| andrewsh | maybe synapse.util.retryutils?
2020-01-17 15:07:11,464 - synapse.util.retryutils - 218 - INFO - federation_transaction_transmission_loop-3974- Connection to thomasroos.nl was unsuccessful (<c
lass 'synapse.api.errors.RequestSendFailed'>(Failed to send request: ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.)); b
ackoff now 123114643
2020-01-17 15:07:11,467 - synapse.federation.sender.per_destination_queue - 319 - WARNING - federation_transaction_transmission_loop-3974- TX [thomasroos.nl] Fa
iled to send transaction: Failed to send request: ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
| 14:41:31 |
|  wire joined the room. | 16:52:37 |
|  @fraengii:fratrix.de joined the room. | 16:53:28 |
| @fraengii:fratrix.de left the room. | 16:54:55 |
|  helix joined the room. | 17:05:08 |
|  st.haydn joined the room. | 17:06:34 |
