Kplex on Raspberry Pi 4, Ubuntu 20.04

201 views
Skip to first unread message

James Starkey

unread,
Sep 9, 2020, 5:39:43 PM9/9/20
to kplex
I'm trying to bring up kplex on a Raspberry Pi 4 running 32 bit Ubuntu 20.04.  No problem building kplex, no problem running it from a command line, and no problem starting it manually from /etc/init.d/kplex (after I added root to the dialout group, that is).  But I have been able to get it started during boot.  Here is the output from systemctl status kplex:

jas@ais2:~$ systemctl status kplex
● kplex.service - LSB: Start kplex NMEA 0183 multiplexer
     Loaded: loaded (/etc/init.d/kplex; generated)
     Active: active (exited) since Wed 2020-09-09 17:27:26 EDT; 1min 24s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1742 ExecStart=/etc/init.d/kplex start (code=exited, status=0/SUCC>

Sep 09 17:27:26 ais2 systemd[1]: Starting LSB: Start kplex NMEA 0183 multiplexe>
Sep 09 17:27:26 ais2 kplex[1742]:  * Starting kplex multiplexer kplex
Sep 09 17:27:26 ais2 kplex[1742]:    ...done.
Sep 09 17:27:26 ais2 systemd[1]: Started LSB: Start kplex NMEA 0183 multiplexer.

Anyone have a clue?

Keith Young

unread,
Sep 12, 2020, 5:16:07 PM9/12/20
to kplex
- obviously check that kplex isn't running
- try running it from the command line: just "kplex -d5".  See if you get any clues from that
- If it's all running fine when you manually start and stop it but fails from systemd try moving /etc/init.d/kplex to /etc/init.d/kplex.bak, doing update-rc.d kplex remove, then symlink the unit file in /usr/share/kplex/kplex.service to /lib/systemd/system/ : some people have reported problems with dependencies when using legacy init scripts.  Do check the obvious error messages from kplex first though.

James Starkey

unread,
Sep 12, 2020, 5:23:00 PM9/12/20
to Keith Young, kplex
Thanks, but it always starts from a command line, and after some tweaking, usually but not always starts at boot.

How can I get it to report its exit reason in syslog?  

The documentation suggests that a space is needed between the -d switch and the debug level but your example suggests -d5 is correct.  I guess I should have looked at the code.

Still, it’s up and running and reporting to Marine Traffic; last time I had to manually start it.  But it’s on a UPC so rebooting should be a problem going forward, but I would like to have it start reliably on an unattended boot.

--


You received this message because you are subscribed to the Google Groups "kplex" group.


To unsubscribe from this group and stop receiving emails from it, send an email to kplex+un...@googlegroups.com.


To view this discussion on the web visit https://groups.google.com/d/msgid/kplex/c9ef256e-0c7d-42c6-8693-2e92e2ca6bcbn%40googlegroups.com.


--
Jim Starkey

Keith Young

unread,
Sep 13, 2020, 5:08:12 PM9/13/20
to kplex
How can I get it to report its exit reason in syslog?  

The documentation suggests that a space is needed between the -d switch and the debug level but your example suggests -d5 is correct.  I guess I should have looked at the code.

Add the debug flag (e.g. -d5) at the end of the invocation line in /etc/init.d/kplex, ie after "-o mode=background".  Through the  magic of getopt(3) -d5 and -d 5 should both work :-)

My money is on systemd starting kplex before the network is "ready".  And there's an interesting discussion of the idea that "ready" is an imprecise concept here:
Bottom line is systemd is probably starting kplex before some network services are available and you can either augment the auto-generated service files as described in the link above or remove the init file and use the kplex unit file:
Note that the one distributed with 1.4 has a typo.

Brett Marl

unread,
Jan 25, 2021, 10:09:11 PM1/25/21
to kplex
Keith - I think your instincts are correct here. I've just been trying to get a RPi3B with latest Raspian to start kplex on boot. With the init.d method I'm getting eth0 unavailable errors so it seems to be starting the service before the network layer is ready. I'm going to try moving to the systemd approach later this evening and will report back. 

Brett Marl

unread,
Jan 25, 2021, 11:56:22 PM1/25/21
to kplex
I tried the systemd config you have posted on github with Raspbian buster (latest) with a Pi 3B. The service attempts to start but bails due to "Interface eth0 has no suitable address" (see syslog below) In this configuration - eth0 is using DHCP - so the network layer is probably 'up' as far as Raspian is concerned but it hasn't got its lease yet from the router. 

