Solved php-fpm_enable in /etc/rc.conf not work

/etc/rc.conf
Code:
php-fpm_enable="YES"

# service php-fpm status
Code:
/etc/rc.conf: php-fpm_enable=YES: not found
php-fpm is stopped

# service php-fpm start
Code:
/etc/rc.conf: php-fpm_enable=YES: not found
Starting php-fpm  done

# service php-fpm status
Code:
/etc/rc.conf: php-fpm_enable=YES: not found
php-fpm (pid 2665) is running...

Test php in web browser, it's ok.
Why php-fpm can't be started automatically when booting?
 
FPM is enabled by default and modules are typically split off into their own ports, in this case databases/php73-pgsql.

after installing the ports lang/php73 databases/php73-pgsql databases/phppgadmin
and configure properly

when using phppgadmin, the web page display:
databases/phppgadmin
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Misc has a deprecated constructor in /usr/local/www/phpPgAdmin/classes/Misc.php on line 8

Fatal error: Uncaught Error: Call to undefined function session_name() in /usr/local/www/phpPgAdmin/libraries/lib.inc.php:55 Stack trace: #0 /usr/local/www/phpPgAdmin/index.php(11): include_once() #1 {main} thrown in /usr/local/www/phpPgAdmin/libraries/lib.inc.php on line 55

What is the problem?
 
Can't do much about the deprecated warning, that's something in the phpPgAdmin code itself. The fatal error is because you're missing www/php73-session.
 
Can't do much about the deprecated warning, that's something in the phpPgAdmin code itself. The fatal error is because you're missing www/php73-session.

already there

# pkg info | grep php73
php73-7.3.0 PHP Scripting Language
php73-pgsql-7.3.0_1 The pgsql shared extension for php
php73-session-7.3.0 The session shared extension for php
phppgadmin-php73-5.6.0 Web Based Postgres Administration

/usr/ports/www/php73-session # ll
total 8
-rw-r--r-- 1 root wheel 215 Oct 8 16:52 Makefile
drwxr-xr-x 4 root wheel 1024 Jan 8 02:13 work/

after reboot, error changes, no fatal error, but phpPgAdmin still unusable, why?
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Misc has a deprecated constructor in /usr/local/www/phpPgAdmin/classes/Misc.php on line 8

Warning: session_name(): Cannot change session name when headers already sent in /usr/local/www/phpPgAdmin/libraries/lib.inc.php on line 55

Warning: session_start(): Cannot start session when headers already sent in /usr/local/www/phpPgAdmin/libraries/lib.inc.php on line 56

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/phpPgAdmin/classes/Misc.php:8) in /usr/local/www/phpPgAdmin/classes/Misc.php on line 526
 
You can probably suppress the deprecated error warnings by changing the error_reporting variable in /usr/local/etc/php.ini. In my php 7.2.10 setup, the php.ini file has these comments in it:
Code:
; error_reporting
;   Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT
I'm using the same settings they suggested for the production value, and I don't see any of those errors. I suspect that the phppgadmin developer(s) are also using the production settings, and therefore might very well be unaware of all these deprecations.

I probably can't help you with these other problems other than to say that I'm using php 7.2.10, postgresql 9.5, and phppgadmin 5.1 together with Apache server 2.4, and everything including phppgadmin seems to be working perfectly as far as I can tell, under both FreeBSD versions 11.2-RELEASE and 12.0-RELEASE. Given the problems you've reported, I probably won't be upgrading php or postgresql anytime soon. Best of luck to you.
 
I'm using the same settings they suggested for the production value, and I don't see any of those errors. I suspect that the phppgadmin developer(s) are also using the production settings, and therefore might very well be unaware of all these deprecations.
solved
# cd /usr/ports/lang/php73/work/stage/usr/local/etc/php.ini-production /usr/local/etc/php/php.ini

summary:
  1. make install from ports is automatic, including a configure dialog, it's nice
  2. confiure should be done manually, 2 cases: (1) edit a configure file in installation place (2) a new configure file needs to be created. The 1st case is ok. For the 2nd case, there is no explicit clue to find out in which place there lack a configure file, is there?
 
after installing the ports lang/php73 databases/php73-pgsql databases/phppgadmin
and configure properly

when using phppgadmin, the web page display:
databases/phppgadmin


What is the problem?

Also trying databases/phppgadmin here and getting the same errors. The last fatal error was solved by enabling the ZTS option in lang/php72 and in www/mod_php72, because www/apache24 was build with multithreading.

