search

heistp / irtt

Isochronous Round-Trip Tester
GNU General Public License v2.0
190 stars 23 forks source link

Add systemd unit file #7

Closed tohojo closed 6 years ago

tohojo commented 6 years ago

This adds a systemd unit file for running the irtt server

heistp commented 6 years ago

Thanks! I'll update the "Running Server at Startup" doc when I get a chance as I have a basic service file example there. This is way better.

tohojo commented 6 years ago

Pete Heist notifications@github.com writes:

Thanks! I'll update the "Running Server at Startup" doc when I get a chance as I have a basic service file example there. This is way better.

Ah, didn't see that you have a unit file example there already. But yeah, that seems to be running irtt as root, which is probably not a good idea ;)

Also, daemons should generally run with a working directory of /, which is what systemd defaults to. Should probably add the Restart to the on I posted; maybe even set it to on-failure?

-Toke

heistp commented 6 years ago

On Nov 24, 2017, at 6:03 PM, Toke Høiland-Jørgensen notifications@github.com wrote:

Pete Heist notifications@github.com writes:

Ah, didn't see that you have a unit file example there already. But yeah, that seems to be running irtt as root, which is probably not a good idea ;)

Also, daemons should generally run with a working directory of /, which is what systemd defaults to. Should probably add the Restart to the on I posted; maybe even set it to on-failure?

Actually the example file has User=irtt (at least not root :), but I think nobody along with all the protections you added is better.

So far I see no harm in restart on-failure vs on-abort, but I’m not certain about it.

There are some cases where I allow a listener to exit with an error which might not be desirable on a production server, like if there’s a read or write error, or short write. For now I just wanted fail-fast behavior to know about them. I never saw these conditions occur. But I added a task to make this more robust, at least I think I should check if the error is “permanent” or not according to Go before letting a listener exit. Also I need to make sure the exit code gets set right in these cases. :)