I don't especially like this as a 'fix', but if I change your kplex.system file to add Restart parameters, systemd will fire it off again 15s later when the lease has been granted and it boots up perfectly. 

[Service]
Type=forking
PIDFile=/var/run/kplex.pid
ExecStart=/usr/bin/kplex -p /var/run/kplex.pid -o mode=background
KillMode=process
Restart=on-failure
RestartSec=15


Jan 25 20:39:08 raspberrypi systemd[1]: Pulling in kplex.service/stop from sysinit.target/stop
Jan 25 20:39:08 raspberrypi systemd[1]: Found redundant job kplex.service/stop, dropping from transaction.
Jan 25 20:39:15 raspberrypi kplex[463]: Interface eth0 has no suitable address
Jan 25 20:39:15 raspberrypi kplex[463]: Failed to initialize Interface _udp-id3
Jan 25 20:39:15 raspberrypi systemd[1]: kplex.service: Passing 0 fds to service
Jan 25 20:39:15 raspberrypi systemd[1]: kplex.service: About to execute: /usr/bin/kplex -p /var/run/kplex.pid -o mode=background
Jan 25 20:39:15 raspberrypi systemd[1]: kplex.service: Forked /usr/bin/kplex as 463
Jan 25 20:39:15 raspberrypi systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/kplex_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=35 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Jan 25 20:39:15 raspberrypi systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/kplex_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=36 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Jan 25 20:39:15 raspberrypi systemd[1]: kplex.service: Changed dead -> start

For the record, my kplex.conf looks like this:

[serial]
filename=/dev/serial0
direction=both
baud=38400
[tcp]
mode=server
port=10110
direction=both
[udp]
port=10021
device=eth0
type=broadcast



--
You received this message because you are subscribed to a topic in the Google Groups "kplex" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kplex/w9ZnesiPA90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kplex+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kplex/e174b09c-5bd6-464e-b6a4-f04824da81d3n%40googlegroups.com.

John W. Kitz

unread,
Jan 26, 2021, 8:27:14 AM1/26/21
to kplex

All,

 

Is it a good idea to begin with to use DHCP on a device which is acting as a server?

 

I'd answer that question with no. That noted as a newbie to all things relating to RPi's and Raspios, I recently installed kplex on an RPi3B with a dAISy HAT using DHCP to serve AIS messages to OpenCPN running on a Windows desktop and, much to my surprise I got it working relatively quickly following the documentation supplied by the respective vendors or, in the case of kplex, developers to the letter.

 

To get kplex to start automatically I used:

 

sudo update-rc.d kplex defaults

To stop kplex without rebooting run:

sudo service kplex stop

To start kplex without rebooting run:

sudo service kplex start

 

See http://www.stripydog.com/kplex/kplex.html.

 

Regards, Jk.

--

You received this message because you are subscribed to the Google Groups "kplex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kplex+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kplex/CAKqYLu2OXggqH24%3DE3BJzmbw0Omu7BT4T0z8ggDqZ-ZORaowUA%40mail.gmail.com.

Brett Marl

unread,
Jan 26, 2021, 12:47:43 PM1/26/21
to kplex
In general I’d agree that servers should be static but I’m not sure that is always the case nor should it be assumed. I can see plenty of reasons where DHCP might be acceptable. 

In any case - I think the interesting thing here is that a few people have reported issues with auto-starting kplex on a RPi and Keith went out of his way to  get systemd working assuming init.d was somehow the problem. I suspect regardless of which boot method you use the underling problem to kplex not launching an interface it uses is setup for DHCP vs static. Maybe this is reported more with Pi users as perhaps they know less about what they are doing (like me ;)) to assume they would need a static ip. 

Keith Young

unread,
Jan 26, 2021, 1:19:14 PM1/26/21
to kplex
I'm somewhat winging it as I claim no special love of or familiarity with systemd, but having perused this:
...I suspect that the unit file should have "network-online.target" rather than "network.target" in the Wants: line.  The downside of that would be that kplex configured to only service the loopback interface might be delayed in starting by lack of an address on an external interface.  Happy to listen to opinions on this but Brett, maybe you could try network-online.target instead of network.target and see if that has the desired effect?

Brett Marl

