Directadmin – Process failed (1) when writing error message to (frozen)

User complained about not being able to receive error messages from remote mail servers. When he sent to this email address from Gmail, error message return, but when he tried from Directadmin server, no error message arrived in inbox. I could see those messages in Exim’s mail queue as frozen.

In Exim mail log, this error was shown:

Process failed (1) when writing error message to (frozen)

After a while of digging online, I’ve found out that BlockCracking is causing this problem. We had BlockCracking version 1.8 which was apparently version with this issue. You’ll have to upgrade BlockCracking to version 1.10 or newer. Just go to your Directadmin’s custombuild directory, then follow this steps:

./build exim
./build dovecot_conf
./build spamassassin
./build blockcracking
./build update
./build exim_conf

After that, error messages should arrive in your inbox.

Postfix – OpenDKIM not signing outgoing email (not authenticated)

I had this weird issue. On CentOS 7 I set up mail server with Postfix, Dovecot, ClamAV, rspamd and OpenDKIM. Everything was working fine except all of my outgoing emails weren’t signed by DKIM.

In mail log this message was shown:

Mar 2 14:02:16 vps opendkim[10810]: 6FD942E30BB: not authenticated
Mar 2 14:02:16 vps opendkim[10810]: 6FD942E30BB: no signature data

After a lot of trying different configs an options, I googled answer on this forum. Apparently, opendkim thought that user wasn’t authenticated, but in reality, it was. This was due to Postfix configuration. There was missing milter macro. I added {auth_type} macro to milter_mail_macros. Then restarted Opendkim and Postfix and it started to work properly.

