OpenRC on FreeBSD

Matt Joras mjoras at freebsd.org
Wed Dec 19 15:55:53 UTC 2018


On Wed, Dec 19, 2018, 9:49 AM Marcelo Araujo <araujobsdport at gmail.com wrote:

> Em qua, 19 de dez de 2018 às 23:02, Warner Losh <imp at bsdimp.com> escreveu:
>
> >
> >
> > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <miwi at freebsd.org> wrote:
> >
> >> Hi,
> >>
> >> The missing bit was actually the flag for switching the rc’s which have
> >> been resolved.
> >>
> >
> > No. The missing bit is an articulated plan. While that minor sub-issue
> may
> > be resolved, I see no plan for integration into the tree. Unless the plan
> > is 'commit the review in one big push' which really isn't a viable plan.
> > There are problems with the review (it's too large to be successful, and
> > has issues that need to be discussed in a less massively huge
> environment).
> > This isn't what the working group's conclusion would be the next steps.
> The
> > FCP I provided feedback on died. It was a good start on a plan, but was
> > just dropped with my feedback completely ignored.
> >
>
> Hi Warner,
>
> I have asked miwi@ to keep that huge patch on the review because of the
> lack of coordination and discussion between different groups and also
> because there is not a clear plan how to bring OpenRC into FreeBSD. So in
> that way people could try the patch easily without chasing different open
> reviews, and to be honest, without further discussion regarding to how the
> transition would happens between rcd and OpenRC, there is nothing much to
> review there.
>

Just making a small suggestion here, does our Phabricator support "stacked"
diffs? That is the defacto way for a group of diffs on Phabricator to be
logically grouped so they are easy to navigate and review separately.


> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
> broad discussion, because it will impacts not only the base system but also
> ports, and also docs needs to get involved because we eventually would need
> to update our documentation. We have people that wants OpenRC also in other
> hands we have people that wants to keep things as it is.
>
> NOTE: I have updated the review with the same content of this email just to
> make it registered there.
>
> I agree for review purpose small chunks are better, however I don't see yet
> a plan for all this migration between rcd and OpenRC.
> Best,
>
>
> >
> > Warner
> >
> >
> >> - Martin
> >>
> >> On 19 Dec 2018, at 10:51 PM, Warner Losh <imp at bsdimp.com> wrote:
> >>
> >>
> >>
> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <miwi at freebsd.org> wrote:
> >>
> >>> Hi
> >>>
> >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
> >>> 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
> >>>
> >>>
> >>> To recap the discussion
> >>>     * First attempt of RFC in March of 2018:
> >>>
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
> >>>     * Working group at BSDCan:
> >>> 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
> named
> >>> 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
> Gentoo
> >>> as baselayout v2, and was then split off as a separate BSD-licensed
> >>> project. It is under active development, portable, and remains BSD
> licensed
> >>> 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. The
> >>> rc-status command shows how many times a service has restarted.
> >>>
> >>> Device hotplug support and event-driven service management: the hotplug
> >>> 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
> speed
> >>> up booting.
> >>>
> >>> Interactive mode:
> >>> The boot process can be run interactively for more effective debugging.
> >>>
> >>> OpenRC uses the term “runlevels” to refer to the context in which a
> >>> script is running. There are only three at present:
> >>> sysinit (the OpenRC system is starting), boot (start base services when
> >>> the computer is booting), and default (normal execution).
> >>>
> >>> OpenRC, by default, provides a “colorized” 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 it
> >>> 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>
> >>> 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
> group
> >> 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
> cool,
> >> 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
> >>
> >>
> >>
>
> --
>
> --
> Marcelo Araujo            (__)araujo at FreeBSD.org
> \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> Power To Server.         .\. /_)
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>


More information about the freebsd-hackers mailing list