Bug #55694
closedSystem-status-updates sends emails about same "errors" over and over again
Added by Stefan Neufeind over 10 years ago. Updated over 4 years ago.
0%
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?
Updated by Friesen Kiwi about 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:
So, investigating, what this WARN is about, you go to your Backend, System->Berichte->StatusberichtSystem 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)
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.
- 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
Updated by Tobias Klepp almost 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?
Updated by Mathias Schreiber almost 9 years ago
- Target version deleted (
next-patchlevel)
Updated by Riccardo De Contardi about 5 years ago
- Related to Feature #62420: improved configuration for mail notification added
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.