linuxserver / docker-bookstack

A Docker container for the BookStack documentation wiki
GNU General Public License v3.0
797 stars 109 forks source link

CHOWN command incredibly slow #60

Closed robotarmy closed 3 years ago

robotarmy commented 4 years ago

linuxserver.io

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?

https://github.com/linuxserver/docker-bookstack/blob/d5d65fdaad38273bee41dbd492222f89c1a20a10/root/etc/cont-init.d/50-config#L84


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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

robotarmy commented 4 years ago

@aptalca thx for the info.

github-actions[bot] commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

cdrfun commented 4 years ago

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 commented 4 years ago

https://github.com/docker/for-linux/issues/388

j0nnymoe commented 4 years ago

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

Kidswiss commented 3 years ago

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 commented 3 years ago

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: https://github.com/docker/for-linux/issues/388#issuecomment-555037130

Roxedus commented 3 years ago

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

Kidswiss commented 3 years ago

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

thespad commented 3 years ago

https://github.com/linuxserver/docker-bookstack/pull/102 should help but it's not a fix.

homerr commented 3 years ago

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.