XAMPP: Error 1! Couldn’t start Apache! … Sorry, I’ve no idea what’s going wrong.

Today I helped my friend to install XAMPP on a Debian system. When I tried to start the Apache webserver, I got the following message:

#/opt/lampp/lampp startapache
XAMPP: Starting Apache with SSL (and PHP5)...
XAMPP: Error 1! Couldn't start Apache!
XAMPP: Starting diagnose...
XAMPP: Sorry, I've no idea what's going wrong.
XAMPP: Please contact our forum http://www.apachefriends.org/f/

This problem is likely related to your Apache configuration file. To drill down to the root of the problem, we can take a look to the Apache error log:

tail /opt/lampp/log/error_log

and it should give you some info on how to solve this computer problem.

–Derrick

Our sponsors:

Update for xz-4.999.9_1 failed

Recently, I tried to upgrade the installed port on my FreeBSD:

portmaster -Da

and I got the following message:

===>>> Launching child to update xz-4.999.9_1 to xz-5.0.0

===>>> Port directory: /usr/ports/archivers/xz

        ===>>> This port is marked IGNORE
        ===>>> is already in the base system

        ===>>> If you are sure you can build it, remove the
               IGNORE line in the Makefile and try again.

===>>> Update for xz-4.999.9_1 failed
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster  ports-mgmt/portmaster

I google it and someone suggested to do the following:

Just run a

portmaster -e xz-4.999.9_1

And say yes to the prompt. 

Don’t do it!
I tried that and the nightmare began. It will first ask you whether you want to remove xz. Then it will go through every package that depends on xz, and ask you whether you want to delete them or not. If you accidentally click yes, your system will get into trouble.

Instead, try to deinstall it from port:

cd /usr/ports/archivers/xz
sudo make deinstall

This is a lot safer.

Our sponsors:

MySQL: Starting MySQL….. ERROR! The server quit without updating PID file

This step-by-step guide is mainly for FreeBSD, however the idea is the same for Linux. Every once a while, when I update my FreeBSD box, the system likes to shutdown my MySQL server. Therefore, I need to start it again after the update is done. Unfortunately, the upgrade process is not smooth every time. Sometimes it will throw me some error.

/usr/local/etc/rc.d/mysql.server start

Oh well, I got the following error messages:

Starting MySQL..... ERROR! The server quit without updating PID file.

Sometimes, the message will tell you the exact location of which PID file:

Starting MySQL..... ERROR! The server quit without updating PID file (/var/db/mysql/www.icesquare.com.pid).

There are several solutions to troubleshoot these problems. I will go over each one by one.

Solution 1: Reboot The Computer

Although it sounds simple, but it really works. During the system upgrade, the OS may disable some of your daemons. Instead of troubleshooting each one by one, the easiest way is to start everything over. For example, I experienced this problem today after upgrading the Apache and Ruby (Yes, MySQL is not part of the update), and I got this error message afterward. After rebooting the computer, the error message is gone.

Solution 2: Remove Your MySQL Config File

If you have modified your MySQL configuration file, MySQL may not like it few versions after (MySQL is not backward compatibility friendly). It can be the problem of using an unsupported variable, or something similar. The easiest way is to remove your configuration file, and try to start the MySQL server again:

Backup your MySQL configuration first.

mv /etc/my.cnf /etc/my.cnf.backup

And restart the MySQL server again:

/usr/local/share/mysql/mysql.server start

Hopefully you will see the following message:

Starting MySQL. SUCCESS!

Solution 3: Upgrade Your Database File

Sometimes, the newer MySQL doesn’t like the database created in earlier version. I discovered this when I upgrade to MySQL 5.5.7:

Starting MySQL..... ERROR! The server quit without updating PID file (/var/db/mysql/www.icesquare.com.pid).

Since MySQL tells me which PID file causes the problem, I open the file and take a look what’s going on:

sudo tail /var/db/mysql/www.icesquare.com.err

And I saw something interesting: tables: Table ‘mysql.proxies_priv’ doesn’t exist:

