new user service should be enabled before starting
mrezzamoradi opened this issue · 4 comments
In Manually Starting and Stopping the Service section, if you don't enable the service before starting, it will return Failed to start python_demo_service.service: Unit python_demo_service.service not found. when you try to start the service.
my systemctl version is 237, and this happened to me as I was following your tutorial. So I enabled the service and it worked.
From the result of systemctl --user status python_demo_service in your tutorial, it seems you too had enabled the service before starting but forgot to mention it
I cannot reproduce this issue over here (Ubuntu 16.04, systemd 229). The new service starts fine using systemctl --user start python_demo_service for me, I don't need to enable it.
This is also how things are supposed to work (as far as I understand): Enabling/disabling a service is relevant for connecting/disconnecting the service from systemd targets. From the systemctl manpage:
enable UNIT..., enable PATH...
Enable one or more units or unit instances. This will create a set of symlinks, as
encoded in the "[Install]" sections of the indicated unit files. After the symlinks
have been created, the system manager configuration is reloaded (in a way equivalent
to daemon-reload), in order to ensure the changes are taken into account immediately.
Note that this does not have the effect of also starting any of the units being
enabled. If this is desired, combine this command with the --now switch, or invoke
start with appropriate arguments later. Note that in case of unit instance enablement
(i.e. enablement of units of the form foo@bar.service), symlinks named the same as
instances are created in the unit config enable UNIT..., enable PATH...
Enable one or more units or unit instances. This will create a set of symlinks, as
encoded in the "[Install]" sections of the indicated unit files. After the symlinks
have been created, the system manager configuration is reloaded (in a way equivalent
to daemon-reload), in order to ensure the changes are taken into account immediately.
Note that this does not have the effect of also starting any of the units being
enabled. If this is desired, combine this command with the --now switch, or invoke
start with appropriate arguments later. Note that in case of unit instance enablement
(i.e. enablement of units of the form foo@bar.service), symlinks named the same as
instances are created in the unit configuration directory, however they point to the
single template unit file they are instantiated from.uration directory, however they point to the
single template unit file they are instantiated from.
[...]
These mechanisms are covered in the Automatically Starting the Service during Boot part of the tutorial.
According to the error message you pasted, systemd doesn't find your service. If that is the case, then one of the previous steps in the tutorial should already have failed for you. In particular, what does the following command return for you?
systemctl --user list-unit-files | grep python_demo_service
systemctl --user list-unit-files | grep python_demo_service returns python_demo_service.service static and everything works according to the tutorial.
It's been a long time and I'm not sure how it happened. Thanks anyway for the great tutorial. I used it in my job 👍
Good to hear that things are working for you, @mrezzamoradi, and I'm glad you found the tutorial helpful.