NextBSD, kann das mal ein Guru (Yamagi o.ä) erklären ?

H

handwerker

Well-Known Member
Hallo,

kann das Thema mal jemand erklären für einen "Normalsterblichen" der nicht Informatik mit Schwerpunkt Betriebssystemdesign studiert hat :confused:

Insbesondere die Argumente dagegen, oder was das dragonflybsd/iOS/Android ? für Mechanismen enthält ?

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
http://www.nextbsd.org/
http://blog.darknedgy.net/technology/2015/08/26/0/
 
Das würde ein langer Beitrag werden. Aber kurz zusammengefasst: Jordan Hubbard hat so um und bei 1993 FreeBSD mitbegründet und hat das Projekt bis 2001 sozusagen geleitet. Dann wechselte er zu Apple, wo er in verschiedenen Rollen hauptsächlich für die Entwicklung von Darwin (also dem OS X zugrundeliegenden Unix) verantwortlich war. Hubbards Wechsel zu Apple war damals einer der Hauptgründe für die "BSD is dying" Kampagne einiger Personen aus dem Konkurrenzlager. FreeBSD gab sich daraufhin eine demokratische Struktur, in der einzelne Personen nur noch einen begrenzten Einfluss haben. Letztes Jahr verließ Jordan Hubbard dann Apple und ging zu iX Systems, die Systeme auf Basis von FreeBSD bauen und auch ein großer Sponsor sind.

Recht schnell zeigte sich, dass Jordan Hubbard und die FreeBSD-Entwickler sowie der größere Teil der Community unterschiedliche Vorstellungen von der Zukunft haben. Jordan sieht die Sache aus einer Apple-Perspektive, schon in seinen ersten Mails nach seiner Rückkehr in die FreeBSD-Welt warb er für die Integration diverser Techniken aus Darwin in FreeBSD. Das führte zu Widerstand. Das Jordan auf mehreren Konferenzen so tat, als würde er für die FreeBSD-Entwickler sprechen, machte die Sache nicht besser. So kam zum Beispiel das Gerücht zustande, dass FreeBSD planen würde auf launchd zu wechseln. "NeXTBSD", ältere Semester werden das Wortspiel mit dem OS X Vorläufer NeXTStep erkennen, ist eine direkt Folge dieser Entwicklung.

Ich finde, dass Jordan Hubbard in einigen Dingen durchaus recht hat. Wir FreeBSDler haben teilweise zu lange Reviewprozesse und einige Regeln sind zu hart. So wird kaum etwas ins System aufgenommen, was vorhandene Dinge verändert. Und es werden generell keine Änderungen vorgenommen, die Workloads benachteiligen. Selbst wenn sie einer breiten Masse Vorteile bringen würden. Oder anders gesagt: Man darf gerne konservativ sein. Wir leben davon, dass wir ein konservatives System sind. Aber man muss auch darauf achten, dass eine konservative Denkweise nicht dazu führt, dass man Fortschritt generell kritisch gegenüber steht.

Auf der anderen Seite geht man beim NeXTBSD gerade wie mit der Axt im Walde vor. Oder will es zumindest tun. Beispielsweise muss man sich fragen, was MACH-IPC in einem unixoiden System zu suchen hat. Oder auch launchd. Wenn es große Vorteile bringt und es einen Konsens darüber gibt, gerne. Aber wenn es nur darum geht eine Service-Überwachung zu bekommen muss man sich fragen, wieso man 29 Jahre Rückkompatibilität einfach wegwerfen will. Genauso einheitliche Config-Files. Natürlich wäre das schön. Aber man ist nicht auf einer grünen Wiese, es gibt >30 Jahre Vergangenheit...

Insgesamt stehe ich dem neutral gegenüber. Erstmal muss NeXTBSD beweisen, dass sie nicht den Weg von so vielen anderen Forks gehen. EccoBSD (schrieb sich das so?), MirBSD, DesktopBSD, EdgeBSD, Birtrig scheint noch aktiv zu sein und wird trotzdem von niemanden genutzt, etc. Und dann kann man weitersehen.
 
