That’s not really clear even when you speak English well
It’s explicitly mentioned in the manual page for systemctl:
enable UNIT
Enable one or more units or unit instances. […]
Note that this does not have the effect of also starting any of the units being enabled.
[…]
Enabling units should not be confused with starting (activating) units, as done by the start command. Enabling and starting units is orthogonal: units may be enabled without being started and started without being enabled. Enabling simply hooks the unit into various suggested places (for example, so that the unit is automatically started on boot or when a particular kind of hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds the socket (in case of socket units), and so on.
I had no idea of the manual, and hardly read any, anymore…
however from that (the manual) , I get the modus operandi, in simple terms, and in this order
enable = stand-by mode (be ready for ops)
start = operation mode
stop = go back to stand-by mode (terminate and be ready for ops)
disable = completely disable previous modes. (terminate permanently).
did I get it right ?
Synchronizing state of piaware.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable piaware
.
(1) Rebooted
pi@raspberrypi:~ $ sudo reboot
.
(3) Status after reboot. Did NOT start on reboot automatically.
This command will be required after every reboot, as long as it is disabled. If enabled again, will start automatically at reboot, and manual restart is not required.
pi@raspberrypi:~ $ sudo systemctl restart piaware
pi@raspberrypi:~ $ sudo systemctl status piaware
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; disabled; vendor preset:
Active: active (running) since Sat 2019-02-09 15:28:19 EST; 6s ago
Docs: https://flightaware.com/adsb/piaware/
Main PID: 724 (piaware)
CGroup: /system.slice/piaware.service
├─724 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusf
├─751 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localho
└─760 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --n
Feb 09 15:28:23 raspberrypi piaware[724]: Started faup1090 (pid 760) to connect
Feb 09 15:28:23 raspberrypi piaware[724]: piaware received a message from dump10
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): fa-mlat-client 0.2.1
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): Using UDP transport
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): Listening for Beast-
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): Listening for Extend
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): Input connected to l
Feb 09 15:28:23 raspberrypi piaware[724]: mlat-client(751): Input format changed
Feb 09 15:28:24 raspberrypi piaware[724]: piaware has successfully sent several
Feb 09 15:28:24 raspberrypi piaware[724]: mlat-client(751): Beast-format results
.
(5) Restored the system
pi@raspberrypi:~ $ sudo systemctl enable piaware Synchronizing state of piaware.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable piaware
Trivia: for those who might not be comfortable with the new-fangled way of managing Linux services on Intel/AMD-based CPUs (systemd), there is the antiX community that is dedicated to maintaining “things that aren’t broken don’t need fixing” and “keep it light and simple” mindsets (my opinion). Service management is still the ‘old’ way, providing a systemd-free lightweight Linux distribution for computers old and new. The latest distribution based on Debian Stretch (32-bit and 64-bit) may be found at https://mxlinux.org/. While I tried this personally, I wound up using the Raspberry Pi Desktop for PCs since I needed to be fluent in systemd (among other ‘new’ things) for work anyway. And for anyone interested in a very skinny operating system on their Rasperry Pi or other single board computer - check out DietPi
The mx-linux is NOT totally systemd free. By default, it boots to a systemd free os, but the grub menu has “advance option” through which one gets choice to boot with or without systemd. It is possible to change default to boot with systemd by editing grub.
Couple of months ago I have installed mx-linux on my x86 PC on VM, and installed dump1090-mutability, Piaware, FR24 feeder, Planefinder feeder and Radarbox24 feeder. Details are here.
There is another distro “StretchDog”, which also gives choice to boot with or without systemd. By default it boots without systemd,but this can be changed by editing file /boot/menu.lst