systemd 255 released

[schmidicom]

Gestern Abend wurde die Version 255 von systemd freigegeben und da sind einige seit längerem angekündigte aber dennoch interessante Änderungen drin.

...

• Support for split-usr (/usr/ mounted separately during late boot, instead of being mounted by the initrd before switching to the rootfs) and unmerged-usr (parallel directories /bin/ and /usr/bin/, /lib/ and /usr/lib/, …) has been removed. For more details, see: https://lists.freedesktop.org/archives/ ... 48352.html
• Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software *now* to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases.
• "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead.

...

- So weit ich weiß ist Gentoo eine von wenigen Distributionen wo noch "unmerged-usr" angeboten wird, bin gespannt wie das bei Nutzern (die systemd anstelle von OpenRC verwenden) gehandhabt wird die noch nicht auf "merged-usr" umgestellt haben. Ich selbst habe das vor einiger Zeit bei meinem Laptop ausprobiert und danach alle meine Gentoo-Installationen auf "merged-usr" umgestellt ohne deswegen jemals Probleme zu haben.

- Das mit dem "split-usr" ist so weit ich weiß nur ein Thema wenn man kein initrd hat das die benötigten Partitionen mountet bevor das eigentlich System startet. Aber eigene Erfahrungen habe ich da nie gesammelt weil ich nie das Bedürfnis hatte das System derart aufzuteilen, weiß auch gar nicht was das einem für Vorteile bringen soll die den Aufwand rechtfertigen.

- Der Drop für die "System V Initscripts" berührt mich auch nicht wriklich, das wurde am Anfang angeblich eingebaut um den Distributionen den Wechsel zu erleichtern aber wurde das abseits von irgendwelchen Ausanhmen jemals wirklich genutzt?

[firefly]

- Das mit dem "split-usr" ist so weit ich weiß nur ein Thema wenn man kein initrd hat das die benötigten Partitionen mountet bevor das eigentlich System startet. Aber eigene Erfahrungen habe ich da nie gesammelt weil ich nie das Bedürfnis hatte das System derart aufzuteilen, weiß auch gar nicht was das einem für Vorteile bringen soll die den Aufwand rechtfertigen.

Eine Variante war AFAIK, dass man den /usr part als readonly image/nfs mount bereitstellen kann um diese Daten nur einmal zu haben wenn man mehrere identische Systeme hat.

- Der Drop für die "System V Initscripts" berührt mich auch nicht wriklich, das wurde am Anfang angeblich eingebaut um den Distributionen den Wechsel zu erleichtern aber wurde das abseits von irgendwelchen Ausanhmen jemals wirklich genutzt?

Da kann ich nur von Debian ein Beispiel geben: Erst ab mysql-8 gab es upstream systemd units um den service zu mit systemd zu verwalten. Vorher gab es nur die klassichen Init scripts.
Welche dann über diesen Support via systemd genutzt werden konnten

[schmidicom]

- Das mit dem "split-usr" ist so weit ich weiß nur ein Thema wenn man kein initrd hat das die benötigten Partitionen mountet bevor das eigentlich System startet. Aber eigene Erfahrungen habe ich da nie gesammelt weil ich nie das Bedürfnis hatte das System derart aufzuteilen, weiß auch gar nicht was das einem für Vorteile bringen soll die den Aufwand rechtfertigen.

Eine Variante war AFAIK, dass man den /usr part als readonly image/nfs mount bereitstellen kann um diese Daten nur einmal zu haben wenn man mehrere identische Systeme hat.

Das sollte dann ja durch ein entsprechendes "initrd" nach wie vor möglich sein. Bin mir ziemlich sicher das man das nicht mal selber machen müsste sondern "sys-kernel/dracut" überlassen könnte.

- Der Drop für die "System V Initscripts" berührt mich auch nicht wriklich, das wurde am Anfang angeblich eingebaut um den Distributionen den Wechsel zu erleichtern aber wurde das abseits von irgendwelchen Ausanhmen jemals wirklich genutzt?

Da kann ich nur von Debian ein Beispiel geben: Erst ab mysql-8 gab es upstream systemd units um den service zu mit systemd zu verwalten. Vorher gab es nur die klassichen Init scripts.
Welche dann über diesen Support via systemd genutzt werden konnten

OK wusste nicht das die so lange brauchten um ein Service-Unit bereit zu stellen.
Da fragt man sich was die aufgehalten hat, ist ja nun wirklich keine Hexerei so ein INI-File. Ich vermute jetzt einfach mal das die in ihrem Initscript Sachen gemacht haben wie weit über das starten eines Dienstes hinausgingen und eigentlich ins Binary des Dienstes selbst gehört hätten. Aber naja, sie haben es inzwischen ja offensichtlich doch noch hinbekommen und gerade eine Distribution wie Debian wird das neue systemd wohl erst ausliefern wenn alle anderen Pakete die sie im Repo haben damit auch klar kommen. Zumindest wäre ich überrascht wenn Debian das anders handhaben würde.

[firefly]

- Das mit dem "split-usr" ist so weit ich weiß nur ein Thema wenn man kein initrd hat das die benötigten Partitionen mountet bevor das eigentlich System startet. Aber eigene Erfahrungen habe ich da nie gesammelt weil ich nie das Bedürfnis hatte das System derart aufzuteilen, weiß auch gar nicht was das einem für Vorteile bringen soll die den Aufwand rechtfertigen.

Eine Variante war AFAIK, dass man den /usr part als readonly image/nfs mount bereitstellen kann um diese Daten nur einmal zu haben wenn man mehrere identische Systeme hat.

Das sollte dann ja durch ein entsprechendes "initrd" nach wie vor möglich sein. Bin mir ziemlich sicher das man das nicht mal selber machen müsste sondern "sys-kernel/dracut" überlassen könnte.

- Der Drop für die "System V Initscripts" berührt mich auch nicht wriklich, das wurde am Anfang angeblich eingebaut um den Distributionen den Wechsel zu erleichtern aber wurde das abseits von irgendwelchen Ausanhmen jemals wirklich genutzt?

Da kann ich nur von Debian ein Beispiel geben: Erst ab mysql-8 gab es upstream systemd units um den service zu mit systemd zu verwalten. Vorher gab es nur die klassichen Init scripts.
Welche dann über diesen Support via systemd genutzt werden konnten

OK wusste nicht das die so lange brauchten um ein Service-Unit bereit zu stellen.
Da fragt man sich was die aufgehalten hat, ist ja nun wirklich keine Hexerei so ein INI-File. Ich vermute jetzt einfach mal das die in ihrem Initscript Sachen gemacht haben wie weit über das starten eines Dienstes hinausgingen und eigentlich ins Binary des Dienstes selbst gehört hätten. Aber naja, sie haben es inzwischen ja offensichtlich doch noch hinbekommen und gerade eine Distribution wie Debian wird das neue systemd wohl erst ausliefern wenn alle anderen Pakete die sie im Repo haben damit auch klar kommen. Zumindest wäre ich überrascht wenn Debian das anders handhaben würde.

Nope. Systemd ist in debian schon länger drinn und aktiv genutzt. Daher weis ich das auch, da mit mysql 5.x noch systemd die meldung wegen system V init script gebracht hat wenn man den mysql service aktiviert hat.

[schmidicom]

Da kann ich nur von Debian ein Beispiel geben: Erst ab mysql-8 gab es upstream systemd units um den service zu mit systemd zu verwalten. Vorher gab es nur die klassichen Init scripts.
Welche dann über diesen Support via systemd genutzt werden konnten

OK wusste nicht das die so lange brauchten um ein Service-Unit bereit zu stellen.
Da fragt man sich was die aufgehalten hat, ist ja nun wirklich keine Hexerei so ein INI-File. Ich vermute jetzt einfach mal das die in ihrem Initscript Sachen gemacht haben wie weit über das starten eines Dienstes hinausgingen und eigentlich ins Binary des Dienstes selbst gehört hätten. Aber naja, sie haben es inzwischen ja offensichtlich doch noch hinbekommen und gerade eine Distribution wie Debian wird das neue systemd wohl erst ausliefern wenn alle anderen Pakete die sie im Repo haben damit auch klar kommen. Zumindest wäre ich überrascht wenn Debian das anders handhaben würde.

Nope. Systemd ist in debian schon länger drinn und aktiv genutzt. Daher weis ich das auch, da mit mysql 5.x noch systemd die meldung wegen system V init script gebracht hat wenn man den mysql service aktiviert hat.

Ja Ok aber die aktuellen oder nächsten Debian Versionen werden doch kein MySQL 5 sondern MySQL 8 verwenden wo es ein Service-Unit gibt? Also ist doch zumindest an dieser Stelle der Drop kein Problem mehr?

[firefly]

Ja Ok aber die aktuellen oder nächsten Debian Versionen werden doch kein MySQL 5 sondern MySQL 8 verwenden wo es ein Service-Unit gibt? Also ist doch zumindest an dieser Stelle der Drop kein Problem mehr?

In debian main repro ist mysql selbst gar nicht enthalten sondern mariadb.
Ich hab aber beruflich mit mysql zu tun in form eines percona galera clusters. Und da gab es erst ab version 8 systemd unit files in den debian packages.

[schmidicom]

Es gibt noch eine weitere interessante Neuerung:

• A new component "systemd-bsod" has been added, which can show logged error messages full screen, if they have a log level of LOG_EMERG log level. This component is experimental and its public interface is subject to change.

Kleine Ergänzung meinerseits zu diesem Punkt: Entgegen der Beschreibung ist es, gemessen am Sourcecode, aber nicht wirklich eine neue Komponente sondern nur eine neue Funktion von journald die über ein neues Service-Unit optional aktiviert werden kann.

Als jemand der schon einmal versucht hat einem "normalen" Benutzer zu erklären wie er nach einem Systemcrash an die letzten relevanten Meldungen im Log kommt kann ich den Nutzen dieser Neuerung durchaus nachvollziehen, aber ich hätte da direkt zwei Punkte die zu kritisieren sind.

• Das Ding zeigt nur die letzte Emergency-Meldung aus dem Log an und das ist, zumindest nach meiner Erfahrung, zu wenig. Da müssten mindestens die letzten 5 Emergency-Meldungen hergenommen werden.
• Für den BSOD werden die VT's des Kernel benutzt und das hätte man wirklich besser machen können, denn die VT's des Kernel sind schon seit längerem "veraltet" (siehe Deprecating CONFIG_VT von "David Herrmann") und sollten eigentlich aus dem Kernel raus. An dieser Stelle jetzt eine weitere Abhängigkeit zu diesen VT's zu erschaffen halte ich für keine gute Idee. Es wäre mir lieber gewesen wenn dieser BSOD auf die gleiche Art und Weise umgesetzt worden wäre wie zum Beispiel kmscon (das ursprünglich von "David Herrmann" ins leben gerufen wurde).