CHOWN command incredibly slow

[robotarmy]

My ubuntu host hangs on this 2 year old line for quite a while.

I don't know why correct 'chown' encoded into the docker image?

docker-bookstack/root/etc/cont-init.d/50-config

Line 84 in d5d65fd

chown -R abc:abc \

---

Expected Behavior

Expected that my server would start within a minute or so

Current Behavior

Can hang for as long as 5-10 minutes on my slow slice.

Steps to Reproduce

using standard docker-compose

Environment

**OS: Ubuntu 18.x
CPU architecture: x86_64/arm32/arm64
How docker service was installed:

Command used to create docker container (run/create/compose/screenshot)

docker-compose -f docker-compose-book.yml up -d

Docker logs

... docker exec bookstack ps ax
271 root 0:00 bash /var/run/s6/etc/cont-init.d/50-config
308 root 0:03 chown -R abc:abc /config /var/www/
324 root 0:00 ps ax

[robotarmy]

I'm working around this atm by killing the chmod

hack# docker exec -it bookstack_insecure ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   30 root      0:00 foreground  if   /etc/s6/init/init-stage2-redirfd   foregr
   31 root      0:00 s6-supervise s6-fdholderd
   42 root      0:00 if  /etc/s6/init/init-stage2-redirfd  foreground   if    i
   43 root      0:00 foreground  if   if    s6-echo    -n    --    [s6-init] ma
   49 root      0:00 if  if  -t   s6-test   -d   /var/run/s6/etc/cont-init.d
  213 root      0:00 if  pipeline   s6-ls   -0   --   /var/run/s6/etc/cont-init
  216 root      0:00 forstdin -o 0 -0 -- i importas -u i i if  s6-echo  --  [co
  217 root      0:00 [s6-ls]
  218 root      0:00 [s6-sort]
  269 root      0:00 foreground  /var/run/s6/etc/cont-init.d/50-config  importa
  271 root      0:00 bash /var/run/s6/etc/cont-init.d/50-config
  308 root      0:00 chown -R abc:abc /config /var/www/
  309 root      0:00 ps ax
failed to resize tty, using default size
                                        #                                                                   hack# docker exec -it bookstack_insecure kill 308
failed to resize tty, using default size
                                        #                                                                   hack# docker exec -it bookstack_insecure ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   31 root      0:00 s6-supervise s6-fdholderd
  347 root      0:00 s6-supervise memcached
  348 root      0:00 s6-supervise php-fpm
  349 root      0:00 s6-supervise cron
  350 root      0:00 s6-supervise nginx
  352 root      0:00 nginx: master process /usr/sbin/nginx -c /config/nginx/ngi
  353 root      0:00 {php-fpm7} php-fpm: master process (/etc/php7/php-fpm.conf
  355 abc       0:00 memcached -u abc
  356 root      0:00 /usr/sbin/crond -f -S -l 5 -c /etc/crontabs
  384 abc       0:00 nginx: worker process
  385 abc       0:00 nginx: worker process
  386 abc       0:00 nginx: worker process
  387 abc       0:00 nginx: worker process
  388 abc       0:00 {php-fpm7} php-fpm: pool www
  389 abc       0:00 {php-fpm7} php-fpm: pool www
  390 root      0:00 ps ax
failed to resize tty, using default size
                                        #58 

[robotarmy]

Looking at the files - they are all readable exec as root:root - which should work just fine since world readable + exec on dirs

-rw-rw-r--  1 root root     251 May 12 21:34 phpcs.xml
-rw-rw-r--  1 abc  users   2451 May 12 21:34 phpunit.xml
drwxrwxr-x  1 abc  users   4096 May 22 02:10 public
-rw-rw-r--  1 abc  users  13430 May 12 21:34 readme.md
drwxrwxr-x  7 root root    4096 May 12 21:34 resources
drwxrwxr-x  1 abc  users   4096 May 12 21:34 routes
-rw-rw-r--  1 abc  users    567 May 12 21:34 server.php
drwxrwxr-x  1 abc  users   4096 May 12 21:34 storage
drwxrwxr-x 10 root root    4096 May 12 21:34 tests
drwxrwxr-x  1 abc  users   4096 May 12 21:34 themes
drwxr-xr-x  1 root root    4096 May 18 19:09 vendor
-rw-rw-r--  1 root root       8 May 12 21:34 version
-rw-rw-r--  1 root root    1365 May 12 21:34 webpack.config.js
failed to resize tty, using default size
                                        #                                                                   hack# docker exec -it bookstack_insecure ls -al /var/www/html

[aptalca]

It's an old overlayfs/docker bug that affects some small hardware/kernel combos

[robotarmy]

@aptalca thx for the info.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cdrfun]

Just got the same issue while updating from v0.30.2-ls107 to v0.30.3-ls108. I'm running Ubuntu LTS 20.04 on a Hyper-V which doesn't seem such an uncommon config to me. System was stuck for 5 minutes

[j0nnymoe]

@cdrfun it's a known issue with docker/overlayfs

[cdrfun]

Yeah, I've read this. Could someone provide the upstream issue? I think this could perhaps explain why this happened when I updated from v0.30.2-ls107 to v0.30.3-ls108 without updating the kernel nor the system in between. @aptalca stated that this bug affects some small hardware/kernel combos. Without updating any of those I'm still puzzled, why this happens now.

Big thanks for all your work btw., I really love to use linuxserver.io containers.

[aptalca]

docker/for-linux#388

[j0nnymoe]

@aptalca to the rescue - I went hunting for the link but didn't manage to find it.

[Kidswiss]

Also suffering from this.

Couln't it be mitigated by chowning /var/www during the docker build? Or is there a reason for the chown during startup?

[cdrfun]

Also suffering from this.

Couln't it be mitigated by chowning /var/www during the docker build? Or is there a reason for the chown during startup?

Another possible mitigation is mentioned in the upstream issue: docker/for-linux#388 (comment)

[Roxedus]

Both these methods don't work with the PGID PUID variables, as they vary between setups

[Kidswiss]

@Roxedus good point... Oh well I have to live with it until the upstream bug is fixed then.

[thespad]

#102 should help but it's not a fix.

[homerr]

Given we have a confirmed bug upstream of this and #102 in place to try and mitigate this, I'm going to close this off as we can't really do much more for now.