Installation process for HHVM fails, causing EE installation to halt

On a newly provisioned server, I ran the following command:

ee stack install --web

…resulting in a big red error message

Oops Something went wrong!!

Check logs for reason tail /var/log/ee/ee.log & Try Again!!!

So I check the error log, as it says using the following command:

cat /var/log/ee/ee.log

According to the log:

dpkg: error processing /var/cache/apt/archives/hhvm_3.7.1~wheezy_amd64.deb (--unpack):
     subprocess new pre-installation script returned error exit status 100

I tried running the installation command again:

ee stack install --web

…same resulting error. The Installation process for HHVM fails, causing the installation to halt. I have included the relevant content of the ee.log file below:

Fetched 1,505 kB in 3s (420 kB/s)
Reading package lists...
2015-06-02 20:06:03,892 (INFO) ee : Installing packages, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  hhvm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/27.8 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 34696 files and directories currently installed.)
Unpacking hhvm (from .../hhvm_3.7.1~wheezy_amd64.deb) ...
invoke-rc.d: unknown initscript, /etc/init.d/hhvm not found.
dpkg: error processing /var/cache/apt/archives/hhvm_3.7.1~wheezy_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 100
Errors were encountered while processing:
 /var/cache/apt/archives/hhvm_3.7.1~wheezy_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
2015-06-02 20:06:04,825 (INFO) ee : Oops Something went wrong!!
2015-06-02 20:06:04,826 (ERROR) ee : Check logs for reason `tail /var/log/ee/ee.log` & Try Again!!!

Anyone know why this is happening?

Hello? Am I on my own here? Seven days and not one response?

Hello @bamajr,

Sorry for delayed reply. Which distribution you are using?

lsb_release -a

Also are you able to install HHVM manually ?

apt-get install hhvm

I’m running Debian 7 and I’m pretty sure that building HHVM on Debian 7 is no longer supported, due to the requirement of GCC 4.8 (newer than the version included in the distro). According to this link, GCC will have to be manually built, with each new Debian 7 installation.

Now knowing all of this, I still have to ask myself who thought HHVM was a good idea to begin with. Facebook’s claims of performance are seriously overshadowed by Facebook’s own blatent lack of performance, platform wide. They have yet to build (or buy) anything that proves performance is a key element for them. So why in the world would EE developers so suddenly jump on the HHVM bandwagon? Furthermore, why make it part of the default installation when such a widely adopted major distro (Debian 7) doesn’t support it? Lastly, why can’t it easily be removed, without crashing the server it is installed on?

Inclusion of HHVM seems to have been in poor form, no matter how I look at it.

HHVM is much faster when it works.

The key is “when it works”. That it why, we do not enable HHVM by default. That is why to use HHVM you need to specify --hhvm flag.

We have added note about it our release post - https://rtcamp.com/blog/easyengine-3-1-hhvm-pagespeed/#additional-notes-about-hhvm

So please stop using experimental feature or atleast complaining about them. If HHVM would have worked for all sites, we have made it default.

I forgot to give instruction for this, though they were part of release note.

For sites where you have enabled HHVM, you can run command:

ee site update example.com --hhvm=off

HHVM has been included, intentionally or unintentionally, with the EE install script. So, no, I won’t quit complaining about it. This inclusion causes installations to fail, time and time again. You can’t even get to the point where a website can have HHVM turned off.

I don’t want HHVM on my servers - PERIOD. So, how does one install EE without installing HHVM? How does one update a website without the EE updater/installer assuming you want HHVM installed?

Oh, and if I wanted to install applications and frameworks independently, using work-arounds and hacks, I wouldn’t want (or need) to use EE.

@bamajr Sorry. There is some misunderstanding here.

I was under impression that you have enabled hhvm on a site and it broke that site. This is common as many WordPress plugins are not WordPress ready.

I re-read complete thread to discover you are having problem during ee stack install --web. I did not anticipate this because every easyengine release gets tested on all platforms. I am not sure how test passed. It could be difference in debian 7 build. I will check this on Monday.

In any case, we will remove hhvm and pagespeed packages as part of default installation process.

Also we will add ee stack install --hhvm and ee stack install --pagespeed commands, including there remove and purge counterpart. These commands will be executed internally when someone turn on hhvm and pagespeed for a site respectively.

You can track progress here - https://github.com/rtCamp/easyengine/issues/564

