37

I recently compiled a PHP 5.2.9 binary, and I tried to execute some PHP scripts with it. I can execute some scripts without problems, but one of them halts its execution midway, exiting with no errors or warnings. The returned status code of the process is 255.

I've read in the manual that such status is 'reserved'. The question is: for what?

I believe it's got something to do with missing dependencies in the PHP executable, but I can't be sure.

Anyone knows what does an exit code of 255 mean?

P.S. There are no errors in the PHP scripts, they run OK on other machines.

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
Silvio Donnini
  • 497
  • 1
  • 6
  • 9

6 Answers6

38

255 is an error, I could reproduce that same exit code by having a fatal error.

This means that somehow your error reporting is hidden, there are some possible causes for this:

  • error_reporting is not defined and php reports no error at all
  • An @ (error suppression operator) hides the output of the error
  • STDERR is redirected somewhere else (php -f somefile.php 2>/dev/null, remove the redirection)
  • This could still be an internal error due to missing dependencies and that a fatal error has the same exit code as a program crash.
hakre
  • 156
  • 1
  • 13
Weboide
  • 3,275
  • 1
  • 23
  • 32
  • 1
    In some rare cases on Windows this is related to a broken `php.ini` file (i.e the file has broken chars inside). Took me 2 hours to figure this out. Tip: If your script (i.e. `composer.phar`) works with `php -n composer.phar`, then your `php.ini` file is probably broken. – tftd Apr 20 '15 at 19:17
12

It could also mean that /etc/php5/cli/php.ini (on Debian/Ubuntu) or /etc/php.ini (on RHEL/CentOS/etc.) has display_errors = Off which means that any errors or warnings from command-line scripts will go nowhere, unless log_errors = On (see also the error_log setting).

Try running your scripts with a wrapper script that uses php -d display_errors=on ...

Alastair Irvine
  • 1,172
  • 10
  • 22
  • 4
    I just want to say thanks for the `-d display_errors=on` tip—I was trying to debug a custom script for someone's PHP app that tries to handle all the exception logging on its own, but often eats exceptions. Using that flag I can get the exception to print to the CLI! – geerlingguy Oct 14 '17 at 06:41
  • In my case, this showed me that the php script exceeded it's maximum execution time. Thanks for the great tip! – Hannah Vernon Sep 25 '18 at 15:56
1

It could also mean that

  • /etc/php5/cli/php.ini (on Debian/Ubuntu)

  • /etc/php.ini (on RHEL/CentOS/etc.)

has set

display_errors = Off

which means that any errors or warnings from command-line scripts will go nowhere, unless 

log_errors = On

See also the error_log setting.

Try running your scripts with a wrapper

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
Alauddin
  • 11
  • 1
1

In my case that was xDebug death because of low xdebug.max_nesting_level value.

zored
  • 121
  • 1
0

Locate what php.ini your php-cli used. 

brain@cordova:~% php -i | grep "php.ini"

8:Configuration File (php.ini) Path => /etc/php/7.3/cli
9:Loaded Configuration File => /etc/php/7.3/cli/php.ini

Make sure display_errors parameters is active.

brain@cordova:~% php -i | grep "error"

106:display_errors => On => On
114:error_log => /tmp/php_errors.log => /tmp/php_errors.log
116:error_reporting => 22527 => 22527
134:log_errors => On => On

Make sure display_errors and log_errors are ON.

Define the error_log location to logging errors into file.

Error messages should shown now.

Brain90
  • 111
  • 1
  • 6
0

This might be caused by PHP suppressed error messages (the line starts with @). I found the line by 

grep -r "@" src/

and then commented out the @. After this I got the actual error and was able to fix it easily. I also noticed afterwards that PHPStorm had found out the same error already, but I hadn't fixed/noticed it.

Antti Hätinen
  • 1