Project

General

Profile

Actions

Bug #28694

closed

PHP Warning: session_start()

Added by Henrik Ziegenhain over 12 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-08-03
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.2
Tags:
Complexity:
medium
Is Regression:
Sprint Focus:

Description

Since the Update to v4.5.4 I get the following errors in the BE-Log:

Core: Error handler (BE): PHP Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cache limiter - headers already sent in /typo3src/typo3_src-4.5.4/t3lib/class.t3lib_userauth.php line 256
Core: Error handler (BE): PHP Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent in /typo3src/typo3_src-4.5.4/t3lib/class.t3lib_userauth.php line 256

I could not find out why these errors are comming, but they only exists in installations where the Scheduler is used and started by a cronjob. The Cronjobs are running every 30 minutes, so these messages are flooting the system log every 30mins.


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #28948: Session is always startedClosed2011-08-12

Actions
Related to TYPO3 Core - Bug #24456: Information disclosure during backend loginClosed2011-01-03

Actions
Related to TYPO3 Core - Bug #29274: Regression on session handling for security fixClosedHelmut Hummel2011-08-26

Actions
Actions #1

Updated by Thorsten Kahler over 12 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Henrik Ziegenhain
  • Priority changed from Must have to Should have
  • Complexity set to easy

First step: disable PHP warnings on production sites ;-)

Could you provide the calling line from your cron file? In CLI mode no headers are sent [1] so I guess you're invoking the scheduler in another way.

[1] PHP CLI mode

Actions #2

Updated by Henrik Ziegenhain over 12 years ago

Hi Thorsten,

yes. You are right. We should disable the PHP warnings, but TYPO3 gets it before a user can see it :)

We use a managed server, the provider told us to invoke the scheduler this way:
Create a new bash-file which invokes the scheduler and start this file via the cronjob

The bash-file holds these two lines:

#!/bin/bash
env -i /usr/local/bin/php5 -f /path/to/site/typo3/cli_dispatch.phpsh scheduler
Actions #3

Updated by Thorsten Kahler over 12 years ago

Looks like it uses CLI, but to be sure could you please execute env -i /usr/local/bin/php5 -v on your server and post the result here?

Actions #4

Updated by Henrik Ziegenhain over 12 years ago

(07:36:17) [~] env -i /usr/local/bin/php5 -v
PHP 5.2.13 (cgi) (built: Jan  7 2011 15:20:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
    with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies
Actions #5

Updated by Thorsten Kahler over 12 years ago

Henrik Ziegenhain wrote:

[...]

PHP 5.2.13 (cgi) (built: Jan 7 2011 15:20:07)
[...]

So you're executing the CLI script using a CGI binary.

CGI is aimed to be used from a web server and TYPO3 acts like being run in a web server context.

You should ask your provider for a CLI PHP binary!

Actions #6

Updated by Henrik Ziegenhain over 12 years ago

I think this could be closed.
The "bug" seems to be caused by a wrong configured system.

Thorsten Kahler wrote:

First step: disable PHP warnings on production sites ;-)

btw: whats the preferred way to disable PHP warnings? Via php.ini (display_errors = off) or via the TYPO3 Install Toll (increase [SYS][systemLogLevel] to 3 or higher)

Thanks for your support!

Actions #7

Updated by Oliver Hader over 12 years ago

  • Target version changed from 4.5.5 to 4.5.6
Actions #8

Updated by Thorsten Kahler over 12 years ago

  • Status changed from Needs Feedback to Accepted
  • Assignee deleted (Henrik Ziegenhain)
  • Complexity changed from easy to medium

After reading #28948 and experiencing this on an own server running CLI binary I can acknowledge this issue.

It seems to be caused by 281713c3.

Actions #9

Updated by Helmut Hummel over 12 years ago

  • Status changed from Accepted to Needs Feedback

Can you check if the fix in #29274 resolves your problem?

Actions #10

Updated by Chris topher over 12 years ago

  • Target version changed from 4.5.6 to 4.5.8
Actions #11

Updated by Ernesto Baschny about 12 years ago

  • Target version changed from 4.5.8 to 4.5.12
Actions #12

Updated by Alexander Opitz almost 11 years ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (4.5.12)

No feedback for over 90 days.

Actions

Also available in: Atom PDF