Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

There isn't we should create one.  It's come up in CRI-O discussions, and I
think a simple boolean is reasonable to add to the kube container surface
area, since we can't opt in users to being non PID 1, they have to opt
themselves in.

On Tue, Mar 7, 2017 at 9:20 AM, Colin Walters  wrote:

> On Tue, Mar 7, 2017, at 08:32 AM, Clayton Coleman wrote:
> > Doesn't work in Kubernetes today.
>
> Is there a kube issue for exposing it?  I can't find it if so.
>
> For reference this came from:
> https://github.com/docker/docker/pull/26061
>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

On Tue, Mar 7, 2017 at 9:38 AM, Muayyad AlSadi  wrote:

> I've packaged dumb-init, it's in copr
> And there was a package review for official repos
>

That's great - couldn't find it during the search last night, good to know
it exists.


>
> > Anyone using these today?
>
> yes, I use it along with oneway < https://github.com/muayyad-
> alsadi/oneway/releases/
>
> > What does dumb-init or tini get me that systemd doesn't?
>
> simply dumb init does not thing, it's just exec a single process (the
> docker way which is single process per container)
>
> so instead of start.sh we use dumb-init start.sh
>
> it's not intended to do what sysvinit / systemd / upstart do
> it just fork then exec it's argument, the parent process just handle defunct
> processes
>
> > I am skeptical of any "resource" argument against systemd
>
> it does not do any management (the dumb part of it's name)
>
> > I think multiple init systems will just generate more technical
> questions
>
> please give it a chance, not because we need another init system, but
> because it's NOT an init system.
> it just run a single process (look at supervisord which is in the official
> repo, is more close to be an init system than dumb-init)
>
> > Doesn't work in Kubernetes today.
>
> I do use it with k8s!
>

I was referring to docker run --init

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

https://admin.fedoraproject.org/pkgdb/package/rpms/dumb-init/
https://copr.fedorainfracloud.org/coprs/alsadi/dumb-init/

On Tue, Mar 7, 2017 at 4:42 PM, Muayyad AlSadi  wrote:

> typical use is a Dockerfile having
>
> RUN curl -sSL -o /usr/local/bin/dumb-init https://github.com/Yelp/dumb-
> init/releases/download/v1.0.2/dumb-init_1.0.2_amd64 && chmod +x
> /usr/local/bin/dumb-init
>
> ENTRYPOINT ["dumb-init", "--", "/start.sh"]
>
>
>
>
> On Tue, Mar 7, 2017 at 4:38 PM, Muayyad AlSadi  wrote:
>
>> I've packaged dumb-init, it's in copr
>> And there was a package review for official repos
>>
>> > Anyone using these today?
>>
>> yes, I use it along with oneway < https://github.com/muayyad-als
>> adi/oneway/releases/
>>
>> > What does dumb-init or tini get me that systemd doesn't?
>>
>> simply dumb init does not thing, it's just exec a single process (the
>> docker way which is single process per container)
>>
>> so instead of start.sh we use dumb-init start.sh
>>
>> it's not intended to do what sysvinit / systemd / upstart do
>> it just fork then exec it's argument, the parent process just handle defunct
>> processes
>>
>> > I am skeptical of any "resource" argument against systemd
>>
>> it does not do any management (the dumb part of it's name)
>>
>> > I think multiple init systems will just generate more technical
>> questions
>>
>> please give it a chance, not because we need another init system, but
>> because it's NOT an init system.
>> it just run a single process (look at supervisord which is in the
>> official repo, is more close to be an init system than dumb-init)
>>
>> > Doesn't work in Kubernetes today.
>>
>> I do use it with k8s!
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman 
>> wrote:
>>
>>> Doesn't work in Kubernetes today.
>>>
>>> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer 
>>> wrote:
>>> >
>>> >
>>> > Clayton Coleman  writes:
>>> >
>>> >> [...] Anyone using these today?
>>> >
>>> > What about "docker run --init"?  Anything wrong with that?
>>>
>>>
>>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

typical use is a Dockerfile having

RUN curl -sSL -o /usr/local/bin/dumb-init
https://github.com/Yelp/dumb-init/releases/download/v1.0.2/dumb-init_1.0.2_amd64
&& chmod +x /usr/local/bin/dumb-init

ENTRYPOINT ["dumb-init", "--", "/start.sh"]




On Tue, Mar 7, 2017 at 4:38 PM, Muayyad AlSadi  wrote:

> I've packaged dumb-init, it's in copr
> And there was a package review for official repos
>
> > Anyone using these today?
>
> yes, I use it along with oneway < https://github.com/muayyad-
> alsadi/oneway/releases/
>
> > What does dumb-init or tini get me that systemd doesn't?
>
> simply dumb init does not thing, it's just exec a single process (the
> docker way which is single process per container)
>
> so instead of start.sh we use dumb-init start.sh
>
> it's not intended to do what sysvinit / systemd / upstart do
> it just fork then exec it's argument, the parent process just handle defunct
> processes
>
> > I am skeptical of any "resource" argument against systemd
>
> it does not do any management (the dumb part of it's name)
>
> > I think multiple init systems will just generate more technical
> questions
>
> please give it a chance, not because we need another init system, but
> because it's NOT an init system.
> it just run a single process (look at supervisord which is in the official
> repo, is more close to be an init system than dumb-init)
>
> > Doesn't work in Kubernetes today.
>
> I do use it with k8s!
>
>
>
>
>
>
>
>
> On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman 
> wrote:
>
>> Doesn't work in Kubernetes today.
>>
>> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer 
>> wrote:
>> >
>> >
>> > Clayton Coleman  writes:
>> >
>> >> [...] Anyone using these today?
>> >
>> > What about "docker run --init"?  Anything wrong with that?
>>
>>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

I've packaged dumb-init, it's in copr
And there was a package review for official repos

> Anyone using these today?

yes, I use it along with oneway <
https://github.com/muayyad-alsadi/oneway/releases/

> What does dumb-init or tini get me that systemd doesn't?

simply dumb init does not thing, it's just exec a single process (the
docker way which is single process per container)

