I’ve run into the following error(s) intermittently while starting or stopping RabbitMQ on my FreeBSD machine. It was rather perplexing as it seemed inconsistent.

The messages have been abbreviated for brevity.

$ sudo /usr/local/etc/rc.d/rabbitmq start
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: .. Function: read_file_info. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./standard_error.beam. Function: get_file. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./supervisor_bridge.beam. Function: get_file. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./user_sup.beam. Function: get_file. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./user.beam. Function: get_file. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./kernel_config.beam. Function: get_file. Process: code_server."}
{error_logger,{{2009,10,14},{9,8,46}},std_error,"File operation error: eacces. Target: ./queue.beam. Function: get_file. Process: code_server."}

...

=ERROR REPORT==== 14-Oct-2009::09:08:46 ===
file:path_eval([".","/var/db/rabbitmq"],".erlang"): permission denied
Starting all nodes...
Starting node rabbit@localhost...

=ERROR REPORT==== 14-Oct-2009::09:08:46 ===
File operation error: eacces. Target: ./inet_gethost_native.beam. Function: get_file. Process: code_server.

=ERROR REPORT==== 14-Oct-2009::09:08:46 ===
File operation error: eacces. Target: ./dist_util.beam. Function: get_file. Process: code_server.

=ERROR REPORT==== 14-Oct-2009::09:08:46 ===
File operation error: eacces. Target: ./proplists.beam. Function: get_file. Process: code_server.
({"init terminating in do_boot",{badarg,[{erl_prim_loader,check_file_result,3},{erl_prim_loader,check_file_result,3},{init,get_boot,1},{init,get_boot,2},{init,do_boot,3}]}}
no error logger present) error: "Error in process <0.1.0> with exit value: {badarg,[{erl_prim_loader,check_file_result,3},{erl_prim_loader,check_file_result,3},{init,get_boot,1},{init,get_boot,2},{init,do_boot,3}]}\n"

=ERROR REPORT==== 14-Oct-2009::09:08:47 ===
File operation error: eacces. Target: ./erl_scan.beam. Function: get_file. Process: code_server.
init terminating in do_boot ()
Error: {node_start_failed,normal}

Not being familiar with Erlang, or RabbitMQ for that matter, these messages seemed meaningless. Following various links on Google suggested privilege issues, others suggested running strace to help pin point the problem.

Finally, after the umpteenth time reviewing the error log, this popped out at me.

file:path_eval([".","/var/db/rabbitmq"],".erlang"): permission denied

RabbitMQ’s rc.d script runs the following

env HOME=/var/db/rabbitmq su -m rabbitmq -c 'sh -c \"/usr/local/sbin/rabbitmq-multi start_all 1

Notice, via su -m, it runs the command as rabbitmq.
The error file:path_eval([".","/var/db/rabbitmq"],”.erlang”): permission denied, reveals a permission issue. Assuming you installed via ports and haven’t mucked with the rabbitmq directory, the permissions on /var/db/rabbitmq are probably okay. But what about “.”.

In my case I was running it as a non-root user, but that user’s umask is 027 and the home directory permissions are 750. Likewise if you’re running it as root, root’s home directory may not (and should not) have permissions for rabbitmq to read it.

Let’s try it again

$ pwd
/
$ sudo /usr/local/etc/rc.d/rabbitmq start
Starting all nodes...
Starting node rabbit@localhost...

+---+   +---+
|   |   |   |
|   |   |   |
|   |   |   |
|   +---+   +-------+
|                   |
| RabbitMQ  +---+   |
|           |   |   |
|   v1.7.0  +---+   |
|                   |
+-------------------+
AMQP 8-0
Copyright (C) 2007-2009 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd.
Licensed under the MPL.  See http://www.rabbitmq.com/

Success!

First you will need to translate the pkcs12 certificate into a PEM certificate.
The PEM certificate is only needed temporarily and can later be removed.

$ openssl pkcs12 -in certificate.p12 -out tempcrt.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase: pass
Verifying - Enter PEM pass phrase: pass

Now, we use the tempcrt.pem that we generated to determine the expiration date. The first method, which only displays the expiration date can be retrieved like this:

$ openssl x509 -in tempcrt.pem -noout -enddate
notAfter=Jan  3 23:19:24 2009 GMT

The second method which includes a lot more detail about the certificate below, I’ve only included the details relevant to the creation and expiration dates.

$ openssl x509 -in tempcrt.pem -noout -text
        [ ... snip ... ]
        Validity
            Not Before: Jan  3 23:19:24 2008 GMT
            Not After : Jan  3 23:19:24 2009 GMT
        [ ... snip ... ]

I have recently encountered this error:
PHP Warning: preg_match(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0

And despite some of the suggested solutions I have found in various Drupal and MediaWiki forums, all of them related to older versions of ports.
The version of pcre I have installed is 7.8. as seen here:

PCRE version 7.8 2008-09-05
Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

But the curious thing is phpinfo(), told a different story.

 
Why was phpinfo() telling me the version of pcre was 5.0.13?
I checked various things like which libraries php was linked to, and sure enough it was in fact the libpcre that it should have been. After countless iterations of “let me tweak this Makefile and see if it makes a difference” and countless rebuilds of pcre and php, it occurred me, what about Apache? Now I’m not really sure why I this occurred to me, or why it did not occur to me earlier, perhaps it was a result of having felt I had already exhausted the rest of my options.

So I took a look at the Apache build config:

# cd /usr/ports/www/apache22
# make config

 
Apparently the pcre Apache is using is a bundled one, so I decided to change this to use devel/pcre, where I know UTF-8 support is enabled.

 
and proceeded to rebuild and reinstall the apache22 port.
After restarting apache, my first test was to inspect what phpinfo() was reporting.

 
Now phpinfo is agreeing with what I originally expected it to, the pcre port that is installed. I proceeded to test my php code with great success and have not seen the error since.

I encountered this on FreeBSD 7.0 , Apache 2.2.9, PHP 5.2.7, and pcre 7.8. But given the large number of seemingly unresolved threads I’ve encountered through google I expect that there are similar situations in other operating systems and software versions as well.