Open Artim96 opened 2 weeks ago
Describe the bug Updated from 2.1.1 to 2.2.2, the admin page opens without issues, but loading any pad results in
2024/08/28 11:19:12 [error] 985096#985096: *14 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: pad.domain.de, request: "GET /socket.io/?EIO=4&transport=websocket HTTP/1.1", upstream: "http://127.0.0.1:9001/socket.io/?EIO=4&transport=websocket", host: "pad.domain.de"
Also, during running bin/run.sh the script claims issues with the
socketTransportProtocols
setting and falling back to defaults. But for all I can tell, it's identical to what's in the settings template:"socketTransportProtocols" : ["websocket", "polling"],
Full log from running the pad from CLI: etherpad_log.txt
To Reproduce Steps to reproduce the behavior:
- Update to v2.2.2
- open any pad
Expected behavior Pad opens
Screenshots If applicable, add screenshots to help explain your problem.
Server (please complete the following information):
- Etherpad version: v2.2.2
- OS: Debian 12.6
- Node.js version (
node --version
): v20.17.0- npm version (
npm --version
): 10.8.2- Is the server free of plugins: yes
Hi the bug with the invalid socketIOTransportProtocols is already fixed. It is not a bug in your configuration. For reproduction I updated my pad server and updated to v2.2.2 . So far it works without a problem: https://pad.samtv.fyi/p/test
Hi the bug with the invalid socketIOTransportProtocols is already fixed. It is not a bug in your configuration. For reproduction I updated my pad server and updated to v2.2.2 . So far it works without a problem: https://pad.samtv.fyi/p/test
Then how come I'm getting that exact issue with v2.2.2? If it keeps appearing it kinda can't be fixed, don't you think?
Hi the bug with the invalid socketIOTransportProtocols is already fixed. It is not a bug in your configuration. For reproduction I updated my pad server and updated to v2.2.2 . So far it works without a problem: https://pad.samtv.fyi/p/test
Then how come I'm getting that exact issue with v2.2.2? If it keeps appearing it kinda can't be fixed, don't you think?
Oh might be a misunderstanding. I fixed the message in the develop branch. I deployed my test Etherpad to demonstrate that it works for me with v2.2 with connecting to pads. Maybe something is wrong on your side? Was there a change to your reverse proxy?
Hi the bug with the invalid socketIOTransportProtocols is already fixed. It is not a bug in your configuration. For reproduction I updated my pad server and updated to v2.2.2 . So far it works without a problem: https://pad.samtv.fyi/p/test
Then how come I'm getting that exact issue with v2.2.2? If it keeps appearing it kinda can't be fixed, don't you think?
Oh might be a misunderstanding. I fixed the message in the develop branch. I deployed my test Etherpad to demonstrate that it works for me with v2.2 with connecting to pads. Maybe something is wrong on your side? Was there a change to your reverse proxy?
nope, nothing. Just the usual path of git pull origin
and git checkout tags/v2.2.2
, followed by bin/run.sh
(obviously all as the etherpad user).
Hi the bug with the invalid socketIOTransportProtocols is already fixed. It is not a bug in your configuration. For reproduction I updated my pad server and updated to v2.2.2 . So far it works without a problem: https://pad.samtv.fyi/p/test
Then how come I'm getting that exact issue with v2.2.2? If it keeps appearing it kinda can't be fixed, don't you think?
Oh might be a misunderstanding. I fixed the message in the develop branch. I deployed my test Etherpad to demonstrate that it works for me with v2.2 with connecting to pads. Maybe something is wrong on your side? Was there a change to your reverse proxy?
nope, nothing. Just the usual path of
git pull origin
andgit checkout tags/v2.2.2
, followed bybin/run.sh
(obviously all as the etherpad user).
Could you give me access to your environment? Would be worthy to check why this happened. Maybe it is an undiscovered bug in Etherpad.
Could you give me access to your environment? Would be worthy to check why this happened. Maybe it is an undiscovered bug in Etherpad.
Sorry, but that's out of the question. There's just way too much other stuff on the same system I can't just have anyone poke through.
Could you give me access to your environment? Would be worthy to check why this happened. Maybe it is an undiscovered bug in Etherpad.
Sorry, but that's out of the question. There's just way too much other stuff on the same system I can't just have anyone poke through.
Maybe try to replicate the issue somehow. I need some sort of reproducible system where I can safely check logs, debug code etc.
Could you give me access to your environment? Would be worthy to check why this happened. Maybe it is an undiscovered bug in Etherpad.
Sorry, but that's out of the question. There's just way too much other stuff on the same system I can't just have anyone poke through.
Maybe try to replicate the issue somehow. I need some sort of reproducible system where I can safely check logs, debug code etc.
Question is how much is needed to reproduce the issue. The actual content of the pads is saved in a mariadb, so if it's a setup issue, theoretically handing you an archive of the installation - with the config file redacted - including everything used to bring it online, should do the trick, doesn't it?
Could you give me access to your environment? Would be worthy to check why this happened. Maybe it is an undiscovered bug in Etherpad.
Sorry, but that's out of the question. There's just way too much other stuff on the same system I can't just have anyone poke through.
Maybe try to replicate the issue somehow. I need some sort of reproducible system where I can safely check logs, debug code etc.
Question is how much is needed to reproduce the issue. The actual content of the pads is saved in a mariadb, so if it's a setup issue, theoretically handing you an archive of the installation - with the config file redacted - including everything used to bring it online, should do the trick, doesn't it?
Yes let's try it that way. The database shouldn't be a problem we have tests for every used database but I'll give it a try :)
I've created an archive, it should have preserved all permissions and ownerships except where I had to edit files. Is there a way to privately message you the link?
I've created an archive, it should have preserved all permissions and ownerships except where I had to edit files. Is there a way to privately message you the link?
Thanks. I'll have a look after work. You can email me the link to samelus1998@outlook.de
I managed to start Etherpad on bare metal with your configuration. I used the following configuration for the database:
# Use root/example as user/password credentials
version: '3.1'
services:
db:
image: mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: EtherpadProto3
# (this is just an example, not intended to be a production configuration)
MYSQL_USER: etherpad_user
MYSQL_DATABASE: etherpad_db
MYSQL_PASSWORD: EtherpadProto3
ports:
- "3306:3306"
I'll continue now with the reverse proxy configuration.
I've created an archive, it should have preserved all permissions and ownerships except where I had to edit files. Is there a way to privately message you the link?
Do you have instructions on how to setup a new Etherpad instance with your nginx configuration? My nginx is crashing:
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2024/09/09 17:58:39 [emerg] 1#1: dlopen() "/etc/nginx/modules/ngx_http_brotli_filter_module.so" failed (/etc/nginx/modules/ngx_http_brotli_filter_module.so: cannot open shared object file: No such file or directory) in /etc/nginx/nginx.conf:6
nginx: [emerg] dlopen() "/etc/nginx/modules/ngx_http_brotli_filter_module.so" failed (/etc/nginx/modules/ngx_http_brotli_filter_module.so: cannot open shared object file: No such file or directory) in /etc/nginx/nginx.conf:6
You are missing the libraries for brotli support. Either comment out the two lines towards the beginning of the nginx conf or follow this guide: https://linuxhint.com/enable-brotli-compression-nginx/
You are missing the libraries for brotli support. Either comment out the two lines towards the beginning of the nginx conf or follow this guide: https://linuxhint.com/enable-brotli-compression-nginx/
Thanks that fixed the issue. I'll continue debugging this.
Describe the bug Updated from 2.1.1 to 2.2.2, the admin page opens without issues, but loading any pad results in
2024/08/28 11:19:12 [error] 985096#985096: *14 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: pad.domain.de, request: "GET /socket.io/?EIO=4&transport=websocket HTTP/1.1", upstream: "http://127.0.0.1:9001/socket.io/?EIO=4&transport=websocket", host: "pad.domain.de"
Also, during running bin/run.sh the script claims issues with the
socketTransportProtocols
setting and falling back to defaults. But for all I can tell, it's identical to what's in the settings template:"socketTransportProtocols" : ["websocket", "polling"],
Full log from running the pad from CLI: etherpad_log.txt
To Reproduce Steps to reproduce the behavior:
Expected behavior Pad opens
Screenshots If applicable, add screenshots to help explain your problem.
Server (please complete the following information):
node --version
): v20.17.0npm --version
): 10.8.2