Workaround for 20 minute script hang on Truenas installs

[DrPepperG]

I've noticed ever since installing this repo onto my install of Truenas Scale that the container will hang for about 20 minutes after checking for a file that will never be persistently stored meaning it will run each start. Reference is located in issue #270

The code below is referencing a file that will always be non existent on container start so chown will always run, with the overlay driver issue it will cause a 20 minute round of fun.

# create file with contents of here doc, note EOF is NOT quoted to allow us to expand current variable 'install_paths'
# we use escaping to prevent variable expansion for PUID and PGID, as we want these expanded at runtime of init.sh
cat <<EOF > /tmp/permissions_heredoc

# get previous puid/pgid (if first run then will be empty string)
previous_puid=\$(cat "/root/puid" 2>/dev/null || true)
previous_pgid=\$(cat "/root/pgid" 2>/dev/null || true)

# if first run (no puid or pgid files in /tmp) or the PUID or PGID env vars are different
# from the previous run then re-apply chown with current PUID and PGID values.
if [[ ! -f "/root/puid" || ! -f "/root/pgid" || "\${previous_puid}" != "\${PUID}" || "\${previous_pgid}" != "\${PGID}" ]]; then

	# set permissions inside container - Do NOT double quote variable for install_paths otherwise this will wrap space separated paths as a single string
	chown -R "\${PUID}":"\${PGID}" ${install_paths}

fi

# write out current PUID and PGID to files in /root (used to compare on next run)
echo "\${PUID}" > /root/puid
echo "\${PGID}" > /root/pgid

EOF

Workaround

Since we've already ran chown at least once we can reference the pgid and puid in a persistent file. Add two new mounts with the file owner being root, example below.

My user is running as 3002 and group as 3002, both files just contain 3002.

This workaround was tested on two separate installs.

[zacharyfleck]

This helped me! Thank you!!

[binhex]

This is not a viable workaround, if you do this then when a new image is created and you re-create the container to use the new image the chown will not happen (PUID and PGID files already exist) and thus permissions will not be set correctly inside of the container.

[binhex]

will hang for about 20 minutes after checking for a file that will never be persistently stored meaning it will run each start.

This is not true, the files PUID and PGID will be created on first run, subsequent runs will skip the chown as the files exist inside the container, it will only re-apply chown if you change the values of PUID and PGID, or if the container is rebuilt, if you are seeing different results then let me know.

[zacharyfleck]

@binhex with all due respect, reading your code snippet provided by @DrPepperG I think I understand half the confusion.

The files "/root/puid" and "/root/pgid" are checked against the ENVs set, and if they differ, then the CHOWN runs accordingly. It appears to me that the script in question was designed this way.

In testing this method, it does spin up a brand new container quickly and correctly. What I haven't tested yet is pulling an updated version of the image (say when 5.0.2 is released for example) to see the behavior there. If for any reason that breaks, I wonder if we could add some similar logic to the script to determine if the application version has changed to re-run chown if necessary.

Now, I'm currently on mobile so I haven't looked back yet at what the "install_paths" variable contains, but it doesn't make much sense to me as to why that step holds up launching the image. In the other issue you mentioned it must be some kind of driver issue but it still doesn't make sense to me how that causes a slow down. I do think it's worth getting to the bottom of.

[danielloader]

Ah so that explains the slow container launch, was confused until I found this thread - when I ran it on my laptop on a local docker compose installation it started nearly instantly but on my TRUENAS Scale install it's taking 6 mins to start.

As an aside reading about, this worked for me as a custom YAML app:

services:
  qbittorrent-vpn:
    image: binhex/arch-qbittorrentvpn:4.6.7-1-01
    container_name: qbittorrent
    privileged: true
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
    ports:
      - "8118:8118"
      - "6881:6881"
      - "6881:6881/udp"
      - "8080:8080"
    volumes:
      - /lib/modules:/lib/modules
      - /etc/localtime:/etc/localtime:ro
      - /mnt/storage/apps/qbittorrent-vpn:/config
      - /mnt/scratch/downloads/:/mnt/scratch
      - /mnt/storage/media:/mnt/media
    environment:
      - VPN_CLIENT=wireguard
      - ENABLE_PRIVOXY=yes
      - VPN_ENABLED=yes
      - VPN_USER=<example>
      - VPN_PASS=<example>
      - VPN_PROV=pia
      - LAN_NETWORK=10.0.0.0/8
      - STRICT_PORT_FORWARD=yes
      - WEBUI_PORT=8080
      - PUID=1000
      - PGID=1000
      - UMASK=022
    configs:
      - source: puid
        target: /root/puid
      - source: pgid
        target: /root/pgid
configs:
  puid:
    content: |
      1000
  pgid:
    content: |
      1000

Same idea but easier to just inline some content in the compose configs definitions.

Let's see if it holds up with an upgrade later but it's helping for now.