Bug#727708: init multiple instances of a daemon

2013-12-26 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Dec 22, 2013 at 03:56:04PM -0800, Russ Allbery wrote: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: But this should be safe for instance units, so I'd like to see 'systemctl stop/status/... server@*.service' implemented. That would be very useful for distribution

Bug#727708: init multiple instances of a daemon

2013-12-23 Thread Daniel Pocock
On 23/12/13 08:41, Adrien Clerc wrote: Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit : It looks like both upstart and systemd don't provide direct mechanisms to manage all instances. That's true (I'm only speaking about systemd). There have been requests for such functionality

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Daniel Pocock
This email is not so much about the change of init system but just about the multiple-instance problem, regardless of which init we use. It is not a huge hassle but it is something that could be handled more smoothly. Some packages provide a way to start multiple instances in one shot from

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Russ Allbery
Daniel Pocock dan...@pocock.com.au writes: This email is not so much about the change of init system but just about the multiple-instance problem, regardless of which init we use. It is not a huge hassle but it is something that could be handled more smoothly. Some packages provide a way

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Daniel Pocock
On 22/12/13 21:03, Russ Allbery wrote: Daniel Pocock dan...@pocock.com.au writes: This email is not so much about the change of init system but just about the multiple-instance problem, regardless of which init we use. It is not a huge hassle but it is something that could be handled more

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Russ Allbery
Daniel Pocock dan...@pocock.com.au writes: Just to clarify: does this mean systemd and upstart can refer to the instances collectively or individually as required? E.g. you can tell it restart all instances of httpd (on dpkg upgrade) or just restart one specific instance (after a config

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Tollef Fog Heen
]] Russ Allbery Daniel Pocock dan...@pocock.com.au writes: Just to clarify: does this mean systemd and upstart can refer to the instances collectively or individually as required? E.g. you can tell it restart all instances of httpd (on dpkg upgrade) or just restart one specific

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Russ Allbery
Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery It looks like both upstart and systemd don't provide direct mechanisms to manage all instances. The upstart cookbook recommends getting a list of all active services and extracting the list of instances of a particular service from

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Dec 22, 2013 at 12:48:47PM -0800, Russ Allbery wrote: upstart calls this instances and systemd calls this unit templates. We too call them instances: an instance is created from a template. Daniel Pocock dan...@pocock.com.au writes: Just to clarify: does this mean systemd and

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Russ Allbery
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: But this should be safe for instance units, so I'd like to see 'systemctl stop/status/... server@*.service' implemented. That would be very useful for distribution packagers. If, for example, you support a multiple-instance Tomcat

Bug#727708: init multiple instances of a daemon

2013-12-22 Thread Tollef Fog Heen
]] Russ Allbery Does that mean that you can do a systemctl restart getty and have it restart all of the services spawned from the getty template? If you want that, add PartOf=foo.target and possibly ReloadPropagatedFrom=foo.target in foo@.service It'd be systemctl restart foo.target, not