Posts Tagged ‘Cannot’

17th of May Saint Martyr Nikolay Sofiiski (Nikolas of Sofia) – Bulgarian Martyr Confessor saint from the XV century

Friday, May 21st, 2021

Saint Confessor Nikolay Sofijski (Nikolay of Sofia) Short Biography



St. Nikolay (Nicolas) of Sofia has been born in Ioannina (city now in territory of Greece). He was a pious and with his honorable craft of shoemaking going through the stormy sea of life. When he arrived in Sofia (Serdica / Sredetz), one of the main cities of the Ottoman Empire of that time, a long remain of the glorious past when even the righteous emperor Constantine The great was considering to set as a capital of the Eastern empire either Constantinople today's Istanbul in Turkey or Sofia (Fortress of Serdika).

When Nikolay came to Sofia, he was immediately recognized by the Turkish authorities and rich people of the city  and to have him part of their "nobel" turkish society and enrich the city ruleship, the Turkish tried to push Nikolay to accept Islam. 
Once a time Turkish invited Nikolay, put a somniferous herb in his offered drink and once he fall asleep without his knowledge they have circumcised him according to Islamic tradition observance. 
Once awaken Nikolay realised what has been done to him and fall in a deep regret and mourned over the abuse of his body which according the Christian faith is a temple of the Holy Spirit. Once he started appearing on the streets of Sofia, Turkish immediately invited him to attend the mosque considering him already a muslim due to the circumcision ritual commited on him. 
He firmly rejected the offer publicly, considering himself a Christian as he never publicly resigned his Christian faith and never ever wanted to be muslim and never ever has attended another temple apart from the Eastern Orthodox Christian Church he belonged to.
Facing the rejection, the powerful of the day turks cannot believe their eyes as they already thought Nikolay accepted the fact he is already a muslim, not understanding that for a Christian the temporary flesh is nothing but a temporary hut and the Spiritual and Eternal Soul and The Spirit of God which enlightens it as well as the Eternal Kingdom of Heaven is everything. The turks thouhgt over it fleshly, thinking that having a sign of circumcision already puts a person belonging to his faith, not knowing that the the first desciples of Christ, the most holy apostles as belonging to the Jewish faith had their circumcision themselves, and this circumcision never ever hindered their faith in the Resurrected Messiah Jesus Christ.

Immediately facing the rejecting the Turks, arrested him as a traitor of their faith and put him into a harsh torments.



Combined icon with the living of saint Nikolay of Sofia

Putting him on trial In the local court, the judge announced his opinion that Nikolay doesn't hold a fault, neither against Islam neither against the claimants.
Nevertheless the crowd put Nikolay outside of Sofia (in a similar way the Jews resurrected Christ outside of the city of Jerusalem) in Sofia's near region called "Yuch Bunar", translated from Turkish as the  ("The Tree Wells"), there they stoned to death on 17th of May year 1555 A.D., (the stoning a transgressor of the Islamic law, tradition is still followed by some countries even today, for example I heard similar cases do happen still in Saudi Arabia for sinners against islamic law).


Saint Nikolay icon in his traditional Bulgarian clothes wear (Nosia)
holding his shoemaking instrument

His holy body has been moved to the graveyear called (Търница) Térnitza and has been burned – and the dust has been scattered through the four directions of the world North, East, South, West following islamic tradition and in attempt to completely irradicate the memory of the saint in the relatives and the living Christians of that time.  Even though due to the request of Matey Gramatik (Mathew the Gramatik – translated as Chronicler / Annalist), a boy managed to collect little burned part remains of the relics and a pious christian, secretly made a burial prayer for his Soul (Опело – called Opelo in the Slavonic Eastern Orthodox Church) according to the Christian tradition and buried him with honor.


