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 <smcca...@redhat.com> 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 <ccole...@redhat.com >> <mailto:ccole...@redhat.com>> 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 <smcca...@redhat.com >> <mailto:smcca...@redhat.com>> 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 <mailto:epa...@redhat.com> >> <mailto:epa...@redhat.com <mailto: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 <mailto:smcca...@redhat.com> >> >> Phone: 312-660-3535 <tel:312-660-3535> >> >> Cell: 330-807-1043 <tel: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 > >