Edit: got it working by changing the php.ini from the development version to the production version in /usr/local/etc.
 
It's still a good idea to use the development version of php.ini to debug any php scripts you write before putting them into production. That's the intended purpose of having two versions of php.ini, and if the developers of phppgadmin had been doing that themselves, we probably wouldn't even see those deprecation warnings.

The php install should be putting copies of php.ini-development and php.ini-production in the directory /usr/local/etc/ which makes it easy for us to put our customizations in both files and then copy whichever one we're using over to the working file /usr/local/etc/php.ini. That we we won't get caught with our pants down in future upgrades. When the Zend developers eventually remove those deprecated functions completely, which they're almost certain to do in a future upgrade, those deprecation warnings would then become fatal errors. Deprecating the functions gives us sort of a "grace period" which we can use to upgrade our own scripts in advance of their removal.
 
Notice:, Deprecated: and Warning: in PHP don't stop execution of the script / code you are running. They are simply telling you that the PHP code is either doing something in not the best way or is using an old feature that will soon be removed/changed in a newer version of PHP.

Changing the settings in /usr/local/etc/php.ini are doing precisely nothing to fix the underlying issues in databases/phppgadmin, all you have done is told PHP to not display the warning/notice messages when it runs the code if you use the production.ini file.

"Notice: $variable not defined..." or similar is saying that the PHP code did something to that $variable without first defining it so the result calculated might not have been the desired outcome and that the coder should update the code to explicitly define the variable before using it. This doesn't stop the current code working, it just might not give the expected result.
"Warning: session_start(): Cannot start session..." is saying that the PHP code tried to correctly do something but at the wrong time or in a way that won't actually have any effect, in this case its saying you can't start a session after the headers are sent to the client which is true.
"Deprecated: Methods with the same name..." or similar wording is saying that the way the code is written today works in the current version of PHP but will not work in a future version as the feature used has been marked as deprecated and will be removed or changed in the future version. The coder will need to change how they do this in the future but it will still work ok today.

None of those are fatal issues though and the databases/phppgadmin application will still run.

However these are terminal errors in the code trying to be run and that will always stop the application code running regardless of changing the settings in /usr/local/etc/php.ini.
"Fatal error: Uncaught Error: Call to undefined function session_name()..." or similar is saying that the code tried to do something or use a feature that is not installed/enabled currently, so you will need to correct it before it will even run. In the case above installing the additional packages enabled these features and removed the error.
"Parse error: Unexpected T_STRING at line 20..." or similar is saying that the syntax of the PHP file being run contains errors that need to be fixed. The code won't run until these are fixed
 
solved
# cd /usr/ports/lang/php73/work/stage/usr/local/etc/php.ini-production /usr/local/etc/php/php.ini
You don't need to copy them from the stage source build. The samples are installed as /usr/local/etc/php.ini-development and /usr/local/etc/php.ini-production. Note that you must save the file as /usr/local/etc/php.ini, not /usr/local/etc/php/php.ini. I think, not sure because I use my own copy, the default php.ini that gets installed is a copy of php.ini-production.

You can easily have a look to see what files actually got installed by using pkg info -l php73 for example.
 
You don't need to copy them from the stage source build. The samples are installed as /usr/local/etc/php.ini-development and /usr/local/etc/php.ini-production. Note that you must save the file as /usr/local/etc/php.ini, not /usr/local/etc/php/php.ini. I think, not sure because I use my own copy, the default php.ini that gets installed is a copy of php.ini-production.

You can easily have a look to see what files actually got installed by using pkg info -l php73 for example.

When installed by pkg(), it's true. When ports(), fine /usr/local -n php.ini* finds nothing.
 
A port builds a package and it's this package that eventually gets installed. So in the end everything is a package. Packages don't install things a port doesn't (or vice versa).

This may go a little over your head right now but ports have to adhere to strict rules and tests regarding the files it installs. It's imperative that the package's plist is correct and a port update/patch submission will be denied if it fails to do so.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing.html
 
I too am having difficulties with php-fpm_enable="YES" not running the daemon on startup or manually with onestart. I have tried PHP 7.4, PHP 7.3 and now on PHP 7.2.
 
Then it simply fails for some other reason, usually a configuration error. Without php_fpm_enable it would refuse to even attempt to start.
 
Then it simply fails for some other reason, usually a configuration error. Without php_fpm_enable it would refuse to even attempt to start.
SirDice,

Thanks. I will await to see if anyone has a solution on my thread I posted then. Was prusing for solves.
 
Back
Top