unread,
Jan 26, 2021, 5:56:28 PM1/26/21
to Keith Young, kplex
I tried adding "network-online.target", but get a difference error that is less obvious. There is a warning about legacy PID paths, but /var/run seems to be symlinked to /run. I can't tell is kplex is bailing due to not finding the PID it's looking for ( New main PID 350 does not exist or is a zombie) or some protocol error ( Failed with result 'protocol'.)

Also, FWIW - I am getting the same "eth0 has no suitable address" with the current configuration using systemd and a static ip address on eth0, so doesn't seem to be DHCP related. The only other slightly weird config I have - is that my wlan1 is setup as an access point using hostapd routing through eth0 (https://www.raspberrypi.org/documentation/configuration/wireless/access-point-routed.md) 

here's syslog output:
Jan 26 14:44:53 raspberrypi systemd[1]: /etc/systemd/system/kplex.service:7: PIDFile= references path below legacy directory /var/run/, updating /var/run/kplex.pid → /run/kplex.pid; please update the unit file accordingly.
Jan 26 14:44:53 raspberrypi systemd[1]: kplex.service: Changed dead -> failed
Jan 26 14:44:59 raspberrypi systemd[1]: /etc/systemd/system/kplex.service:7: PIDFile= references path below legacy directory /var/run/, updating /var/run/kplex.pid → /run/kplex.pid; please update the unit file accordingly.
Jan 26 14:44:59 raspberrypi systemd[1]: kplex.service: Changed dead -> failed
Jan 26 14:45:06 raspberrypi systemd[1]: Pulling in kplex.service/stop from shutdown.target/start
Jan 26 14:45:06 raspberrypi systemd[1]: Added job kplex.service/stop to transaction.
Jan 26 14:45:06 raspberrypi systemd[1]: Pulling in kplex.service/stop from sysinit.target/stop
Jan 26 14:45:06 raspberrypi systemd[1]: Found redundant job kplex.service/stop, dropping from transaction.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Passing 0 fds to service
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: About to execute: /usr/bin/kplex -p /var/run/kplex.pid -o mode=background
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Forked /usr/bin/kplex as 337
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Changed dead -> start
Jan 26 14:45:13 raspberrypi systemd[337]: kplex.service: Executing: /usr/bin/kplex -p /var/run/kplex.pid -o mode=background
Jan 26 14:45:13 raspberrypi systemd[1]: Received SIGCHLD from PID 337 (kplex).
Jan 26 14:45:13 raspberrypi systemd[1]: Child 337 (kplex) died (code=exited, status=0/SUCCESS)
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Child 337 belongs to kplex.service.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Control process exited, code=exited, status=0/SUCCESS
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Got final SIGCHLD for state start.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: New main PID 350 does not exist or is a zombie.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Setting watch for PID file /run/kplex.pid
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Trying to read PID file /run/kplex.pid in case it changed
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: New main PID 350 does not exist or is a zombie.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Failed with result 'protocol'.
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Stopping watch for PID file /run/kplex.pid
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Changed start -> failed
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Job 79 kplex.service/start finished, result=failed
Jan 26 14:45:13 raspberrypi systemd[1]: kplex.service: Unit entered failed state.
Jan 26 14:45:13 raspberrypi systemd[1]: Child 350 (kplex) died (code=exited, status=1/FAILURE)

this output was with this config:

# /etc/systemd/system/kplex.service
[Unit]
Description = NMEA 0183 Multiplexer
Documentation = http://www.stripydog.com/kplex/configuration.html
After=syslog.target network-online.target audit.service


[Service]
Type=forking
PIDFile=/var/run/kplex.pid
ExecStart=/usr/bin/kplex -p /var/run/kplex.pid -o mode=background
KillMode=process
#Restart=on-failure
#RestartSec=15

[Install]
WantedBy=multi-user.target


# my /etc/dhcpcd.conf
interface eth0
static ip_address=172.31.24.2/161
static routers=172.31.24.1

interface wlan0
    static ip_address=192.168.4.1/24
    nohook wpa_supplicant

# my /etc/kplex.conf
[serial]
filename=/dev/serial0
direction=in
baud=38400
[tcp]
mode=server
port=10110
direction=out
[udp]
address=172.31.255.255
port=10021
device=eth0
type=broadcast
direction=out

--
You received this message because you are subscribed to a topic in the Google Groups "kplex" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kplex/w9ZnesiPA90/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kplex+un...@googlegroups.com.

John W. Kitz

unread,
Jan 27, 2021, 5:58:27 AM1/27/21
to kp...@googlegroups.com, Brett Marl

