Difference between pages "Package:OpenRC" and "Subarches"

(Difference between pages)
 
 
Line 1: Line 1:
{{Ebuild
+
= Funtoo Linux Sub-Architectures =
|Summary=OpenRC manages the services, startup and shutdown of a host
+
__NOTITLE__
|CatPkg=sys-apps/openrc
+
This page provides an overview of Funtoo Linux sub-architectures (also called ''subarches'') designed for quick and easy reference. Funtoo Linux provides optimized installation images for all sub-architectures listed below. See the [[Funtoo Linux Installation|Funtoo Linux Installation Guide]] to install Funtoo Linux.
|Maintainer=William Hubbs, Drobbins, Oleg
+
|Repository=Funtoo Overlay
+
|Organization=Funtoo Technologies
+
|Overlay=Funtoo
+
}}
+
Funtoo OpenRC is the current implementation of the system startup and init script framework for Funtoo Linux. Official development sources can be found on [http://www.github.com/funtoo/openrc GitHub].
+
 
+
Funtoo OpenRC is an independently-maintained, forked version of the [http://roy.marples.name/projects/openrc/wiki OpenRC] init scripts ([http://www.gentoo.org/proj/en/base/openrc/ now maintained by Gentoo]). Funtoo Linux-specific changes generally relate to [[Funtoo Linux Networking|Funtoo network configuration]].
+
 
+
== Purpose and description ==
+
 
+
OpenRC is an init system for Unixoid operating systems. It takes care of
+
startup and shutdown of the whole system, including services.
+
 
+
It evolved out of the Gentoo "Baselayout" package which was a custom pure-shell
+
startup solution. (This was both hard to maintain and debug, and not very
+
performant)
+
 
+
Most of the core parts are written in C99 for performance and flexibility
+
reasons, while everything else is posix sh.
+
The License is 2-clause BSD
+
 
+
Current size is about 10k LoC C, and about 4k LoC shell.
+
 
+
OpenRC is known to work on Linux, many BSDs (FreeBSD, OpenBSD, DragonFlyBSD at
+
least) and HURD.
+
 
+
Services are stateful (i.e. start; start will lead to "it's already started")
+
 
+
== Startup ==
+
 
+
Usually PID1 (aka. init) calls the OpenRC binary ("/sbin/rc" by default).
+
(The default setup assumes sysvinit for this)
+
 
+
rc scans the runlevels (default: "/etc/runlevels") and builds a dependency
+
graph, then starts the needed init scripts, either serialized (default) or in
+
parallel.
+
 
+
When all the init scripts are started rc terminates. There is no persistent
+
daemon. (Integration with tools like monit, runit or s6 can be done)
+
 
+
== Shutdown ==
+
 
+
On change to runlevel 0/6 or running "reboot", "halt" etc., rc stops all
+
services that are started and runs the scripts in the "shutdown" runlevel.
+
 
+
== Modifying single services ==
+
 
+
Any single service can, at any time, be started/stopped/restarted by calling
+
the init script: /etc/init.d/someservice start
+
 
+
OpenRC will take care of dependencies, e.g starting apache will start network
+
first, and stopping network will stop apache first.
+
 
+
There is a special command "zap" that makes OpenRC 'forget' that a service is
+
started; this is mostly useful to reset a crashed service to stopped state
+
without invoking the (possibly broken) stop function of the init script.
+
 
+
Calling "rc" without any arguments will try to reset all services so that the
+
current runlevel is satisfied; if you manually started apache it will be
+
stopped, and if squid died but is in the default runlevel it'll be restarted.
+
 
+
There is a "service" helper that emulates the syntax seen on e.g. older Redhat
+
and Ubuntu ("service nginx start" etc.)
+
 
+
== Runlevels ==
+
 
+
OpenRC has a concept of runlevels, similar to what sysvinit historically
+
offered. A runlevel is basically a collection of services that needs to be
+
started. Instead of random numbers they are named, and users can create their
+
own if needed. This allows, for example, to have a default runlevel with
+
"everything" enabled, and a "powersaving" runlevel where some services are
+
disabled.
+
 
+
The "rc-status" helper will print all currently active runlevels and the state
+
of init scripts in them:
+
  
 +
The cpuid application can be used to help identify your processor and it's microarchitecture.
 
<console>
 
<console>
# ##i##rc-status
+
sudo emerge cpuid; cpuid | tail -n 1
* Caching service dependencies ... [ ok ]
+
Runlevel: default
+
modules                    [  started  ]
+
lvm                        [  started  ]
+
 
</console>
 
</console>
  
All runlevels are represented as folders in /etc/runlevels/ with symlinks to
+
== 64-bit PC-Compatible ==
the actual init scripts.
+
  
Calling rc with an argument ("rc default") will switch to that runlevel; this
+
{{TableStart}}
will start and stop services as needed.
+
<tr><th class="warn" colspan="3">64-bit AMD Processors</th></tr>
 
+
{{#ask:[[CPU Family::64-bit AMD Processors]]
Managing runlevels is usually done through the "rc-update" helper, but could of
+
|?#
course be done by hand if desired.
+
|?Subarch
e.g. "rc-update add nginx default" - add nginx to the default runlevel
+
|?CFLAGS
Note: This will not auto-start nginx! You'd still have to trigger "rc" or run
+
|?Description
the initscript by hand.
+
|format=template
 
+
|link=none
FIXME: Document stacked runlevels
+
|headers=hide
 
+
|searchlabel=... further results
The default startup uses the runlevels "boot", "sysinit" and "default", in that
+
|sep=,
order. Shutdown uses the "shutdown" runlevel.
+
|template=SubarchList
 
+
}}
 
+
<tr><th class="warn" colspan="3">64-bit Intel Processors</th></tr>
== Syntax of init scripts ==
+
{{#ask:[[CPU Family::64-bit Intel Processors]]
 
+
|?#
Init scripts are shell scripts. OpenRC aims at using only the standardized
+
|?Subarch
POSIX sh subset for portability reasons. The default interpreter (build-time
+
|?CFLAGS
toggle) is /bin/sh, so using for example mksh is not a problem.
+
|?Description
 
+
|format=template
OpenRC has been tested with busybox sh, ash, dash, bash, mksh, zsh and possibly
+
|link=none
others. Using busybox sh has been difficult as it replaces commands with
+
|headers=hide
builtins that don't offer the expected features.
+
|searchlabel=... further results
 
+
|sep=,
The interpreter for initscripts is #!/sbin/runscript
+
|template=SubarchList
Not using this interpreter will break the use of dependencies and is not
+
}}
supported. (iow: if you insist on using #!/bin/sh you're on your own)
+
<tr><th class="warn" colspan="3">64-bit PC-Compatible (Generic) Processors</th></tr>
 
+
{{#ask:[[CPU Family::64-bit Processors (PC-Compatible, Generic)]]
A "depend" function declares the dependencies of this init script. All scripts
+
|?#
must have start/stop/status functions, but defaults are provided. Extra
+
|?Subarch
functions can be added easily:
+
|?CFLAGS
 
+
|?Description
extra_commands="checkconfig"
+
|format=template
checkconfig() {
+
|link=none
doSomething
+
|headers=hide
}
+
|searchlabel=... further results
 
+
|sep=,
This exports the checkconfig function so that "/etc/init.d/someservice
+
|template=SubarchList
checkconfig" will be available, and it "just" runs this function.
+
}}
 
+
{{TableEnd}}
While extra_commands is always available, commands defined in
+
extra_started_commands will only work when the service is started. This can be
+
used for implementing graceful reload and similar behaviour.
+
 
+
Adding a restart function will not work, this is a design limitation within
+
OpenRC. Since there may be dependencies involved (e.g. network -> apache) a
+
restart function is in general not going to work.
+
restart is internally mapped to stop() + start() (plus handling dependencies)
+
(Figuring out a reliable improvement for this "bug" is appreciated)
+
 
+
 
+
== The depend function ==
+
 
+
This is a newline-separated list that uses builtins. A little bit 'dirty'
+
maybe, but simple:
+
 
+
depend() {
+
        need net
+
        use dns logger netmount
+
}
+
 
+
"need" declares a hard dependency - net always needs to be started before this
+
service does
+
"use" is a soft dependency - if dns, logger or netmount is in this runlevel
+
start it before, but we don't care if it's not in this runlevel.
+
"before" declares that we need to be started before another service
+
"after" declares that we need to be started after another service, without
+
creating a dependency (so on calling stop the two are independent)
+
"provide" allows multiple implementation to provide one service type, e.g.:
+
'provide cron' is set in all cron-daemons, so any one of them started
+
satisfies a cron dependency
+
"keyword" allows platform-specific overrides, e.g. "keyword -lxc" makes this
+
init script a noop in lxc containers. Useful for things like keymaps,
+
module loading etc. that are either platform-specific or not available
+
in containers/virtualization/...
+
 
+
FIXME: Anything missing in this list?
+
 
+
== The default functions ==
+
 
+
All init scripts are assumed to have the following functions:
+
 
+
start()
+
stop()
+
status()
+
 
+
There are default implementations in rc/sh/runscript.sh - this allows very
+
compact init scripts. These functions can be overriden per init script as
+
needed.
+
 
+
The default functions assume the following variables to be set in the init
+
script:
+
command=
+
command_args=
+
pidfile=
+
 
+
Thus the 'smallest' init scripts can be half a dozen lines long
+
 
+
== The magic of conf.d ==
+
 
+
Most init scripts need default values. It would be fragile to explicitly source
+
some arbitrary files. By convention runscript will source the matching file in
+
/etc/conf.d/ for any script in /etc/init.d/
+
 
+
So you can set random startup-related things easily. Example:
+
conf.d/foo:
+
 
+
<syntaxhighlight lang="bash">
+
START_OPTS="--extraparameter sausage"
+
 
+
init.d/foo:
+
start() {
+
/usr/sbin/foo-daemon ${STARTOPTS}
+
}
+
</syntaxhighlight>
+
 
+
The big advantage of this split is that most of the time editing of the init
+
script can be avoided.
+
 
+
== Start-Stop-Daemon ==
+
 
+
OpenRC has its own modified version of s-s-d, which is historically related and
+
mostly syntax-compatible to Debian's s-s-d, but has been rewritten from scratch.
+
 
+
It helps with starting daemons, backgrounding, creating PID files and many
+
other convenience functions related to managing daemons.
+
 
+
== /etc/rc.conf ==
+
 
+
This file manages the default configuration for OpenRC, and it has examples of
+
per-initscript variables.
+
 
+
Among these are rc_parallel (for parallelized startup), rc_log (logs all boot
+
messages to a file), and a few others.
+
 
+
== ulimit, and CGroups in Linux ==
+
 
+
Setting ulimit and nice values per service can be done through the rc_ulimit
+
variable.
+
 
+
OpenRC can optionally use CGroups in the Linux kernel for process management.
+
By default each init script's processes are migrated to their own CGroup.
+
 
+
By changing certain values in the conf.d file limits can be enforced per
+
service. It is easy to find orphan processes of a service that persist after
+
stop(), but by default these will NOT be terminated.
+
To change this add rc_cgroup_cleanup="yes" in the conf.d files for services
+
where you desire this functionality.
+
 
+
== Caching ==
+
 
+
For performance reasons OpenRC keeps a cache of pre-parsed initscript metadata
+
(e.g. depend). The default location for this is /lib/rc/cache/
+
 
+
The cache uses mtime to check for file staleness. Should any initscript change
+
it'll re-source the relevant files and update the cache
+
 
+
== Convenience functions ==
+
 
+
OpenRC has wrappers for many common output tasks in libeinfo.
+
This allows to print colour-coded status notices and other things.
+
To make the output consistent the bundled initscripts all use ebegin/eend to
+
print nice messages.
+
 
+
== Commands ==
+
 
+
; rc-update
+
: add or remove a service from a particular runlevel, or implement [[Stacked Runlevels]]
+
; rc-status
+
: show current status of system services
+
; rc
+
: manage runlevel changes
+
 
+
== FAQ ==
+
 
+
=== How do I tell one startup script to depend on another? ===
+
 
+
The easiest way to do this is to modify the <tt>/etc/conf.d</tt> script that corresponds to the service that needs to depend on something else, so let's call this service <tt>this_service</tt>. Add the following to its conf.d file:
+
 
+
<pre>
+
rc_need="other_service"
+
</pre>
+
 
+
Now, <tt>this_service</tt> will depend on <tt>other_service</tt>.
+
 
+
=== OpenRC is ignoring dependencies and not reacting to dependency changes ===
+
 
+
This can happen when your system's time changes suddenly (maybe due to realizing your system clock is wrong and resetting it) and OpenRC dependency cache files are created with future dates. To clear the OpenRC cache, type:
+
 
+
<pre>
+
# rc-update -u
+
</pre>
+
 
+
Alternatively, you can perform this step manually:
+
 
+
<pre>
+
# rm /libexec/rc/cache/*
+
# rm /libexec/rc/init.d/deptree
+
</pre>
+
 
+
Now regenerate the cache by typing:
+
 
+
<pre>
+
# /libexec/rc/bin/rc-depend
+
</pre>
+
 
+
The OpenRC dependency cache should now be up-to-date and OpenRC should behave properly again.
+
 
+
== History ==
+
 
+
The Gentoo modular init scripts were developed by Daniel Robbins for Gentoo Linux 1.0_rc6 during most of 2001 and released in September 2001 (TODO: add refs). After their development, the dependency-based init script system was maintained by a number of senior developers, starting with Azarah (Martin Schlemmer), with migration to the new init system assisted by Woodchip (Donnie Davies) who converted all ebuild init scripts to work with the new system. As Grant Goodyear notes:
+
 
+
''My recollection is that one of woodchip's more impressive early feats was the
+
''complete replacement of all of the init scripts in Portage for Gentoo Linux
+
''1.0_rc6. Through 1.0_rc5 Gentoo had used fairly standard rc scripts modified
+
''from Stampede Linux, but for 1.0_rc6 Daniel Robbins (drobbins) and Martin
+
''Schlemmer (azarah) had created a new dependency-based init script system that
+
''is still used today. Within a span of days Donny rewrote every single init
+
''script in the Portage tree and committed new masked packages to await the
+
''release of 1.0_rc6. Thanks to woodchip (and drobbins and azarah, of course) the
+
''transition to the new init scripts was nearly painless.'' <ref>http://www.gentoo.org/news/en/gwn/20040426-newsletter.xml</ref>
+
 
+
Roy Marples became a Gentoo/Linux developer in 2004 and maintained the modular network scripts for the Gentoo baselayout package. Towards the end of 2005, he became the primary maintainer for baselayout and the init scripts.
+
 
+
At the start of 2007, Roy Marples announced the ongoing development of baselayout-2, containing a rewritten init script coded in C and allowing POSIX sh init scripts instead of forcing the use of bash. By mid 2007, Roy Marples had re-implemented the Gentoo init script design created by Daniel Robbins, using an entirely new code base. Alpha and pre-release baselayout-2 snapshots were added to Gentoo's Portage tree as an optional component.
+
 
+
Towards the end of 2007, Roy Marples retired as a Gentoo developer. Baselayout-2 was still in the pre stage, and aside from the gentoo-fbsd users, it was masked. However, Roy Marples desired to keep the baselayout-2 project moving forward as an independent project. The Gentoo Council permitted Roy Marples to release OpenRC under the 2-clause BSD license, managed by him as an external project.
+
 
+
Around mid-2010, Roy Marples decided to no longer maintain OpenRC. At this point, he transferred development back to Gentoo. However, Daniel Robbins continues to maintain an independent, forked version of OpenRC for Funtoo Linux, which includes a Funtoo-specific network configuration
+
system.
+
 
+
= References =
+
<references/>
+
 
+
[[Category:Projects]]
+
{{EbuildFooter}}
+

Revision as of 10:08, December 20, 2014

Funtoo Linux Sub-Architectures

This page provides an overview of Funtoo Linux sub-architectures (also called subarches) designed for quick and easy reference. Funtoo Linux provides optimized installation images for all sub-architectures listed below. See the Funtoo Linux Installation Guide to install Funtoo Linux.

The cpuid application can be used to help identify your processor and it's microarchitecture.

sudo emerge cpuid; cpuid | tail -n 1

64-bit PC-Compatible

64-bit AMD Processors
amd64-bulldozerThe amd64-bulldozer subarch supports the AMD bulldozer microarchitecture CPUs, which were released from late 2011 through the first quarter of 2012 as a replacement for the K10 microarchitecture CPUs.-march=bdver1 -O2 -pipe
amd64-jaguarAMD jaguar microarchitecture debuted in mid-2013 and is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the Playstation 4 and Xbox One,-march=btver2 -O2 -pipe
amd64-k10The amd64-k10 subarch provides support for the AMD Family 10h processors, which were released in late 2007 as a successor to the AMD K8 series processors.-march=amdfam10 -O2 -pipe
amd64-piledriverThe amd64-piledriver subarch supports the AMD Piledriver microarchitecture produced by AMD from mid-2012 through 2015, which is the successor to the AMD bulldozer microarchitecture.-march=bdver2 -O2 -pipe
amd64-steamrollerThe amd64-steamroller subarch supports the AMD steamroller microarchitecture, produced from early 2014. It is the successor to the AMD Piledriver microarchitecture.-march=bdver3 -O2 -pipe
64-bit Intel Processors
atom_64The atom_64 sub-architecture supports 64-bit capable Intel Atom CPUs.-O2 -fomit-frame-pointer -march=atom -pipe
core2-64The core2_64 subarch supports 64-bit-capable processors based on the Core microarchitecture and all processors of the Penryn microarchitecture. This includes all Intel Core 2 branded processors, some Celeron, some Pentium and some Xeon branded processors.-march=core2 -O2 -pipe
corei7The corei7 subarch supports the Nehalem, Westmere, Sandy_Bridge, Ivy Bridge, and Haswel microarchitecture-based Intel Pentium/Celeron, Intel Core i3, i5, i7 and Xeon Processors.-march=corei7 -O2 -pipe
intel64-haswellThe intel64-haswell subarch specifically supports processors based on Intel's Haswell microarchitecture. Haswell desktop processors are branded as 4th Generation Intel Core i3, Core i5, and Core i7 Processors.-march=core-avx2 -O2 -pipe
64-bit PC-Compatible (Generic) Processors
generic_64The generic_64 subarch is designed to support 64-bit PC-compatible CPUs, such as the AMD K8-series processors, which were introduced in late 2003.-mtune=generic -O2 -pipe