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

FlightAware ADS-B Flight Tracking
1

I seem to only do things in Linux with enough frequency to remember that I’ve forgotten everything.

I dusted off a Pi (running Stretch) the other day and it has dump1090-fa on it, and it runs at boot. Cool. I want to change to using the mutabilityvariant (to take advantage of the native server and such), which I got working sans one conflict:

I can’t stop dump1090-fa from running.

I don’t see any script in init.d running dump1090-fa, nor is it referenced in rc.local.

Since it’s been a while since I set this all up, and thought I may be forgetting something I did check dump1090-mutability in init.d but it’s not executing a command to start -fa.

Any idea what I might be missing?

Thanks!

2

systemctl disable dump1090-fa

init system is no longer managed by init.d scripts but systemd.

dump1090-mutability normally has the builtin server disabled.
it is not an advantage.

dump1090-fa is basically the successor of dump1090-mutability as mutability is now working for FA (you might have read posts by obj)

1 Like
3

Thanks much! I learned a number of things from your reply (several of which lead me back to more research).

Now I’m just trying to get lighttpd to start. I’m getting a duplicate config variable error but am not seeing what the duplicates actually are. Hopefully I’m missing something dumb. Posted about it here: [Solved] Failing to start - Duplicate config variable in conditional 0 global: server.stat-cache-engine - I can't find a duplicate variable - Lighttpd - lighty labs

4

That is not multiple errors but 1 error.
I believe the error message is displaying something like a stack trace.

Anyway, your problem is too many configs enabled, do this to check:

ls /etc/lighttpd/conf-enabled

You basically only want one config file for dump1090-fa, not another one for dump1090 or dump1090-mutability.
You can always reenable configs with

sudo lighty-enable-mod dump1090

after deleting one of those files. (actually in conf-enabled are only links, not files)

Of course you will need sudo for making changes.

Also note in regards to the error message, it is not telling you where it is occuring twice, just that it occured twice.
It expects you to check all config files and find the double option yourself or delete the occurence it highlights.

5

You may also consider downloading a new image and starting from scratch.

Joe’s scripts are pretty good for doing it for you and supporting multiple feeders.
https://www.adsbreceiver.net/

6

Got it all running, thanks.

wiedehopf - I deleted (well, moved to a backup dir) all config files but one and that did it (after a port adjustment in the remaining config).

jonhawkes2030 - I likely will, but I’m trying to patch work problems as much as possible for the sake of my learning a bit more about what I am doing :slight_smile: Plus this box has other stuff running on it at the moment. I think I’m going to dedicate one box to just running AIS and ADS-B feeds, and then put another one up for other purposes.

Thanks to you both!

1 Like
7

You can leave multiple ones, just not different dump1090 config files.

Anyway you moved symbolic links, much like a http link just that they look like files and point to another file basically.
The actual config files are in /etc/lighttpd/conf-available
the lighty-enable-mod just creates the symbolic link.

No matter, glad that it works.
(dump1090-fa has actually two configurations belonging to it, you want both:
88-dump1090-fa-statcache.conf
89-dump1090-fa.conf
)

You can enable them by using:
lighty-enable-mod dump1090-fa-statcache

for example.
Hope that makes the system a little clearer.
lighty-disable-mod works as well instead of deleting the symlinks (doesn’t do anything different)

8

.
The above command needs to be reissued after every reboot.

A better method to disable the service, as given below. This will servive reboots.

sudo systemctl disable dump1090-fa.service

If later you want to enable it, give following command, which will also servive reboots.

sudo systemctl enable dump1090-fa.service

.

There was no need to delete anything, as folder “config-enabled” contains symlinks created by enable command. These symlinks will disappear from “config-enabled” by issueing disable command.

sudo lighty-disable-mod dump1090-fa 

sudo service lighttpd force-reload
9

Including or omitting the .service at the end does not make a difference.

systemctl stop would need to be repeated.

disable won’t stop, but it won’t start automatically on boot anymore.

Anyway i get the impression he is figuring it out :slight_smile:

10

@wiedehopf
I have never used disable/enable without .service at the end and was under impression that without .service, it will not servive reboots. Thanks for clarification.

After every diable or enable command, a reboot is required to implement it. Once implemented, it servives reboots

The start, stop, and restart commands are implemented instantly, but lost on reboot.

11

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
12

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.

13

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 ?

14

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
15

so how to avoid, at boot time, both feeders starting ?
(even if 2 receivers are present, 1 for ads-b, 1 for live-atc)

16

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
17

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

18

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)

19

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
20

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"