[SOLVED] antiX OS: dump1090-fa fails due to missing Systemd

jaymot · 2022-07-20T23:09:49.429Z

It’s antiX not Anti-X. The antiX delevoper’s attitude about systemd is “never had it, never will.” Rather than trying to change either the distro or dump1090-fa, just use a different distro. There are hundreds to choose from.

abcd567 · 2022-07-20T23:42:44.113Z

jaymot:

Rather than trying to change either the distro or dump1090-fa, just use a different distro. There are hundreds to choose from.

This experiment was not meant to use antiX as OS for ADS-B. This experiment was meant to find out:

(1) Why some apps work on both Systemd as well as SysVinit, while some others work only on Systemd.

(2) Is there a workaround available?

abcd567 · 2022-07-21T01:05:52.479Z

jaymot:

It’s antiX not Anti-X.

Thanks, corrected the spelling.

jaymot:

The antiX delevoper’s attitude about systemd is “never had it, never will.”

is there any justification/advantage of this attitude, or is it due to intolerance to change and stubborness?

jaymot · 2022-07-21T02:05:12.831Z

Developers of Linux distros make certain decisions about what to include and what to omit. In this case the dev chose to use a different init system. I think it’s SysV init but 'm not 100% sure.

Apparently dump1090-fa comes with only a systemd service script file. You would have to write an init.d sript for dump1090-fa, or ask the FlightAware devs to include one with the app so it can work with either init system.

abcd567 · 2022-07-21T02:44:34.222Z

jaymot:

You would have to write an init.d sript for dump1090-fa,

This I have already done BEFORE creating the current thread, but it failed.
Below is what I have done:

sudo nano /etc/init.d/dump1090-fa.sh   
## Added required init code (please see below)

sudo chmod +x /etc/init.d/dump1090-fa.sh  

sudo update-rc.d dump1090-fa.sh defaults  

sudo /etc/init.d/dump1090-fa.sh start

The contents of the init file /etc/init.d/dump1090-fa.sh are as follows:

#!/bin/bash
### BEGIN INIT INFO
#
# Provides:		dump1090-fa
# Required-Start:	$remote_fs
# Required-Stop:	$remote_fs
# Default-Start:	2 3 4 5
# Default-Stop:		0 1 6
# Short-Description:	dump1090-fa initscript

#
### END INIT INFO
## Fill in name of program here.
PROG="dump1090-fa"
PROG_PATH="/usr/share/dump1090-fa/start-dump1090-fa"

PIDFILE="/var/run/dump1090-fa.pid"

start() {
      if [ -e $PIDFILE ]; then
          ## Program is running, exit with error.
          echo "Error! $PROG is currently running!" 1>&2
          exit 1
      else
          ## Change from /dev/null to something like /var/log/$PROG if you want to save output.
          cd $PROG_PATH
          ./$PROG $PROG_ARGS 2>&1 >/dev/null &
          echo "$PROG started"
          touch $PIDFILE
      fi
}

stop() {
      if [ -e $PIDFILE ]; then
          ## Program is running, so stop it
         echo "$PROG is running"
         killall $PROG
         rm -f $PIDFILE
         echo "$PROG stopped"
      else
          ## Program is not running, exit with error.
          echo "Error! $PROG not started!" 1>&2
          exit 1
      fi
}

## Check to see if we are running as root first.
## Found at http://www.cyberciti.biz/tips/shell-root-user-check-script.html
if [ "$(id -u)" != "0" ]; then
      echo "This script must be run as root" 1>&2
      exit 1
fi

case "$1" in
      start)
          start
          exit 0
      ;;
      stop)
          stop
          exit 0
      ;;
      reload|restart|force-reload)
          stop
          start
          exit 0
      ;;
      **)
          echo "Usage: $0 {start|stop|reload}" 1>&2
          exit 1
      ;;
esac
exit 0

abcd567 · 2022-07-24T04:19:39.725Z

OK, succeeded in creating a file /etc/init.d/dump1090-fa with code given below.

@obj : The dump1090-fa is running and producing data, but skyaware map is without any aircraft. Any thoughts?

The dump1090-fa’s SysVinit file `/etc/init.d/dump1090-fa` was not available in the installed package. It was created by me using following code.

The code is from /etc/init.d/piaware, but it did not work out-of-the-box. I had to use following options instead of original ones:

INSTEAD OF: --pidfile $PIDFILE
USED: --make-pidfile --pidfile $PIDFILE

INSTEAD OF: --logfile $LOGFILE
USED: --output $LOGFILE

INSTEAD OF: --exec $DAEMON
USED: --exec $STARTFILE -- $WRITEJSON

WHERE:
STARTFILE=/usr/share/dump1090-fa/start-dump1090-fa
WRITEJSON=" --write-json %t/dump1090-fa"

#!/bin/bash

### BEGIN INIT INFO
# Provides:          dump1090-fa
# Required-Start:    $network $remote_fs $syslog $time
# Required-Stop:     $network $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: RTL SDR Receiver/Decoder.
# Description:       ADS-B receiver running dump1090
#
### END INIT INFO

