DietPi-Software | Lighttpd: fpm socket being created in wrong directory.

[TerryE]

Required Information	Value
DietPi Version	159
SBC Device	RPi 3
Power supply	R-S DIN PSU 5.3V to 5A
SD card used	8Gb Sandisk ultra + 120Gb Kingston UV400 SSD as root partition
Distro	4.9.62-v7+ #2 SMP ... 2017 armv7l GNU/Linux

Additional Information:

• Running Ligthttpd + Mysql + PHP5 webstack
• Can this issue be replicated on a fresh installation of DietPi? Don't know but this is a pretty new install. Doubled checked by removing and reinstalling the webstach using the dietpi-software management tool
• (I am in the process of bringing up HTTPS on Public IP:433 port forwarded to a locked-down home server, and this was a simple check en-route that failed.)

Expected behaviour:

Local connect to http://server/phpinfo.php should bring up standard info page.

Actual behaviour:

It barfs, as does any PHP script, with a bind failure to the php5-fpm.sock

The fpm processes needs write access to this socket, but it is currently created in /run and therefore the interpreter dies. Moving the socked to /var/run/lighttpd/php5-fpm.sock (that is owned by www-data) in /etc/lighttpd/conf-available/15-fastcgi-php.conf and /etc/php5/fpm/pool.d/www.conffixes this.

[Fourdee]

@TerryE

Thanks for the report 👍

Local testing with RPi 3 and our default Stretch image:

• 🈯️ phpinfo.php loads correctly, and, after subsequent reboots.

Permissions seem correctly set during start of services:

• php7.0-fpm.service, runs under the root user by default to start with, allowing permissions to be set.

root@DietPi:~# ls -lha /run/php
total 4.0K
drwxr-xr-x  2 www-data www-data  80 Dec 29 15:32 .
drwxr-xr-x 19 root     root     580 Dec 29 15:32 ..
-rw-r--r--  1 root     root       4 Dec 29 15:32 php7.0-fpm.pid
srw-rw----  1 www-data www-data   0 Dec 29 15:32 php7.0-fpm.sock

@TerryE
Is there anything else installed/configured on the system that we can try to replicate here?

(I am in the process of bringing up HTTPS on Public IP:433)

Was this by editing the lighttpd.conf ? Can we please see the end result?

Notes:

In FHS 3.0, /var/run is replaced by /run; a system should either continue to provide a /var/run directory, or provide a symbolic link from /var/run to /run, for backwards compatibility.

[Fourdee]

@TerryE

I see your running Jessie with php5. I'll re-test under a new system.

[TerryE]

@Fourdee Dan, I started with your standard Raspian bootstrap image linked from your DietPi website download page. The Download->Raspberry Pi image still links to your Jessie image file. I've just had a look at the containing downloads/images folder view and I see that you now have a Stretch Image dated 10^th Dec.

I was trying to use the standard DietPi distro so I used Jessie, even though I'd have preferred to use Stretch and would have done if I had known it was available. Perhaps you could update the download link on the Download page to point to the Stretch image? Thanks.

I am a reasonably experienced admin, so using DietPi isn't a huge saving for me personally, but I work in another community where members are continually fighting setting up SBCs, so something like this is a really boon for them and hence it merits support. I've tried to work with it and feedback issues / solutions / suggestions.

I used to work on the PHP core as a contributor so I know my way around the source. Just on a quick scan, the root php5_fpm process forks its children at sapi/fpm/fpm/fpm_children.c:150-156 and the setuid() call is done in fpm_unix_init_child() after the logfile has been opened, so logfile access should be OK. The Unix socket is created with the correct ownership by lighttpd so this shouldn't be an issues either. So to double check, I did a lot of diagnostics bouncing and the penny eventually dropped. php5_fpm is run as a separate service (basically to facilitate server farm configs), and I'd forgot this, so any changes to the configuration which changes shared resources such as the unix php5-fpm.sock requires the both services to bounced in the correct order. Of course any test which involved bouncing the server reset the services correctly resulting in a few misleading false positives. Sorry guys. I'll close this issue.