Well yes but now it’s getting silly. The whole point of the vrsfeed script is to test for, and restart, socat on a per-feed basis. This is because socat will exit if the connection is interrupted. It doesn’t make sense for vrsfeed to run continuously. If anything it is socat which is the service element and that’s what should be ‘servicifed’. Turning vrsfeed itself into a service, and then adding a while and sleep construct to hack around its unsuitability as a service, is just really nasty.
Your comments about cron are correct generally (although a reboot isn’t needed), but again consider why someone would use vrsfeed. Like dump1090 itself, it’s not a function which would need to be turned off and on all the time; most of the time it simply ticks along checking that socat is running. If for some reason socat does need to be interrupted now and again, one can simply rename vrsfeed and pkill socat, do whatever needs doing and rename vrsfeed back when ready. If there was a need to do this a lot I’d still rather edit the vrsfeed script to use a lock file and manage it via that rather than hack it into a service.
As for bandwidth, reduced bandwidth is useful for a remote site running a cellular data plan, for example, but it’s nothing to do with whether a service is the way to go. The execution aspect is divorced from the function aspect. And using external installation scripts for these mods has its own pitfalls – it’s something else to have to trust and track and hope that it’s behaving and it’s difficult to implement offline if a baseline build is desired, and it can make system management more difficult as there’s now external scripting out of your control influencing your environment. It’s got its place but for simpler requirements the risks and costs outweight the benefits in my admin experience.