. /lib/lsb/init-functions

DAEMON=/usr/bin/dump1090-fa
STARTFILE=/usr/share/dump1090-fa/start-dump1090-fa
WRITEJSON=" --write-json %t/dump1090-fa" 
PIDFILE=/var/run/dump1090-fa.pid
LOGFILE=/var/log/dump1090-fa.log
RUNAS=dump1090

test -x $DAEMON || exit 5

start() {
    log_daemon_msg "Starting adsb-decoder" "dump1090-fa"

    # ensure the logfile exists with the right ownership
    # so dump1090-fa can modify it
    touch $LOGFILE
    chown $RUNAS $LOGFILE
    chmod u+rw $LOGFILE

   
    /sbin/start-stop-daemon --start --output $LOGFILE --make-pidfile --pidfile $PIDFILE --oknodo --background --user $RUNAS --chuid $RUNAS --exec $STARTFILE  -- $WRITEJSON
    status=$?
    log_end_msg $status
    return
}




stop() {
    log_daemon_msg "Stopping decoder" "dump1090-fa"
    /sbin/start-stop-daemon --stop --quiet --oknodo --user $RUNAS --pidfile $PIDFILE --exec $DAEMON --retry 5
    log_end_msg $?
    rm -f $PIDFILE
    return
}



case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop && sleep 2 && start
        ;;
    status)
        status_of_proc $DAEMON "decoder dump1090-fa "
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 2
        ;;
esac

image802×602 151 KB

abcd567 · 2022-07-24T20:53:50.212Z

The error message shown inside red rectangle in screenshot of PuTTY below keeps on recurring.
Not sure, but seems this is reason for a blank map and blank aircraft table in skyaware map.

What is causing this error? Has anyone any idea?

abcd567 · 2022-07-25T02:56:20.566Z

@obj

[ S O L V E D ]

Finally Solved All Issues

(A) The sky aware map was empty because I have missed following piece of code in file `/etc/init.d/dump1090-fa` :

(1) Missing in variable declaration:
RUNDIR=/var/run/dump1090-fa

(2) Missing inside function start()

    # create $RUNDIR for json files aircraft.json and history.json
    mkdir -p $RUNDIR
    chown $RUNAS $RUNDIR
    chmod 0755 $RUNDIR

(B) After above additions the aircraft on map & table appeared, but following warning kept repeating

Solved it by following workaround:

Replaced variable:
WRITEJSON=" --write-json %t/dump1090-fa"

By variable:
WRITEJSON=" --write-json /var/run/dump1090-fa"

Final fully working, bug-free file `/etc/init.d/dump1090-fa`:

#!/bin/bash

### BEGIN INIT INFO
# Provides:          dump1090-fa
# Required-Start:    $network $remote_fs $syslog $time
# Required-Stop:     $network $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: RTL SDR Receiver/Decoder.
# Description:       ADS-B receiver running dump1090
#
### END INIT INFO

. /lib/lsb/init-functions

DAEMON=/usr/bin/dump1090-fa
STARTFILE=/usr/share/dump1090-fa/start-dump1090-fa
WRITEJSON=" --write-json /var/run/dump1090-fa"
RUNDIR=/var/run/dump1090-fa
PIDFILE=/var/run/dump1090-fa.pid
LOGFILE=/var/log/dump1090-fa.log
RUNAS=dump1090

test -x $DAEMON || exit 5

start() {
    log_daemon_msg "Starting adsb-decoder" "dump1090-fa"

    # ensure the logfile exists with the right ownership
    # so dump1090-fa can modify it
    touch $LOGFILE
    chown $RUNAS $LOGFILE
    chmod u+rw $LOGFILE

    # create $RUNDIR for json files aircraft.json and history.json
    mkdir -p $RUNDIR
    chown $RUNAS $RUNDIR
    chmod 0755 $RUNDIR

    /sbin/start-stop-daemon --start --output $LOGFILE --make-pidfile --pidfile $PIDFILE --oknodo --background --user $RUNAS --chuid $RUNAS --exec $STARTFILE  -- $WRITEJSON  
    status=$?
    log_end_msg $status
    return
}

stop() {
    log_daemon_msg "Stopping decoder" "dump1090-fa"
    /sbin/start-stop-daemon --stop --quiet --oknodo --user $RUNAS --pidfile $PIDFILE --exec $DAEMON --retry 5  
    log_end_msg $?
    rm -f $PIDFILE
    return
}



case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop && sleep 2 && start
        ;;
    status)
        status_of_proc $DAEMON "decoder dump1090-fa "
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 2
        ;;
esac

image802×600 180 KB

image741×429 52.4 KB

jaymot · 2022-07-25T04:20:55.142Z

You should package it as a .deb file and put it on GitHub or somewhere in case someone else needs a systemd-free version of dump1090-fa.

abcd567 · 2022-07-25T08:07:44.557Z

jaymot:

put it on GitHub or somewhere in case someone else needs a systemd-free version of dump1090-fa.

“Linux distributions without systemd”

The following 53 OS are in this category.


