On 2/17/2022 at 1:52 AM, wgstarks said:

Has anyone tested qbit 4.4.1 with the latest version of Radarr? I know 4.4.0 had some issues. Don't see anything in the release notes about Radarr compatibility fixes.

no idea on that front, but the memory leak persists in 4.4.1, word to the wise, stick on 4.3.9 for the time being:- https://www.reddit.com/r/qBittorrent/comments/suuoi3/does_441_fix_440s_memory_leak_issues/

 

1 hour ago, binhex said:

no idea on that front, but the memory leak persists in 4.4.1, word to the wise, stick on 4.3.9 for the time being:- https://www.reddit.com/r/qBittorrent/comments/suuoi3/does_441_fix_440s_memory_leak_issues/

 

Didn’t know about the memory leak. Maybe I’ll revert back to 4.3.9.

5 hours ago, binhex said:

no idea on that front, but the memory leak persists in 4.4.1, word to the wise, stick on 4.3.9 for the time being:- https://www.reddit.com/r/qBittorrent/comments/suuoi3/does_441_fix_440s_memory_leak_issues/

 

 

According to this Github issue, there isn't a memory leak. Also see the top comment in the Reddit thread you linked to.

 

Edit: After updating to the latest version of this container, it's reporting half the RAM usage it was previously. It's been running a couple of hours and has not increased. 

 

https://github.com/arvidn/libtorrent/issues/6667

 

Libtorrent started using memory mapped file IO which causes more memory to be reported as being used, but the additional "RAM" is actually virtual addresses used to access files more quickly. On Linux this uses mmap which has the effect of treating files like swap space. This makes file access faster because the application can read and write files one byte at a time as if it was RAM. It doesn't use any additional system RAM, but causes the OS to think the application is using RAM at those mapped addresses, even those the addresses are mapped to a file on disk, not an area in RAM. 

 

This can apparently cause some issues on Windows since it handles RAM and swap space differently than Unix type operating systems, but works as intended on Linux/Docker/Mac.

 

 

Edited February 18, 20224 yr by WalkerJ

16 hours ago, xxDeadbolt said:

Nope, I've been on the 4.3.9-2-01 tag since the whole thing with the paths 

 

If you're talking about the category save paths, it looks like that has been fixed. The release notes contains this update, and I just updated to the 4.4.1 version of this container and it's fixed for me.

• WEBUI: WebAPI: fix wrong key used for categories (Chocobo1)

 

This isn't the first time this bug has happened, and each time it was just a display issue. The paths were still saved and used, but when you went back into the edit dialog it was blank.

 

Edited February 18, 20224 yr by WalkerJ

Just installed binhex-qbittorrentvpn on unRAID. I am able to access the GUI via port 8080 when VPN is off. When I enable VPN (NordVPN) I am no longer able to get access via port 8080. Version of unRAID is 6.10 RC2. Privoxy is off. 

 

what logs can I provide?

 
According to this Github issue, there isn't a memory leak. Also see the top comment in the Reddit thread you linked to.
 
Edit: After updating to the latest version of this container, it's reporting half the RAM usage it was previously. It's been running a couple of hours and has not increased. 
 
https://github.com/arvidn/libtorrent/issues/6667
 
Libtorrent started using memory mapped file IO which causes more memory to be reported as being used, but the additional "RAM" is actually virtual addresses used to access files more quickly. On Linux this uses mmap which has the effect of treating files like swap space. This makes file access faster because the application can read and write files one byte at a time as if it was RAM. It doesn't use any additional system RAM, but causes the OS to think the application is using RAM at those mapped addresses, even those the addresses are mapped to a file on disk, not an area in RAM. 
 
This can apparently cause some issues on Windows since it handles RAM and swap space differently than Unix type operating systems, but works as intended on Linux/Docker/Mac.
 
 

I appreciate the detailed explanation of the memory usage increase that is very interesting, I haven't run 4.4.x yet so I haven't seen any memory increase, expected or otherwise, so it's nice to hear it isn't a bug.

