I think that php-fpm initscript should include ensure for fpm - unix sockets path. It could be something like that below: start_pre() { checkpath --directory --owner "${FPM_USER}":"${FPM_GROUP}" "${FPM_SOCKETS_DIR}" } Variables must be defined in /etc/conf.d/php-fpm Now there is a problem after reboot - fpm doesn't start because of lacking socket directory Reproducible: Always Steps to Reproduce: 1.Configure fpm, add to autostart - rc-update add php-fpm 2. Reboot system Actual Results: On next start initscript will fail (lack of /var/run/php5-fpm directory) Expected Results: It should work after reboot
I do not plan on making any such feature at the moment. Have you tried going upstream with this?
Why uptream? In my view it's related to Gentoo baselayout and initscripts which clean run directories on shutdown. I see similar fnuctionality in many Gentoo initscripts (e.g. mysql, mongodb, postgresql) so that's why I proposed such a solution. Now if I try to run php-fpm with Gentoo's default configuration (sockets in /var/run/php5-fpm) I'll get error on startup - in general initscript doesn't work. If it's only a matter of contribution and preparing such a patch to ebuild I'm ready to do it :)
That directory is specific to our init script.. it's not easy to find the documentation, but the way that OpenRC suggests to do this is by calling `checkpath` before we attempt to use the path. The docs are hidden in `man openrc-run`. The annoying part would be having to add those variables and a conf file. Since we currently have that directory root:root, I think PHP probably drops permissions after creating the socket. If we're lucky and that's the case, we won't need to mess with the variables at all. The ${FPM_SOCKETS_DIR} is hard-coded, so that's not a problem =)
(In reply to Michael Orlitzky from comment #3) > > The annoying part would be having to add those variables and a conf file. > Since we currently have that directory root:root, I think PHP probably drops > permissions after creating the socket. If we're lucky and that's the case, > we won't need to mess with the variables at all. > > The ${FPM_SOCKETS_DIR} is hard-coded, so that's not a problem =) Oops, I jumped the gun. I was thinking of the PID directory being hard-coded and root:root. We may not be able to fix this in the init script after all. The settings for the user, group, and socket are all found in php-fpm.conf which is PHP's file, not ours. By default, it listens on a TCP socket and runs as nobody/nobody. That will work fine right after you install it. The problem is only if you change the socket to a unix socket (in php-fpm.conf) and point it to somewhere that doesn't exist, right? In that case, we have no way to get the value of the "listen" variable out of php-fpm.conf, so we have no way to create it beforehand. If we went the conf.d file route, we would be forced to override the user's php-fpm.conf for the user, group, and "listen" variables which I think would be pretty annoying and raise complaints. So I really don't see a way to fix it in the init script. Sorry, but I'm changing my opinion to "don't point the socket at a directory that doesn't exist." *If* it was going to get auto-created, php-fpm would have to do it, since only it knows where you've configured the socket to go.
One more thing (sorry for the spam). I just tried the conf.d override -- I figured maybe we could do nothing if the variables FPM_USER, FPM_GROUP, etc. were unset. Then I could comment them by default. That wouldn't be so annoying. The bigger problem is that, to set the socket path, we need to override the "listen" variable on the command-line. So that third variable needs to be something like FPM_LISTEN. But then, things get hairy: the "listen" variable takes four different forms: * ip.add.re.ss:port * [ip:6:addr:ess]:port * port * /path/to/unix/socket So now we have to parse that thing to find out if it's a path.. ugh. I guess we could check to see if the first character is a slash?
Haha, 'twas all in vain. It turns out that the only settings you can override on the command-line are php.ini settings, NOT php-fpm.conf settings. So even after I create a conf.d file with FPM_USER, FPM_GROUP, and FPM_LISTEN, there's no way to pass them to the daemon! You could try sending this upstream, since it does make sense to stick the socket in a temporary location like /run or /var/run. I see a lot of similar complaints on e.g. stackoverflow. The only other option I see is to put the socket in a permanent location that you can create once with the correct permissions. Or the ugly way: editing your init script. I tried. We could also revisit this if they give us the ability to override php-fpm.conf settings on the command-line.
