-q deliberately makes the scripting engine think that headers have been sent, but it's been that way for so long that I can't say exactly why it does so. I can only assume there is/was a good reason.

Then, there is no way to use a session with a quiet script? thanks.

Well, without knowing what you're doing or why, I would suggest using the regular PHP binary instead of php-cgi.

I'm using the php-cli only because it is the default used by cron jobs and i'm using session on it just because the script uses session to store data for the execution.
If this behavior is intended I can only work around it.
Thanks for the explanation.

a proper software runtime skips session_start() when not running within a webserver environment, these are a few lines of PHP code and be it only to prevent spit session files to disk for no gain

php-cli should be used for cronjobs, yes, but this bug report is about php-cgi. They are not the same.
Either you are using php-cli and this bug is irrelevant, or you are using php-cgi and you should not be.

And you know sessions don't really work from the command line, right? You would have to force a particular session ID, new or existing, for sessions to work across multiple runs.

I was retesting everything, so my server provider uses cgi-fcgi to execute cronjobs, to test this I just echo php_sapi_name() on an empty script executed by cronjob.
I'm only using sessions because the backoffice uses it, i'm only using it as global variables.

if you provider is using cgi-fcgi instead of /usr/bin/php for cronjobs he is a fool becaus ethat breaks the usual way such code looks like

if(PHP_SAPI !== 'cli')
{
 session_start();
}

The /usr/bin/php is the cgi version :

# /usr/bin/php -v
PHP 7.2.8 (cgi-fcgi) (built: Jul 19 2018 09:57:11)

Apparently this is setup like this as deployed by CloudLinux service, should I contact them about this?

In the olden days there was no CLI SAPI.  Instead the CGI
executable could be used, and -q (which is --no-headers) served to
make it more useful for the command line.  For better
compatibility with the CLI SAPI, we might consider to “fix” it[1].
OTOH, perhaps we should rid the -q option of the CGI SAPI
altogether?

Anyhow, the following workaround might be sufficient in this case:

  php -q -d session.use_cookies=0 -d session.cache_limiter="" <file>

[1] <https://github.com/php/php-src/blob/php-7.3.0beta1/sapi/cgi/cgi_main.c#L2420>

Time flies …

It's probably best to leave it as is, and to close this ticket as
not a bug:

> Either you are using php-cli and this bug is irrelevant, or you
> are using php-cgi and you should not be.