Soon after the martyrdom of saint Nikolay the New, the Metropolitan of Sredetz Iakov (Jacob), announced the canonization of st. Nikolay on a specially summoned for the consideration of saintship of St. Nikolay, a Local Church Metropolitan Council. Jacob received parts from holy relics (parts of the skull and the bones) of st. Nikolay, that has been secretly kept by a faithful Christians till then and placed the new received saint relics and placed them together in the ark (coffin) with the incorruptable holy relics of Saint King Stephan Milutin at that time located in Church of St. Archangel Michaelsee my previous article pilgrimage to the incorruptable Holy relics of Saint Stephan Milutin in Cathedral Saint Nedelya, Sofia Bulgaria. Later parts of the holy relics has been housed in in a Wood maden Church.


The grave of saint Nikolay of Sofia is one of the few known graves of Bulgarian saints. Today, it is situated in the city center of Sofia capital city of Bulgaria in the district "Три кладенци" / "The Three Wells". Three hundred meters from there (in the tiny park like garden between the streets of "Pirotska" and "Opalchenska") lays a Beatiful Majestic Church, dedicated to the Holy Martyr st. Nikolay Sofijski. The Church of Saint Nicolas of Sofia is one of the biggest Cathedral Churches in Bulgaria (it is second by size in city of Sofia). The Temple has been rised following a project of architecture created by Anton Tornyov after the Liberation of Bulgarian following the Russian/Bulgarian-Turkish war on 3-rd of December 1900. Church saint Nikolay Sofijski has been consecrated by Metropolitan Partenij (Parthenius of Sofia was a senior Bulgarian clergyman and church figure, Metropolitan of Sofia from 1892 to 1918. Metropolitan Parthenius is an exceptional clergyman who has left a lasting mark in the history of the Bulgarian Orthodox Church.).


Church of Saint Nikolay of Sofia in Sofia Bulgaria (corner of street "Opalchenska" and "Pirotska").


Church Nikolay Sofijski view to Iconostasis Church interior


Church dome paintings of St. Nikolay Sofijski


Iconostasis of the Church (notice the beatiful flower forms curved wood)

In the beginning of XXth century in 1870s on the exact place of the grave of the saint has been built a small chapel in his memoriam. It is situated in a small yard on today's Street of "Tzar Simeon / King Simeon" it is opened for pilgrim visitors everyday in the early afternoon every working day. 
The Chapel entrance door 


A Heavenly beauty roman like chapel


The Chapel on the grave of Saint Nikolas of Sofia, built on the place called "Terniza" (Tzar Simeon Street), where on 17-th of May, year 1555 A.D. where remains of the saint has been burned by turks – photo by Martin Mitov (C) 


The Grave of Saint Nikolay of Sofia (View to Alter dedicated to the matryr saint)

The holy relics of Saint Nikolay the new are now preserved in his Church  and are brought for veneration by believers and pilgrims on each 16 and 17 of May and sometimes in a Church feasts of a higher importance.

Each 17-th of May in Sofia it is a tradition for clirics (clergy) to gather together with pilgrims and layman for a Lithia with the holy relics of saint Nikolay from the Church to the chapel, and for the following two days 18, 19th of May his holy relics are publicly displayed for veneration.

Sofia's mediaval historian and clergyman deacon Matey Gramatik (upmentioned), was a comtemporary of the saint and eyewitness of his martyrdom and death, soon after wrote his Church service and Biography (Saint Living). Today the original manuscript is preserved in the the Library of the church "St. Martyr Nikolai Novi Sofiyski" in Sofia.

Let by the holy prayers of Saint Nikolay Sofijski our homeland Bulgaria is given peace prosperity in The Hope, Faith and Love and every Good and firmness in the True faith given by Christ the Holy Eastern Orthodox faith. Let by his Holy prayers God gives peace and love to everyone in the world and grant, repentance for us the lost and spiritually poor and "fatherless" children of the 21st century.

Fix FTP active connection issues “Cannot create a data connection: No route to host” on ProFTPD Linux dedicated server

Tuesday, October 1st, 2019


