Die größere Änderung, die mit Ubuntu 15.04 einhergeht, ist der Wechsel von upstart zu systemd als Standard für die Verwaltung des Boot- und Systemdienststarts.
Könnte jemand einem nicht-technischen Benutzer angemessen erklären, wie und ob dies uns überhaupt betrifft? Und warum ist es wichtig?
Laien sollten keine Änderungen bemerken. Es ist ein Init-System, mit dem Benutzer traditionell nicht interagieren. Es sollte die von Upstart bereitgestellten Funktionen vollständig ersetzen - und ein paar zusätzliche Dinge tun -, aber das einzige Mal, wenn ein nicht-technischer Benutzer dies sieht, ist, wenn es schief geht.
Benutzer, Systemadministratoren und Entwickler, die Upstart aktiv genutzt und entwickelt haben, müssen sich mit den Dingen befassen. Es gibt ein Migrationsdokument im Ubuntu-Wiki , das Entwicklern hilft, ihre Init-Skripte zu konvertieren, aber Benutzer und Sysops können Upstart weiterhin verwenden, indem sie sich an 14.04 halten (was bis 2019 unterstützt wird).
Der Grund und die Gründe für die Veränderung waren wirklich nicht von Ubuntus Seite. Canonical war mit Upstart (ihrem Projekt) zufrieden, aber viele Debian-Benutzer wollten auf eine moderne Init-Engine umsteigen, um eine bessere Parallelität beim Booten und eine bessere Überwachungsfunktionalität für alle Dienste zu erzielen.
Das bedeutete, dass ein Kampf zwischen verschiedenen Optionen (den Begründungen) und dem System letztendlich gewonnen wurde.
Canonical ist Debian gefolgt, weil es am einfachsten und wahrscheinlich am besten ist. Sie dürfen ein Projekt fallen lassen und kämpfen nicht stromaufwärts. Es bringt uns auch in Einklang mit anderen Distributionen (Red Hat, Fedora usw.), die ebenfalls auf systemd umsteigen. Mehr Fokus und weniger Doppelarbeit.
tl; dr Zu einer nicht technischen Person, soll dies nicht , dass Sie überhaupt beeinflussen. Für Ubuntu sollte dies weniger Arbeit und ein besseres Init-System bedeuten.
Könnte jemand einem nicht-technischen Benutzer angemessen erklären, wie und ob dies uns überhaupt betrifft?
Theoretisch sollte dies keine Auswirkungen auf den nicht-technischen Endbenutzer haben, der sich nicht mit der tatsächlichen Funktionsweise des Systems befasst. In der Praxis gibt es viele Dinge, die Sie sehen werden.
Hier ist eine unvollständige Liste:
init5+ rcsind gebissen von der Tatsache, dass systemd nur abwärtskompatibel mit System 5 ist rc. Wie Emporkömmlinge und in der Tat die meisten anderen Systeme erklärt und liefert es keine Abwärtskompatibilität mit System 5 initund seiner Konfigurationsdatei /etc/inittab.Leute, die den Ratschlägen aus den 30 Jahren gefolgt sind, in denen sie geraten haben "Nun, Sie können dies einfach in /etc/inittab... ändern ", oder Leute, die Software verwenden, die diesen Ratschlägen gefolgt sind, haben jetzt Software, die nicht mit dem Bootstrap beginnt. Beispiel: https://unix.stackexchange.com/a/196197/5132
shutdownshutdownshutdown nowsystemctl rescue--userOption sprechen systemctl. Das gilt (noch) nicht für Ubuntu. upstart und systemd unterscheiden sich in diesem Bereich erheblich, und Ubuntu Version 15 verwendet weiterhin den Start pro Sitzung anstelle einer systemd -Instanz pro Benutzer . So gilt beispielsweise https://superuser.com/a/860598/38062 nicht. ☺Wie andere hier bereits angemerkt haben, sollte dies theoretisch keine Auswirkungen auf den nicht-technischen Endbenutzer haben - und theoretisch gibt es keinen Unterschied zwischen Theorie und Praxis, aber in der Praxis.
Ich denke, dass einige Dinge, die hier gepostet werden, einer Klärung bedürfen:
Es ist ein Init-System, mit dem Benutzer traditionell nicht interagieren.
Dies war bei SysV init und Upstart der Fall, bei systemd jedoch nicht mehr. Es macht eine Menge Dinge, mit denen Benutzer traditionell interagieren:
Es sollte die von Upstart bereitgestellten Funktionen vollständig ersetzen und ein paar zusätzliche Dinge tun
Zwei Dinge, die geklärt werden müssen - zuerst, um Upstart vollständig zu ersetzen:
Eines der Probleme, die Menschen mit systemd haben, ist, dass es keine SysV-Init-Skripte ausführt. Es gibt also ein Beispiel, das die von Upstart bereitgestellten Funktionen nicht vollständig ersetzt.
Darauf können wir uns seit über 30 Jahren verlassen. Traditionell haben Sie SysV-Init-Skripte geschrieben, um maximale Portabilität zu erzielen, ohne sich zu wiederholen (indem Sie mehrere Versionen derselben Skripte schreiben), was nicht mehr der Fall ist.
Dies sollte kein Problem sein, wenn nur Pakete aus offiziellen Repositorys verwendet werden, da vermutlich bei allen Paketen, für die zuvor SysV-Init- oder Upstart-Skripts verwendet wurden, die Skripts neu geschrieben werden müssen, bevor sie gepackt werden.
Dies ist nur für Benutzer problematisch, die Software von Drittanbietern oder benutzerdefinierte Software verwenden, deren Init-Skripte entweder für SysV init oder für Upstart geschrieben wurden, und für die die Init-Skripte vor dem Upgrade auf ein System mit systemd (oder get neu geschrieben werden müssen der installierte Upstart, der auch eine Option ist , oder die Migration auf ein System, das systemd nicht verwendet.
Es gibt systemd-sysv-generator, der SysV-Init-Skripte automatisch in systemd-Skripte übersetzen soll, aber es gibt einige Fehler und eine lange Liste expliziter Inkompatibilitäten .
Nun die zweite Klarstellung - über diese wenigen zusätzlichen Dinge:
Die "wenigen zusätzlichen Dinge", die systemd - gemäß einer Perspektive für systemd - behandeln wird - was erreicht wurde und was vor der Präsentation von Lennart Pöttering auf GNOME.asia im Jahr 2014 liegt - sind die folgenden:
Zurück zu: "Es ist ein Init-System, mit dem Benutzer traditionell nicht interagieren." - Es muss darauf hingewiesen werden, dass das Init-System nur ein Punkt in dieser Liste ist.
Und zum Schluss möchte ich noch Folgendes kommentieren:
[D] Das einzige Mal, wenn ein nicht technischer Benutzer dies sieht, ist, wenn es schief geht.
Oh, was für eine Erleichterung. :)
Die wichtigsten Änderungen für Endbenutzer (außer den Skripten selbst) betreffen das Starten und Beenden von Diensten und die Verwendung von Befehlen wie:
die nicht mehr wie erwartet funktionieren. nohupEin POSIX-Befehl stellt beispielsweise sicher, dass der Prozess weiter ausgeführt wird, nachdem Sie sich von Ihrer Sitzung abgemeldet haben. Auf systemd funktioniert es nicht mehr . Auch Programme wie screenund tmuxmüssen auf besondere Weise aufgerufen werden, da sonst die Prozesse, die Sie mit ihnen ausführen, abgebrochen werden.
Dies ist kein Fehler, es ist eine Designentscheidung, daher ist es unwahrscheinlich, dass es in Zukunft behoben wird. Das hat Lennart Pöttering zu diesem Thema gesagt :
Meiner Ansicht nach war es für UNIX eigentlich ziemlich seltsam, dass es nach dem Abmelden standardmäßig beliebigen Benutzercode uneingeschränkt herumstehen lässt. Unter vielen OS-Anwendern wird seit Ewigkeiten diskutiert, dass dies möglich sein sollte, aber sicherlich nicht die Standardeinstellung, aber bisher wagte es niemand, den Schalter zu betätigen, um ihn von einer Standardeinstellung in eine Option umzuwandeln. Das Bereinigen von Benutzersitzungen nach dem Abmelden ist nicht nur hässlich und etwas hackisch, sondern auch ein Sicherheitsproblem. systemd 230 hat jetzt endlich den Schalter umgelegt und standardmäßig alles richtig aufgeräumt, wenn sich der Benutzer abmeldet.
Für weitere Informationen siehe:
screenscreensystemd-run --user --scope screen(Hinweis: Das Verhalten von "upstart" oben ist wirklich alles außer systemd, dies ist nicht spezifisch für den upstart)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Siehe meine Antwort auf Was sind die Vor- / Nachteile von Upstart und systemd? Für weitere Einzelheiten, die für diese Frage nicht relevant sind.)
Es gibt auch einen großen Unterschied im Umgang mit den Protokollen, da die Protokolle von systemd entgegen der Unix-Tradition in Binärdateien in einem benutzerdefinierten Format gespeichert werden, anstatt:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
Sie benötigen spezielle Befehle, um auf Ihre Protokolle zuzugreifen:
sudo journalctl -u foo
sudo journalctl -u foo -f
Die Einführung von systemd in Debian und später in Ubuntu war nicht ohne Kontroversen und großen Widerstand, wie jeder weiß, der einen der folgenden Artikel geschrieben hat:
Die offizielle Debian-Position zu systemd und die sich daraus ergebende Kontroverse führten 2014 zur Erklärung von Exodus und endeten mit dem Rücktritt von Ian Jackson .
Die Initiativen Init Freedom , Without-Systemd.org und Systemd-Free.org wurden ins Leben gerufen und in den Hacker News viel diskutiert .