Description
Hi!
Thank you very much for your two very detailed articles and script on how to setup the chroots for PHP. I've been using this in low power ARM devices where I "can't" run docker/lxc/systemd-nspawn due to RAM limitations.
Now, over the years I've noticed a small glitch in the script that I never come around to fix. It appears that whenever I reboot the system php-chroots.target is reached however the subsequent targets aren't usually reached.
After rebooting here is what happened:
root@hostname:~# systemctl status php-chroots.target
● php-chroots.target - Bind all binds for all PHP-FPM chroots
Loaded: loaded (/etc/systemd/system/php-chroots.target; enabled; vendor preset: enabled)
Active: active since Sat 2020-11-07 19:20:14 UTC; 37s ago
root@hostname:~# ./web/php-chroot-bind status
Chroot: /mnt/NVME1/web/test_chroot/chroot
- /usr/share/zoneinfo
- /dev/urandom
- /dev/zero
- /dev/null
- /etc/resolv.conf
- /etc/hosts
- /lib/aarch64-linux-gnu/libnss_dns.so.2
- /usr/share/ca-certificates
- /etc/ssl/certs
Now the test_chroot:
root@hostname:~# systemctl status php-chroot-mnt-NVME1-web-test_chroot-chroot.target
● php-chroot-mnt-NVME1-web-test_chroot-chroot.target - Bind all binds for PHP-FPM chroot /mnt/NVME1/web/test_chroot/chroot
Loaded: loaded (/etc/systemd/system/php-chroot-mnt-NVME1-web-test_chroot-chroot.target; static; vendor preset: enabled)
Active: inactive (dead)
As you can see php-chroots.target is loaded and active, and then php-chroot-mnt-NVME1-web-test_chroot-chroot.target is inactive.
To fix this, I just need to issue:
systemctl start php-chroots.target
And then all chroots get to work just fine. Any idea why this would be happening? I've also noticed that sometimes some of the other chroots start others don't. It seems random.
OS: Debian 10 / Armbian 20.08.17 Buster with Linux 4.4.213-rk3399