Earlier I've blogged about an encounter problem that prevented Active mode FTP connections on CentOS
As I'm working for a client building a brand new dedicated server purchased from Contabo Dedi Host provider on a freshly installed Debian 10 GNU / Linux, I've had to configure a new FTP server, since some time I prefer to use Proftpd instead of VSFTPD because in my opinion it is more lightweight and hence better choice for a small UNIX server setups. During this once again I've encounted the same ACTIVE FTP not working from FTP server to FTP client host machine. But before shortly explaining, the fix I find worthy to explain briefly what is ACTIVE / PASSIVE FTP connection.


1. What is ACTIVE / PASSIVE FTP connection?

Whether in active mode, the client specifies which client-side port the data channel has been opened and the server starts the connection. Or in other words the default FTP client communication for historical reasons is in ACTIVE MODE. E.g.
Client once connected to Server tells the server to open extra port or ports locally via which the overall FTP data transfer will be occuring. In the early days of networking when FTP protocol was developed security was not of such a big concern and usually Networks did not have firewalls at all and the FTP DATA transfer host machine was running just a single FTP-server and nothing more in this, early days when FTP was not even used over the Internet and FTP DATA transfers happened on local networks, this was not a problem at all.

In passive mode, the server decides which server-side port the client should connect to. Then the client starts the connection to the specified port.

But with the ever increasing complexity of Internet / Networks and the ever tightening firewalls due to viruses and worms that are trying to own and exploit networks creating unnecessery bulk loads this has changed …


2. Installing and configure ProFTPD server Public ServerName

I've installed the server with the common cmd:


apt –yes install proftpd


And the only configuration changed in default configuration file /etc/proftpd/proftpd.conf  was
ServerName          "Debian"

I do this in new FTP setups for the logical reason to prevent the multiple FTP Vulnerability Scan script kiddie Crawlers to know the exact OS version of the server, so this was changed to:


ServerName "MyServerHostname"


Though this is the bad security through obscurity practice doing so is a good practice.

3. Create iptable firewall rules to allow ACTIVE FTP mode

But anyways, next step was to configure the firewall to be allowed to communicate on TCP PORT 21 and 20 to incoming source ports range 1024:65535 (to enable ACTIVE FTP) on firewal level with iptables on INPUT and OUTPUT chain rules, like this:


iptables -A INPUT -p tcp –sport 1024:65535 -d 0/0 –dport 21 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 –sport 1024:65535 -d 0/0 –dport 20 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 –sport 21 -d 0/0 –dport 1024:65535 -m state –state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 –sport 20 -d 0/0 –dport 1024:65535 -m state –state ESTABLISHED,RELATED -j ACCEPT

Talking about Active and Passive FTP connections perhaps for novice Linux users it might be worthy to say few words on Active and Passive FTP connections

Once firewall has enabled FTP Active / Passive connections is on and FTP server is listening, to test all is properly configured check iptable rules and FTP listener:

/sbin/iptables -L INPUT |grep ftp
ACCEPT     tcp  —  anywhere             anywhere             tcp spts:1024:65535 dpt:ftp state NEW,ESTABLISHED
ACCEPT     tcp  —  anywhere             anywhere             tcp spts:1024:65535 dpt:ftp-data state NEW,ESTABLISHED
ACCEPT     tcp  —  anywhere             anywhere             tcp dpt:ftp
ACCEPT     tcp  —  anywhere             anywhere             tcp dpt:ftp-data

netstat -l | grep "ftp"
tcp6       0      0 [::]:ftp                [::]:*                  LISTEN    


4. Loading nf_nat_ftp module and net.netfilter.nf_conntrack_helper (for backward compitability)

Next step of course was to add the necessery modules nf_nat_ftp nf_conntrack_sane that makes FTP to properly forward ports with respective Firewall states on any of above source ports which are usually allowed by firewalls, note that the range of ports given 1024:65535 might be too much liberal for paranoid sysadmins and in many cases if ports are not filtered, if you are a security freak you can use some smaller range such as 60000-65535.


Here is time to say for sysadmins who haven't recently had a task to configure a new (unecrypted) File Transfer Server as today Secure FTP is almost alltime used for file transfers for the sake of security might be puzzled to find out the old Linux kernel ip_conntrack_ftp which was the standard module used to make FTP Active connections work is substituted nowadays with  nf_nat_ftp and nf_conntrack_sane.

