Docker新手求助：logspout容器systemd开机自启动故障排查

Hey there! Let’s walk through how to figure out why your logspout systemd service is failing on boot even though it works manually. The key here is that manual execution works, so the problem is almost certainly tied to timing, environment differences, or systemd-specific behavior. Here’s your step-by-step checklist:

1. Dig into systemd’s detailed service logs #

Systemd gives you granular logs that will tell you exactly why the service is failing. Run this command to view the full context of the failure:

journalctl -u logspout.service -xe

Look for clues like:

• Did the service try to start before your user data script finished updating the DOCKER_HOST config?
• Is there an error about not being able to connect to the Docker daemon or resolve the DOCKER_HOST IP?
• Are there permission issues reading your config file?

2. Verify your user data script’s execution timing and config output #

Your user data script modifies the config file, but systemd might be trying to start logspout before the script finishes running. To check this:

• First, confirm the config file actually has the correct DOCKER_HOST value after boot:

  cat /path/to/your/logspout-config-file
  

• Check if the script runs before the logspout service. If you’re using cloud-init, view its logs to confirm completion:

  journalctl -u cloud-init.service
  

• Ensure the config file has proper permissions so the systemd service can read it (e.g., owned by root:root with 644 permissions).

3. Fix systemd service dependencies and environment setup #

Systemd runs services in isolation, so it might be missing critical dependencies or environment variables that your shell has:

• Add Docker daemon dependencies: Make sure logspout only starts after Docker is fully ready. Update your service file to include:

  Requires=docker.service
  After=docker.service
  

• Load your config file correctly: If your DOCKER_HOST is stored in a config file, ensure the service loads it with an EnvironmentFile directive:

  EnvironmentFile=/path/to/your/logspout-config-file
  

• Match shell environment: Systemd uses a minimal PATH by default. If your Docker binary is in a non-standard location, add this to your service file:

  Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
  

4. Simulate systemd’s execution environment #

Your manual command runs in your shell’s environment, which might have variables systemd doesn’t. Test the command exactly as systemd would run it:

su -s /bin/sh -c "/path/to/your/logspout-start-command" root

If this fails, you’ve found an environment difference. If it works, move on to checking timing.

5. Ensure clean container state on each start #

Systemd might be trying to start logspout against a leftover or corrupted container. Add a pre-start command to your service file to clean up old containers:

ExecStartPre=/usr/bin/docker rm -f logspout || true

This ensures every start attempts to run a fresh container, even if the previous one didn’t clean up properly.

6. Check logspout’s own startup logs #

Even if systemd marks the service as failed, logspout might have generated logs before exiting. If the container exists briefly on boot, retrieve its logs:

docker logs logspout

If the container is deleted immediately, modify your service file to capture stdout/stderr to a file:

StandardOutput=file:/var/log/logspout.log
StandardError=file:/var/log/logspout.err.log

These files will show you exactly what logspout is complaining about (e.g., invalid DOCKER_HOST, connection timeouts).

内容的提问来源于stack exchange，提问作者SnazzyBootMan