lvestats-server: class sqlite3.OperationalError: no such table: history

Sometimes on a Cloudlinux server, you may receive following error in /var/log/messages

lvestats-server: <class 'sqlite3.OperationalError'>: no such table: history

The error is due to inconsistent lvestats database missing some fields and it can be recreated by

# /etc/init.d/lvestats stop

# mv /var/lve/lveinfo.db /var/lve/lveinfo.db_bad

# /etc/init.d/lvestats start

How to check installed perl modules on a server

To check the installed perl modules on a cpanel server, you can use the command provided below.

[email protected] [~]# instmodsh
Available commands are:
   l            - List all installed modules
   m <module>   - Select a module
   q            - Quit the program
cmd? l
Installed modules are:
   CPAN
   Compress::Raw::Bzip2
   Compress::Raw::Zlib
   Crypt::PasswdMD5
   DBI
   Digest::SHA1
   Encode::Locale
   Expect
   ExtUtils::MakeMaker
   File::Listing
   Filesys::Df
   GnuPG
   HTTP::Cookies
   HTTP::Daemon
   HTTP::Date
   HTTP::Message
   HTTP::Negotiate
   IO::Compress
   IO::HTML
   IO::Tty
   LWP
   LWP::MediaTypes
   Module::Build
   Module::Metadata
   Net::HTTP
   Perl
   Perl::OSType
   Regexp::Assemble
   Test::Deep
   Test::NoWarnings
   Test::Tester
   URI
   WWW::RobotRules
   local::lib
   version
cmd?

SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid root

Sometimes, you may encounter with a website showing 500 internal server error and in apache error logs, it shows the following error message.

SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid root?

Premature end of script headers: index.php

This error is because of the suphp binary which is missing its sticky/suid permissions. It can be fixed by executing the following command.

# chmod +s /opt/suphp/sbin/suphp

Once permissions are corrected, check the website, it should be working fine now.

No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_nginx.cgi) with exit signal: 2

While accessing Nginx Admin in WHM, you may receive the following error;

No response from subprocess (/usr/local/cpanel/whostmgr/docroot/cgi/addon_nginx.cgi) with exit signal: 2

To resolve the issue, you need to install the following perl module;

[email protected] [~]# /scripts/perlinstaller Task::Cpanel::Core

Once installation is completed, refresh the page, it should be working fine without any error.

How to set limit to remove the Frozen emails automatically?

To set auto-delete for the frozen emails, you need to edit the exim configuration file on your server.

# vi /etc/exim.conf

timeout_frozen_after = 5d ( 5 Days )

# /etc/init.d/exim restart

That’s it!

suPHP must be enabled to install Owncloud

While installing Owncloud through softaculous, you may get the following error.

suPHP must be enabled to install Owncloud

This is because of the suphp configuration in softaculous admin panel.

To resolve the issue, login to the WHM >> Plugins >> softaculous – Instant Installs >> Settings >> Under General Settings Change the values;

CHMOD Files to 644
CHMOD Directories to 755
CHMOD Config files to 644

save the changes and try to install the script. It should be installed without any error.

Softaculous_suphp

Web server software (WebServerX) is not supported, sorry.

After installing moodle by using Fantastico or softaculous, its showing the following error.

Web server software (WebServerX) is not supported, sorry.

This is because the mod_security installed on the server and it can be resolved by editing the mod_security configuration file.

# vi /usr/local/apache/conf/modsec2.conf

search for

SecServerSignature "WebServerX"

and comment it, save the file and restart the apache service.

Moodle should be working fine now.

domain.com exceeded the max records and failures per > hour (5/5 (%)) allowed. Message discarded.

In cPanel 11.32, a new feature is added to limit the ability of exploited or hacked sites to send out spam emails. A few customers who send out mass mailings have been triggering this feature, due to the number of bad/undeliverable email addresses on their lists.

Due to this feature you may get the following bounce back.

“Domain has exceeded the max defers and failures per hour (5/5 (26%)) allowed. Message discarded.”

cPanel will regularly monitor the emails sent through all email accounts on your domain, and if, over the past hour, more than 25% of the attempted deliveries have failed, outbound email will temporarily be limited.

To solve the issue,remove following file.

/var/cpanel/email_send_limits/max_deferfail_domain.com

and restart the exim service or you may need to disable the option “Ratelimit incoming connections with only failed recipients” in tweak Settings in WHM. If you still have an issue with this, in Tweak settings, change the value for “Maximum percentage of failed or deferred messages a domain may send per hour”. The option is used for the maximum percentage of a domain’s outgoing mail that can consist of failed or deferred messages. Once the domain exceeds this percentage, it is temporarily blocked from sending mail.

If you’re not sure exactly what is causing this, you can probably figure it out by using the Email Trace icon in your hosting control panel. When you click the Email Trace icon, you’ll see a field where you can enter a recipient’s email address and then click a “Run Report” button to get information about email sent to that recipient. If you enter nothing for the recipient email address, you’ll get back data for all email traffic, and as you look through it you should see groups of bounced messages which can help you determine what sender caused the problem, and why.

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

After upgrading Magento to Magento 1.6.0.0, you may get the following message on Front-end AND Back-end:

Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

In the release notes there’s a reference to this issue:

“If you see the Service Temporarily Unavailable page after refreshing the frontend, open the Magento installation directory on the server and remove the maintenance.flag file. Then go to Magento var directory and remove the cache directory”.

[email protected] [/home/xxxxxxx/public_html]# mv maintenance.flag maintenance.flag.bk

Or

[email protected] [/home/xxxxxxx/public_html]# rm -rf maintenance.flag

[email protected] [/home/xxxxxxx/public_html]# cd var/cache

[email protected] [/home/xxxxxxx/public_html/var/cache]# ll

total 72

drwxrwxrwx 12 xxxxxxx xxxxxxx 4096 Aug 7 20:55 ./

drwxr-xr-x 10 xxxxxxx xxxxxxx 4096 Aug 7 20:30 ../

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–0/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–4/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–6/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–8/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–a/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–b/

drwxrwxrwx 2 xxxxxxx xxxxxxx 20480 Aug 7 20:55 mage–c/

drwxrwxrwx 2 xxxxxxx xxxxxxx 12288 Aug 7 20:55 mage–d/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–e/

drwxrwxrwx 2 xxxxxxx xxxxxxx 4096 Aug 7 20:55 mage–f/

[email protected] [/home/xxxxxxx/public_html/var/cache]#rm -rf mage*

Now, refresh the page and check the website. It should be working fine now.

SoftException in Application.cpp:422: Mismatch between target UID (99) and UID (502) of file

Sometimes on a suphp enabled server, you may get internal server error for a website and in error log it shows the folowing error;

Premature end of script headers: index.php

SoftException in Application.cpp:422: Mismatch between target UID (99) and UID (502) of file “/home/xxxxxxxx/public_html/index.php

To resolve the issue, check the ownweship and permissions of the files and folders. On a SuPHP enabled server, the file permissions should be 644 whereas the folders should have 755 and the ownership sould be cpaneluser:cpaneluser

If you still have an issue after correcting the permissions and ownership, check the httpd.conf and check the user set for the domain name. If its set to nobody, change it to cpaneluser.

You are done!