We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Installation

Phalcon binary on virtual servers - errors when moved to new hardware

Hi

We just had an issue where the hardware of one of our cloud providers failed and they moved our virtual servers to a new hardware. Our phalcon binary though was incompatible with that server and caused the following errors and could not write to the MySQL database:

[pid 7169] AH00052: child pid 7251 exit signal Illegal instruction (4)

Recompiling phalcon on the servers fixed the issue but has opened us up to concerns about using phalcon on virtual servers.

Is phalcon using the settings of the virtualized server or the hardware layer of the device it is on? How can we compile it so phalcon is using the virtual server only so if the virtual server is moved to different hardware phalcon continues to function.

We are running ubuntu 14.04.



125.8k
Accepted
answer

Part of the advantages of virtualization is you should be able to move the server onto new hardware with no issue. This is done because the OS and software running in the OS (ie: Phalcon, and the zephir compiler) think they're running on certain hardware, but that certain hardware is being faked by the virtualization software. Like the Matrix.

The only way I can think of that moving a virtual server could have caused an error like this is if the hardware the virtual server thinks it's running on has changed. So a misconfiguration of the virtual environment.

To respond to this question directly: "Is phalcon using the settings of the virtualized server or the hardware layer of the device it is on?" - Phalcon has no way to access the underlying hardware layer. When it talks and interacts with the virtualized server, it thinks it IS talking to the hardware layer.



11.6k

for my previous Phalcon app, I've cloned the staging VM HDD (virtualbox) directly on a brand new HDD using dd ( howto available somewhere on the web), so my server was so working exactly as expected (but natively, no more inside a VM)...the dd copy is a long operation, so it's not suitable during dev or server conf, but at this time it's the best way I've found for final deployment.

It's especially usefull cause I can do server conf peacefully at home, and one time I have fully configured a server, I can snapshot the VM and use this later as a template for my next servers...



79.0k
edited Apr '16

This should not happen unless you changed architecture, which is very rare these days when x86 is predominant computer architecture. For instance, I can run PHP app on RISC architecture and then move it to standard X86 (amd64) architecture w/o any issues. BUT, I need to provide my app valid version of PHP binary (interpreter) to my app on new machine. So the code will run, but without proper compiled version for specific target architecture you just cannot migrate with copy-paste. So for phalcon this is the important part:

phalcon.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=43a0aa713aa9b28aaa2b3e89b5b67bb243808e0c, stripped

In this case, this binary will run only on amd64 machines. For other you need to recompile it.