Es gab noch einen anderen Hans(nicht der Pal) der verbreitet hat er als Openlaunchd-Entwickler würde das in FreeBSD integrieren. Danach kamen in vielen Threads auf den Newsseiten Leute an und meinten, so schlecht kann Systemd nicht sein, wenn jetzt selbst FreeBSD auf artverwandtes wechselt. Ich glaub nicht daran. Nicht das launchd besonders schlecht wäre sondern das man andere Baustellen hat die mehr stören.
 
Einmal unabhängig von der Frage, ob launchd nun gut oder schlecht, sinnvoller oder nicht wäre, sehe ich es in der nächsten Zeit aus zwei Gründen nicht in FreeBSD:
  • Es gibt bisher nicht mal den Ansatz einer öffentlichen Diskussion launchd zu integrieren. Ohne öffentliche Diskussion und eine entsprechende Vorlaufzeit wird das aber nicht passieren können. So etwas braucht aber seine 2 bis 3 Jahre, weshalb FreeBSD 12.0 das früheste Ziel wäre. Bei launchd kommt noch dazu, dass vor inzwischen etwa 10 Jahen beim ersten Versuch es zu integrieren in der damaligen Diskussion die Stimmung deutlich dagegen war. Schon daher wird man die Diskussion besonders gründlich und umfassend führen wollen.
  • launchd wäre ein riesiger POLA-Bruch, die größte für Anwender sichtbare Änderung seit vielen Jahren. Wenn man es richtig integrieren will, müssten rc-Scripte verschwinden. Das hieße, dass ein aus Anwendersicht seit Mitte der 1980er Jahre nahezu unveränderter Bereich grundlegend umgebaut und zehntausende Scripte dort draußen auf einen Schlag unbrauchbar werden würden. Das zu rechtfertigen würde schon einiges an Vorteilen verlangen. Wenn es nur um Service-Überwachung und Parallelisierung des Starts geht, könnte man es auch wesentlich weniger invasiv in rc umsetzen.
Und man darf bei der ganzen Sache nicht vergessen, dass launchd bei weitem nicht der einzige Servicemanager ist. Es gibt inzwischen eine ganze Reihe anderer Projekte, die ihre Erfahrungen auf launchd, systemd und co. gezogen haben. nosh, runit und s6, nur im einmal 3 Stück zu nennen. Schon daher könnte man nicht mehr blind auf launchd setzen, man müsste auch diese Alternativen evaluieren und zuerst eine Vorabentscheidung zu Gunsten eines dieser Systeme treffen.
 
Yamagi schrieb:
Und man darf bei der ganzen Sache nicht vergessen, dass launchd bei weitem nicht der einzige Servicemanager ist.
Zum Vergrößern anklicken....
Yamagi, kannst du bitte kurz erklären was was solche Servicemanager leisten solllen und warum die bisherigen Lösungen - boot/init und rc scripte wenn ich das recht verstehe - tatsächlich oder vermeintlich unzureichend sind. Anders gesagt: Um was geht es bei dieser Diskussion ?
 
instabile Software..
ein launchd+co entstanden nicht zuletzt, weil man daemons nicht nur starten will, sondern auch ueberwachen.
Wenn gecrashed, bitte starte (automatisch) neu.
 
double-p schrieb:
ein launchd+co entstanden nicht zuletzt, weil man daemons nicht nur starten will, sondern auch ueberwachen.
Zum Vergrößern anklicken....
Das erscheint mir als ein plausibles Argument. Die Frage ist allein was hier unter "überwachen" verstanden wird und ich vermute mal dass da eine ganze Menge problematischer Dinge dranhängen, oder ?.
Wenn gecrashed, bitte starte (automatisch) neu.
Zum Vergrößern anklicken....
Wenn es nur das ist: In Erlang gibt es eine "Heartbeat-Node" der alle laufenden Erlang-Knoten ünerwacht und neu startet falls die crashen. Dazu brauchte man nicht alle umzumodeln...
 
Man kann immer irgendwie was bauen was auf Altem aufsetzt und neue Features bringt, ohne alles umzubauen. Aber gerade so sind fürchterliche Projekte wie Xorg entstanden. Es geht da ja in der Diskussion weniger um "wir brauchen genau Feature X", sondern mehr darum das ganze Konzept zu modernisieren.