Now my postfix configuration ( for milters looks like this:

milter_protocol = 6
milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
milter_mail_macros="i {mail_addr} {client_addr} {client_name} {auth_type} {auth_authen}"
smtpd_milters = inet:localhost:11332 inet:localhost:8891 unix:/var/spool/postfix/clamav/clamav-milter.socket
non_smtpd_milters = $smtpd_milters

And emails are getting signed correctly:

Mar 2 14:15:56 vps opendkim[11513]: 8C5213E36D: DKIM-Signature field added (s=mail,

CSF – whitelist user from SMTP_BLOCK

CSF features great option SMTP_BLOCK which block outgoing SMTP for all users except root, exim and mailman. I had a problem with one user which was using MailChimp as mass mailing within their application. Because of SMTP_BLOCK it wasn’t working. Disabling SMTP_BLOCK globally is not recommended, you can white list users for which you would like to allow sending.

Go to your CSF settings and find SMTP_ALLOWUSER. Then add user which should be allowed (users separated with coma). Don’t forget to restart CSF.

Disable OPcache for specific PHP script. Exclude from OPcache.

Sometimes accelerating with opcache can cause some problems with your application scripts. In those cases, when your script shouldn’t be accelerated, you can specify those scripts with opcache’s blacklist which will exclude this files from acceleration. Example bellow is done on CentOS 7.

First, find configuration file for your opcache php extension. You can do something like this:

[root@meow php.d]# php -i | grep opcache | grep ini
Additional .ini files parsed => /etc/php.d/10-opcache.ini,

Open 10-opcache.ini and you should see something like bellow. Path to opcache’s blacklist file.

; The location of the OPcache blacklist file (wildcards allowed).
; Each OPcache blacklist file is a text file that holds the names of files
; that should not be accelerated.

Close 10-opcache.ini and open file named opcache-default.blacklist which should be in same directory. If not, create one. This file will contain a list of php scripts which should be ignored by opcache. 

[root@meow php.d]# cat opcache-default.blacklist
; The blacklist file is a text file that holds the names of files
; that should not be accelerated. The file format is to add each filename

cPanel email problem – (13): Permission denied: failed to chdir to /home/username

I had this weird issue on one of our production cpanel servers where user’s email stopped working without any reason. Only error that was available was:

T=dovecot_virtual_delivery defer (13): Permission denied: failed to chdir to /home/username

From time to time users document root permissions were set to user nobody and execution privileges were removed. Because of this, email wasn’t working and I couldn’t find out why.

After a lot of headache I googled across this thread. Permissions were altered by cPanel’s File Protect. Somehow file protect recognized this accounts permissions weren’t right. After checking in users account, there was sub-domain created for which document root was set to “/”. This is not valid document root, and because of this, file protect altered users permissions.

I changed document root for this sub-domain and problem was solved. You should also correct user’s permissions on document root after fixing issue with file protect:

chmod +x /home/username
chown username:username /home/username

You should make sure that user accounts permissions are absolutely correct.

Hope this saves some sleep 🙂

Get list of mass/multi domain redirects with CURL

I had large list of domains for which I had to check to which location are they pointing/redirecting. Curl is best option for this kind of work. To save some time, I wrote this simple one liner which will do that for you.

First, create txt file which will contain list of all domains that you want to check. For this example I will create domains.txt. 

Then, run this command – replace file name with yours.

> $ for i in `cat domains.txt`; do echo -n "$i -> "; curl -I -s -L -o /dev/null -w %{url_effective} -o /dev/null $i; echo "\t"; done

This will give you domain name with location to which it’s redirecting: -> -> -> -> -> https://www. ->

Password protect Netdata with NGINX / Permission denied while connecting to upstream error

Netdata is great free tool for generating server statistics. By default it’s open for entire world on port 19999 – It is not a good idea to leave this open so everyone can your system statistics.

One way to limit access from where it is accessible is by editing netdata.conf and specify IPS in “allow connections from” variable.

allow connections from = ip's that are allowed to access>

There is no option to password protect it. This can be done with NGINX. You can create reverse proxy, so that nginx will serve content from netdata application. To make netdata accessible on subfolder of your hostname, eg., then create nginx configuration like bellow.

First generate password file for nginx:

htpasswd -c /etc/nginx/.htpasswd "username"

Then create or edit existing nginx configuration to something like this:

upstream netdata {
        keepalive 64;

server {
     listen 443 ssl http2;
     location = /netdata {
         return 301 /netdata/;

    location ~ /netdata/(?.*) {

        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;

        proxy_redirect off;
        proxy_set_header Host $host;   

        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
        proxy_pass http://netdata/$ndpath$is_args$args;

        gzip on;
        gzip_proxied any;
        gzip_types *;

    error_log /var/log/nginx/error.log;
    access_log off;

Also, don’t forget to edit netdata.conf and change some variables. Make netdata accessible only from localhost (nginx):

bind to =
allow connections from = localhost
allow dashboard from = localhost

You should also allow connection to port 19999 only to local traffic (localhost).

Restart nginx and netdata, then try to access like: http(s)://

If you’re getting error like bellow in your nginx error log, than chances are that SELinux is active. Disable selinux or execute this command “setsebool -P httpd_can_network_connect true”.

[crit] 8411#0: *1 connect() to failed (13: Permission denied) while connecting to upstream, client:, server:, request: "GET /netdata/ HTTP/1.1", upstream: "", host: ""




NGINX: rewrite non-www to www for multi domain virtual hosts

If you have NGINX virtual host that has a multi different domains pointing to same document root (multi server_name), and you want to automatically redirect non-www to www, than bellow is simple solution. I also wanted to redirect to https with www.

If you don’t need https redirection, than you can simply use variable $scheme instead of “https:”. 

if ( $host !~ ^www\. ) {
            return 302 https://www.$host$request_uri;

So virtual host should look something like this:

server {

      if ( $host !~ ^www\. ) {
           return 302 https://www.$host$request_uri;
      return 302 https://$host$request_uri;

You should also make this redirect in your https server definition. otherwise request for won’t redirect to www.

server {
      if ( $host !~ ^www\. ) {
              return 302 https://www.$host$request_uri;

      ssl on;
      ssl_certificate /etc/letsencrypt/live/;
      ssl_certificate_key /etc/letsencrypt/live/;

      .... //other nginx configuration ....

cPanel’s Awstats: There are no domains which have awstats stats to display

One client had issue with Awstats statistics. They stoped working. When he tried to add new domain and check Awstats in cPanel, this message was shown:

There are no domains which have awstats stats to display

Awstats were configured correctly, cron was executed. I then discovered that there were no active access log in /usr/local/apache/domlogs/ So I tried to tail this log while visit web site, no access log was generating.

A while ago I enabled cPanels option “Piped Log Configuration” which was suggested to enable to speed up cPanel control panel experience. When this was disabled, access log per domain started to working again.


Magento: PHP Fatal error – Allowed memory size exhausted when bin/magento module:status

This was strange one. When calling simple magento command with PHP CLI I was getting error that allowed memory size was exhausted.

[root@machine ~]# php bin/magento module:status
[root@machine ~]# PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 32768 bytes) in /path/to/wwww/ on line 951

I checked php.ini and it was set like this:

memory_limit = 2048M

I checked if there are different values for CLI version. It were the same.

Solution was simple. Change your php.ini value for memory_limit and define it in gigabytes instead in megabytes.

memory_limit = 2G

I restarted Apache and it started to work.

© 2019
Hosted by Hosterdam

About author