so instead of start.sh we use dumb-init start.sh

it's not intended to do what sysvinit / systemd / upstart do
it just fork then exec it's argument, the parent process just handle defunct
processes

> I am skeptical of any "resource" argument against systemd

it does not do any management (the dumb part of it's name)

> I think multiple init systems will just generate more technical questions

please give it a chance, not because we need another init system, but
because it's NOT an init system.
it just run a single process (look at supervisord which is in the official
repo, is more close to be an init system than dumb-init)

> Doesn't work in Kubernetes today.

I do use it with k8s!








On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman  wrote:

> Doesn't work in Kubernetes today.
>
> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer 
> wrote:
> >
> >
> > Clayton Coleman  writes:
> >
> >> [...] Anyone using these today?
> >
> > What about "docker run --init"?  Anything wrong with that?
>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

Doesn't work in Kubernetes today.

> On Mar 7, 2017, at 2:44 AM, Marius Vollmer  wrote:
>
>
> Clayton Coleman  writes:
>
>> [...] Anyone using these today?
>
> What about "docker run --init"?  Anything wrong with that?

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Marius Vollmer]

Clayton Coleman  writes:

> [...] Anyone using these today?

What about "docker run --init"?  Anything wrong with that?

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

I'd probably be ok with something like "systemd-act-like-a-real-init-shim"
if it means stdin, stdout, and stderr are propagated properly to my child.
The reason systemd is a non-starter right now is logging, but give me a
single word binary that does logging, is available via a package, and I
might forgive you.  :)

On Mon, Mar 6, 2017 at 10:03 PM, Scott McCarty  wrote:

>
>
> On 03/06/2017 10:02 PM, Clayton Coleman wrote:
>
>> Dumb-init is more like nohup, or tee, or strace. It's for processes (most
>> of them) that don't deal with being PID 1.  So jumping through hoops to
>> write a unit file feels like you're saying "do it the hard way" when I know
>> perfectly well that I don't need to do it the hard way.
>>
> I get it.
>
>>
>> On Mon, Mar 6, 2017 at 10:00 PM, Clayton Coleman > > wrote:
>>
>> Please do not tell me that I want to write a unit file when the
>> *entire* ecosystem takes command lines just fine.  I have hundreds
>> of dockerfiles that have entry points - why do I need to write
>> unit files for them?  I have command line tools that generate
>> docker images... with command lines - why would I want to write
>> unit files for them?
>>
>> Also, dumb-init is not an init system.  It's a signal proxy.
>>
>>
>> On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty > > wrote:
>>
>> I am skeptical of any "resource" argument against systemd. Are
>> you seeing some actually impact to performance that is causing
>> problems? As for unit files, they are rediculously easy. Much
>> easier than figuring out how to start a daemon properly by
>> reading documentation.
>>
>> I don't have a strong opinion for CentOS/Fedora. But for RHEL,
>> I think multiple init systems will just generate more
>> technical questions from customers and eat up more sales
>> resources explaining when people should use what. Options are
>> great, but confusing, that's why Apple got rid of a lot of them...
>>
>>
>> On 03/06/2017 09:48 PM, Clayton Coleman wrote:
>>
>> Zero overhead, defunct process management, proper logging,
>> simplicity, no moving parts, no additional unit file (I
>> don't have unit files).
>>
>> Turn it around - if I have the command line
>> "ansible-playbook ...", what does systemd get me?
>>
>> On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris
>> 
>> >> wrote:
>>
>> On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
>> > They'd be really helpful for cases where you don't
>> want full blown
>> > systemd, but want a long running container that
>> needs to reap
>> > processes.  I don't know that one or the other
>> matters, I have a
>> > slight bias for dumb-init in terms of signal
>> rewriting (a few cases
>> > might need that).
>> >
>> > Anyone using these today?
>>
>> What does dumb-init or tini get me that systemd doesn't?
>>
>>
>>
>> --
>> Scott McCarty, RHCA
>>
>> Technical Product Marketing: Containers
>>
>> Email: smcca...@redhat.com 
>>
>> Phone: 312-660-3535 
>>
>> Cell: 330-807-1043 
>>
>> Web: http://crunchtools.com
>>
>> When should you split your application into multiple
>> containers? http://red.ht/22xKw9i
>>
>>
>>
>>
> --
>
> Scott McCarty, RHCA
>
> Technical Product Marketing: Containers
>
> Email: smcca...@redhat.com
>
> Phone: 312-660-3535
>
> Cell: 330-807-1043
>
> Web: http://crunchtools.com
>
> When should you split your application into multiple containers?
> http://red.ht/22xKw9i
>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Scott McCarty]

On 03/06/2017 10:02 PM, Clayton Coleman wrote:
Dumb-init is more like nohup, or tee, or strace. It's for processes 
(most of them) that don't deal with being PID 1.  So jumping through 
hoops to write a unit file feels like you're saying "do it the hard 
way" when I know perfectly well that I don't need to do it the hard way.

I get it.


On Mon, Mar 6, 2017 at 10:00 PM, Clayton Coleman > wrote:


Please do not tell me that I want to write a unit file when the
*entire* ecosystem takes command lines just fine.  I have hundreds
of dockerfiles that have entry points - why do I need to write
unit files for them?  I have command line tools that generate
docker images... with command lines - why would I want to write
unit files for them?

Also, dumb-init is not an init system.  It's a signal proxy.


On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty > wrote:

I am skeptical of any "resource" argument against systemd. Are
you seeing some actually impact to performance that is causing
problems? As for unit files, they are rediculously easy. Much
easier than figuring out how to start a daemon properly by
reading documentation.

I don't have a strong opinion for CentOS/Fedora. But for RHEL,
I think multiple init systems will just generate more
technical questions from customers and eat up more sales
resources explaining when people should use what. Options are
great, but confusing, that's why Apple got rid of a lot of them...


On 03/06/2017 09:48 PM, Clayton Coleman wrote:

Zero overhead, defunct process management, proper logging,
simplicity, no moving parts, no additional unit file (I
don't have unit files).

Turn it around - if I have the command line
"ansible-playbook ...", what does systemd get me?

On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris

>> wrote:

On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't
want full blown
> systemd, but want a long running container that
needs to reap
> processes.  I don't know that one or the other
matters, I have a
> slight bias for dumb-init in terms of signal
rewriting (a few cases
> might need that).
>
> Anyone using these today?

What does dumb-init or tini get me that systemd doesn't?



-- 


Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com 

Phone: 312-660-3535 

Cell: 330-807-1043 

Web: http://crunchtools.com

When should you split your application into multiple
containers? http://red.ht/22xKw9i





--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Scott McCarty]