To make the 2 modules permanently loaded on next boot on Debian Linux they have to be added to /etc/modules

Here is how sample /etc/modules that loads the modules on next system boot looks like

cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

Next to say is that in newer Linux kernels 3.x / 4.x / 5.x the nf_nat_ftp and nf_conntrack-sane behaviour changed so  simply loading the modules would not work and if you do the stupidity to test it with some FTP client (I used gFTP / ncftp from my Linux desktop ) you are about to get FTP No route to host errors like:


Cannot create a data connection: No route to host



Sometimes, instead of No route to host error the error FTP client might return is:


227 entering passive mode FTP connect connection timed out error

To make the nf_nat_ftp module on newer Linux kernels hence you have to enable backwards compatibility Kernel variable





echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


To make it permanent if you have enabled /etc/rc.local legacy one single file boot place as I do on servers – for how to enable rc.local on newer Linuxes check here

or alternatively add it to load via sysctl

sysctl -w net.netfilter.nf_conntrack_helper=1

And to make change permanent (e.g. be loaded on next boot)

echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf


5. Enable PassivePorts in ProFTPD or PassivePortRange in PureFTPD

Last but not least open /etc/proftpd/proftpd.conf find PassivePorts config value (commented by default) and besides it add the following line:


PassivePorts 60000 65534


Just for information if instead of ProFTPd you experience the error on PureFTPD the configuration value to set in /etc/pure-ftpd.conf is:

PassivePortRange 30000 35000

That's all folks, give the ncftp / lftp / filezilla or whatever FTP client you prefer and test it the FTP client should be able to talk as expected to remote server in ACTIVE FTP mode (and the auto passive mode) will be not triggered anymore, nor you will get a strange errors and failure to connect in FTP clients as gftp.

Cheers 🙂

Fix “tar: Error exit delayed from previous errors” and its cause and solution

Monday, August 18th, 2014


tar: Error exit delayed from previous errors

error is a very common error encountered when creating archives (or backing up server configurations / websites / sql binary data). The error is quite unexplanatory and whenever creating files verbose in order to see the files added to archve in "real time" with lets say:

tar -czvf /tmp/filename_backup_date-of-backup.tar.gz /home/websites /home/sql

its pretty hard to track on exactly which file is the backup producing the Error exit delayed from previous errors, this is especially the case whenever adding to archive directories containing millions of tiny few kilobyte sized files. Many novice on uncautious Linux admins , might simply ignore the warning if they're in a hurry / are having excessive work to be done as there will be .tar.gz backup produced and whenever uncompressed most of the files are there and the backup error would seem not of a big issue.

However as backuping files is vital stuff, especially when moving the files from a server to be decomissioned you have to be extra careful and make the backup properly, e.g. figure out the cause of the error, to do so log the full output of tar operations with tee command, like so:

tar -czvf /tmp/filename_backup_date-of-backup.tar.gz /home/websites/ /home/sql | tee /tmp/backup_tar_full_output.log

Then you will have to review the file and lookup for errors with less search string – / (slash) – look for "error" and "permission den" keywords and this should point you to what is causing the error. In cases when millions of files are to be archived, the log might grow really big and hard to process, therefore a much quicker way to understand what's happening is to only log and show in shell standard output last file error with > (shell redirect):

tar -czvf /tmp/filename_backup_date-of-backup.tar.gz /home/websites /home/sql > /tmp/backup_failure-cause.log


