LinuxHostingSupport

An email from a cPanel server with the “tailwatchd failed” warning message indicates that either the cpanel service is offline/down OR the cpanel service was restarted. The complete message looks like the following:

tailwatchd failed @ Tue Jan 1 00:00:00 2010. A restart was attempted automagically
Service Check Method: [check command] tailwatchd is not running

There isn’t anything to worry, however, you can check the tailwatchd logs for the failure reasons:

# tail -f /usr/local/cpanel/logs/tailwatchd_log

To check the status of the ‘tailwatchd’ service and it’s output, execute

# /usr/local/cpanel/libexec/tailwatchd --status
Driver (Active: 1) Cpanel::TailWatch::ChkServd
tailwatchd is enabled
Running, PID 24463
Driver (Active: 1) Cpanel::TailWatch::cPBandwd
Driver (Active: 1) Cpanel::TailWatch::Antirelayd
Driver (Active: 1) Cpanel::TailWatch::Eximstats

Restart the ‘cpanel’ service once, just to make sure it’s online

# service cpanel restart

and if you still continue to receive the ‘tailwatchd failed’ emails, update “cPanel” on the server

# /scripts/upcp --force

On a Suhosin enabled server, the values of suhosin parameters for example “suhosin.post.max_vars” are updated in the PHP configuration file i.e. php.ini. By default, non of the parameter is listed in the php.ini file and you have to mention the parameter and it’s new value manually.

In order to increase the value of suhosin.post.max_vars from 2000 to 3000, locate the server side php.ini file

# php -i | grep php.ini

and define the parameter and the new value at the end of the file as shown below

[suhosin]
suhosin.post.max_vars = 3000

The values of other parameters can be updated in the same way, one per line. Save the file and restart the Web server.

# service httpd restart

To verify the new value, you can either execute the command

# php -i | grep suhosin.post.max_vars

OR create a phpinfo.php file and browse it.

http://yourserverip/phpinfo.php

The error message “php: symbol lookup error: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/suhosin.so: undefined symbol: zend_atol” occurs when an application is not compatible with Suhosin.

The error message also appears when an old application/software is upgraded to it’s latest version. It may not cause issues with all the applications but definitely does affect some of them.

The only work around is to enable suhosin.simulation for the account (domain) instead of disabling Suhosin server wide. The suhosin.simulation if turned ON, will log the violations as usual but nothing will be blocked or removed from the request.

You can perform this task in one of the either ways:

1) Enable suhosin.simulation in a .htaccess file of the domain (non-suphp enabled server)

php_flag suhosin.simulation On

OR

2) Create a php.ini file under the account (domain) and turn ON the simulation

suhosin.simulation = On

There is no need to restart any service in any of the above case.

The error message “unpacking of archive failed on file /usr/bin/xxxx: cpio: open Failed” indicates that the system failed to install the rpm since it cannot unpack the package under the /usr/bin directory.

For example, you may see the error message as stated below while installing a ‘nano’ package using yum

Error unpacking rpm package nano-1.x.x.i386
error: unpacking of archive failed on file /usr/bin/nano;4c70f874: cpio: open Failed:

This indicates that the file /usr/bin/nano cannot be created under the /usr/bin directory which mostly happens if an attribute is set on the directory.

Use ‘lsattr’ command to check the attributes set on the directory:

root@server [~]# lsattr /usr | grep bin

If the output is something like the following, it states that the immutable bit (lowercase ‘i’) is set to the “/usr/bin” directory thus denying to write under that directory.

----i-----I-- /usr/bin

Use ‘chattr’ command to remove the attributes from the directory:

root@server [~]# chattr -i /usr/bin

Once done, you can successfully install the rpm.