Closed robotarmy closed 3 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
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
It's an old overlayfs/docker bug that affects some small hardware/kernel combos
@aptalca thx for the info.
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.
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
@cdrfun it's a known issue with docker/overlayfs
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 to the rescue - I went hunting for the link but didn't manage to find it.
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?
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
Both these methods don't work with the PGID PUID variables, as they vary between setups
@Roxedus good point... Oh well I have to live with it until the upstream bug is fixed then.
https://github.com/linuxserver/docker-bookstack/pull/102 should help but it's not a fix.
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.
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