Strict Standards: date() [function.date] Error

admin    Linux, Troubleshooting     apache, compile, configuration, date, error, fix, Linux, nagios, nagvis, ntpd, php, php.ini, red hat, rhel, sles, source, standards, strict, suse, time zone, timezone, utc, warning

I was installing NagVis when I came across this weird message:

Strict Standards: date() [function.date]: It is not safe to rely on the system’s timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘UTC’ for ‘GMT/0.0/no DST’ instead in /usr/local/nagios/nagvis/nagvis/includes/classes/objects/NagVisStatefulObject.php on line 360

It clearly says that I should check the timezone, which I did. But there’s nothing wrong with time or date. ntpd is running and it set the correct timezone so what could be wrong?

If you are reading this then probably you are seeing this error too. To fix this, open your php.ini using your favourite text editor (like vi) and add this line:

date.timezone=UTC

Take note that depending on how you installed php, it could be in /etc/php.ini (RedHat) or /etc/php5/apache2/php.ini (SLES) or if compiled, /usr/local/php5/php.ini.

You need to restart Apache for changes to take effect.

Sudo error: Sorry, you must have a tty to run sudo

Rai    Linux     configuration, error, fix, Linux, permission, rsync, sudo, troubleshoot, tty, user, visudo

From time to time, we perform remote actions on the servers that we manage, including, but not limited to, automated file transfers. For this, rsync is used to simplify the operation and until recently, I encountered this weird error:

sudo: sorry, you must have a tty to run sudo

But where on this bloody earth did that error came from? All was going well until a new server was added to the pool of money-making machines and powerful enough to throw me off guard. This can’t be happening! I own these machines, I built them from scratch and configured them exactly the way I built the other servers! I could not be any wrong-er, the server must be leading an uprising against me!

Okay, that was an exaggeration (or paranoia). But it is true that the server has the same configuration as the rest. Except for one little line of default configuration:

Defaults requiretty

Comment out this line in visudo (must be root to edit) and everything should checkout.

How to Fix PECL PHP Error: /bin/sh: bad interpreter: Permission denied

Rai    Linux     bash, denied, error, fix, how, interpreter, Linux, pear, pecl, permission, php, red hat, server, xdebug

I recently tried installing xdebug on a RHEL 4 machine, and somehow, the server decided that it should refuse having xdebug installed. As if running a heavy Java app is not enough, I decided to add more processes for the server to run. And it looks like the server has got me:

[root@server src]# pecl install xdebug
downloading xdebug-2.0.5.tgz ...
Starting to download xdebug-2.0.5.tgz (287,621 bytes)
.............done: 287,621 bytes
12 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
/usr/local/bin/phpize: /tmp/pear/temp/xdebug/build/shtool: /bin/sh: bad interpreter: Permission denied

So, like I always do, I tackle the problem with my handy tool: Google. I found out that this error occurs when /tmp is mounted as read-only (ro). You can check this by looking at the /etc/fstab file and check the /tmp partition.

Okay, now I know what the problem is. How do I get over this?

Lazy that I am, I moved the /tmp/pear directory, and create a symlink to the root directory.

[root@server src]# mv /tmp/pear /tmp/pear-ori
[root@server src]# mkdir /root
[root@server src]# ln -s /tmp/pear /root/tmp/pear

Now that the directory from where the PECL scripts are running is in /root, the installation should go smoothly.

Another way to go around this is to remount the /tmp:

[root@server src]# mount -oremount,exec /tmp

I have not tried the above command because I thought that creating symlink is a safer approach rather than messing with the mounts.

If there are other ways to fix this, let me know using the comment box below.

Fix Fatal error: Allowed memory size of 8388608 bytes exhausted

Rai    Linux     allowed memory, code, error, exhausted, fatal, installing, Linux, memory, pear, pecl, php, size, xdebug

I was installing xdebug a few days back to one of the production servers when I encountered this beautiful error message:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 143 bytes) in /usr/share/pear/PEAR/PackageFile/v2/Validator.php on line 1608 Allowed memory size of 8388608 bytes exhausted (tried to allocate 64 bytes)

So my instinct tells me to look inside the php.ini file and find for this line:

memory_limit = 12M

The server’s php.ini file is already set to 256M so I should go look for something else. Luckily, I found this tip from www.agileapproach.com.

Open the file /usr/share/pear/pearcmd.php and add this right after the < ?php line:

@ini_set('memory_limit', '16M');

That should fix the “Fatal error: Allowed memory size” error. I can now resume installing xdebug without any errors.

The reason why editing the php.ini will not fix the issue is because PECL/PEAR does not use the PHP settings, so the PEAR settings needs to be adjusted.

Hope this helps.

Tip: MySQL Replication Error: Duplicate Entry for Key

Rai    Linux     database, error, fix, Linux, mysql, replication, solution

I have encountered this error, which to my surprise occurred on a slave database.

error 'Duplicate entry '2355476' for key 1' on query ' INSERT INTO logs (DateStamp) VALUES (NOW())

You might be wondering how a slave database could have a duplicate entry while the master and other slaves are running just fine?

Some say that there could be an entry where it was written in the slave and then written again so the duplicate error occurred. Others say that if myisamchk was run in the master, it removed some entries and tries to create those entries again. The slave then attempts to write the same entry, but since myisamchk was not executed on the slave, the entry exists hence the duplication error.

But luckily, found myself a solution to fix the replication error:

mysql> set sql_slave_skip_counter = 1;
Query OK, 0 rows affected (0.01 sec)

mysql> slave start;
Query OK, 0 rows affected (0.00 sec)

This will skip the error and continue on with the replication. Do not forget to start the slave process afterwards.