From J.deBoynePollard-newsgroups@NTLWorld.com Mon Jan 11 04:51:37 2016 Date: Mon, 11 Jan 2016 04:51:09 -0500 From: Jonathan de Boyne Pollard To: Benjamin Kaduk Subject: Re: relaunchd: a portable clone of launchd Benjamin Kaduk: > Mark Heily did write up a short piece noting that there are three > projects aiming to modernize system startup, which will probably make > it into the report. The current plan is to list him, you, and jkh as > the contacts on that entry, and mention in the body who is responsible > for which project, but of course that can change if you would prefer > otherwise. Just make sure, given what he's already written in public only days ago, that you fact check it mercilessly. He got a of of things blatantly wrong, including mixing up systembsd and systemd, erroneously ascribing to me his own idea of bringing D-Bus into his own project ("I'm thinking of using D-Bus as the RPC mechanism for relaunchd, since a lot of open source programs are already using D-Bus."), and not noticing that systembsd is an OpenBSD project whose instigator (Ian Sutton) has long since discussed porting to FreeBSD. And as you can see, that led several people (including Jordan Hubbard) completely up the garden path. I'd like to give you a status report that includes all of the new stuff for PC-BSD 10.2 that I'm on the cusp of releasing. But we're working to the same calendar. (-: I've quickly thrown something together below. I've probably missed some things. The nosh project Jonathan de Boyne Pollard J.deBoynePollard-newsgroups@NTLWorld.COM Introduction and blurb FreeBSD binary packages Installation How-To Roadmap Commands A slightly outdated nosh Guide The Supervision mailing list

The nosh package is a suite of system-level utilities for initializing, running, and shutting down BSD systems; and for managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d system, taking leaves out of several books including named milestones from Solaris SMF, daemontools-encore service control/status mechanisms, UCSPI, and separated service and system management like IBM AIX. It comprises a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying it to its native service definitions and creating additional native services. It is portable (being also available for Linux), it is composable, it already has a large knowledgebase accrued over more than a decade of how to manage daemons and logging this way that one can draw upon, it provides a migration path from the world of systemd Linux that is potentially useful in ports and elsewhere, and it does not require new kernel APIs. And it provides things that the world now considers de rigueur for system and service management: clean service environments all of the time, with no more problems because of the service command; orderings and dependencies between services; parallelized startup and shutdown, including fsck; strictly sized-capped and autorotated logging; the service manager as a "subreaper"; and extensive use of the capabilities of kevent().

Since the last status report, in October 2015, the project has seen: the complete replacement of its event-handling subsystem on Linux; the introduction of tools for exporting cyclog/multilog logs via RFC 5426 to remote log handlers (such as logstash); and the switching of the user-mode virtual terminal subsystem on BSD to using USB devices directly, a more powerful device interface than sysmouse et al. because it permits directly positioning touch devices for mice and other stuff (and thus permits "mouse integration" under VirtualBox for those who run PC-BSD/FreeBSD on VirtualBox virtual machines), but sysmouse et al. can still be used.

In version 1.24, which should be released by the time of the publication of this status report (and was undergoing testing when the report was compiled), there are extensive additions for supporting a purely-ZFS system with an empty /etc/fstab (as the PC-BSD 10.2 system installer creates), and the ability to convert systemd unit files' process priority settings to BSD's rtprio/idprio.

Version 1.24 also sees a large chunk taken out of the remainder of the on-going project to create enough native service bundles and ancillary utilities to entirely supplant the rc.d system. The progress of this project has been open from the start, and can be followed on the nosh roadmap WWW page. As of version 1.24 as you can see there are a mere 27 items remaining out of the original target list of 157, with a 28th and a 29th (from PC-BSD 10.2) added. Items crossed off by version 1.24 include (amongst others) mfs support for /tmp, static ARP and networking, persistent "entropy" for the randomness subsystem, pefs, and hald.

As always, your help will be gratefully received with items on the task list, which in the main involve items outwith the nosh project which would make overall system integration cleaner, and friendlier to modern systems.

Or simply take the installation how-to in hand and see how you get on. Suggestions and bug reports can be sent to the Supervision or FreeBSD Hackers mailing lists.

nosh takes a page out of Linux's book, adopting its idea of "emergency" and "rescue" mode bootstraps, the latter superseding "single-user" mode (and allowing that single user to be someone other than root) and the former being a truly barebones bootstrap that doesn't even run shell .profile scripts. To fully enable this same functionality on FreeBSD, the kernel needs to support passing a -b option to process #1, and the loader needs something like a boot_bare variable (along the same lines as boot_single, of course). (History: The -b mechanism and idea date back to version 2.57d of Miquel van Smoorenburg's System 5 init clone, dated 1995-12-03, and was already known as "emergency boot" by 1997.) Linux fsck has a mode in which it can spit out machine-readable progress reports (to a designated open file descriptor) when invoked non-interactively during the bootstrap. The nosh package supports this, with a daemon that takes the machine-readable progress information from multiple parallel fscks and displays progress bars. The similar instrumentation of the FreeBSD fsck would be very welcome. The external configuration import system needs to be triggered in the right places, when things like bsdconfig alter configuration files. Please help to identify these places, and with creating the necessary hooks.