On Wed, 24.08.11 17:09, Hans de Goede (hdegoede@xxxxxxxxxx) wrote: > > Hi, > > On 08/24/2011 04:56 PM, Simo Sorce wrote: > > On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: > >> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: > >>> On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: > >>>> Why not? > >>>> > >>>> If the service is enabled but the daemon not currently running, is it so > >>>> terrible for a connection test to cause the daemon to start? Remember, > >>>> in systemd logic 'service enabled with socket activation, daemon not > >>>> currently running' is effectively an 'on' state, not an 'off' state. If > >>>> you wanted the database to be 'off' you should have the service > >>>> disabled, and in that case, the ping test wouldn't cause the daemon to > >>>> start. > >>> > >>> It generally is a bad idea to automatically restart a database based on > >>> a random connection. There many reasons why you may have stopped the db > >>> (or it may have stopped itself) and requires inspection before > >>> attempting a new restart. Having to battle with socket activation while > >>> in a critical situation is not a good idea. > >> > >> You'd have the same problem with any init system that supports automatic > >> service restarting. You can easily disable the service via systemctl. > > > > You can do that if you are doing a planned outage. But not for unplanned > > ones. > > > > I am not saying automatic restarts should never be employed, only that > > not all software should be automatically restarted. I think databases > > shouldn't in most cases. But that's just my opinion on the specific > > case. That doesn't mean socket-activation shouldn't be employed in other > > cases. > > So maybe we need a socket-activate-once attribute for .service files, > which makes systemd do the socket activation only once, hmm thinking of > it, doesn't it do that already in the form of handing the listening fd over? > > So if a service is set to not auto restart the service I would expect > the order would be: > > 1) systemd starts > 2) systemd creates listening socket > 3) connection comes in > 4) systemd starts foodb, hands overlistening socket > 5) foodb crashes > 6) db is dead, no one listening to socket. > > Right? I guess that unless auto-restart is set for the service, systemd > won't re-create the listening socket and start listening itself again on > step 6. If it does I'm sure that the systemd authors are very reasonable > people and we can tell them that socket activation should not imply > auto-restart on daemon crash / exit (unless explicitly requested). I think what you are basically asking for is that we propagate the failure state from the service unit to the socket unit, right? As mentioned in another mail I just sent this has been on the todo list for a while. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
