docs: fix systemd unit example for casual hosting

[vanWittlaer]

The Issue

During shutdown of a Linux host, the ddev poweroff triggered in the ExecStop= directive of the provided sample systemd unit file left containers dangling around. This may result in file permission conflict, if a custom mySQL config file is provided.

How This PR Solves The Issue

Changes the After= from network.target to multi-user.target, which is fired later on startup and thus ExecStop= will be fired earlier on shutdown, leaving ddev poweroff more time to properly clean up.

Compare the traces from the systemd-analyze critical-chain ddev.service for the alternate settings:

# After=network.target

ddev.service +21.635s
└─basic.target @5.090s
  └─sockets.target @5.090s
    └─docker.socket @5.083s +5ms
      └─sysinit.target @5.056s
        └─cloud-init.service @4.063s +987ms
          └─systemd-networkd-wait-online.service @2.301s +1.757s
            └─systemd-networkd.service @2.250s +46ms
              └─network-pre.target @2.245s
                └─cloud-init-local.service @1.390s +852ms
                  └─systemd-remount-fs.service @545ms +72ms
                    └─systemd-journald.socket @464ms
                      └─-.mount @418ms
                        └─-.slice @418ms

# After=multi-user.target
                              
ddev.service +1min 7.167s
└─multi-user.target @6.749s
  └─docker.service @5.287s +1.459s
    └─containerd.service @4.865s +420ms
      └─basic.target @4.856s
        └─sockets.target @4.856s
          └─docker.socket @4.849s +5ms
            └─sysinit.target @4.831s
              └─cloud-init.service @4.100s +728ms
                └─systemd-networkd-wait-online.service @2.385s +1.709s
                  └─systemd-networkd.service @2.330s +51ms
                    └─network-pre.target @2.323s
                      └─cloud-init-local.service @1.440s +881ms
                        └─systemd-remount-fs.service @487ms +37ms
                          └─systemd-journald.socket @415ms
                            └─-.mount @378ms
                              └─-.slice @378ms

In particular the containerd.service and docker.service are required up prior to start of ddev.service, and in turn required to stay up until stop of ddev.service.

For more details see:

• Debian: https://manpages.debian.org/testing/systemd/systemd.special.7.en.html
• Ubuntu: https://manpages.ubuntu.com/manpages/focal/en/man7/systemd.special.7.html

Manual Testing Instructions

Setup a Ubuntu server, setup a ddev project with a custom mySQL file, restart server with shutdown -r 0.

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[rfay]

Thanks for this! I'll look forward to trying it on my own little VM that runs the little sites I maintain.

[rfay]

@vanWittlaer do you have a link to add about how you learned this? Please edit the PR to add it, thanks!

[vanWittlaer]

@vanWittlaer do you have a link to add about how you learned this? Please edit the PR to add it, thanks!

@rfay Thx for the hint - updated the PR description - is that what you meant?

[rfay]

Thanks for the update. I was also hoping for a link to Debian/Ubuntu/Systemd docs (at least in the PR description here) that explain how this works and perhaps why we should use this approach.

[vanWittlaer]

Links added to description.

[rfay]

Very nice. I was able to actually watch it happen after sudo reboot. That kicked me out right away but then ssh <host> and ddev list and I could see it bringing down each project.

Thanks for all the work on this! How is it working for you?

[vanWittlaer]

Hi @rfay thanks for merging, and for all the discussions and thoughts on this. Amazing you could reproduce it, must be a matter of milliseconds I thought. Anyway, looks to be stable now on my server.

[rfay]

It takes 10 seconds or more to ddev stop and my shutdown has to do 6-7 ddev stop so it was pretty easy to get back in there and see it. What surprised me is that sudo reboot kicked my ssh session out right away, but I was still able to ssh in again to look at this process.

Thanks for all your work on this!