[BUG] Thread Deadlock/Unreleased Connections

[DerMuffin]

Hey there!

just test the server installation. Installation worked great but when i try to connect via IP-Adress, this is the only thing i see

Any Idea?

[thearyadev]

Hello.

Could you stop the container, then re-run it with docker run -p 50947:50947 msrf_06b The only change is -d flag is removed so the logs can be displayed in your terminal.

Try to load the page then copy the output and send it here.

There is a few things that could cause this, like problems with the database. Is this a fresh installation or has this problem started after some use of MSRF?

Thanks.

[DerMuffin]

root@Server:/home/user# docker run -p 50947:50947 msrf_06b

[INFO][][<>][Line 24] Loaded ./configuration.yaml into config object

[INFO][][<>][Line 26] Connection to database was successful. /root/.cache/pypoetry/virtualenvs/msrf-dev-k0wZ3IgI-py3.10/lib/python3.10/site-packages/tzlocal/unix.py:177: UserWarning: Can not find any timezone configuration, defaulting to UTC.

warnings.warn("Can not find any timezone configuration, defaulting to UTC.")

[INFO][][][Line 108] Eligible account was not found.

[INFO][][][Line 108] Eligible account was not found.

[INFO][][][Line 108] Eligible account was not found.

Run on a fresh install Ubuntu Server. I install like its in your readme. Never worked for me

Thanks!

[thearyadev]

Thanks.

It seems the server setup for docker needs some work. I'm working on this now.

[DerMuffin]

Great! As soon the new release get publish, i give you a feedback

[DerMuffin]

Hey! I test the new version on a fresh install Ubuntu Server. The error remains the same.

I install everything with sudo. Is this maybe a problem?

[thearyadev]

Hmm ok. I’m not entirely sure what the problem is. I’m gonna work on a test container which just runs Flet, the server-generated UI Framework.

Initially i was thinking that the problem may have been an error in MSRF which caused the server to become unresponsive to the web interface, but i’m not so sure about that now, since i’m unable to replicate that.

In the coming days ill be working on:

1. Test GUI app to diagnose potential problems with Flet
2. linux executable so it can be run without Docker to test functionally (docker vs host operating system)

Thanks again for the feedback and helping me work on this. I will let you know when those two are ready, should be soon 😄

[DerMuffin]

Maybe you can share your Test machine? Specs and OS. Maybe its only related to my machine. Its a VM.

Thanks again!

[quadbyte]

Any progress on this? thanks

[thearyadev]

I know what the problem is, but i don’t have a solution for it.

Basically the app uses web sockets to communicate with the server. If the websocket’s dont respond, then you get that loading screen attempting to re-connect (waiting for a websocket response)

So why are web socket connections not going through? Well, it could be a network firewall rule on the linux server, or it could be some external network configuration like Nginx Proxy Manager, which requires websockets be explicitly enabled.

currently the app still runs just the GUI is inaccessible over the network.

@DerMuffin mentioned their setup is running on a VM, which depending on the OS may have various firewall rules, so it is hard to pin point a problem on this one.

I don’t know all that much about linux network configuration to give feedback on finding out what the issue is, i know that there should be a way to check if some connections are allowed or not.

My recommendation is to test on a different OS/Platform using the docker instructions and see if it works.

[quadbyte]

Can report 0.8b is working fine on Debian11, thank you!
Do we still need to change the "mode" to "SERVER" in configuration.yaml ?

[quadbyte]

talked to soon, it crashes after half an hour with errors : WARNING:urllib3.connectionpool:Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f01d56fb490>: Failed to establish a new connection: [Errno 111] Connection refused')': /session/afa4a4d975f2a049958ff1a926563595

[thearyadev]

could you share the logs approaching the crash? remember to remove any login info from the logs before sending it here.

I think the crash may be an unrelated bug. (i think) the error is from Selenium losing connection with the chromedriver.

[quadbyte]

Here you go : msrf_crash_log.txt

I restarted the container after the crash and it went smoothly on the 3 other accounts. Will report back wheter it crashes again or not in the next few days.

[thearyadev]

Ok so i think Chromedriver just crashed. ill look into why specifically it is crashing,

the crash occurs after attempting to load the dashboard data, which is the data on rewards.bing.com.

2023-06-02T11:09:58.051626683Z [INFO][<account3@xxxx.com>][<load_dashboard_data>][Line 21] loading 
2023-06-02T11:09:58.051682175Z dashboard data

It runs some javascript on the browser to get the dashboard data object from the js runtime.

return util.DashboardData(**browser.execute_script("return dashboard"))

some error in browser.execute_script's communication with the chromedriver likely caused it. Some additional testing will be required on this. I develop in a windows environment with a chrome/chromedriver that is like 5 months old now, whereas the docker installation always pulls the latest available chromium-chromedriver for each build.

Thank you for sharing the logs. I know that must have taken a bit to do haha.

todo:

• store errors on the host file system
• store logs on the host file system
• investigate script exec

[quadbyte]

got a pretty similar crash on the same account today. attached log for reference.

only difference I see is : WARNING:urllib3.connectionpool:Connection pool is full, discarding connection: localhost. Connection pool size: 1

that was not there yesterday. thanks for your hard work!

msrf_log2.txt

[thearyadev]

thanks.

i think i’ve made some progress in addressing it, but i will need to do some testing before i can confirm.

Thanks again for the logs, they have been super helpful.