Brett, et all,

 

Although I have quite an extensive background in IT, my experience is rather dated as well as limited when it comes to UNIX derivatives, so as I already noted, I am a newbie to all things relating to RPi's and Raspios. That noted I'd argue the letter "D" in the acronym DHCP most likely didn't end up there by chance. In fact, as many on this list are probably aware DHCP is an acronym for Dynamic Host Configuration Protocol, or in other words when designing the protocol the designers probably had hosts in mind that tend to roam in a (wired) network, i.e. they don't always connect to the same network wall socket or wireless access point.

 

So in that sense such hosts are, from a network perspective, dynamic in that they are moved around a network by their end users. They may connect to a network at someone's desk in the morning and in a conference room of another site of the same company in the afternoon, in doing so chances are that, from an IP-protocol perspective, such an end user device is going to need to use IP addresses in different subnets of the same company's network throughout the day, week, etc.

 

To remove the burden of manually assigning a new IP address and manually configuring it in every host every time it moves within a network a couple of clever dudes at some point in time conceived the DHCP protocol (https://tools.ietf.org/html/rfc2131#page-6).

 

As for your question and not knowing the specifics of what you're trying to achieve, but in general I'd say it's probably best to always first think about what role (client or server) one's end user device, in this case an RPi, is going to have before one starts to download, install and configure software. I.e. if the aim is to use an RPi as a cheap alternative to a PC like end user device it's OK to use DHCP. However, if one intends to use an RPi as a server that is going to serve one or more clients I'd opt for a statically rather than for a dynamically assigned and configured IP-address on the server.

 

I'm not saying you must, but I think you should (https://tools.ietf.org/html/rfc2119).

 

Obviously there are many different ways in which one can use an RPi. In addition an end user device like an RPi may be used to act as both server and client. That is to say I believe software like OpenCPN can also be installed on the same Pi that is receiving the AIS messages, so what would one do in such a case?

 

But in general I would stick with the rule of thumb of sorts that I described above.

 

Earlier this month someone pointed me to the following (I quote):

If you want to fix your LAN IP you do it by amending /etc/dhcpcd.conf adding the following lines (adjust to suit your environment):

# It is possible to fall back to a static IP if DHCP fails:

# define static profile

profile static eth0

static ip_address=192.168.1.7/24

static routers=192.168.1.254

static domain_name_servers=8.8.8.8 8.8.4.4

# fallback to static profile on eth0

interface eth0

fallback static_eth0

This way DHCP will work if plugged into a client switch port, but static IP will default when no DHCP is available.

Great for testing the box on one’s desktop before going live.

Amend your hostname by editing /etc/hostname and then adding the below to /etc/hosts.

I.e. if you call your machine ‘brett’ fix the /etc/hosts 127.0.1.1 line:

127.0.1.1 brett

 

(end of quote) 

 

I haven't tested it, but at first glance it seems to make sense, so I hope this helps.

 

Regards, Jk.

 

From: kp...@googlegroups.com [mailto:kp...@googlegroups.com] On Behalf Of Brett Marl
Sent: Tuesday, 26 January, 2021 18:48
To: kplex
Subject: Re: Kplex on Raspberry Pi 4, Ubuntu 20.04

 

In general I’d agree that servers should be static but I’m not sure that is always the case nor should it be assumed. I can see plenty of reasons where DHCP might be acceptable. 

 

In any case - I think the interesting thing here is that a few people have reported issues with auto-starting kplex on a RPi and Keith went out of his way to  get systemd working assuming init.d was somehow the problem. I suspect regardless of which boot method you use the underling problem to kplex not launching an interface it uses is setup for DHCP vs static. Maybe this is reported more with Pi users as perhaps they know less about what they are doing (like me ;)) to assume they would need a static ip. 

 

On Tuesday, January 26, 2021 at 5:27:14 AM UTC-8 John W. Kitz wrote:

All,

 

Is it a good idea to begin with to use DHCP on a device which is acting as a server?

 

I'd answer that question with no. That noted as a newbie to all things relating to RPi's and Raspios, I recently installed kplex on an RPi3B with a dAISy HAT using DHCP to serve AIS messages to OpenCPN running on a Windows desktop client and, much to my surprise I got it working relatively quickly following the documentation supplied by the respective vendors or, in the case of kplex, developers to the letter.

Reply all
Reply to author
Forward
0 new messages