* Tollef Fog Heen (tfh...@err.no) [131221 13:57]:
> sd-daemon.c is also intentionally designed to not have dependencies on
> the rest of the systemd source and to be portable to non-linux
> architectures too (but basically just stubs then) just so people can put
> the file in their source and not h
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
their
Daniel Pocock 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 to start multiple
On 22/12/13 21:03, Russ Allbery wrote:
> Daniel Pocock 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.
Daniel Pocock 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 change)?
It looks li
]] Russ Allbery
> Daniel Pocock 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
Tollef Fog Heen 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 that, and
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 writes:
>
> > Just to clarify: does this mean systemd and upstart can refe
Zbigniew Jędrzejewski-Szmek 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 configuration (which is
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 before, but nothing was implemented. But I thi
]] 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 ju
11 matches
Mail list logo
