Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

php-chroots.target subsequent targets not active #2

Open
TCB13 opened this issue Nov 7, 2020 · 1 comment
Open

php-chroots.target subsequent targets not active #2

TCB13 opened this issue Nov 7, 2020 · 1 comment

Comments

@TCB13
Copy link

TCB13 commented Nov 7, 2020

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

@TCB13 TCB13 changed the title Issue with php Issue with php-chroots.target Nov 7, 2020
@TCB13 TCB13 changed the title Issue with php-chroots.target php-chroots.target subsequent targets not active Nov 7, 2020
@Wa-JHH
Copy link

Wa-JHH commented Dec 21, 2020

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

I have same problem,
my OS: debian 10.7 x86_64
SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux

comment the script line : 82 and 83 using "#"
#Requires=php-chroot-create-mountpoint-file-${eBind}@${eChroot}.service
#Requires=php-chroot-create-mountpoint-dir-${eBind}@${eChroot}.service

It's work fine on my system, reboot will auto re-mount files/dir

Because when using command:
php-chroot-bind bind will auto create empty file and dir.

you can use "sudo journalctl -b -0" check the systemd log, you will found some line like
"Create mountpoint (dir) for xxxxxxxxxx in PHP-FPM Chroot skiped"

the php-chroot-create-mountpoint-file-${eBind}@${eChroot}.service file will check dir/file exits,
if dir/file exits = true , it will skip the mount command. so reboot can't re-mount file / dir.

my english no good, Hope you can understand

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants