Corrupted session.state file on shutdown

[grelldoc]

Running deluge in a docker container and I've had this issue for ages where when my rpi restarts, deluge can't connect to the port saying that its already taken. The only solution is to stop the container, delete the session.state file and restart the container. In the past, my hack solution has just been to run a script on start-up to delete the session.state file. I recently upgraded the os on my rpi and now my old start up process doesn't work. I could find another boot process to run my old script, but I thought I'd maybe try to actually solve the real problem this time. Any ideas as to why the session.state file seems to prevent a proper restart?

Code: Select all

deluged --version
deluged 2.1.1
libtorrent: 2.0.11.0
Python: 3.12.9
OS: Linux

Log report (ports redacted)

Code: Select all

[custom-init] No custom files found, skipping...

Connection to 127.0.0.1 #### port [tcp/*] succeeded!

07:25:26 [ERROR   ][deluge.core.daemon_entry      :1672] Cannot start deluged, listen port in use.

 Check for other running daemons or services using this port: :####

07:25:29 [ERROR   ][deluge.core.daemon_entry      :1672] Cannot start deluged, listen port in use.

 Check for other running daemons or services using this port: :####

Connection to 127.0.0.1 #### port [tcp/*] succeeded!

[ls.io-init] done.

07:25:33 [ERROR   ][deluge.core.daemon_entry      :1672] Cannot start deluged, listen port in use.
 

[shinger]

Hello grelldoc,

It says the listen port is already in use as you said. Could you give the output of ss -tulpn | column -t. That will show all the ports that your RPI is listening on.

The second thing what you could do, is put a delay in the startup of docker container (lets say 30 seconds after your OS on your RPI has started).

Maybe something else is running in the background, like deluge-web. Make that one start later than deluged (deluge-daemon) and also make it dependable on deluged.

You could also test it by not letting docker to even start and check the output of ss to see if indeed the port is being used and by what applications. Do remember to run it as sudo or root, or else you will not be able to see what application is using what port.