Date: Sat, 09 Feb 2019 15:34:55 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Enji Cooper <yaneurabeya@gmail.com> Cc: Wojciech Puchar <wojtek@puchar.net>, Sidju <lists@sidju.se>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Conrad Meyer <cem@freebsd.org> Subject: Re: nosh init system Message-ID: <201902092334.x19NYtZe036559@slippy.cwsent.com> In-Reply-To: Message from Enji Cooper <yaneurabeya@gmail.com> of "Sat, 09 Feb 2019 09:55:17 -0800." <CF8D2DCD-F63A-4E79-9CBC-CD45D5D596DD@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CF8D2DCD-F63A-4E79-9CBC-CD45D5D596DD@gmail.com>, Enji Cooper writes : > On Feb 9, 2019, at 09:32, Wojciech Puchar <wojtek@puchar.net> wrote: > > >> pid 2 and reap zombies. We're missing a half-decent service > >> management system. On Linux, systemd performs both roles. On > >> FreeBSD, init(8) serves one role, and rc(8) is a tiny subset of a real > >> service management system like systemd. > > > > systemd is overcomplex crap. And a reason many people migrated to FreeBSD f > rom linux. > > > >> > >> (I think the piece we would consider replacing or supplementing would > >> be rc(8). Part of that might be migrating some responsibilities from > >> pid 1 to pid 2, such as spawning gettys. I don't hold strong opinions > >> about that.) > > > > this make sense but with spawning gettys left to init. > > > > > > what do you want to improve in rc? starting services in parallel doesn't se > em to be major problem to make i think. > > Starting and stopping services based on logical events and “run levels”, > apart from what devd handles with hardware events is what comes to mind for m > e. > > rc(8) is also incredibly fragile when it comes to starting or stopping servic > es beyond first boot, or when dealing with “optional” services, like nis/ > yp. I tried to clean this up a few years ago, but it’s not close to my idea > l design (it feels like a bubblegum and duct tape solution). I've been using NIS on FreeBSD for a couple of decades and still using it on my network. Except for one bad patch a few years ago it's been 100% solid. There are no startup or shutdown issues. I don't see what's so "incredibly fragile" about rc(8). That's not to say there aren't better solutions, like SMF. Where rc(8) falls down is any port or a customer's (user of FreeBSD) rc script could fail hosing the boot or worse hosing the system*. Where a solution like SMF solves the problem is that should a service which other services depend on fail, only that branch of the startup tree would fail. In that scenario, if a service fails but sshd start, a sysadmin would still be able to login remotely to resolve the problem. So in this regard rc(8) is at a disadvantage. We could address the above paragraph by starting sshd earlier during boot thereby allowing the opportunity to fix remotely. Regarding SMF, it could be implemented by rc(8) invoking smf in similar fashion as Solaris does -- Solaris invokes it through inittab(5) -- or it could through a special yet to be determined entry in ttys(5). The Solaris approach is init(8)'s sole job, through the inittab(5) entry, is to restart smf, while smf does the rest. I prefer not to discuss implementation details right now, it's premature. * Incredibly stupid people can hose SMF too. It is more complex. OTOH that complexity might scare the uninitiated from attempting something dumb. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201902092334.x19NYtZe036559>