Ok, I understand what you are saying. Your replies where helpful in that I now know what workaround options I have.
I agree this is ultimately a more general rcctl(8) or rc(8) issue. And I don’t have any ideas on how to improve that. But given that a somewhat high level interface such as rcctl(8) exists, I feel editing the low level /etc/rc.conf.local directly is much more fragile. (And I shudder when I hear vi — but let’s not start a discussion/war about editor preferences.) But that all comes down to personal preference I guess. Thanks! Mike > Am 10.07.2023 um 16:31 schrieb Stuart Henderson <s...@spacehopper.org>: > > On 2023/07/10 15:57, Mike Fischer wrote: >>>> (Note: I know this could be further reduced to just one master process for >>>> each version with a chroot(2) and a non-chroot(2) pool defined in the >>>> single php-fpm.conf for each PHP version. But that is irrelevant to the >>>> issue at hand.) >>> >>> Actually I think that is relevant. At least, if you just had one running >>> php-fpm daemon per version, you totally avoid the problem. >> >> That would only solve the chroot/non-chroot problem, not the multiple >> versions of PHP. If you want, then just reduce my issue to one web server >> (either one). Then this is indeed irrelevant as I stated. > > It absolutely does solve the multiple versions of PHP problem, I use it > exactly that way. > >>> With a single daemon per version, remove the extra added phpXX_fpm >>> copies, instead follow the suggestion after "If you need to run multiple >>> versions of PHP on one machine" in php's pkg-readme. >> >> Actually that is effectively what I did. >> Ok to be fair the strict pkg-readme method would store the config file paths >> in /etc/rc.conf.local which means the scripts in /etc/rc.d/ do not need to >> be modified. That does help with the update issue but then I loose my >> settings when I disable and later re-enable the service. So it opens another >> issue. > > Putting the daemon flags in rc.conf.local is the key to it. > > The "lose settings when disabling and re-enabling" is an rcctl > limitation, and affects everything not just php. You can however > add/remove phpXX_fpm from the pkg_scripts line yourself i.e. > not use rcctl(8) for that part.. > > (IIRC the reason for that in the first place is because base daemons > use xxx_flags=NO so there would be no way to "save" the old flags when > disabling them, and generally base+pkg daemons should be treated the > same).. > >>>> 2) Would it make sense to include the more specific pexp in the PHP ports? >>>> (I don’t think doing so would hurt the default use case, but maybe I’m >>>> overlooking something?) >>> >>> This is a bit awkward to do; the rc script would then need to >>> parse the phpXX_fpm_flags variable and figure out what string php-fpm >>> will use when it sets the process name (i.e. look for -y or --fpm-config >>> and parse them the same way that php-fpm itself does). >> >> No not really. Just adding »/etc/php-fpm.conf.*« to the pexp in the default >> rc.d script for the PHP version works for all versions of php-fpm and solves >> the problem. E.g.: >> pexp="php-fpm-8.2: master process .*/etc/php-fpm.conf.*“ > > That breaks my use case (which is also the use case suggested in the > pkg-readme, so others probably use it too): > > $ pgrep -lf php.*process > 65701 php-fpm-8.0: master process (/etc/php-fpm-8.0.conf) > 28288 php-fpm-8.2: master process (/etc/php-fpm.conf) > >>> Though the existing pexp is slightly less flexible, IMHO it's enough for >>> most use cases, and it doesn't really seem worth the extra fragility to >>> do this differently. >> >> Is my suggestion really more fragile? > > Yes, because you need to parse the command-line string from > phpXX_fpm_flags to figure out how the process string will look, > i.e. what config filename is used. > >> Is there any chance the default install would not use /etc/php-fpm.conf as >> the php-fpm config file? > > Yes, if someone sets phpXX_fpm_flags. > >> Ok, I do see that someone strictly using the pkg-readme method would run >> into issues as the matched pattern would not always match the the manually >> configured config file. So I guess I’m left with the strict pkg-readme >> method, /etc/rc.conf.local and the fact that my settings get lost on >> disable. Sigh… >> >> Maybe I need to write scripts to enable the services and automatically >> restore the settings. Something like: >> >> # cat /root/bin/enable_php74_fpm.sh >> #!/bin/sh >> service='php74_fpm' >> /usr/sbin/rcctl enable "$service" && \ >> /usr/sbin/rcctl set "$service" flags '-c /etc/php-7.4.ini -y >> /etc/php-fpm-74.conf' >> # EOF. >> # cat /root/bin/enable_php80_fpm.sh >> #!/bin/sh >> service='php80_fpm' >> /usr/sbin/rcctl enable "$service" && \ >> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.0.ini -y >> /etc/php-fpm-80.conf' >> # EOF. >> # cat /root/bin/enable_php81_fpm.sh >> #!/bin/sh >> service='php81_fpm' >> /usr/sbin/rcctl enable "$service" && \ >> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.1.ini -y >> /etc/php-fpm-81.conf' >> # EOF. >> # cat /root/bin/enable_php82_fpm.sh >> #!/bin/sh >> service='php82_fpm' >> /usr/sbin/rcctl enable "$service" && \ >> /usr/sbin/rcctl set "$service" flags '-c /etc/php-8.2.ini -y >> /etc/php-fpm-82.conf' >> # EOF. >> # > > honestly I would just "vi /etc/rc.conf.local" to disable/enable by > adding or removing from the pkg_scripts line...