Sent from my SM-T970 using Tapatalk

6 minutes ago, mgadbois said:

what logs can I provide?

The supervisord log. Just attach it to your next post. Be sure to redact login credentials.

Logs attached. Server IP is 10.5.254.80/24 and docker network is 172.19.0.14/16

supervisord.log

37 minutes ago, mgadbois said:

Logs attached. Server IP is 10.5.254.80/24 and docker network is 172.19.0.14/16

supervisord.log 6.9 MB · 1 download

Your logs are showing an authorization failure. If you’re sure your using the correct credentials you should probably contact your vpn provider.

would that stop me from getting the the GUI when I am local?

15 minutes ago, mgadbois said:

would that stop me from getting the the GUI when I am local?

Probably. With debug enabled it’s hard to read your logs. They’re very long. I didn’t see your container settings.

I did correct the username and PW and now it works. Apparently spelling counts.   I am now trying to get jackett to run through this container. Is that possible? I added port 9117 (TCP) as a variable in this docker and made the network type for jackett to none. Can I still leave this vpn docker on my docker network or do I need to change it to bridge?

2 hours ago, mgadbois said:

I did correct the username and PW and now it works. Apparently spelling counts.   I am now trying to get jackett to run through this container. Is that possible? I added port 9117 (TCP) as a variable in this docker and made the network type for jackett to none. Can I still leave this vpn docker on my docker network or do I need to change it to bridge?

I don’t use that setup but there is a video to explain it.

https://youtu.be/znSu_FuKFW0

Thanks. I'll take a look.

On 2/18/2022 at 12:43 PM, binhex said:

appreciate the detailed explanation of the memory usage increase that is very interesting, I haven't run 4.4.x yet so I haven't seen any memory increase, expected or otherwise, so it's nice to hear it isn't a bug

I’ve gotten several rounds of notifications of high docker image usage. Usually a warning at 90%, 91%, 92%, and then “Returned to normal”. Every time this has happened I’m always in the middle of something and don’t get a chance to investigate since the entire thing only lasts 4 or 5 minutes. Wondering if this is related to the (non) memory leak though? Just started after updating to 4.4.1.

I am getting this error when trying to start qbitorrentvpn.

[info] VPN is enabled, beginning configuration of VPN

2022-02-20 12:12:28,556 INFO success: shutdown-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-02-20 12:12:28,556 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-02-20 12:12:28,556 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-02-20 12:12:28,558 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2022-02-20 12:12:28,558 DEBG 'start-script' stdout output:
[info] Adding 84.200.69.80 to /etc/resolv.conf

2022-02-20 12:12:28,561 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2022-02-20 12:12:28,564 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2022-02-20 12:12:28,567 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.177 to /etc/resolv.conf

2022-02-20 12:12:28,570 DEBG 'start-script' stdout output:
[info] Adding 84.200.70.40 to /etc/resolv.conf

2022-02-20 12:12:28,572 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2022-02-20 12:12:29,135 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 12 retries left
[info] Retrying in 10 secs...

2022-02-20 12:12:39,667 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 11 retries left
[info] Retrying in 10 secs...

2022-02-20 12:12:50,023 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 10 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:00,439 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 9 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:10,618 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 8 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:20,786 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 7 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:31,302 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 6 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:41,803 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 5 retries left
[info] Retrying in 10 secs...

2022-02-20 12:13:52,212 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 4 retries left
[info] Retrying in 10 secs...

2022-02-20 12:14:02,611 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 3 retries left
[info] Retrying in 10 secs...

2022-02-20 12:14:13,190 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 2 retries left
[info] Retrying in 10 secs...

2022-02-20 12:14:23,584 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
[info] 1 retries left
[info] Retrying in 10 secs...

2022-02-20 12:14:33,585 DEBG 'start-script' stdout output:
[crit] Unable to successfully download PIA json to generate token for wireguard, exiting script...