On sidenote, may I know why don’t you use Debian 8? We always use latest OS ourself so rarely run into issues like this.

This issue DID originally start when I upgraded EE on an existing server, using the following command:

sudo ee update

…without any knowledge HHVM was going to installed, as a part of the update process (No, I didn’t catch it in the list of new packages being installed). As soon as the update installed HHVM, the associated website crashed. The website didn’t have much on it, so I immediately dumped the site and its server, spinning up a new VM instance and starting the process, identified above, in my initial post.

FYI: There is a lot of confusion about this issue throughout the rtCamp Community support area and other places on the internet. While manually installing HHVM may (emphasis on MAY) allow HHVM to work on Debian 7.8, I suspect the default inclusion of HHVM, with all EE update and EE install processes has a LOT to do with the confusion.

Does this mean HHVM will also be removed from the default EE update process?

Debian is my distro of choice, and I try to stay as current as possible, with their releases. However, I use the Google Developers Console, Compute Engine for all Easy Engine websites (soon all my websites will be migrated to EE on the Google Developers Console). As such, I only use their vetted and approved, preconfigured Debian images (as shown in the attached screenshot) and Debian 8 is not yet available.

I have submitted a request for Debian 8 and it may be preferable when using HHVM, but it isn’t yet available on the Google Developers Console and isn’t likely to show up in the next few days.

I was definitely confused as to why HHVM was included as a part of the default update and install process, as this immediately crashed sites on Debian 7.8

without any knowledge HHVM was going to installed

I am surprised that you did not bother to read release notes before running ee update command! If you continue like this, you may break things again.

An ideal way is to run major updates on staging server and see if all goes well there first.

Does this mean HHVM will also be removed from the default EE update process?

ee update process is different. What an update delivers depends on how old EE version is installed. But in this case, ee update will not install HHVM and pagespeed if EE already don’t have them. If someone has installed them already, they won’t be removed either.

Google Developers Console, Compute Engine

Sorry we never used that so really have no idea. We test on DigitalOcean only. It is not possible for us to test on each hosting company. But we will surely try to not break anything. Even if you run ee update without reading release note. :wink:

We hope to roll out fix for this before weekend. You may keep an eye on - https://github.com/rtCamp/easyengine/issues/564

Once again sorry for inconvenience you have faced.

Please be careful in your assumptions. What kind of admin would I be if I didn’t read update/release notes?

I did read the release notes and I was to understand that if HHVM was not installed, it would NOT be installed - but it was installed, anyway.

I’ll re-state that again for emphasis:

–> I did NOT already have HHVM installed, but HHVM was installed during the update anyway.

I can fully understand how it is not possible to test on every hosting company. I didn’t assume or expect that you did. However, that doesn’t make my point any less viable.

You asked why I didn’t use Debian 8. I answered you. If a host company, the size of Google isn’t offering Debian 8 as an approved option, I’m sure there is a reason and I’m sure they aren’t the only ones holding back.

I did NOT already have HHVM installed, but HHVM was installed during the update anyway.

Installing HHVM and enabling it are two different things. Unless HHVM is enabled, no request will be sent to HHVM, even it is installed.

…If a host company, the size of Google isn’t offering Debian 8…

We don’t use Google or Azure. So why should we spend money to test there? This has to been done by community or users like you. It will be really good if you test major releases on staging server. I hope Google provides way to create replicas easily.

We test only on DigitalOcean, Linode and Amazon AWS. It cost us to test each release but we use these three companies so it’s fine.

Sorry but we cannot test on Google, no matter how big they are! But we are planning to make testing easy so community member, if they wish to pay for testing with their favorite hosting companies, can test easily.

There seems to be a language gap here…

At the time I reported this issue, I did NOT already have HHVM installed. However, not only was HHVM installed during the update process, it was automatically enabled. I’m not sure how much clearer I can be. This issue seems to have been resolved in later releases, though I’m still scared to run the EE Update command.

Personally, I don’t like HHVM and refuse to use it. I can’t see how anyone can get on board with anything pushed by Facebook. Facebook likes to cite speed and efficiency, but is actually quite clunky, cumbersome, inefficient and slow. Why in the world would I want to use one of their garbage technologies on my servers?

As for which hosts you use…

