kplex start vs restart

[landi]

Hi,


I tried to restart kplex. For my understanding kplex should stop and after sleep 2 kplex should start. As I saw with pgrep kplex, kplex disappeared and after 2 seconds it was not loaded.

After the second restart, kplex was loaded.



Hope anybody can explain
Juergen

[nohal]

The second restart simply was the same as a start. Without looking at least at your logs I would evaluate the chance you could get an explanation as next to non existent.

Pavel

[landi]

Hi pavel,
which logs do you mean?
Juergen

[nohal]

Main syslog (= usually /var/log/syslog or /var/log/messages), systemd if applicable, the ones produced by kplex itself if any.

If you ask me, I would simply ignore this "incident" if it was not 100% reproducible....

[landi]

[landi]

[nohal]

You will have to dig deeper, but at least we know that you are probably using raspbian and systemd...

From what I see kplex is using the old sys-v style init scripts instead of a real systemd unit, which is an idea worse with every systemd release, so I would probably read the /etc/init.d/kplex script and reimplemented it as a systemd unit instead (Which as a bonus will also give you automatic restarts in case the thing crashes).

[landi]

Thanks.
How can I convert and embed the script as system unit?

[nohal]

1. You read what it does. I have never seen kplex, but from a very short look at it's source would suspect that actually nothing but "/usr/bin/kplex -f /etc/kplex.conf"
2. You write a service unit to do the same, in this case probably something like (remember that I really do not know kplex besides the fact it exists)

[Unit]
Description=kplex multiplexer

[Service]
ExecStart=/usr/bin/kplex -f /etc/kplex.conf
Restart=always 

[Install]
WantedBy=multi-user.target

and save it as /etc/systemd/system/kplex.service (I would probably also stop kplex before doing this)
3. You get rid of the /etc/init.d/kplex script
4. You start the service

systemctl start kplex.service

5. You make it start automatically

systemctl enable kplex.service

6. You contribute the working systemd unit upstream

Relevant systemd documentation: https://www.freedesktop.org/software...d.service.html

[landi]

Thanks.
I will try, but this will take several days....
I will report.

[landi]

Hi,
here are the first results.
The kplex.service was aready installed. I made a new service kplex_jl, but it didnt work. Where ist the mistake?

[nohal]

The mistake in one of them sure is you use the forking mode and start kplex with -o background. Do not do this. The second mistake in the same one is you do not specify the configfile location using the -f parameter (if your configfile is in one of the default locations not needed)

The mistake in the second one is wrong value for the -f parameter, /var/run/kplex.pid is not your config file, I would say.

[landi]

Originally Posted by nohal

The mistake in one of them sure is you use the forking mode and start kplex with -o background. Do not do this.

The second mistake in the same one is you do not specify the configfile location using the -f parameter (if your configfile is in one of the default locations not needed)

Okay, but this ist the original after installation.

Originally Posted by nohal

The mistake in the second one is wrong value for the -f parameter, /var/run/kplex.pid is not your config file, I would say.

Yes, now I see.
I will try it in the evening.
Thanks

[nohal]

Originally Posted by landi

Okay, but the service it is the original after installation.

I do not understand what you are trying to say, but you can't simply copy everything you see.
Systemd is much more powerful than the old init system in terms of service management so it is generally not a good idea fighting with it.
The forking type is there only to support stuff where you don't have a choice and for special cases where you would need to wait for something that needs to happen before the PID file is created. Neither is the case with kplex as far as I can tell.

[muttnik]

Originally Posted by nohal

From what I see kplex is using the old sys-v style init scripts instead of a real systemd unit, which is an idea worse with every systemd release, so I would probably read the /etc/init.d/kplex script and reimplemented it as a systemd unit instead (Which as a bonus will also give you automatic restarts in case the thing crashes).

Yes and no..

Yes for systemd-based systems unit files are a much better idea. But init scripts do still work (as long as they don't have possible errors in (see below))

The release announcement for the most recent kplex version noted the systemd issue and the fact that a unit file is now distributed with kplex but not enabled. Why? Well, basically incompetence and impatience but there were mitigating factors that I'll explain elsewhere rather than clutter up the OpenCPN forum. Suffice to say: The provided unit file should work for those who prefer to use it.

Originally Posted by nohal

The mistake in one of them sure is you use the forking mode and start kplex with -o background.

You were right about the second mistake. I don't guarantee it but the first might not be a mistake (and if it is, it came from my unit file, so my bad). kplex does do its set-up before forking and writes the child (background) pid to the pidfile.

I've replied to landi on the kplex forum where this issue was also posted but if I were to place a bet it would be on the surprised-no-one-reported-that-til-now error in the init script which leaves 2 seconds between shutdown and startup when kplex's grace period for shutting down connections (ie time from receipt of SIGTERM kplex allows to cleanly shut down interface before killing all threads and exiting) is 3 seconds, so if you have a problematic connection that won't die cleanly, this might well exhibit this behaviour. debuglevel=3 in the [global] section of the config file would help with knowing what was going on. Using the unit file, hacking the init script to make the restart delay 4 seconds, or adding graceperiod=1 to [global] might all address the restart/grace period mis-match if that is indeed what lands is facing.