tar: Cannot open: Permission denied
tar: Removing leading `/' from member names

The error indicates clearly the cause of error is lack of Permissions to read the file tnsnames.ora.20080918 so solution is to either grant permissions to non-root user with (chmod / chown) cmds, in my case grant perms to user hipo with which tar is ran, or run again the website backup with superuser, I usually just run with root user to prevent tampering with original permissions, e.g. to solve the error, either:

$ su root
# tar -czvf /tmp/filename_backup_date-of-backup.tar.gz /home/websites /home/sql

Or even better if sudo is installed and user is added to /etc/sudoers file

$ sudo tar -czvf /tmp/filename_backup_date-of-backup.tar.gz /home/websites /home/sql

Though permission errors is the most often reason for:

tar: Error exit delayed from previous errors, you should keep in mind that in some cases the error might be caused due to failing RAID membered disk drive or single hdd failure on systems that are not in some RAID array


How to disable IPv6 on Debian / Ubuntu / CentOS and RHEL Linux

Friday, December 9th, 2011

I have few servers, which have automatically enabled IPv6 protocols (IPv6 gets automatically enabled on Debian), as well as on most latest Linux distribituions nowdays.

Disabling IPv6 network protocol on Linux if not used has 2 reasons:

1. Security (It’s well known security practice to disable anything not used on a server)
Besides that IPv6 has been known for few criticil security vulnerabilities, which has historically affected the Linux kernel.
2. Performance (Sometimes disabling IPv6 could have positive impact on IPv4 especially on heavy traffic network servers).
I’ve red people claiming disabling IPv6 improves the DNS performance, however since this is not rumors and did not check it personally I cannot positively confirm this.

Disabling IPv6 on all GNU / Linuces can be achieved by changing the kernel sysctl settings net.ipv6.conf.all.disable_ipv6 by default net.ipv6.conf.all.disable_ipv6 equals 1 which means IPv6 is enabled, hence to disable IPv6 I issued:

server:~# sysctl net.ipv6.conf.all.disable_ipv6=0

To set it permanently on system boot I put the setting also in /etc/sysctl.conf :

server:~# echo 'net.ipv6.conf.all.disable = 1 >> /etc/sysctl.conf

The aforedescribed methods should be working on most Linux kernels version > 2.6.27 in that number it should work 100% on recent versions of Fedora, CentOS, Debian and Ubuntu.

To disable IPv6 protocol on Debian Lenny its necessery to blackist the ipv6 module in /etc/modprobe.d/blacklist by issuing:

echo 'blacklist ipv6' >> /etc/modprobe.d/blacklist

On Fedora / CentOS there is a another universal “Redhat” way disable IPv6.

On them disabling IPv6 is done by editting /etc/sysconfig/network and adding:


I would be happy to hear how people achieved disabling the IPv6, since on earlier and (various by distro) Linuxes the way to disable the IPv6 is probably different.

Alto to stop Iptables IPV6 on CentOS / Fedora and RHEL issue:

# service ip6tables stop

# service ip6tables off

How to solve “[crit] [client] (13)Permission denied: /var/lib/ejabberd/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer:” – Error Cause and Solution

Thursday, January 5th, 2012

While configuring JWchat domain, I've come across around an error:

pcfg_openfile: unable to check htaccess file, ensure it is readable

The exact error I got in /var/log/apache2/error.log looked like so:

[crit] [client] (13)Permission denied: /var/lib/ejabberd/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer:

The error message suggested /var/lib/ejabberd/.htaccess – is missing or not readable, however after checking i've seen .htaccess existed as well as was readable:

debian:~# ls -al /var/lib/ejabberd/.htaccess
-rw-r--r-- 1 www-data www-data 114 2012-01-05 07:44 /var/lib/ejabberd/.htaccess

At first glimpse it seems like the message is misleading and not true, however when I switched to www-data user (the user with which Apache runs on Debian), I've figured out the error meaning of unreadability is exactly correct:

www-data@debian:$ ls -al /var/lib/ejabberd/.htaccess
ls: cannot access /var/lib/ejabberd/.htaccess: Permission denied

This permission denied was quite strange, especially when considering the .htaccess is readable for all users:

debian:~# ls -al /var/lib/ejabberd/.htaccess
-rw-r--r-- 1 www-data www-data 114 2012-01-05 07:44 /var/lib/ejabberd/.htaccess

After a thorough look on what might go wrong, thanksfully I've figured it out. The all issues were caused by wrong permissions of /var/lib/ejabberd/.htaccess .You can see below the executable flag for all users (including apache's www-data) is missing :

debian:/var/lib# ls -ld /var/lib/ejabberd/drw-r--r-- 3 ejabberd ejabberd 4096 2012-01-05 07:45 /var/lib/ejabberd/

Solving the error, hence is as easy as adding +x flag to /var/lib/ejabberd :

debian:/var/lib# chmod +x /var/lib/ejabberd

Another way to fix the error is to chmod to 755 to the directory which holds .htaccess:

From now onwards pcfg_openfile: unable to check htaccess file, ensure it is readable err is no more 😉

How to solve qmail /usr/local/bin/tcpserver: failed to map segment from shared object: Cannot allocate memory

Saturday, April 30th, 2011

If you’re building (compiling) a new qmail server on some Linux host and after properly installing the qmail binaries and daemontools, suddenly you notice in readproctitle service errors: or somewhere in in qmail logs for instance in/var/log/qmail/current the error:

/usr/local/bin/tcpserver: error while loading shared libraries: failed to map segment from shared object: Cannot allocate memory

then you have hit a bug caused by insufficient memory assigned for tcpserver in your /var/qmail/supervise/qmail-smtpd/run daemontools qmail-smtpd initialize script:

This kind of issue is quite common especially on hardware architectures that are 64 bit and on Linux installations that are amd65 (x86_64) e.g. run 64 bit version of Linux.

It relates to the 64 bit architecture different memory distribution and thus as I said to solve requires increase in memory softlimit specified in the run script an example good qmail-smtpd run script configuration which fixed the failed to map segment from shared object: Cannot allocate memory I use currently is as follows:

#!/bin/shQMAILDUID=`id -u vpopmail`NOFILESGID=`id -g vpopmail`MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`# softlimit changed from 8000000exec /usr/local/bin/softlimit -m 32000000 /usr/local/bin/tcpserver -v -H -R -l 0 -x /home/vpopmail/etc/tcp.smtp.cdb -c "$MAXSMTPD"
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp
/home/vpopmail/bin/vchkpw /bin/true 2>&1

