There was a slashdot article about Busybox removing systemd support, which turned into an sub-thread about an ipv6 over ipv4 service. The systemd maintainers added a respawn "fix" that would restart the service within 10 seconds since the daemon would abort if the network wasn't up .... of course this means that the upstream service providers get hit with retries every 10 seconds if your password is wrong or something else is misconfigured, and they were annoyed that the warning NOT to respawn wasn't being acknowledged and no notification was given that the unit file was being changed. They site systemd as the problem for not verifying that the network is up before starting the service. The systemd folks site that this shouldn't be necessary since "modern" systems (he mentions his Apple Powerbook) have intermittent networking and the daemon should use exponential backoff if the network is down. The daemon author says people need to read the logs before restarting the daemon and the systemd guys say that users aren't admins and don't read logs!
This is a classic example of what I see as the division of thought. The old-school admins see a server and classic start-up routines - you are started when networking comes up. If networking is down, abort. Read the logs. Auto-restart is bad. Systemd wants it easy and wants it to work on a laptop without thought (and apparently without a GUI tool that checks the log to decide if it should respawn), wants services to be restarted and says that the daemon author doesn't provide an exit code as to why the daemon stopped, so the only choice is to restart for all exits. He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.
Here's my take on this. Network down and can't connect are two different things. The former is a local issues and easy to detect. In this instance, the daemon can/should quit and log. Further, networking should be UP before the daemon is started. Specifically, the daemon should be started as a response to the "event" that the network is up. If there is a login problem or other issue, it should also abort and log. If the network is up, but you can't connect to the server, then use exponential backoff and retry. Systemd should know when network devices like Wifi disconnect and reconnect. It should also know if the daemon is running. It should start the daemon on the condition that the network has been brought up and it is not already running.
Now ... what am I missing ??? Why would it start without networking being up? Why would anyone restart the service every 10 seconds? Sounds brain dead to me! Typical SysV init would run the network up/down scripts and get this right. Systemd SHOULD get this right, and I'm sure someone will say its been misconfigured or whatever, but notice two different mind-sets here. One person wants it to just work with focus on easy - and who cares what damage it may cause. The other person wants people to stop and read (no matter how unrealistic that may be).
I once had someone tell me they couldn't print ... they said some error message kept popping up. I said, "What does it say?" They said, "I dunno". I said, "Well, try it again and read it!" And I could tell they were mad that I wouldn't run over there and fix their stupid Windows problem ... they did not want to read me any technical jargon from some error message on the screen! The response was, "Nevermind." ... WHAT? ... Guess what the Error said?