Better daemon mode

[samplonius]

On https://iperf.fr/iperf-servers.php, the suggested script has a lot of lines like this:

/usr/bin/sudo -u nobody /usr/bin/iperf3 -s -p 5200 -D >/dev/null 2>&1

So this writes all output (and errors) to /dev/null. That isn't a good idea as you have no idea what iperf3 is doing. It would be better that if -D was specified, that output was written to syslog instead.

Plus, the rest of script has a bunch of killall stuff that is suggested to run hourly (!). Is there really a chance that iperf3 requires a -9 kill? If it could hang up like that, that would seem to be a bug. Or is this page out of date?

If I submitted a pull request with syslog output if -D is specified, would that be something that would be considered?

[bmah888]

We actually don't control the content of https://iperf.fr/, which actually appears to be unmaintained (we have not been able to contact that site's maintainer for years). iperf3 wasn't intended to run as a public service, and we haven't really put a lot of thought about how to best do that.

With respect to saving the output to a file when doing -D, you can use the --logfile flag on the server to send output to a file. I see value in sending output to syslog, but I'm concerned that iperf3 writes a lot of output, and not necessarily in a syslog-friendly format (self-contained log lines). So I think we'd want to think a bit about whether people would find that useful (given that there's the option to be logged to a file).

[rathann]

What do you think about including a systemd unit? Currently, I'm using this:

[Unit]
Description=Network throughput testing daemon
Documentation=man:iperf3(1) https://software.es.net/iperf/
After=network.target

[Service]
EnvironmentFile=-/etc/sysconfig/iperf3
ExecStart=/usr/bin/iperf3 --server $IPERF3_OPTIONS
SuccessExitStatus=1
User=iperf3

[Install]
WantedBy=multi-user.target

I had to set SuccessExitStatus=1, otherwise systemd considers the service "failed" after stopping, because iperf3 exits with exit code 1 after receiving SIGTERM (or SIGHUP).

[bjornfor]

I had to set SuccessExitStatus=1, otherwise systemd considers the service "failed" after stopping, because iperf3 exits with exit code 1 after receiving SIGTERM (or SIGHUP).

Feature request: exit with status 0 when receiving SIGTERM. From the glibc manual:

The SIGTERM signal is a generic signal used to cause program termination. Unlike SIGKILL, this signal can be blocked, handled, and ignored. It is the normal way to politely ask a program to terminate.

Exiting with non zero status should only be done in error conditions, and being asked politely to exit isn't an error.

[rathann]

So, the systemd unit is there at contrib/iperf3.service, great! It could use a few improvements like admin-settable options (see my comment above), but it's good enough.

However, iperf3 still has:

    exit(1)

at src/iperf_error.c:139, which is causing systemd to interpret clean exit as failure due to the exitcode:

Feb 06 09:38:44 iperf3[76442]: iperf3: interrupt - the server has terminated
Feb 06 09:38:44 iperf3[76442]: -----------------------------------------------------------
Feb 06 09:38:44 iperf3[76442]: Server listening on 5201 (test #1)
Feb 06 09:38:44 iperf3[76442]: -----------------------------------------------------------
Feb 06 09:38:44 systemd[1]: Stopping iperf3.service - Perform network throughput tests...
Feb 06 09:38:44 systemd[1]: iperf3.service: Main process exited, code=exited, status=1/FAILURE
Feb 06 09:38:44 systemd[1]: iperf3.service: Failed with result 'exit-code'.

Using SuccessExitStatus=1 will hide other errors, so it's far from ideal, too.

[davidBar-On]

@rathann, per this comment, suggest when iperf3 gets a signal it should exit(0) on SIGTERM. Do you think there are other termination signals that should cause exit code 0?

[davidBar-On]

Submitted PR #1829 with a suggested change to exit with code 0 when iperf3 is terminated because of SIGTERM.

I considered adding a parameter to allow of dynamic list of signals that should cause termination with exit code 0, but it seems to be an overkill. If there are other signals like SIGTERM they may be hard coded (as SIGTERM is hard coded in the PR).

[rathann]

@rathann, per this comment, suggest when iperf3 gets a signal it should exit(0) on SIGTERM. Do you think there are other termination signals that should cause exit code 0?

I'd say: SIGINT. See that glibc manual linked by @bjornfor above. SIGHUP is usually used for asking the daemon to re-read and re-apply its config.

[davidBar-On]

Thanks. Added SIGINT to PR #1829.