On a Linode Ubuntu 12.04 server on a Linode server, I have the following error after upgrading to BOA 2.09.

Drush command terminated abnormally due to an unrecoverable error. Error: PHP Startup: Unable to load dynamic library '/opt/local/lib/php/extensions/no-debug-non-zts-20090626/newrelic.so' - /opt/local/lib/php/extensions/no-debug-non-zts-20090626/newrelic.so: cannot open shared object file: No such file or directory in Unknown, line 0

Because of that cloning and migrating is not working.

/var/aegir/config/includes/barracuda_log.txt

Mon Sep 17 13:36:12 CEST 2012 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.3 / Barracuda BOA-2.0.3 / Nginx 1.3.0 / PHP 5.2.17 and 5.3.13 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.27 localhost / Wildcard YES
Sun Dec  2 18:36:20 CET 2012 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.4 / Barracuda BOA-2.0.4 / Nginx 1.3.8 / PHP 5.2.17 and 5.3.18 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.28a localhost / Wildcard YES
Mon Dec 31 16:23:29 CET 2012 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.5 / Barracuda BOA-2.0.5 / Nginx 1.3.9 / PHP 5.2.17 and 5.3.20 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.28a localhost / Wildcard YES
Tue Apr  2 18:06:21 CEST 2013 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.6 / Barracuda BOA-2.0.6 / Nginx 1.3.15 / PHP 5.2.17 and 5.3.23 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.30 localhost / Wildcard YES
Fri Apr  5 07:18:04 CEST 2013 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.7 / Barracuda BOA-2.0.7 / Nginx 1.3.15 / PHP 5.2.17 and 5.3.23 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.30 localhost / Wildcard YES
Wed Apr 10 06:59:35 CEST 2013 / Ubuntu.precise i686 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.8 / Nginx 1.3.15 / PHP 5.2.17 and 5.3.23 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.30 localhost / Wildcard YES
Sat May 11 20:20:32 CEST 2013 / Ubuntu.precise x86_64 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.9 / Nginx 1.5.0 / PHP 5.2.17 and 5.3.25 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.30 localhost / Wildcard YES
Tue May 14 10:10:35 CEST 2013 / Ubuntu.precise x86_64 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.9 / Nginx 1.5.0 / PHP 5.2.17 and 5.3.25 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.30 localhost / Wildcard YES
Fri May 24 21:14:35 CEST 2013 / Ubuntu.precise x86_64 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.9 / Nginx 1.5.0 / PHP 5.2.17 and 5.3.25 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.31 localhost / Wildcard YES
Fri May 24 21:50:07 CEST 2013 / Ubuntu.precise x86_64 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.9 / Nginx 1.5.0 / PHP 5.2.17 and 5.3.25 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.31 localhost / Wildcard YES
Fri May 24 22:07:01 CEST 2013 / Ubuntu.precise x86_64 XEN / Aegir BOA-2.0.8 / Barracuda BOA-2.0.9 / Nginx 1.5.0 / PHP 5.2.17 and 5.3.25 / MODERN-YES / FPM 5.3 / CLI 5.3 / MariaDB-5.5.31 localhost / Wildcard YES

Comments

lsolesen’s picture

lsolesen commented

The file seems present:

globen:/usr/lib/newrelic-php5/agent/x86# ls -al
total 28M
drwxr-xr-x 2 root root 4.0K May 14 10:06 ./
drwxr-xr-x 3 root root 4.0K May 14 10:05 ../
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20050922.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20050922-zts.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20060613.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20060613-zts.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20090626.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20090626-zts.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20100525.so
-rw-r--r-- 1 root root 3.5M Apr 30 21:00 newrelic-20100525-zts.so
globen:/usr/lib/newrelic-php5/agent/x86#
lsolesen’s picture

lsolesen commented

I tried (suggested in #1263602: New Relic Agent 3.0 integration, upgrade path and compatibility):

$ aptitude -f -y remove newrelic-php5 newrelic-daemon newrelic-php5-common newrelic-sysmond
$ aptitude -f -y purge newrelic-php5 newrelic-daemon newrelic-php5-common newrelic-sysmond
$ apt-get autoremove -y
$ mv /etc/newrelic /tmp/
$ barracuda up-stable

But that did not resolve the issue.

lsolesen’s picture

lsolesen commented 
globen:~# newrelic-daemon -v
New Relic local collector daemon version 3.4.5.167 ("ecstatic")
(C) Copyright 2009-2013 New Relic Inc. All rights reserved.
lsolesen’s picture

lsolesen commented

Hm, seems that only the x86 and not the x64 version is installted (and the x64 version shoud be installede, as it is a x64 server). However, it has recently been updated to a x64 kernel instead of a x86 server.

globen:/usr/lib/newrelic-php5/agent# ls
x86/

Where should the system be instructed to download the x64 version instead of the x86 version (I have done barracuda up-stable several times, but still the x86 version is downloaded).

omega8cc’s picture

omega8cc commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Please follow guidelines.

omega8cc’s picture

omega8cc commented
Issue summary: View changes

Added additional info.

lsolesen’s picture

lsolesen commented
Issue summary: View changes

Added more info.

omega8cc’s picture

omega8cc commented

You have "upgraded" i686 system to "x86_64" ? How this happened between Apr 10 and May 11 ?

omega8cc’s picture

omega8cc commented

Also, please never modify original request. You should add information in the comments only. Otherwise you are introducing chaos here.

omega8cc’s picture

omega8cc commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

If this is true that you have simply switched i686 system to x86_64 kernel, then you have made a major mistake and we can't do anything to help you, sorry. There is no such thing as smooth 'upgrade' from 32bit to 64bit without reinstalling many things (and probably breaking many things, which are not aware/compatible with dual mode) even if latest versions of Debian and Ubuntu are expected to support dual-mode (Multiarch), BOA doesn't support nor expect this kind of upgrade.

lsolesen’s picture

lsolesen commented

Cool. Thanks. It was Linode that suggested the upgrade because one of their migrations cause my box not to boot.

omega8cc’s picture

omega8cc commented

Uh, sorry if it sounded a bit harsh, but it is really a huge mistake and I can't comprehend how Linode could even suggest it for running system!

Supporting Multiarch mode is an interesting concept, but the fact it is possible from the modern OS point of view, doesn't mean that you are free to "upgrade" live system, while there can be tools and libraries installed which are not smart enough (yet) to be able to switch to 64bit just by running standard apt-get upgrade.

You could try to force PHP (and thus New Relic) rebuild by adding _PHP_FORCE_REINSTALL=YES in the /root/.barracuda.cnf file and running the upgrade again, but it doesn't guarantee anything at this stage.