service docker start fails in WSL because the legacy SysVinit command cannot interact with Systemd as a service manager. You must use systemctl start docker instead, which correctly communicates with the PID 1 process. This article explains how to verify your environment and resolve the permission or path errors that often accompany this transition.
The Incompatibility of Legacy Commands
When you enable Systemd in Windows Subsystem for Linux (WSL), the underlying init system changes from the traditional SysVinit or Upstart to Systemd. This shift fundamentally alters how services are managed. The command service docker start is a wrapper script designed for older init systems. It attempts to execute scripts located in /etc/init.d/ or uses LSB (Linux Standard Base) headers that Systemd does not prioritize or recognize in the same way.
In a Systemd-enabled WSL environment, Docker runs as a unit managed by the Service Manager. When you invoke the legacy service command, it often results in a "command not found" error, a permission denied message, or simply no output at all because the initialization scripts have been deprecated or replaced by unit files. The Systemd daemon expects commands directed through its own API, specifically via systemctl. Using the wrong interface creates a disconnect between your user request and the actual state of the Docker daemon.
This issue is particularly common for users migrating from older Linux distributions or those accustomed to traditional server administration where service was the standard tool. However, in modern containerized environments within WSL, relying on legacy commands introduces unnecessary friction and potential failure points. It is crucial to align your operational commands with the active init system to ensure reliable service management.
Verifying Systemd Status in WSL
Before switching commands, you must confirm that Systemd is actually running and functioning correctly. Many users enable Systemd in their configuration but may encounter issues due to incomplete initialization or version mismatches. You can check the status of the Systemd manager by running:
systemctl --versionIf this returns a version number, Systemd is installed. To see if it is acting as PID 1, run:
ps -p 1 -o comm=The output should be systemd. If it outputs something else like bash or init, then Systemd is not fully active, and you may need to re-enable it via the Windows Registry or WSL settings. Additionally, checking the status of the Docker service itself provides immediate feedback on whether the service unit file is recognized:
systemctl status dockerThis command will show you if the service is loaded, enabled, and currently active. If the service is inactive or failed, the output will provide specific error codes or logs that can guide further troubleshooting. Understanding this baseline is essential before attempting to start the service manually.
Correct Command Syntax and Permissions
Once Systemd is confirmed, replace service docker start with systemctl start docker. This command sends a signal directly to the Systemd manager to activate the Docker socket and daemon. If you encounter permission errors, such as "Failed to start docker.service: Access denied," it usually indicates that your user lacks the necessary privileges to manage system services. In WSL, you typically need to run these commands with sudo:
sudo systemctl start dockerHowever, many WSL configurations allow non-root users to manage Docker if the Docker group permissions are set up correctly. Check if your user is part of the docker group by running:
groupsIf docker is not listed, add your user to the group using:
sudo usermod -aG docker $USERYou will need to restart your WSL session for group changes to take effect. This approach avoids the need for sudo for every Docker command while maintaining security boundaries. For more details on managing permissions in Linux environments, you might find Understanding Linux Permissions helpful.
Troubleshooting Common Failures
If systemctl start docker still fails, check the journal logs for detailed error messages. Run:
journalctl -u docker.service -eThis displays the most recent entries related to the Docker service. Common issues include missing network interfaces or conflicting port bindings. In WSL, the docker0 bridge interface sometimes fails to initialize properly, leading to startup failures. If you suspect network issues, refer to Troubleshooting Missing Docker0 Interface in Docker Desktop on WSL for specific fixes regarding interface creation.
Another frequent problem arises from Docker Desktop integration. If you are using Docker Desktop for Windows alongside WSL, the two might conflict if both try to manage the same daemon instance. Ensure that you are connecting to the correct Docker socket. Sometimes, restarting the WSL instance entirely resolves transient state issues:
wsl --shutdownAfter shutting down, restart your terminal. This forces WSL to reload all services, including Systemd and Docker. It is a clean slate approach that often resolves lingering lock files or zombie processes that prevent service startup.
Ensuring Persistence Across Reboots
Starting the service manually is only useful if it persists after a system restart. Use systemctl enable docker to ensure Docker starts automatically when WSL boots. This creates symlinks in the appropriate Systemd directories so that the service is triggered during the boot sequence. Without enabling, you will have to manually start Docker every time you open a new WSL session, which defeats the purpose of having it integrated into the init system.
Frequently Asked Questions
Why does 'service docker' work in Ubuntu but not in WSL?
Standard Ubuntu installations may still support SysVinit compatibility layers, whereas WSL relies heavily on direct Systemd interaction when enabled. WSL's lightweight nature means some legacy compatibility scripts are either stripped out or behave differently than in full desktop Linux distributions. Always prefer systemctl in WSL to avoid ambiguity.
Can I disable Systemd and go back to using 'service'?
While technically possible by disabling Systemd in WSL settings, it is not recommended. Modern tools and containers are optimized for Systemd. Disabling it may break other dependencies and revert to less efficient process management. Stick to systemctl for consistency and better resource handling.
What if systemctl says 'Unit docker.service not found'?
This indicates that the Docker package installation did not register its unit file correctly. Reinstalling Docker using the official repository scripts usually resolves this. Ensure you are using the latest version compatible with your WSL kernel version to avoid missing components.
Does Docker Desktop interfere with WSL Systemd?
Yes, if configured incorrectly. Docker Desktop can hijack the Docker socket or create conflicts if both instances try to bind to the same ports. Ensure you are using the WSL backend feature in Docker Desktop to integrate seamlessly rather than running separate daemons. See Optimizing WSL Docker Image Sizes on Non-Admin PCs for best practices on integration.
How do I check if Docker is actually running?
Use docker ps to list running containers. If it returns a list without errors, the daemon is active. Alternatively, systemctl is-active docker will return 'active' if the service is running. These are the most reliable indicators of success.