101112 10:49:16  InnoDB: Initializing buffer pool, size = 128.0M
101112 10:49:16  InnoDB: Completed initialization of buffer pool
101112 10:49:16  InnoDB: highest supported file format is Barracuda.
101112 10:49:17  InnoDB: 1.1.3 started; log sequence number 1589404
101112 10:49:17 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.proxies_priv' doesn't exist
101112 10:49:17 mysqld_safe mysqld from pid file /var/db/mysql/www.icesquare.com.pid ended

The reason is very simple. MySQL could not open a table created in the earlier version (< 5.7.7) because it is not compatible with the current version. So, we can try to start the MySQL in safe mode through rc.d. First, you can edit the /etc/rc.conf and put the following into the file:

mysql_enable="YES"
mysql_args="--skip-grant-tables --skip-networking"

Restart MySQL through rc.d:

/usr/local/etc/rc.d/mysql-server start

If you did it right, you should see something like the following:

Starting MySQL.. SUCCESS!

Now, MySQL is already running the safe-mode. We want to perform a MySQL upgrade on all tables:

sudo mysql_upgrade

You should see something like this:

Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/tmp/mysql.sock'
Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/tmp/mysql.sock'
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.servers                                      OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Running 'mysql_fix_privilege_tables'...
OK

Now, we want to switch the MySQL back to normal mode by commenting the extra options in /etc/rc.conf:

mysql_enable="YES"
#mysql_args="--skip-grant-tables --skip-networking"

And restart MySQL through /etc/rc.d:

/usr/local/etc/rc.d/mysql-server restart

Now the MySQL is up and running again!

Happy MySQLing.

–Derrick

Our sponsors:

What can you do with A8M2N-LA / NodusM-GL8E?

Recently, I decided to turn my HP m7557c computer (motherboard: A8M2N-LA / NodusM-GL8E) to an Unix server. The nightmare began. After trying nearly 10 different operating systems and distributions, I found that only very few of them worked with A8M2N-LA / NodusM-GL8E. I think it is worth to share my experience with this beast – an experiment result that took more than 100 hours.

I have not failed. I've just found 10,000 ways that won't work.
-- Thomas A. Edison
The following operating system are listed in alphabetically:

Fedora 13
Status: No
Comment: Installation went well, but the system was very unstable due to kernel panic. This mother board may not compatible with the newer Linux kernel.

FreeBSD 7.3
Status: No
Comment: Does not support USB keyword, i.e., can’t start the installation.

FreeBSD 8.1
Status: Yes
Comment: Stable, however the harddrives are very unstable. Sometimes the system complains about the harddrive. See the full story here.

FreeBSD 8.2
Status: Yes
Comment: Very stable. No problem found so far.

OS X 10.4
Status: No
Comment: Installation failed.

OS X 10.5.8
Status: No
Comment: Installation completed, but very unstable. The system reboots itself.

OS X 10.6
Status: No
Comment: Installation failed

Ubuntu 9.10
Status: Yes, stable.

Ubuntu 10.04
Status: No
Comment: If install directly from the disk, the system will not boot. The only possible way is to upgrade from an earlier version. See Ubuntu 10.04 – Can’t boot / Can’t install for details.

Ubuntu 10.10
Status: No
Comment: Cannot even load the installation disk.

Hope my experience is helpful to you.

–Derrick

Our sponsors:

Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF environment variable. Then, rerun this script.

This post is about FreeBSD, however the idea is about the same for other Unix systems.

While I tried to install memcached, the system complained with this message:

Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

This problem is caused by missing couple variables at the shell level: PHP_AUTOCONF, PHP_AUTOHEADER. It is very easy to solve this problem:

1. First, make sure that Autoconf is installed in your system:

#pkg_info | grep autoconf
autoconf-2.68       Automatically configure source code on many Un*x platforms
autoconf-wrapper-20071109 Wrapper script for GNU autoconf

If autoconf is not available, install it from here:

cd /usr/ports/devel/autoconf268
make install clean

2. Now, we need to set couple variables. This step is very important because you can’t set the variable using sudo export x=y. First, switch to root

sudo su

3. Find out where is autoconf (The location in FreeBSD and Linux are different)

which autoconf

4. Set the autoconf, in my case, it is /usr/local/bin/autoconf

export PHP_AUTOCONF=/usr/local/bin/autoconf

5. Do the same thing for autoheader:

which autoheader
export PHP_AUTOHEADER=/usr/local/bin/autoheader

That’s it. Now try to install your software again and the error message should be gone.

–Derrick

Our sponsors:

How to join file.1, file.2, file.3…

Today, I found a list of files ending with .1, .2, .3 etc. Initially, I thought I could simply join them together, i.e.,

Using hjSplit on Windows, or cat on Unix:

cat file.1 file.2 file.3 > file

Unfortunately, it doesn’t work out. After searching on google, I found that a Spanish software called Hacha can solve this problem. You can download Hacha from here.

Our sponsors:

fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ngx-fancyindex-0.2.2.tar.bz2: File unavailable (e.g., file not found, no access)

Today I tried to run the upgrade my nginx on my FreeBSD box, and I received the following message:

===>  Vulnerability check disabled, database not found
===>  License accepted by the user
===>  Found saved configuration for nginx-0.7.66
=> ngx-fancyindex-0.2.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://connectical.com/attachments/download/26/.
fetch: http://connectical.com/attachments/download/26/ngx-fancyindex-0.2.2.tar.bz2: Not Found
=> Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ngx-fancyindex-0.2.2.tar.bz2: File unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.

Obviously, the FreeBSD box could not download the file. To fix this problem, simply run the following commands:

cd /usr/ports/distfiles/
sudo wget http://files.connectical.com/gentoo/ngx-fancyindex-0.2.2.tar.bz2

This will allow FreeBSD to skip downloading the file from a wrong URL. Now, go back to the nginx port:

cd /usr/ports/www/nginx

and try to install nginx again:

sudo make install clean

Our sponsors:

-bash: /dev/null: Permission denied

Recently, I found that Ubuntu gives the following error when I log in to the system:

-bash: /dev/null: Permission denied

After I run the following command, the problem is gone:

sudo chmod 0666 /dev/null

Our sponsors:

Softlink / Symbolic Link doesn’t work on Samba – Solved

After upgrading my Samba servers (One is Ubuntu Linux, and the other one on Fedora Linux), I found that I can no longer access the symbolic links / soft links from Windows. It keeps returning “permission error”, “You don’t have permission to access this folder” etc. I am pretty sure that it has nothing to do with my user permission settings because it was working just fine before the upgrade. After trying several solutions, here is what I come up:

Edit your samba configuration file:

sudo nano /etc/samba/smb.conf

Add the following into the global section, i.e.,

[global]
...
follow symlinks = yes
wide links = yes
unix extensions = no
...

Save your file and restart Samba:

sudo /etc/init.d/samba restart

It should work now.

Our sponsors:

MediaWiki Error: “Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING in /usr/local/www/apache22/data/wiki/includes/Namespace.php on line 46”


After upgrading my PHP to 5.3.2, I received the following error when accessing MediaWiki (1.6.12):

Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING in /usr/local/www/apache22/data/wiki/includes/Namespace.php  on line 46

There are three solutions:

  1. Downgrade your PHP from 5.3 back to 5.2
  2. Upgrade your MediaWiki to a newer version.
  3. Fix the codes.

In my case, the first couple solutions do not work for me, and therefore I choose 3.

  1. Backup your wiki file first.
  2. Access your webserver and go to the MediaWiki/includes directory.
    For example:

    cd /usr/local/www/apache22/data/wiki/includes
  3. Edit Namespace.php
    nano Namespace.php
  4. Go to line 46, change the following from:
    class Namespace {

    to:

    class MWNamespace {

    Save the file.

  5. Now, let’s create a script:
    nano wikifix.sh

    Copy and paste the following:

    for fl in *.php; do
    mv $fl $fl.old
    sed 's/Namespace::/MWNamespace::/g' $fl.old > $fl
    done

    Save the file.

  6. Change the file to executable by:
    chmod u+x wikifix.sh
  7. Search the keyword Namespace:: and replace it by MWNamespace:::
    ./wikifix.sh

    Warning: Don’t run the script twice!

  8. Delete the script.
    rm wikifix.sh

Try to access the MediaWiki again and the problem should be gone.

Enjoy Wiki.

–Derrick

Our sponsors: