Melyik init replacementet ?

Flame

Versenyzők:
eINIT:

* Upstart is designed to be “event-based” – eINIT uses events too, but eINIT events are used for different things and the events provide less overhead.

* eINIT is designed for embedded devices and things like headless servers.

* Upstart is designed with backwards-compatibility to sysv in mind, eINIT is not. That doesn’t mean you can’t use init.d scripts with eINIT (as of -svn-550, you can), it just means that’s not the primary focus. Whenever compatibility would get in the way, it’s dropped.

"eINIT" seeks to fix this overhead by integrating module management into the init system itself and make init.d scripts obsolete, and also to increase overall boot time by using aggressive paralellisation.

Upstart is an event-based replacement for the init daemon,

initng:
Initng starts a process as soon as all of its dependencies are met. It can start several processes in parallel. Initng is designed to significantly increase the speed of booting a Unix-compatible system by starting processes asynchronously.

baselayout-2:
Gentoo's init system is another important feature of its system. It is similar to the System V init system that most Linux distributions use, but uses dependency based scripts and named run levels rather than numbered ones. It also includes a command called rc-update which manages runlevels.

A faster init system known as initng is available and under active development on the Gentoo forums.

A new baselayout, baselayout-2, version is nearing completion, that moves core system scripts from bash scripting to C code. This change should make boot time and other lower level services faster

Megjegyzés:
BSD-style:
Advantages: Simple and easy to edit manually.

Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system.

SysV-style:
Advantages: Flexibility and scalability.

Problems: Complexity.

Valaki probálta már ezeket ? Mik a tapasztalatok ? Melyik jelentheti a jövőt.

  • 1847 megtekintés

( Replaced | 2007. 06. 22., p – 19:19 )

ha mar altalam erthetetlen okokbol a flame-be raktad, akkor lenne par kerdesem:

"Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system."

ez mit akar jelenteni? mert ez FUD.
Persze ha a monolitikus inirendszerre gondol, akkor igaza van, csak azt mar nem hasznaljak evek ota sehol(?).

"SysV-style:
Advantages: Flexibility and scalability."

ahaha, az a ganyolas? egy rakat kulonbozo konyvtar abc sorrendben indulo scriptekkel ossze-vissza keresztbe symlinkezve, ez minden csak nem flexible :P

--
Those who do not understand Unix are condemned to reinvent it, poorly

szerintem a monolitikus (regi BSD) initet osszemossak a modularis (NetBSD) initrendszerrel, amit az osszes modern BSD valtozat hasznal.
Ami slackyben van az valahol kb a ketto kozottt van.
Gentoo meg nem tudom, de mindjart megnezem a cvs/svn-ukben ha van nekik olyan.

--
Those who do not understand Unix are condemned to reinvent it, poorly

Az OpenBSD szerintem nem hasznal modularis (NetBSD) initrenszert, vagy tevedek? Vagy nem modern?! Bar fogalmam sincs hogy a NBSD modularis initrendszer hogy nez ki, de itt csak ezek vannak: 


$ ls /etc/rc*  
/etc/rc                 /etc/rc.conf.local      /etc/rc.securelevel
/etc/rc.conf            /etc/rc.local           /etc/rc.shutdown

Ebbol is igazabol az rc, rc.conf paros a lenyeg, man
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

bonyolult, nem eleg a kod ujrafelhasznalas (marint, hogy funkciokat alkotna es azokat mar csak meghivni kellene, mint az rc.subr rendszerben), rosszul kommentezett, bar ez utobbi nem feltetel a jo mukodeshez, de a karbantartashoz igen. nem latom rajta, hogy ez egy jo keretrendszer lenne, hanem csak sok script, ami egymast inditja
nem eleg osszeszedett szerintem.

szerk: nyugtass, meg hogy ez vegul nem ilyen hierarchiaba kerul

--
Those who do not understand Unix are condemned to reinvent it, poorly

Nézz bele egy scriptbe.
apache: 


depend() {
        need net
        use mysql dns logger netmount postgresql
        after sshd
}