Ohne jetzt jemanden auf den Schlips treten zu wollen, aber mir ist schon klar, dass sich da der > 40 jährige mit seinem FreeBSD CDE Desktop in seinen Grundsätzen angegriffen fühlt. Ich hab selbst genug Leute in der Familie wo ich das bei jedem Windows Update erlebe. Und nach dem Upgrade will man dann doch nicht zurück, weil man die Vorteile gesehen hat.

Aber FreeBSD kann auch nicht ewig auf der Stelle stehen bleiben. Sicherlich ist ein neues Init-System nicht so dringend nötig, da gibt es sicherlich noch andere Baustellen, aber man sollte den Blick über den Tellerrand nicht scheuen.

Um mal einen kleinen Blick zu gewähren:
Das Start-Skript von MariaDB ein mal unter FreeBSD und ein mal unter Linux/systemd:

FreeBSD:
Code: 
#!/bin/sh

# $FreeBSD: head/databases/mariadb55-server/files/mysql-server.in 361647 2014-07-12 22:42:33Z rakuco $
#
# PROVIDE: mysql
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable mysql:
# mysql_(instance_)?enable (bool):    Set to "NO" by default.
#            Set it to "YES" to enable MySQL.
# mysql_(instance_)?limits (bool):    Set to "NO" by default.
#            Set it to yes to run `limits -e -U mysql`
#            just before mysql starts.
# mysql_(instance_)?dbdir (str):    Default to "/var/db/mysql"
#            Base database directory.
# mysql_(instance_)?args (str):    Custom additional arguments to be passed
#            to mysqld_safe (default empty).
# mysql_(instance_)?pidfile (str): Custum PID file path and name.
#            Default to "${mysql_dbdir}/${hostname}.pid".
# mysql_(instance_)?user (str): User to run mysqld as
#            Default to "mysql" created by the port
# mysql_(instance_)?optfile (str): Server-specific option file.
#            Default to "${mysql_dbdir}/my.cnf".
# mysql_instances (str): Set to "" by default. 
#            If defined, list of instances to enable

. /etc/rc.subr

name="mysql"
rcvar=mysql_enable

load_rc_config $name

: ${mysql_enable="NO"}
: ${mysql_limits="NO"}
: ${mysql_user="mysql"}
: ${mysql_limits_args="-e -U $mysql_user"}
: ${mysql_dbdir="/var/db/mysql"}
: ${mysql_optfile="${mysql_dbdir}/my.cnf"}

command="/usr/sbin/daemon"
procname="/usr/local/libexec/mysqld"
start_precmd="${name}_prestart"
start_postcmd="${name}_poststart"

if [ -n "$2" ]; then
    instance="$2"
    load_rc_config ${name}_${instance}
    case "$mysql_instances" in
    "$2 "*|*" $2 "*|*" $2"|"$2")
        eval mysql_args="\${mysql_${instance}_args:-\"${mysql_args}\"}"
        eval mysql_dbdir="\${mysql_${instance}_dbdir:-\"/var/db/mysql_${instance}\"}"
        eval mysql_limits="\${mysql_${instance}_limits:-\"${mysql_limits}\"}"
        eval mysql_user="\${mysql_${instance}_user:-\"${mysql_user}\"}"
        eval mysql_limits_args="\${mysql_${instance}_limits_args:-\"-e -U $mysql_user\"}"
        eval mysql_optfile="\${mysql_${instance}_optfile:-\"${mysql_dbdir}/my.cnf\"}"
        eval mysql_pidfile="\${mysql_${instance}_pidfile:-\"${mysql_dbdir}/`/bin/hostname`.pid\"}"
    ;;
    *)
        err 1 "$2 not found in mysql_instances" ;;
    esac