The default value which was for softlimit was:

exec /usr/local/bin/softlimit -m 8000000

A good softlimit raise up values which in most cases were solving the issue for me are:

exec /usr/local/bin/softlimit -m 3000000

or exec /usr/local/bin/softlimit -m 4000000

The above example run configuration fixed the issue on a amd64 debian 5.0 lenny install, the server hardware was:

CPU: Intel(R) Core(TM)2 Duo CPU @ 2.93GHz
System Memory: 4GB
HDD Disk space: 240GB

The softlimit configuration which I had to setup on another server with system parameters:

Intel(R) Core(TM) i7 CPU (8 CPUS) @ 2.80GHz
System Memory: 8GB
HDD Disk Space: 1.4Terabytes

is as follows:

QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
exec /usr/bin/softlimit -m 64000000
/usr/local/bin/tcpserver -v -H -R -l 0
-x /home/vpopmail/etc/tcp.smtp.cdb -c "$MAXSMTPD"
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp
/home/vpopmail/bin/vchkpw /bin/true 2>&1

If none of the two configurations pointed out in the post works, for you just try to manually set up the exec /usr/bin/softlimit -m to some high value.

To assure that the newly set value is not producing the same error you will have to, reload completely the daemontools proc monitor system.
To do so open /etc/inittab comment out the line:


Save again /etc/inittab and issue te cmd:

linux:~# init q

Now again open /etc/inittab and uncomment the commented line:

#SV:123456:respawn:/command/svscanboot to

Lastly reload the inittab script once again with command:

linux:~# init q

To check if the error has disappeared check the readproctitle process, like so:

linux:~# ps ax|grep -i readproctitle

The command output should produce something like:

3070 ? S 0:00 readproctitle service errors: .......................................

Hope that helps.

How to solve “eAccelerator requires Zend Engine API version 220060519 , the Zend Engine API version 220090626 which is installed, is newer. Contact eAccelerator at for a later version of eAccelerator.” on FreeBSD

Monday, April 4th, 2011

I’ve recently upgraded my FreeBSD Apache server from port www/apache20 I had some issues before I tune up and recompile also the php5 port but eventually it worked out, however the Eaccelerator content caching module failed to load as it was outdated.

That’s a common inconvenient with eaccelerator that every system administrator out there has faced once or twice, especially on systems that has custom compiled Apache servers and does not use a specific precompiled version of the eaccelerator.

To solve the situation as you can expect I jumped on in the /usr/ports/www/eaccelerator and removed the current installed version of eaccelerator in order to compile and install the latest port version.:
To do that I first attempted to upgrade the eaccelerator port with portmaster but as there were some problems caused by autoconf initialization etc., I finally decided to abandon the idea of using portmaster and did it manually with the good old well known trivial commands:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make deinstall
freebsd# make install && make clean

I’ve continued further and restarted my Apache server to load the new eaccelerator version and made a small phpinfo php script to test if the eaccelerator is properly loaded, yet with zero success.

After checking out in my /var/log/httpd-error.log , I’ve determined the following error:

Failed loading /usr/local/lib/php/20060613/ Cannot open "/usr/local/lib/php/20060613/"

The error is quite obvious, to solve it I’ve opened my php configuration file /usr/local/etc/php.ini and placed in it:

and substituted the line:




Further on I gave Apache another restart with:

freebsd# /usr/local/etc/rc.d/apache2 restart
Performing sanity check on apache2 configuration:
Syntax OK
Stopping apache2.
Waiting for PIDS: 71140.
Performing sanity check on apache2 configuration:
Syntax OK
Starting apache2.

followed by another test if the eaccelerator is loaded with the phpinfo(); script.

Now even though the Failed loading /usr/local/lib/php/20060613/ Cannot open “/usr/local/lib/php/20060613/” was no more, the Eaccelerator was yet not loaded.

Another consult with /var/log/httpd-error.log now revealed me another eaccelerator error you read below:

eAccelerator requires Zend Engine API version 220060519.
The Zend Engine API version 220090626 which is installed, is newer.
Contact eAccelerator at for a later version of eAccelerator.

I did about 20 minutes of investigation on the internet looking for a possible fix which gave me some idea what might be the cause for error message, though it was finally my try/fail methodology that helped me solve the issue.

The solution to the issue appeared to be easy thanks God, to solve the error all you need to do is one more make clean right before installing the eaccelerator port.:
Here are the commands necessary to issue to solve the error and make the eaccelerator load properly:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make clean &&
freebsd# make install clean

Now after restarting the Apache server once again eaccelerator has properly been loaded once again.

phpMyAdmin – Error “Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.”

Monday, February 8th, 2010

I’ve encountered a shitty problem while trying to access my phpmyadmin.
Here is the error:
phpMyAdmin - Error "Cannot start session without errors, please check errors given
in your PHP and/or webserver log file and configure your PHP installation properly.

After some time spend in investigation I’ve figured out something wrong is happening with my
php sessions, therefore I had to spend some time assuring myself php sessions are working correctly.
To achieve that I used a php code taken from the Internet.

Here is a link to the PHP code which checks, if sessions are correctly configured on a server .
Executing the code proove my sessions, are working okay, however still the problem remained.
Everytime I tried accessing phpMyAdmin I was unpleasently suprised by by:

phpmyadmin session error picture
After reconsidering the whole situation I remembered that since some time I’m using varnishd
therefore the problem could have something to do with the varnish-cache.
After checking my default.vcl file and recognizing a problem there I had to remove the following piece
of code from the default.vcl file:

#sub vcl_fetch {
# if( req.request != "POST" )
# {
# unset obj.http.set-cookie;
# }

# set obj.ttl = 600s;
# set obj.prefetch = -30s;
# deliver;

Now after restarting varnishd with:

/usr/local/etc/rc.d/varnishd restart

All is back to normal I can login to PhpMyAdmin and everything is fine!
Thanks God.