Date: Wed, 19 Dec 2018 08:46:21 -0700 From: Warner Losh <imp@bsdimp.com> To: Matthew Seaman <matthew@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: OpenRC on FreeBSD Message-ID: <CANCZdfo62coQDZo%2BCG0Y%2B_j2S_W55eV2r8jh3_DA1U6jdhe0Yg@mail.gmail.com> In-Reply-To: <00f5cd92-05a0-f331-559f-22b1df333dbe@FreeBSD.org> References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <CANCZdfp%2BQXngCRqevXT%2BDKgQj1S276PdpvqyZpiuOC%2BvMAP24A@mail.gmail.com> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> <00f5cd92-05a0-f331-559f-22b1df333dbe@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 19, 2018 at 8:17 AM Matthew Seaman <matthew@freebsd.org> wrote: > On 19/12/2018 14:57, Martin Wilke wrote: > > Hi, > > > > The missing bit was actually the flag for switching the rc=E2=80=99s wh= ich have > been resolved. > > > > - Martin > > > >> On 19 Dec 2018, at 10:51 PM, Warner Losh <imp@bsdimp.com> wrote: > >> > >> > >> > >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <miwi@freebsd.org <mailto= : > miwi@freebsd.org>> wrote: > >> Hi > >> > >> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically thi= s > is the second attempt to get it into FreeBSD. > >> > >> I've opened a review here with a working patch for CURRENT, > >> https://reviews.freebsd.org/D18578 <https://reviews.freebsd.org/D18578= > > >> > >> > >> To recap the discussion > >> * First attempt of RFC in March of 2018: > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > < > https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.htm= l > > > >> * Working group at BSDCan: > https://wiki.freebsd.org/DevSummit/201806/OpenRC < > https://wiki.freebsd.org/DevSummit/201806/OpenRC>; > >> > >> Here some key points: > >> > >> OpenRC provides additional features for service management without > requiring kernel changes or replacing pid 1, unlike launchd and other > solutions. All rc.d scripts have been converted with a few changes, > typically changing the shebang and making sure the start function is name= d > start(). Most service scripts are simplified, usually needing only name, > command, and, if required, depends statements. > >> > >> History: > >> OpenRC started out as an init system by Roy Marples, developed for the > Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gento= o > as baselayout v2, and was then split off as a separate BSD-licensed > project. It is under active development, portable, and remains BSD licens= ed > today. > >> > >> OpenRC and RC: > >> Both can coexist and be chosen with a setting in /boot/loader.conf. > >> > >> OpenRC Features: > >> > >> Service supervision and service monitoring: any service can be > supervised. Supervised services that crash are automatically restarted. T= he > rc-status command shows how many times a service has restarted. > >> > >> Device hotplug support and event-driven service management: the hotplu= g > feature allows devd to take actions when devices are connected. For > example, a USB wifi adapter can create additional network services when > attached. The net-online service can, for example, detect when a network > connection is restored, and restart ntp. > >> > >> Network profiles: using stacked runlevels, different profiles can be > established for different networking settings. For instance, different > profiles can be used for wired or wireless networking, or for differing > wireless networks, as well as dependency caching and parallel startup spe= ed > up booting. > >> > >> Interactive mode: > >> The boot process can be run interactively for more effective debugging= . > >> > >> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the conte= xt in which a > script is running. There are only three at present: > >> sysinit (the OpenRC system is starting), boot (start base services whe= n > the computer is booting), and default (normal execution). > >> > >> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot, = using ANSI color > sequences. This can be disabled. > >> > >> Ports: > >> As of July 2017, iXsystems has created OpenRC versions of port service > scripts for the entire ports tree. These scripts coexist with the rc.d > versions. > >> > >> License: > >> OpenRC is a BSD licensed RC init system written in C. From a user > perspective, it is very similar to the FreeBSD rc.d init system, making i= t > easy to use and learn. > >> > >> Tested: OpenRC has been used as the init system for TrueOS since > October 2016. > >> > >> Ken Moore has an OpenRC vs RC.d comparison which can be found here: > >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>; < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < > http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>>; > >> I look forward to discuss the features and capabilities of OpenRC. > >> > >> This is cool technology. > >> > >> However, what was missing last time was a written plan that could be > critiqued for fit with the project's needs. The result of the working gro= up > was that this was to be produced, and we'd iterate through it to ease the > landing of openrc in the tree. I think there's wide agreement this is coo= l, > and that we'd like tot have both it and rc.d in the tree for a transition > period. Absent a plan, though, it's not really possible to say 'go do it' > or 'that's insane'. > >> > >> So maybe start there? > >> > >> Warner > > This would mean that we're going to need both OpenRC and rc.d versions > of init scripts in the ports for however long the transition period is. > > How do you plan on managing that? Will port maintainers be expected to > develop and test both flavours of init script? Not all maintainers will > have ready access to build/test systems running CURRENT if that's where > OpenRC gets deployed initially. > > Will both types of init script be added to every pkg, or will there be a > default per major version? Will this change be MFC'd to 11.x / 12.x ? > > Also, isn't this a prime candidate for the FCP treatment? > There was a FCP that started to cover these things. I provided feedback, and then nothing happened. These are exactly the sorts of details that need too be covered somewhere, and the FCP is the logical place. It's why I am asking for there to be a plan. These sorts of policy and logistical details would be in there, and having an agreement in place up front will ease the transition as the project's expectations are clearly articulated. It needn't be perfect, but it has to be something substantially more than the nothing we have today. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo62coQDZo%2BCG0Y%2B_j2S_W55eV2r8jh3_DA1U6jdhe0Yg>