I believe the addition of the Restart
option to your systemd
service file would ensure it gets start when not stopped by the systemctl stop
command:
Restart=[no | on-success | on-failure | on-abnormal | on-watchdog | on-abort | always ]
Info:
no: the default, the service will not be restarted
on-success: will be restarted only when the service process exits cleanly
on-failure: will be restarted when the process exits with a non-zero exit code
on-abort: will be restarted only if the service process exits due to an uncaught signal not specified as a clean exit status
on-watchdog: will be restarted only if the watchdog timeout for the service expires
always: will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by a signal, or hit a timeout
Restart=
Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.
Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned four signals), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abnormal, the service will be restarted when the process is terminated by a signal (including on core dump, excluding the aforementioned four signals), when an operation times out, or when the watchdog timeout is triggered. If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not specified as a clean exit status. If set to on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by a signal, or hit a timeout.

Image source
Source:
https://www.freedesktop.org/software/systemd/man/systemd.service.html
I ran into this when trying to get different types of machines running the latest version of Samba for time machine use as well.
One solution is to change the Type=notify to Type=simple. There is something about the new versions of Samba not playing nice with the way systemd handles process communication.
-Type=notify
+Type=simple
Then run systemctl daemon-reload and try to start er up again.
Best Answer
Short answer:
bad
: It showsSystemd Unit files
enablement statussystemd
you can check the enablement status using command:
if that unit file is a native systemd service then it will give output
enabled
,disabled
, etc. If it is not a native systemd service then it will give report a message like.but with command :
it gives status
bad
. (maybe it is because it is not able to print a complete message or developer decided to printbad
)Long Answer:
what are system unit files ?
Units are the objects that systemd knows how to manage. These are basically a standardized representation of system resources that can be managed by the suite of daemons and manipulated by the provided utilities. It can be used to abstract services, network resources, devices, filesystem mounts, and isolated resource pools. You can read in detail about systemd units here and here
example:
systemctl will check if
apache2
is a native unit or not. If not, then it will asksystemd-sysv-generator
to generate a file in unit format that provides support similar to native units. In the above example, the generated file is kept at/lib/systemd/system/apache2.service.d/apache2-systemd.conf
Note: you can find the generator at
/lib/systemd/system-generators/systemd-sysv-generator
and you can read more about thatMain point:
if we run the command :
you can see if units are native to systemd like
ssh
anddocker
, in the above output it will show onlyenabled
, and for units that are not native likeapache2
but still enabled it gives messages with that rather than printingbad
here because of this condition:Solution:
status
bad
will not create problem (i am not sure it depends) but it will not provide all functionality ofsystemctl
. you can wait for next release of thatpackage
that will natively supportsystemd
. or you can write unit file for your service or any other resource using given references.You can read in detail about systemd , systemctl and units using below References :
Systemctl
Systemd units and Here
Systemd