Homestead: Apache service does not persist beyond SSH session. Web server does not persist after enabling Apache (via flip command or service start) and logging out of SSH session (or after Homestead halt then reload).

[adamdehaven]

Versions

• Vagrant: 2.1.1
• Provider: Virtualbox (5.2.12)
• Homestead: 7.6.0

Host operating system

Windows 10 64-bit

Homestead.yaml

---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: C:/Users/adehaven/PW/Sandbox
      to: /var/www/html/Sandbox

sites:
    - map: sandbox.test
      to: /var/www/html/Sandbox
      type: apache

databases:
    - sandbox

# blackfire:
#     - id: foo
#       token: bar
#       client-id: foo
#       client-token: bar

# ports:
#     - send: 50000
#       to: 5000
#     - send: 7777
#       to: 777
#       protocol: udp

Expected behavior

Apache service should remain enabled (and Nginx remain disabled), even after destroying SSH session, or running vagrant halt and then vagrant reload/up (with or without computer restart).

Actual behavior

I SSH into Homestead and run the flip command to stop Nginx and start Apache. All Apache sites run normally (Alternatively, I could SSH into Homestead and stop Nginx and start Apache). If I log out of my SSH session, Apache immediately stops working.

Steps to reproduce

1. SSH into Homestead homestead ssh
2. Run flip command (Alternatively, stop Nginx, and then run sudo service apache2 restart)
3. Test site running Apache -- everything should work normally.
4. Log out of the SSH session (Cmd + D)
5. Apache stops working. Refreshing the browser with the test site running doesn't work.
6. SSH into Homestead again homestead ssh and see that Apache is not still running.

According to the docs, the flip command "automatically determines which web server is running, shuts it off, and then starts the other server." It appears that this does not persist longer than the active SSH session.

Update

When I SSH into Homestead, if I run sudo service apache2 status I receive the following failure message:

 sudo service apache2 status
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: failed (Result: exit-code) since Fri 2018-05-25 01:46:50 UTC; 22s ago
  Process: 2463 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 2480 (code=exited, status=1/FAILURE)

May 25 01:46:15 homestead systemd[1]: Starting The Apache HTTP Server...
May 25 01:46:15 homestead apachectl[2463]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 12
May 25 01:46:15 homestead systemd[1]: Started The Apache HTTP Server.
May 25 01:46:50 homestead systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
May 25 01:46:50 homestead systemd[1]: apache2.service: Failed with result 'exit-code'.
lines 1-13/13 (END)

If I then run sudo service apache2 restart my sites load normally until I log out of the SSH session, at which point Apache apparently fails again.

[jtwee]

I'm having the same problem, and just to confirm the FQDN error isn't part of the issue, my status message is as follows.

vagrant@homestead:~$ sudo service apache2 status
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: failed (Result: exit-code) since Fri 2018-05-25 11:06:13 AWST; 7s ago
  Process: 2698 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 2715 (code=exited, status=1/FAILURE)

May 25 11:05:14 homestead systemd[1]: Starting The Apache HTTP Server...
May 25 11:05:14 homestead systemd[1]: Started The Apache HTTP Server.
May 25 11:06:13 homestead systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
May 25 11:06:13 homestead systemd[1]: apache2.service: Failed with result 'exit-code'.

[adamdehaven]

@breams are you also on Homestead v7.6.0 ?

[jtwee]

Yes I am.

[email protected] with vagrant box 6.0.0

[jtwee]

Also, I tried using both mod_php and php-fpm (both PHP 7.1) and had the same result for both.

[adamdehaven]

For now I have downgraded my setup to the following to resume normal operation:

• VirtualBox: v5.2.12
• Vagrant: v2.0.4
• vagrant box laravel/homestead v5.2.0
• Homestead v7.3.0

[svpernova09]

Have you tried without using the flip command?

vagrant destroy
vagrant up