Az összes e betüvel kezdődő parancs újra felhasználás.
És a fentiek is.
start-stop-daemon is :)

ha vim el init.d könyvtárba szerkesztesz valamit: 


#!/sbin/runscript
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

depend() {

}

start() {

}

stop() {

}

restart() {

}

templattel nyit.

Minde script, vehet fel beállítást az rc.conf bol és vele megegyező nevű , conf.d beli fileból, ez is egységes.

Amiböl több lehet, (interface,openvpn) nem kell külön scriptet írni.

openvpn.egyik
openvpn.masik

simlink az openvpn -re, egyik,masik nevű conf filet hasznalja.
Egységes.

Megnyugtatlak :)

Egy egyszerű script: 


#!/sbin/runscript

depend() {
        use net
        after logger
        before nfs
        use hotplug
        after vmware
}

start() {
        ebegin "Starting cupsd"
        start-stop-daemon --start --quiet --exec /usr/sbin/cupsd
        eend $?
}

stop() {
        ebegin "Stopping cupsd"
        start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd
        eend $?
}

(A restartot kitalálja magától)

es ehhez mit szolsz?
nem egy masik scriptet hiv meg interpreternek, hanem source-olja a kreterendszert, ami konfig fajlkent ertelmezi.
valamint minden, ami lehet az rc.d-ben van benne (network, mount) es az rcorder nevu c program donti el a sorrendet, amit majd meghiv az /etc/rc indulaskor. dependency es meta csomagok alapjan termeszetesen.
olvastad a design and implementation of the netbsd rc.d system-et? nagyon szepen osszeszedi az eddigi rendszerek hibait es levezeti az rc.d rendszer mukodeset 


#!/bin/sh
#
# $NetBSD: lighttpd.sh,v 1.1.1.1 2005/09/04 06:37:05 jlam Exp $
#
# PROVIDE: lighttpd
# REQUIRE: DAEMON

. /etc/rc.subr

name="lighttpd"
rcvar=$name
command="/usr/pkg/sbin/${name}"
conf_file="/etc/pkgsrc/lighttpd/${name}.conf"
required_files="${conf_file}"
extra_commands="reload"
command_args="-f ${conf_file}"

load_rc_config $name
run_rc_command $1

ui.: ez volt, az amin kiakadtam: rc-mount.sh

--
Those who do not understand Unix are condemned to reinvent it, poorly

"nem egy masik scriptet hiv meg interpreternek, hanem source-olja a kreterendszert, ami konfig fajlkent ertelmezi."

"nevu c program donti el a sorrendet, amit majd meghiv az /etc/rc indulaskor. dependency es meta csomagok alapjan termeszetesen.
olvastad"

#!/sbin/runscript

Ha elkerülte volna a figyelmedet.

#file /sbin/runscript
/sbin/runscript: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped

baselayout része, (nem a minicom runscript)

( hrgy84 | 2007. 06. 22., p – 19:29 )

Tapasztalatok:

- sysvinit: ismerjük, jó, szeressük.
- baselayout-2: pár initscript lassabb tőle, de működik
- einit: Borzalom. Nemjutottam el a konzolig egy egyszerű mysql szerveren. runlevel 'boot' után nemlépett tovább az istennek se.
- upstart: Mé', van hozá ebuild?

Kadmind nehezen indul vele, és a MySQL is kissé lassabban reagál. Bár érdekes, hogy nem közvetlen a kadmind volt a nehézkes, hanem szerintem már az is parallel, és valami lefogta, de hogy mi arra nem tudtam rájönni. A háló tuti nem, mert az fixip-s volt, tehát nem várt DHCP-re.

Hát, ami igaz az igaz, láttam már 5-6 percet is gondolkodni egy NetWare-t... Mondjuk ott lehet olyas is a hiba, hogy egymásra várnak, mert a NetWare tudtommal nagyon alapszinten kezel dependenciákat, jobbára a bootstrap után a autoexec.ncf-ben lecő sorrend határoza meg a betöltést.