Project

General

Profile

Actions

Bug #55694

closed

System-status-updates sends emails about same "errors" over and over again

Added by Stefan Neufeind almost 11 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-02-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.1
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

At least that's what I read from the description of the problem the extension
http://typo3.org/extensions/repository/view/no_opcode_cache_check
tries to solve. Especially for a missing opcache (which is no error, only a recommendation) those things seem to get emailed over and over again?


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #55392: Missing opcode cache throws warning (instead of notice) and triggers mailClosed2014-01-28

Actions
Related to TYPO3 Core - Feature #62420: improved configuration for mail notificationClosed2014-10-23

Actions
Actions #1

Updated by Friesen Kiwi over 10 years ago

  • Target version set to next-patchlevel

The following bug report applies to 6.2.3 and also some earlier versions:

The original reported trigger for getting E-Mails over and over should be resolved by now via #55392.
But E-mails are still sent over and over.
Steps to reproduce:
1. Set up a clean TYPO3 6.2 in a shared hosting environment (e.g. Mittwald)
2. Configure the Scheduler with a Task "Aktualisierung des Systemstatus (reports)", e.g. once a day (86400 Seconds) and to your E-Mail-Address
3. Configure a system cron job, e.g. via the (Mittwald Kundencenter, need to use a .sh-Script) to execute typo3/typo3/cli_dispatch.phpsh scheduler

Expected result:
You get an E-Mail, when extraordinary events happen which influence your system status/health, e.g. server settings changed, insecure extensions found etc.

Actual result:
You get an E-Mail once a day with the following content:

System Status Notification for site: [sitename]
One or more problems were detected with your TYPO3 installation. Please check the status report for more information.

Site: [sitename]

Issues:
[WARN] System environment check - 1 Test(s)

So, investigating, what this WARN is about, you go to your Backend, System->Berichte->Statusbericht
The only items NOT green (which would be the expected appeareance when everything is OK) are:
  • TYPO3 6.2.3 (white, I'd expect this to be green, as long as the running version is still supported with security bugfixes and at the latest bugfix version, e.g.
currently 6.2.3, 6.1.9, 6.0.14, 4.7.19, 4.5.34 [source: https://typo3.org/download/ or https://typo3.org/typo3-cms/roadmap/])
  • XCLASS benutzt Ihr System registriert XCLASSes: TYPO3\CMS\Backend\View\BackendLayoutView registriert eine XCLASS von FluidTYPO3\Fluidpages\Override\Backend\View

\BackendLayoutView and TYPO3\CMS\Backend\View\PageLayoutView registriert eine XCLASS von FluidTYPO3\Fluidpages\Override\Backend\View\PageLayoutView (white, actually I'm

not sure what to make of this item...)
  • Systemumgebungsüberprüfung 6 Test(s) (blue, information)
  • Systemumgebungsüberprüfung 2 Test(s)(white, note)

In my opinion, apart from the mentioned version check, which would be a nice new feature, the rest of the reports are fine and could stay like this. But they mustn't

trigger an e-mail beeing sent! E-Mails should only be sent, if an item's state is yellow (warning) or red (error).

Investigating further by checking the Install Tool (System environment):
There are several green items, but 6 blue informations and 2 white notes:

blue informations:
Suhosin not loaded
If enabling suhosin, suhosin.request.max_vars should be set to at least 400:
suhosin.request.max_vars=400

Suhosin not loaded
If enabling suhosin, suhosin.post.max_vars should be set to at least 400:
suhosin.post.max_vars=400

Suhosin not loaded
If enabling suhosin, suhosin.get.max_value_length should be set to at least 2000:
suhosin.get.max_value_length=2000

Suhosin not loaded
If enabling suhosin, a useful setting is:
suhosin.executor.include.whitelist=phar vfs

Suhosin not loaded
If enabling suhosin, a useful setting is:
suhosin.executor.include.whitelist=phar vfs

Empty systemLocale setting
$GLOBALS[TYPO3_CONF_VARS][SYS][systemLocale] is not set. This is fine as long as no UTF-8 file system is used.

white note:

PHP suhosin extension not loaded
suhosin is an extension to harden the PHP environment. In general, it is good to have it from a security point of view. While TYPO3 CMS works fine with suhosin, it has

some requirements different from the default settings to be set if enabled.

No PHP opcode cache loaded
PHP opcode caches hold a compiled version of executed PHP scripts in memory and do not require to recompile a script each time it is accessed. This can be a massive

performance improvement and can reduce the load on a server in general. A parse time reduction by factor three for fully cached pages can be achieved easily if using an

opcode cache.
For more information take a look in our wiki http://wiki.typo3.org/Opcode_Cache.

My understanding (also coming from the phrase "If enabling suhosin") is, that the first 5 items should not be reported, because suhosin is not enabled.

The sixth can be dispelled by setting
[SYS][UTF8filesystem] = 1
and
[SYS][systemLocale] = de_DE.utf8.
(http://forum.typo3.org/index.php/t/203671/)

Sooo ... to wrap everything up (tl;dr):
- A fresh install on a usual shared webspace should produce an "All Green" dashboard and no problem report mail by the scheduler
- Problem report mails should only be sent for yellow (warning) or red (error) items, not for blue (information) or white (notes)
- The information in the problem report mail should mirror what can be seen in the backend (in the above scenario, it shows WARN although there is none)
- The version should be checked for support and actuality
- The suhosin informations should only be displayed if suhosin is loaded
- It might be nice to provide more information in the problem report mail (e.g. which tests exactly fail)
- It might be nice to have a way to acknowledge items in case you can't do anything about them, so you won't get them mailed over and over and they appear as "green"

What do you think? :-)

Cheers,
Friesenkiwi

Actions #2

Updated by Tobias Klepp about 10 years ago

I really like this idea! I can't use the System Status Notification email, because I always get an email with

[ERR] System environment check - 2 Test(s)

But everythink is fine. It's only a grey info, that

- PHP open_basedir is set
- PHP suhosin extension not loaded

Is there a way to configure the System Status Notification emails?

Actions #3

Updated by Mathias Schreiber about 9 years ago

  • Target version deleted (next-patchlevel)
Actions #4

Updated by Riccardo De Contardi over 5 years ago

  • Related to Feature #62420: improved configuration for mail notification added
Actions #5

Updated by Susanne Moog over 4 years ago

  • Status changed from New to Closed

This has been adjusted in recent versions, currently - if you set the checkbox in the scheduler task to only get notifications for warnings and errors - you only get a mail once a message is severe enough.

I also tested that it works for the mentioned "open_basedir" - if I choose to get all status reports, that results in:

[NOTE] System environment check                 - 1 Test(s)
### PHP open_basedir is set: -2

If I only selected warnings and errors, I don't get an email.

If there are other settings you think are mistakenly classified as warnings, please comment. Until then I'm going to close this.

Actions

Also available in: Atom PDF