You start a service on a server, but after a reboot it is stopped again. It is tempting to assume systemctl start made it run on future boots. Running now and being enabled for startup are separate states. Checking both can prevent unnecessary reinstalls or configuration changes.
systemctl start changes the current running state
Starting from an inactive, disabled service, start requests that it run now. enable changes its startup configuration; enable alone leaves the current service inactive.
start asks systemd to start the named unit immediately. demo-web.service below is an illustrative unit name. Check the exact name of the service you intend to manage before using these commands.
sudo systemctl status demo-web.service
sudo systemctl start demo-web.service
sudo systemctl status demo-web.serviceCompare the first and last status results. active (running) means the service process is running now. If the start job fails, read the error in status first. Changing boot enablement will not repair a startup failure.
start is not a request to reload new settings into an already running service. If it is already running, decide whether that service needs a supported reload or restart to apply a configuration change.
systemctl enable configures future startup
enable connects the unit to its configured startup targets so it can be activated during boot or another defined trigger. Do not interpret it as a command to start an inactive service immediately. The systemd systemctl manual explicitly distinguishes enablement from starting.
sudo systemctl enable demo-web.service
sudo systemctl status demo-web.serviceThe second command may still show the service as inactive. Check its enablement separately from its current activity. Run start as well if it is needed now. If you only want to configure the next boot while keeping a test service stopped, do not start it.
disable removes the enablement links; it does not necessarily stop a running service. Consider stop separately if it must cease immediately.
What should you check after a reboot failure?
Read status for both current activity and displayed enablement. If the service runs now but is not enabled, check the boot configuration. If it is enabled but stopped, investigate why startup failed.
sudo systemctl status demo-web.service
sudo journalctl -u demo-web.serviceLogs can show when and why the unit failed. A missing executable or unavailable file, working directory, or environment will not be fixed by repeating enable. These two commands narrow the cause; they cannot diagnose every service problem on their own.
Before restarting a production service, check whether it is serving requests and when interruption is acceptable. Plan a reboot test with its impact and recovery path in mind. Record status and logs, apply one change, then inspect the result so you can tell what helped.
Key takeaways: current activity and boot enablement differ
systemctl start requests that a unit run now; systemctl enable configures future activation, commonly at boot. After a reboot failure, inspect current status, enablement, and service logs. Repeating only enable after a startup error, or only start without boot enablement, leaves the underlying issue unresolved.