I could care less what host you use for your own work or in your testing. However, a seemingly large assumption has been made, on the part of your development group, that what you may have access to on DigitalOcean, Linode and Amazon AWS is automatically available to every other host. Features were even included, with the default installation, assuming that when Debian was used, it was Debian 8.

This isn’t about a personal hosting preference. This is about a ridiculous flaw in the EE development process, assuming everyone who uses Debian, automatically updates to Debian 8 as soon as it is available, and then using the assumption to install and enable features, not supported on Debian 7. This is not a sound dev process and most people who do things like this, in other communities become the butt of all kinds of jokes. I assume EE has not, simply due to the fact that it is your own open source project.

Finally, I’d be happy to pay for a testing environment for you (putting my money where my mouth is, so to speak), on Google Developers Console. I know it isn’t possible for any one team to test on every hosting platform our there, but it seems many teams (including yours) don’t take the Google Platform seriously. So, I’m offering the opportunity to use it, at my cost.

I really like to re-highlight that HHVM used to get installed automatically only. Not enabled.

In your case, you reported that because of some bug HHVM could not be installed (you gave this link as ref - https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-Debian-7 ) and we failed to anticipate that but which created problem for you.

HHVM was never set to enable automatically. You can seriously check codes on github and I am sure you won’t find any code in update script which enabled HHVM automatically.

We ourself cannot use HHVM on our sites as enabling it by default is not even on roadmap for long time.

About testing with hosting

Thanks for offering Google Console test. I will check with developer team to see if we can have a standard script which people are run with their hosting company.

Till then I request you to simply create a staging server and test update before. We have a release lined up in next 24 hours only.

Again we learned from our problem you have faced, and in upcoming release tried to avoid more than needed in update script.

About Debian 7/8 Issue

It really worked on DigtialOcean, Linode and AWS. We tested again when you reported issue. Even if test Google, there are 1000s of VPS and Dedicated sever provider who can still run into issues.

In fact, I checked again right now and on DigitalOcean, with Debian 7. It has gcc 4.7.x but HHVM gets installed. Isn’t this shocking and contradicting with HHVM docs itself?

I am really feeling clueless has how can we catch such things before they transpire into issues. I am sorry to say such issues are out of our control. All we can do is improve/fix when issues gets reported. Like we delayed installing HHVM when we got to know about your issue.

Development Process

I will be really happy to follow a particular process if you believe that can avoid issues like this. Creating issues for anyone is not objective of any project.

Our community is very small in terms of contributors. There is hardly anyone contributes codes or config tweaks. Very few users give support to others.

So in this situation any input or suggestion to improve EasyEngine is more than welcome. :slight_smile:

I have three Google Developers Console Projects utilizing EE and a minimum of 10 VPS within those projects running EE. That may not make me an expert, but I understand the value in supporting the rtCommunity you have built, by contributing back. Right now, I choose to do so as a user giving support to others and will continue to do so, as long as I have knowledge to contribute.

I know its not realistic to “catch all the issues before they exist” - that just isn’t how development works. However I don’t understand why HHVM needs to be a mandatory part of EE, at all! Why not remove it completely and let it be installed by EE users, as needed or for experimental use?

You already have:

ee stack install --all

…and:

ee stack install --web

…and:

ee stack install --utils

…and:

ee stack install --admin

…why not leave HHVM out of EE unless someone runs:

ee stack install --hhvm

???

I’m not saying I won’t ever use it - too many people report significant performance improvements with it as opposed to without it. However, thus far, ALL of my experiences with it have been a flop!

TRUE - I am a very stubborn Debian user and Debian is notorious for sticking with something longer than it should, even when other “better” options are available. But it seems to me, that something like HHVM should be an ADD-ON and not something EE installs by default.

If a person doesn’t want to use HHVM, why would they want HHVM installed at all, even if it isn’t being used?

If my suggestion (above) was used, for the installation of HHVM:

ee stack install --hhvm

…then maybe WordPress could be installed and configured to use HHVM with something like:

sudo ee site create example.com --wpsubdir --w3tc --hhvm

Just a thought!

DISCLAIMER: Some of the commands I’ve written above, are NOT working commands and are only listed as suggestions for future EE development.

I’m happy to set up a dedicated Google Developers Console Project for the EE Dev Team. I can set it up as early as today. I’m happy to pay for and manage it. I’m also happy to provide your team access to it, if need be, or your team can send me instructions on what to test and how to test it. I can even grant “ownership” level access permissions to it.