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

2017-03-07 Thread 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

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

2017-03-07 Thread 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,

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

2017-03-07 Thread 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

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

2017-03-07 Thread 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

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

2017-03-07 Thread 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,

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

2017-03-07 Thread 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?

2017-03-06 Thread 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?

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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,

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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

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

2017-03-06 Thread 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