Wait for the VM to boot, check if your site is working. (If you specify a site type of Apache you don't need to run the flip command since the script to install and configure Apache will also stop the nginx service.

[adamdehaven]

@svpernova09 When I run homestead up on a new machine (as in, after first destroying), the site(s) work. If I then run homestead halt and then homestead up Apache fails to start as shown above.

This isn't consistent though. Sometimes Apache fails even after a clean up command.

I've also tried manually stopping Nginx and starting Apache (not using the flip command), with the same result.

Edit: I typically don't use the flip command as Homestead typically runs Apache. I'm almost positive it has to do with upgrading to recent versions of the vagrant box and/or Homestead version.

[jtwee]

I don’t use flip personally, I have my sites set as Apache in my Homestead.yml file so to get it started I have to run ‘sudo service apache2 start’.

I’m not really willing to destroy my environment again seeing as I had to rebuild it when I upgraded to 6.0.0. And given that this is a fresh install of that box I’m not sure destroying and rebuilding would help anyway.

For now my workaround is to leave an ssh session running at all times, which isn’t a problem for me.

[svpernova09]

I’m not really willing to destroy my environment again seeing as I had to rebuild it when I upgraded to 6.0.0. And given that this is a fresh install of that box I’m not sure destroying and rebuilding would help anyway.

You should never have to worry about destroying the vagrant box. The VM is not your pet, it's cattle. At most you should have to dump your DBs, destroy, up, and then import your dbs (or run your migrations) and you should be back up and running. If this isn't the case you need to revisit how tightly coupled your application is to the development environment.

[jtwee]

Edit: In the cold light of day I should have just shut up. Apologies for not doing so.

[svpernova09]

That awfully prescriptive of how I “should” be using something.

You're getting awfully defensive which means I struck a nerve. I apologize if I came across that way. You're completely free to use the tool however you want but don't get upset when someone points out that you're not using the tool to it's fullest potential.

Are you saying that my use case is invalid and therefore this isn’t a bug?

Not at all, I'm saying if you can run destroy and up and maybe a DB import command, you're not using the Homestead tooling to it's fullest advantage and creating more work for yourself.

I would prefer to keep this thread on the topic of Apache behavior. If you'd like to chat more you can find me on Freenode as joepferguson or in #homestead-dev on Larachat Slack.

[adamdehaven]

@svpernova09 Sooooo.... back to Homestead and this Apache issue... lol.

Let me know if you need any additional info to help troubleshoot.

[svpernova09]

@adamdehaven

Thanks, I'll try to investigate later today / this weekend.

What's odd is I use Homestead + Apache for the day job and haven't seen this, but I'm also on MacOS, and I know Windows has had some vagrant issues, but it isn't Apache related

[jtwee]

Yeah, sorry bout that, I’m immensely frustrated at the projects I’m working on, and this was just easy to get riled at.

I would be happy to do some testing on a clean install if that helps.

I’m running macOS / virtualbox also.

[adamdehaven]

@breams FYI if you do a dump of all of your Homestead databases (you should probably back up from time to time anyway if you're like me and make, "mistakes"), running destroy and then up is trivial since you can import your DBs back in again as soon as the new box is provisioned.

[svpernova09]

@adamdehaven (and anyone else experiencing this issue) please run apache2ctl configtest from inside the VM and paste the results here for me.

[svpernova09]

@breams Can you share your Homestead.yaml please

[jtwee]

@svpernova09 Here's my Homestead.yaml

Homestead.yaml

---
ip: "10.10.10.10"
hostname: "homestead.test"
memory: 2048
cpus: 2
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/dev/sites
      to: /home/vagrant/code

sites:
    - map: homestead.test
      to: /home/vagrant/homestead.test
      type: apache
      php: "7.1"
    - map: memberpress.test
      to: /home/vagrant/code/memberpress.test/public
      type: apache
      php: "7.1"
    - map: support.wintech.test
      to: /home/vagrant/code/support.wintech.test/public
      type: apache
      php: "7.1"
    - map: wintech.test
      to: /home/vagrant/code/wintech.test
      type: apache
      php: "7.1"
    - map: wp.test
      to: /home/vagrant/code/wp.test/public
      type: apache
      php: "7.1"

databases:
    - memberpress_wp
    - support_wintech_wp
    - wintech_wp
    - wptest

[svpernova09]

@breams, @adamdehaven

I believe I have sorted this out, can you run echo 'Mutex posixsem' | sudo tee -a /etc/apache2/apache2.conf from inside the VM, then exit, then halt and vagrant up and see if Apache is running?

[jtwee]

@svpernova09 Adding Mutex posixsem does seem to fix it, yes. Tried a number of reloads and suspends and it seems to be persistent.

[adamdehaven]

@svpernova09 I'm not currently near my computer so I won't be able to test until super late tonight or more likely tomorrow.

[svpernova09]

@breams thanks! @adamdehaven no worries!

I'll get a release out with the fix in a few

[adamdehaven]

@svpernova09 so just for info, what was the issue?

I've been cautious lately in upgrading Homestead due to the quickly climbing version numbers. Maybe it's me, but they seem to be increasing at a more rapid rate lately?

[svpernova09]

@adamdehaven

Apparently Apache was failing to start on boot because there was no Mutex setting enabled. I found this issue by checking the apache error log.

RE: Upgrading Homestead

You should always use the latest base box and latest repo release (since that's all technically I'll ever officially support). The version numbers have been climbing rather quickly but I credit that to the somewhat strict semantic versioning we've been following. If I'm ever unsure whether to bump the minor or patch, I always bump the number to the left. So as in the fix here is v7.6.1, which is compatible with v7.6.x and should be mostly compatible with v7.x.x.

If you're using per project, you can safely lock Homestead at the major version (I use ^7 currently) and you should never worry that anything will break that a destroy & up won't fix. (If something does break that's a BC break that should be limited as much as possible). Not to say that a breaking change won't ever happen, but I try my best.

Homestead users should be confident a feature in v7.1.x will always be in v7.x, the behavior may change, but it will be there. When we remove or upgrade major features it should always be a major version bump to indicate a big change.

[svpernova09]

This issue is now resolved in https://github.com/laravel/homestead/releases/tag/v7.6.1 It will require a destroy or provision to fully implement. Alternatively you can run echo 'Mutex posixsem' | sudo tee -a /etc/apache2/apache2.conf to implement the fix without destroying but you will need to upgrade before you run up again after a destroy

[adamdehaven]

@svpernova09 I upgraded Homestead on my machine today and the Apache fix is working. However, now, when I run homestead halt I receive the following output (and Vagrant does not actually halt the VM)

$ homestead halt
C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:377:in `parse': (<unknown>): did not find expected key while parsing a block mapping at line 2 column 1 (Psych::SyntaxError)
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:377:in `parse_stream'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:325:in `parse'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:252:in `load'
        from C:/Users/adehaven/Homestead/Vagrantfile:28:in `block in <top (required)>'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/v2/loader.rb:37:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:126:in `block (2 levels) in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:119:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:119:in `block in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:116:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:116:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/vagrantfile.rb:28:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:777:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:777:in `vagrantfile'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:523:in `host'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:191:in `block in action_runner'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/action/runner.rb:33:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:510:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:759:in `unload'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/bin/vagrant:159:in `ensure in <main>'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/bin/vagrant:159:in `<main>'

[svpernova09]

Looks like it choked on your homestead yaml config file

--

• Joe Ferguson
  JoeFerguson.me
  MemphisPHP.org
  On May 30, 2018, 17:30 -0400, Adam DeHaven [e-mail], wrote:

@svpernova09 I upgraded Homestead on my machine today and the Apache fix is working. However, now, when I run homestead halt I receive the following output (and Vagrant does not actually halt the VM)
$ homestead halt
C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:377:in parse': (<unknown>): did not find expected key while parsing a block mapping at line 2 column 1 (Psych::SyntaxError) from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:377:inparse_stream'
from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:325:in parse' from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/psych.rb:252:inload'
from C:/Users/adehaven/Homestead/Vagrantfile:28:in block in <top (required)>' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/v2/loader.rb:37:inload'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:126:in block (2 levels) in load' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:119:ineach'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:119:in block in load' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:116:ineach'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/config/loader.rb:116:in load' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/vagrantfile.rb:28:ininitialize'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:777:in new' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:777:invagrantfile'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:523:in host' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:191:inblock in action_runner'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/action/runner.rb:33:in run' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:510:inhook'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/environment.rb:759:in unload' from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/bin/vagrant:159:inensure in

'
from C:/HashiCorp/Vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/bin/vagrant:159:in `

'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[adamdehaven]

Ok thanks. I'll try destroying and running up again. I may have inadvertently made a change to the yaml file without re-provisioning