2022-02-20 12:14:33,586 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 22859662179152 for <Subprocess at 22859662175600 with name start-script in state RUNNING> (stdout)>
2022-02-20 12:14:33,586 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 22859662179008 for <Subprocess at 22859662175600 with name start-script in state RUNNING> (stderr)>
2022-02-20 12:14:33,586 INFO exited: start-script (exit status 1; not expected)
2022-02-20 12:14:33,586 DEBG received SIGCHLD indicating a child quit

 

2 hours ago, wgstarks said:

I’ve gotten several rounds of notifications of high docker image usage. Usually a warning at 90%, 91%, 92%, and then “Returned to normal”. Every time this has happened I’m always in the middle of something and don’t get a chance to investigate since the entire thing only lasts 4 or 5 minutes. Wondering if this is related to the (non) memory leak though? Just started after updating to 4.4.1.

This isn't related to memory usage but the size of your docker image. What's most likely happening is a docker is updating, at which point it expands the size of the docker image, then once completely updated, it clears the unnecessary parts of the image.

 

Can resolve this by increasing the size of the docker image.

1 hour ago, TheOgre said:

This isn't related to memory usage but the size of your docker image. What's most likely happening is a docker is updating, at which point it expands the size of the docker image, then once completely updated, it clears the unnecessary parts of the image.

 

Can resolve this by increasing the size of the docker image.

I’m not so sure. I’ve never seen this sort of behavior and don’t auto-update dockers.

1 minute ago, wgstarks said:

I’m not so sure. I’ve never seen this sort of behavior and don’t auto-update dockers.

The docker image changes only if dockers add or update new images to it, this does not happen during normal operations. A memory leak will only cause RAM to increase, not the docker image.

35 minutes ago, wgstarks said:

I’m not so sure. I’ve never seen this sort of behavior and don’t auto-update dockers.

The symptoms (growing usage of the image and then suddenly it decreases) sounds typical of downloading within the image and when the download is finished it gets moved to the appropriate share.

 

Double check your paths within the app's settings for where incomplete etc goes and make sure it's mapped outside of the container (spelling and capitalization count here)

7 minutes ago, Squid said:

The symptoms (growing usage of the image and then suddenly it decreases) sounds typical of downloading within the image and when the download is finished it gets moved to the appropriate share.

 

Double check your paths within the app's settings for where incomplete etc goes and make sure it's mapped outside of the container (spelling and capitalization count here)

When I first updated to 4.4.1 all my download settings reverted to defaults. I spotted that right off and reset them to the proper paths I think.

@binhex

 

Followed instructions via github on the Further Help link.

 

https://pastebin.com/raw/kR23wYsZ

 

Here is my password/username redacted full supervisord.log.

 

Thank you!

10 hours ago, WenzelComputing said:

@binhex

 

Followed instructions via github on the Further Help link.

 

https://pastebin.com/raw/kR23wYsZ

 

Here is my password/username redacted full supervisord.log.

 

Thank you!

from your log this is the issue:-

[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

running pihole/pfsense/opnsense? if so check you arent blocking that url, thats the most common cause, it is also entirely possible PIA was having a bad day, so just try it again.

7 hours ago, binhex said:

from your log this is the issue:-

[warn] Unable to successfully download PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

running pihole/pfsense/opnsense? if so check you arent blocking that url, thats the most common cause, it is also entirely possible PIA was having a bad day, so just try it again.

 

Running OPnsense - Yes

Whitelisted in Unbound - Yes

Whitelisted in DNS forwarder - Yes

Able to connect to PIA on network using any other computer using PIA app(wireguard as well) - Yes

Working Today? - Nope

How many days has it not worked? - Since I installed OPnsense 😅, 3 days ago...

 

Are there any specific ports that need to be forwarded or anything specfic urls other than the wildcard *.privateinternetaccess.com/* that need to be allowed?

5 minutes ago, WenzelComputing said:

How many days has it not worked? - Since I installed OPnsense 😅, 3 days ago...

crank up the logging and watch for anything that blocks.