would the following in /etc/rc.local
be a proper solution (in presence of both feeders) ?
sudo killall dump1090-fa &
sudo service dump1090-mutability start &
exit 0
would the following in /etc/rc.local
be a proper solution (in presence of both feeders) ?
sudo killall dump1090-fa &
sudo service dump1090-mutability start &
exit 0
No.
dump1090-fa would get restarted after some time.
Just disable it with systemctl.
And if dump1090-mutability has a service file, which is required to use service … start, then just using systemctl enable dump1090-mutability is the much better solution.
Also by default rc.local is not even executed anymore, you need to change it to executable.
thanks @wiedehopf
meaning chmod 0755 rc.local
?
so is this better or proper ?
sudo systemctl disable dump1090-fa &
sudo systemctl enable dump1090-mutability &
or something else ?
You don’t need to put anything in rc.local at all.
Just running enable/disable once will enable/disable the automatic start on boot.
(of course if you have something in your rc.local to start it then it will still start even if it is disabled, but just don’t put anything there unless it doesn’t have a systemd service)
so how to avoid, at boot time, both feeders starting ?
(even if 2 receivers are present, 1 for ads-b, 1 for live-atc)
ok once again, to avoid a systemd service starting on boot:
systemctl disable xyz
disable and stop are NOT the same.
If you are already starting it via rc.local you will need to delete it form there to avoid the start of course.
ok. I take this to mean the very first time, both programs run, then user uses the command stop
to stop one of them at that instance,
then the command disable
which will continue after the subsequent reboot(s).
ED edited to reflect next posts
Yeah you got it i think
systemctl start/stop: immediate action (start on boot remains unaffected)
systemctl enable/disable: configure start on boot (no immediate action)
yeah, i used to think that -disable- includes stopping first, something that is running, now and for the future, but English not my first language so was not ‘obvious’ to me.
systemd
is a system and service manager for Linux.systemd
is compatible with SysV
and LSB init
scripts which were in use before Jessie (and still in use on some systems).sysvinit
by installing two packages: systemd
and systemd-sysv
service
file./etc/init.d/dump1090-mutability
.# using service command
sudo service dump1090-mutability start | restart | stop | status
# or directly using init file
sudo /etc/init.d/dump1090-mutability start | restart | stop | status
.
Since systemd consists of two packages systemd
and systemd-sysv, it allows using systemd commands for sysvinit through the package
systemd-sysv`:
sudo systemctl start | restart | stop | status dump1090-mutability
.
.
The dump1090-mutability daemon is enabled and disabled by following commands
# to enable
sudo update-rc.d dump1090-mutability defaults
# to disable
sudo update-rc.d -f dump1090-mutability remove
.
Even if dump1090-mutability daemon is enabled, it can be prevented to start at boot as follows:
(1) Open file /etc/default/dump1090-mutability
to edit.
(2) Change “yes” to “no” in following the line:
START_DUMP1090="yes"
.
sudo nano /etc/default/dump1090-mutability
# dump1090-mutability configuration file
# This is a POSIX shell fragment.
# You can edit this file directly, or use
# "dpkg-reconfigure dump1090-mutability"
# Set to "yes" to start dump1090 on boot.
START_DUMP1090="yes"
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.
Source: man systemctl
Huh. So disable/enable won’t work on it or does it translate that as well?
No idea, never tried.
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 ?
You can use start without having it enabled.
Don’t try to understand it by the meaning of “enable” in the English language.
Just think of enable/disable commands as (enable-autostart and disable-autostart)
pi@raspberrypi:~ $ sudo systemctl disable piaware
Synchronizing state of piaware.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable piaware
.
pi@raspberrypi:~ $ sudo reboot
.
pi@raspberrypi:~ $ sudo systemctl status piaware
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; disabled; vendor preset: Active: inactive (dead)
Docs: https://flightaware.com/adsb/piaware/
.
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
.
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
pi@raspberrypi:~ $ sudo reboot
.
…and if anyone wants to REALLY stomp the ability to run or not run the application, there is
systemctl mask/unmask <application>
above taken from and summarized in this thread
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