On 03/06/2017 10:00 PM, Clayton Coleman wrote:
Please do not tell me that I want to write a unit file when the 
*entire* ecosystem takes command lines just fine. I have hundreds of 
dockerfiles that have entry points - why do I need to write unit files 
for them?  I have command line tools that generate docker images... 
with command lines - why would I want to write unit files for them?
Interesting use case. Nothing I have ever heard form a developer. I 
think we are "in" the bubble. You are one of the smartest programmers, 
and one of the largest contributors to Kubernetes. There is zero chance 
that our customers will want to rewrite all of their services from 
scratch. I mean, maybe 15 years from now.


I am not arguing against you using it, I am arguing against us packing 
more stuff in RHEL and confusing the not as smart people...


Also, dumb-init is not an init system.  It's a signal proxy.

On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty > wrote:


I am skeptical of any "resource" argument against systemd. Are you
seeing some actually impact to performance that is causing
problems? As for unit files, they are rediculously easy. Much
easier than figuring out how to start a daemon properly by reading
documentation.

I don't have a strong opinion for CentOS/Fedora. But for RHEL, I
think multiple init systems will just generate more technical
questions from customers and eat up more sales resources
explaining when people should use what. Options are great, but
confusing, that's why Apple got rid of a lot of them...


On 03/06/2017 09:48 PM, Clayton Coleman wrote:

Zero overhead, defunct process management, proper logging,
simplicity, no moving parts, no additional unit file (I don't
have unit files).

Turn it around - if I have the command line "ansible-playbook
...", what does systemd get me?

On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris  >> wrote:

On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't want
full blown
> systemd, but want a long running container that needs to
reap
> processes.  I don't know that one or the other matters,
I have a
> slight bias for dumb-init in terms of signal rewriting
(a few cases
> might need that).
>
> Anyone using these today?

What does dumb-init or tini get me that systemd doesn't?



-- 


Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com 

Phone: 312-660-3535 

Cell: 330-807-1043 

Web: http://crunchtools.com

When should you split your application into multiple containers?
http://red.ht/22xKw9i




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

Dumb-init is more like nohup, or tee, or strace.  It's for processes (most
of them) that don't deal with being PID 1.  So jumping through hoops to
write a unit file feels like you're saying "do it the hard way" when I know
perfectly well that I don't need to do it the hard way.

On Mon, Mar 6, 2017 at 10:00 PM, Clayton Coleman 
wrote:

> Please do not tell me that I want to write a unit file when the *entire*
> ecosystem takes command lines just fine.  I have hundreds of dockerfiles
> that have entry points - why do I need to write unit files for them?  I
> have command line tools that generate docker images... with command lines -
> why would I want to write unit files for them?
>
> Also, dumb-init is not an init system.  It's a signal proxy.
>
>
> On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty  wrote:
>
>> I am skeptical of any "resource" argument against systemd. Are you seeing
>> some actually impact to performance that is causing problems? As for unit
>> files, they are rediculously easy. Much easier than figuring out how to
>> start a daemon properly by reading documentation.
>>
>> I don't have a strong opinion for CentOS/Fedora. But for RHEL, I think
>> multiple init systems will just generate more technical questions from
>> customers and eat up more sales resources explaining when people should use
>> what. Options are great, but confusing, that's why Apple got rid of a lot
>> of them...
>>
>>
>> On 03/06/2017 09:48 PM, Clayton Coleman wrote:
>>
>>> Zero overhead, defunct process management, proper logging, simplicity,
>>> no moving parts, no additional unit file (I don't have unit files).
>>>
>>> Turn it around - if I have the command line "ansible-playbook ...", what
>>> does systemd get me?
>>>
>>> On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris > epa...@redhat.com>> wrote:
>>>
>>> On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
>>> > They'd be really helpful for cases where you don't want full blown
>>> > systemd, but want a long running container that needs to reap
>>> > processes.  I don't know that one or the other matters, I have a
>>> > slight bias for dumb-init in terms of signal rewriting (a few cases
>>> > might need that).
>>> >
>>> > Anyone using these today?
>>>
>>> What does dumb-init or tini get me that systemd doesn't?
>>>
>>>
>>>
>> --
>>
>> Scott McCarty, RHCA
>>
>> Technical Product Marketing: Containers
>>
>> Email: smcca...@redhat.com
>>
>> Phone: 312-660-3535
>>
>> Cell: 330-807-1043
>>
>> Web: http://crunchtools.com
>>
>> When should you split your application into multiple containers?
>> http://red.ht/22xKw9i
>>
>>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

Please do not tell me that I want to write a unit file when the *entire*
ecosystem takes command lines just fine.  I have hundreds of dockerfiles
that have entry points - why do I need to write unit files for them?  I
have command line tools that generate docker images... with command lines -
why would I want to write unit files for them?

Also, dumb-init is not an init system.  It's a signal proxy.

On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty  wrote:

> I am skeptical of any "resource" argument against systemd. Are you seeing
> some actually impact to performance that is causing problems? As for unit
> files, they are rediculously easy. Much easier than figuring out how to
> start a daemon properly by reading documentation.
>
> I don't have a strong opinion for CentOS/Fedora. But for RHEL, I think
> multiple init systems will just generate more technical questions from
> customers and eat up more sales resources explaining when people should use
> what. Options are great, but confusing, that's why Apple got rid of a lot
> of them...
>
>
> On 03/06/2017 09:48 PM, Clayton Coleman wrote:
>
>> Zero overhead, defunct process management, proper logging, simplicity, no
>> moving parts, no additional unit file (I don't have unit files).
>>
>> Turn it around - if I have the command line "ansible-playbook ...", what
>> does systemd get me?
>>
>> On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris  epa...@redhat.com>> wrote:
>>
>> On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
>> > They'd be really helpful for cases where you don't want full blown
>> > systemd, but want a long running container that needs to reap
>> > processes.  I don't know that one or the other matters, I have a
>> > slight bias for dumb-init in terms of signal rewriting (a few cases
>> > might need that).
>> >
>> > Anyone using these today?
>>
>> What does dumb-init or tini get me that systemd doesn't?
>>
>>
>>
> --
>
> Scott McCarty, RHCA
>
> Technical Product Marketing: Containers
>
> Email: smcca...@redhat.com
>
> Phone: 312-660-3535
>
> Cell: 330-807-1043
>
> Web: http://crunchtools.com
>
> When should you split your application into multiple containers?
> http://red.ht/22xKw9i
>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Scott McCarty]

I am skeptical of any "resource" argument against systemd. Are you 
seeing some actually impact to performance that is causing problems? As 
for unit files, they are rediculously easy. Much easier than figuring 
out how to start a daemon properly by reading documentation.


I don't have a strong opinion for CentOS/Fedora. But for RHEL, I think 
multiple init systems will just generate more technical questions from 
customers and eat up more sales resources explaining when people should 
use what. Options are great, but confusing, that's why Apple got rid of 
a lot of them...



On 03/06/2017 09:48 PM, Clayton Coleman wrote:
Zero overhead, defunct process management, proper logging, simplicity, 
no moving parts, no additional unit file (I don't have unit files).


Turn it around - if I have the command line "ansible-playbook ...", 
what does systemd get me?


On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris > wrote:


On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't want full blown
> systemd, but want a long running container that needs to reap
> processes.  I don't know that one or the other matters, I have a
> slight bias for dumb-init in terms of signal rewriting (a few cases
> might need that).
>
> Anyone using these today?

What does dumb-init or tini get me that systemd doesn't?




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Clayton Coleman]

Zero overhead, defunct process management, proper logging, simplicity, no
moving parts, no additional unit file (I don't have unit files).

Turn it around - if I have the command line "ansible-playbook ...", what
does systemd get me?

On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris  wrote:

> On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> > They'd be really helpful for cases where you don't want full blown
> > systemd, but want a long running container that needs to reap
> > processes.  I don't know that one or the other matters, I have a
> > slight bias for dumb-init in terms of signal rewriting (a few cases
> > might need that).
> >
> > Anyone using these today?
>
> What does dumb-init or tini get me that systemd doesn't?
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Eric Paris]

On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't want full blown
> systemd, but want a long running container that needs to reap
> processes.  I don't know that one or the other matters, I have a
> slight bias for dumb-init in terms of signal rewriting (a few cases
> might need that).
> 
> Anyone using these today?

What does dumb-init or tini get me that systemd doesn't?