0–9
* 4MLinux
A
* Absolute Linux
* Alpine Linux
* Android-x86
* AntiX
* ArchBang
* Artix Linux
* Austrumi Linux
C
* Calculate Linux
* ChromeOS
* Chromium OS
* CRUX
D
* Damn Small Linux
* DD-WRT
* Devuan
* DivestOS
* Dragora GNU/Linux-Libre
* Dyne:bolic
E
* /e/ (operating system)
* Endian Firewall
F
* Funtoo
G
* GNU Guix System
* GoboLinux
* GrapheneOS
H
* Hyperbola GNU/Linux-libre
I
* IPFire
K
* Knoppix
* Kwort Linux
L
* LibreCMC
* LiMux
* LineageOS
* Linux From Scratch
M
* Maemo
* MX Linux
N
* Nanolinux
O
* OpenWrt
P
* Parted Magic
* PCLinuxOS
* Pentoo
* Porteus (operating system)
* PostmarketOS
* Puppy Linux
R
* Replicant (operating system)
S
* Salix OS
* Slackware
* SliTaz
* Source Mage
T
* Tiny Core Linux
V
* VectorLinux
* Vine Linux
* Void Linux
Z
* Zenwalk
* Zeroshell

jaymot · 2022-07-25T08:21:46.175Z

abcd567:

|M|
|* Maemo|
|* MX Linux|

Clarification: MX Linux includes systemd and makes it available in its GRUB boot menu for those who prefer it or use apps that require it, it just defaults to SysV init. It’s been my daily driver OS for going on 4 years.

abcd567 · 2022-07-25T08:50:59.705Z

It is not clear to me what is disadvantage of systemd because of which so many OS are still avoiding it and staying with older SysVinit

jaymot · 2022-07-25T09:10:13.359Z

I have no idea why but some people object to systemd for whatever reason. Me, I just want my computer to boot up, run, and let me do what I want to do I don’t care what init system it uses.

obj · 2022-07-25T12:31:21.152Z

It’s unusual to have a debian-like system that does not have systemd, and that’s the only packaging we support, so supporting sysvinit scripts has not been a high priority.

That said I don’t have any objections to a PR to add a sysvinit script, if it is equivalent to what the systemd service does (i.e. accepts the same config etc) and plays nicely with regular Debian.

abcd567 · 2022-07-25T18:54:26.547Z

Quote from today’s PM by @AhrBee

On another topic

A small story from a long-retired grey-beard in this field -

Way back when we were forced to transition from SysV to systemd in the various flavors of unix that ran in our hosting business, I discovered (and documented) that when one wanted to shutdown/reboot, systemd simply ‘pulls the plug’ on process id 1 (the parent of all processes on the host), thereby killing everything that’s running, ungracefully, and unlike SysV, which had graceful shutdown processes with their init scripts. This meant that, with systemd, all our *nix customers’ applications that used databases were not shutting down cleanly (for one example of panic once it was realized). We put together a process that prevented anyone from shutting down or rebooting a host before all applications that needed a graceful stop had finished. Even after constant communication about the changes, this angered and confused our systems engineers during maintenance and updates. It did prevent corruption (unless the system crashes). As far as I know, modern systemd still has that ‘feature’. In anything that uses a database at home, I still have a habit of having a custom shutdown script to gracefully close things before system halt or reboot. Having retired from too many years in this business, I have not much motivation to dive into the forensics of shutdown; corruption/failure (if it happens) is a minor inconvenience at home, and not lost time, money, productivity for customers.

obj · 2022-07-25T19:07:14.288Z

That’s… not what happens.

abcd567 · 2022-07-25T22:05:44.795Z

antiX-forum

no SystemD - advantages/disadvantages? - antiX-forum

Everyone here is aware that antiX doesn't have SystemD - but what are the advantages and disadvantages of not having it? I've noticed when comparing x64 editions, antiX19.4 consumes half the amount of RAM (when idling) than Debian10: e.g. idling at...

Est. reading time: 1 minute

abcd567 · 2022-07-26T06:21:58.181Z

Quora

abcd567 · 2022-07-27T19:13:35.637Z

jaymot:

put it on GitHub or somewhere in case someone else needs a systemd-free version of dump1090-fa.

Github - dump1090-fa-init.d

abcd567 · 2022-07-28T20:17:12.201Z

Tested the dump1090-fa init script installation from github on another Debian based OS “Devuan” which lacks systemd. Found works OK

https://www.devuan.org/
https://www.devuan.org/get-devuan

devuan_chimaera_4.0.0_amd64_desktop-live.iso

After installing dump1090-fa, installed dump1090-fa init file `/etc/init.d/dump1090-fa` by following method:

sudo wget -O /etc/init.d/dump1090-fa https://github.com/abcd567a/dump1090-fa-init.d/raw/main/dump1090-fa    

sudo chmod +x /etc/init.d/dump1090-fa 

sudo update-rc.d dump1090-fa defaults 

sudo /etc/init.d/dump1090-fa start 

sudo /etc/init.d/dump1090-fa status 

cat /var/log/dump1090-fa.log

image802×602 200 KB