On Thu, 22.07.10 21:30, Horst H. von Brand (vonbrand@xxxxxxxxxxxx) wrote: > > Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Thu, 22.07.10 15:19, Simo Sorce (ssorce@xxxxxxxxxx) wrote: > > [...] > > > > Bad example, it may make sense if you have a single host, but if you > > > have multiple HTTP servers, you want the one that died to stop answering > > > until it is back up and running and ready to server requests. > > > > > > The last thing you want is to have a client wait forever because the > > > systemd doesn't kill the socket but apache is not able to properly > > > restart (say for a configuration mistake). > > > Well, not everything makes sense in all contexts. If you have a fallback > > web server in place then you don't need this trick. But I am pretty sure > > there are more web serving devices on this planets that do no failover > > like you suggest then there are that do this. And for those, which > > otherwise have no defined fallback path it is certainly really awesome > > if they can just restart apache if it crashes and can rest assured that > > they won't lose any request except the one apache actually crashed on. > > Sorry, but what if the configuration got screwed up, and <whatever daemon> > just won't start properly? Was replaced by a broken version which crashes > on startup? Or gets into a loop (or just does something very timeconsuming > sometimes) before being ready to answer? This _needs_ answers. Well, if a service might take an hour to start up it is not a good candidate for socket activation. We ratelimit process spawning in systemd. If a unit is respawned too often in a certain amount of time we give up and put the service in maintainance mode. Simialr for the socket. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
