Dusted off the Pi and making changes - How is dump1090-fa starting?

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)

1 Like

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.

1 Like

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 :slight_smile:

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.

1 Like

systemd

  • The systemd is a system and service manager for Linux.
  • It is the default init system for Debian since Debian Jessie.
  • The systemd is compatible with SysV and LSB init scripts which were in use before Jessie (and still in use on some systems).
  • It can work as a drop-in replacement for sysvinit by installing two packages: systemd and systemd-sysv

dump1090-mutability

  • The dump1090-mutability does NOT have a service file.
  • Instead it has its sysvinit file /etc/init.d/dump1090-mutability.
  • Before systemd (i.e. before Jessie), it was controlled by following commands of sysvinit: (I think even with systemd present, these commands are still valid)
# 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 :slight_smile:

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 ? :wink:

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)

(1) Disabled

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

.

(1) Rebooted

pi@raspberrypi:~ $ sudo reboot
.

(3) Status after reboot. Did NOT start on reboot automatically.

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/

.

(4) Started manually by restart command.

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

pi@raspberrypi:~ $ sudo reboot

.

1 Like

…and if anyone wants to REALLY stomp the ability to run or not run the application, there is

systemctl mask/unmask <application>

:stuck_out_tongue_winking_eye:

image
above taken from and summarized in this thread

1 Like

Thanks a lot @AhrBee for posting this important info, and the link to the thread in askubuntu.com

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.

https://forum.flightradar24.com/threads/11137-How-to-Feed-Data-to-Multiple-Sites-A-Brief-Guide?p=111008&viewfull=1#post111008

.

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