else
    if [ -n "${mysql_instances}" -a -n "$1" ]; then
        for instance in ${mysql_instances}; do
            eval _enable="\${mysql_${instance}_enable}"
            case "${_enable:-${mysql_enable}}" in
            [Nn][Oo]|[Ff][Aa][Ll][Ss][Ee]|[Oo][Ff][Ff]|0)
                continue
            ;;
            [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
            ;;
            *)
                if [ -z "$_enable" ]; then
                    _var=mysql_enable
                else
                    _var=mysql_${instance}_enable
                fi
                warn "Bad value" \
                    "'${_enable:-${mysql_enable}}'" \
                    "for ${_var}. " \
                    "Instance ${instance} skipped."
                continue
            ;;
            esac
            echo "===> mysql instance: ${instance}"
            if /usr/local/etc/rc.d/mysql-server $1 ${instance}; then
                success="${instance} ${success}"
            else
                failed="${instance} (${retcode}) ${failed}"
            fi
        done
        exit 0
    else
        mysql_pidfile=${mysql_pidfile:-"${mysql_dbdir}/`/bin/hostname`.pid"}
    fi
fi

pidfile=$mysql_pidfile
mysql_install_db="/usr/local/bin/mysql_install_db"
mysql_install_db_args="--basedir=/usr/local --datadir=${mysql_dbdir} --force"
command_args="-c -f /usr/local/bin/mysqld_safe --defaults-extra-file=${mysql_optfile} --user=${mysql_user} --datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}"

mysql_create_auth_tables()
{
    eval $mysql_install_db $mysql_install_db_args
        [ $? -eq 0 ] && chown -R ${mysql_user}:$(id -gn $mysql_user) ${mysql_dbdir}
}

mysql_prestart()
{
    local dir
    for dir in /etc /etc/mysql; do
        if [ -f "${dir}/my.cnf" ]; then
            echo "Please move existing my.cnf file from ${dir} to /usr/local${dir}"
            return 1
        fi
    done
    if [ ! -d "${mysql_dbdir}/mysql/." ]; then
        mysql_create_auth_tables || return 1
    fi
    if checkyesno mysql_limits; then
        eval `/usr/bin/limits ${mysql_limits_args:-"-e -U $mysql_user"}` 2>/dev/null
    else
        return 0
    fi
}

mysql_poststart()
{
    local timeout=15
    while [ ! -f "${pidfile}" -a ${timeout} -gt 0 ]; do
        timeout=$(( timeout - 1 ))
        sleep 1
    done
    return 0
}

run_rc_command "$1"

Linux/systemd:
Code: 
[Unit]
Description=MariaDB database server
After=syslog.target

[Service]
User=mysql
Group=mysql

ExecStart=/usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid
ExecStartPost=/usr/bin/mysqld-post

Restart=always
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Und jetzt noch mal eine Status-Anfrage an den MariaDB-Server:
FreeBSD:
Code: 
# service mysql-server status
mysql is running as pid 909.

Linux/systemd:
Code: 
# systemctl status mysqld
● mysqld.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor preset: disabled)
   Active: active (running) since Sa 2015-10-17 12:18:12 CEST; 13s ago
  Process: 3707 ExecStartPost=/usr/bin/mysqld-post (code=exited, status=0/SUCCESS)
 Main PID: 3706 (mysqld)
   CGroup: /system.slice/mysqld.service
           └─3706 /usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid

Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] InnoDB: Highest supported file format is Barracuda.
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] InnoDB: 128 rollback segment(s) are active.
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] InnoDB: Waiting for purge to start
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 1618470
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] Plugin 'FEEDBACK' is disabled.
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] Server socket created on IP: '::'.
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] Event Scheduler: Loaded 0 events
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: 151017 12:18:11 [Note] /usr/bin/mysqld: ready for connections.
Okt 17 12:18:11 ArchLinuxKVM.local mysqld[3706]: Version: '10.0.21-MariaDB-log'  socket: '/run/mysqld/mysqld.sock'  port: 3306  MariaDB Server
Okt 17 12:18:12 ArchLinuxKVM.local systemd[1]: Started MariaDB database server.
...
 
rubricanis schrieb:
Das erscheint mir als ein plausibles Argument. Die Frage ist allein was hier unter "überwachen" verstanden wird und ich vermute mal dass da eine ganze Menge problematischer Dinge dranhängen, oder ?.

Wenn es nur das ist: In Erlang gibt es eine "Heartbeat-Node" der alle laufenden Erlang-Knoten ünerwacht und neu startet falls die crashen. Dazu brauchte man nicht alle umzumodeln...
Zum Vergrößern anklicken....
Ja eben.. dependencies. DAS ist dann das Monster-Thema.

Aber NeXTBSD ist doch hoffentlich mehr als nur dieses Hype-Thema "systemd-or-else"?
 
Nur man darf bei der Einfachheit von Unit-Files nicht vergessen, dass Komplexität nicht verschwindet. Im MySQL Beispiel verliert man extrem an Features:
  • Die Unit-File für systemd stellt nicht sicher, dass das Datenbankverzeichnis tatsächlich vorhanden ist und legt es bei Bedarf auch nicht an.
  • Die kümmert sich nicht drum, ob die my.cnf an der richtigen Stelle liegt.
  • Dort ist keine Unterstützung für mehrere Instanzen, man muss die Unit-File kopieren und editieren. Macht bei Updates Spaß.
  • 'Restart=always' ist brandgefährlich. Ich habe genug MySQLs gesehen, die sich durch sinnloses Endlos-Neustarten kaputtrecovered haben. Dort sollte auf jeden Fall ein Check rein, ob er nicht beim Recovery abgeschmiert ist und der Operator besser mal einen Blick raufwirft.
Ja, Unit-Files sind schön leichtgewichtig und viele einfache Sachen lassen sich damit elegant lösen. Aber gerade in komplexeren Szenarien sind sie oft zu leichtgewichtig. Das hat zu dem Anti-Pattern geführt, dass das Unit-File erst einmal ein Script aufruft, was all das tut, was sich nicht direkt oder nur kompliziert in ihm abbilden lässt. Das kann auch nicht Sinn der Sache sein. Davon abgesehen sind einfache rc-Scripte unter FreeBSD auch nicht komplexer als einfache Unit-Files.
 
Sicherlich kann man jetzt Rosinen picken und sich die Schwachstellen in den Unit-Files aussuchen. Genauso kann man auch argumentieren, dass es nicht die Aufgabe des Init-Dienstes ist, die zu startenden Dienste korrekt einzurichten. z.B. der Check der my.cnf ist ja auch eher der Umstellung in FreeBSD geschuldet, weil die Anfangs auch in /etc liegen durfte/sollte.

Sich die Unit-Files nach eigenen Wünschen selbst einzurichten, abseits der Distributionsvorgaben, ist auch nicht verboten. etc-Dateien Update-Orgien sind ja nun auch unter FreeBSD nichts neues.

Kleinere Sachen kann man ja auch per "start-Parameter" bei systemd erledigen. Also um ein spezielles Netzwerkinterface per dhcp zu starten muss man sich kein Unit-File anlegen sondern kann auch einfach:

Code: 
systemctl start dhcpcd@eth0

ausführen. Genauso könnte man sicher auch MySQL-Instanzen verwalten, wenn man dann ein entsprechendes Unit-File macht, ähnlich dhcpcd.

Es liegt halt einfach viel mehr Know-How beim Init-Dienst, als bei den speziellen Start-Skripten. Gerade was verzögerter Start, Limits, Sandboxing und allgemeinen Status angeht. Das zeigt ja auch schön die Status-Abfrage an den Dienst.

Und ich sehe halt keinen Grund warum ein modernes Init-System nicht auch in FreeBSD Einzug halten könnte/sollte. Ähnlich pkg wird es wahrscheinlich eh soweit kommen, dass sich FreeBSD langsam was eigenes zusammenschustert.

Muss ja nicht gleich ein Monster wie systemd sein. Aber ein bisschen Convention over Configuration wäre schon ganz sinnvoll. Bei Jails hat man das ja im Grunde auch gemacht.
 
Ich bin ja immer noch dafür, dass FreeBSD runit als Standard-init-System verwendet. Dann hört vielleicht das Gejammer auf, dass sein Initsystem nicht aktuell genug ist.
 
CrimsonKing schrieb:
Ich bin ja immer noch dafür, dass FreeBSD runit als Standard-init-System verwendet. Dann hört vielleicht das Gejammer auf, dass sein Initsystem nicht aktuell genug ist.
Zum Vergrößern anklicken....

Runit habe ich vor einer Weile mal in einem eigenen Bastelsystem (stark an Arch Linux angelehnt) verwendet und bin dann später wieder bei Void Linux darauf gestoßen. Bei letzterem finde ich vor allem interessant, daß es ursprünglich Systemd verwendete und davon auf Runit umgestiegen ist! Nun liest man ja teilweise, daß Void das „BSD-artigste Linux“ sei (wahrscheinlich der Tatsache geschuldet, daß der Hauptentwickler ursprünglich aus der NetBSD-Welt kommt).

Außerdem ist Runit ja auch in den Ports unter FreeBSD und OpenBSD vorhanden, bzw. pkgsrc unter NetBSD. Hat irgendjemand bereits Erfahrung damit gesammelt und kann irgendetwas dazu sagen? Ich habe mit dem altgedienten Initsystem kein Problem, bin aber auch einer gewissen Dosis Fortschritt nicht abgeneigt. Und Runit macht zumindest bei einer flüchtigen Beschäftigung damit einen recht brauchbaren Eindruck.
 
OpenRC auch. ;)

Das wären dann Alpine und Gentoo Linux (und optional Arch) in der Linux-Welt.

Aber mal ehrlich. Runit schaut ja interessant aus, nur war ein Grund, warum ich RC-Sachen immer lieber hatte, dass man Dependencies statt Runlevel hat.
 
"The Power to serve".
Ein Server fährt in der Regel einmal hoch und läuft dann ohne dass noch einmal init/rc benötigt wird.
Ich finde dieses Nicht-Thema absolut bescheuert, aus meiner Sicht gibt es nichts besseres als ein skriptbasiertes
Init-System, wie es FreeBSD nunmal bereits besitzt.

Rob
 
gerade auf dem Server will ich doch, dass mein Dienst wieder gestartet wird, wenn er mal gestorben ist. Solaris hat mit der SMF schon vor etwa 10 Jahren genau so ein Init System eingeführt, wie es Systemd und konsorten sein wollen. Da hat damals aber niemand rumgejammert, das fanden eigentlich alle toll und sinnvoll. Lag womöglich daran, dass weiterhin noch "legacy" Init-Skripte parallel weiterverwendet werden konnten - die liefen dann einfach als letztes. So ein vorgehen könnte ich mir für FreeBSD grundsätzlich auch vorstellen.
 
Ich würde das nicht wollen. Ein Dienst, der dauernd abrauscht, muss repariert und nicht durch das Init-System ständig wieder aufgepeppelt werden.

Rob
 
- die Kritik an systemd hat nichts mit seinem Konzept des "modernen Init-Systems" zu tun. Die Kritik an systemd ist die Codequalität und das Verhalten der Entwickler.

- Keep Alive / Restart Always ist nicht implizit eingeschaltet, es muss explizit eingeschaltet werden (im Falle von systemd)

- nicht jeder Server ist ein 08/15 Webserver. Einige redundante, verteilte System rotzen alle Nase lang wegen jedem kleinen Scheiß weg. Da will man nicht ständig von Server zu Server springen. Sagt ja auch keiner "ZFS soll meine Daten nicht automatisch reparieren. Wenn was kaputt ging, muss man selbst gucken"...

Ein modernes Init-System nimmt einem doch nichts weg, gibt Leuten die mehr Funktionalität wollen mehr Möglichkeiten.
 
Naja, aber gerade schrottige Software wie MySQL/MariaDB steigt doch schon bei jeder schrägen Anfrage mal aus. Da muss ja nicht mal was am Server kaputt sein.

Gerade wenn man nur Admin ist, der die Software von Entwicklern verwaltet... mal als Beispiel
 
Das ist zu Teil eine Geschmacksfrage. Ich bevorzuge es über Fehler zuverlässig informiert zu werden. Ja automatische Restarts können faul machen, aber meistens helfen sie deutlich mehr als sie Schaden. Die Erkenntnis hinter einfachen Servicesupersioren (z.B. daemontools) ist, dass jede hinreichend komplizierte Software Fehler enthält. Viele dieser Fehler führen zu Abstürzen. Ein System kann sich also zuverlässiger werden indem Prozesse überwacht werden und bei bedarf neugestartet. Natürlich ist das keine Ausrede dafür Abstürze zu ignorieren. Es hilft allerdings massiv sie in Ruhe zu debuggen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben