See: http://drupal.org/node/800064

A vinked on syslog resulted in a webhoster suspending an account. Maybe I read a warning in the past somewhere, maybe not. I just vinked it on and didn´t see a warning. So I think it´s reasonable that there should be a severe warning, a check if its a webhosting account and a php rule that needs to be disabled first manually, before this internal module can be vinked on.

Something like that?

P.S.: as soon as there is a php-patch, I like to implement it, as I´m freightened that my webhoster will cancel my account if this error is made ever again (by human error, or due to a drupal error).

Comments

ClearXS’s picture

Clarifying & taking over the most important text from the mentioned link:

The problem here is that the Drupal install has had the syslog module enabled. This module is not acceptable in a shared hosting environment, it is logging to a system log file on the server where you as an end user would not have any access to see the data being logged after the fact, and as side effects you are causing other users to be spammed with the trivial issues that it logs, while cluttering the server's system log with data that has no rightful place to be there.
As stated, there should be no benefit to you as a customer to direct your Drupal install to log it's errors to the system log since only our admins have access to read that file. I had taken the liberty of disabling the module via the MySQL database, but it seems that the module was re-enabled within 24 hours. Given that the module could not reliably be disabled, we were forced to disable the account to stop the undesirable behavior that it was causing.
I have once again disabled the module via the Database, if you were not responsible for reactivating the module after it's initial deactivation, you will need to take steps to make certain that the module is not re-enabled at any future time. I would recommend removing it all together as it has no suitable place in a shared hosting environment.
Once you have decided on a course of action to ensure that the Drupal syslog module does not continue to be an issue, please let us know and we will be happy to reactivate your account.

I think it should never be possible on a shared hosting account to vink this module on:

Core - optional
Activado Throttle Nombre Version Descripción
Syslog 6.16 Logs and records system events to syslog.

It even lacks a warning here, but even with a warning it should be blocked by a php patch, that needs to be deleted first to get this option working. And/or a check if its a shared webhost account ..?

Think its a major issue; I might loose my account if this ever happens again. Even if I dont vink it on (maybe i should stop using this module vinking page to be sure?!), it theoretically can be vinked on by other modules or another drupal error.

Hosters remarks:

I would recommend removing it all together as it has no suitable place in a shared hosting environment.

=> so please someone can give me where the php code is that I can delete; I don´t want to wait for a new release that maybe never is going to contain such a patch (the next problem then is that on a core update, these changes will disappear and the problem is back again)

ClearXS’s picture

I have had my second time my Bluehost account was "suspended" due to Drupal database errors. Drupal works so pretty well, that I now have to look for another hoster or VPS, as any moment all my other NON-DRUPAL websites also can be taken down on the slightest future error. Yes; they count till three and don't care that much why you are causing a mess on their server; only the result counts...

I dont have the confirmation that this time also the syslog core option was involved (as I double check it now on every change).

BUT HOW DO I DELETE THAT VERY BAD PART OF CORE?

=> OK you stupid! It happened to be very simple; its just a module in core, similar to the modules in sites/all/modules. Just remove it or rename it with a dot "." in front => the option to tick syslog on, disappears...

lyricnz’s picture

Status: Active » Closed (won't fix)

Submitter has noted workaround (deleting from his installation). Drupal cannot be expected to make decisions about what is/isn't suitable for a particular hosting environment - that is what site administrators are for. :)