[Uripura]

Ok, du hast ein Dist-Upgrade gemacht. Dabei auch ein Release-Upgrade? Bist du evtl von Wheezy auf Jessie gewandert? Was steht in deiner sources.list? Bzw in sources.list.d/? Hast du evtl Testing mit in den Paketquellen und beim Pinning nicht sauber gearbeitet? Irgendwo muss dieser neue Kernel ja her kommen.
Bist du sicher, dass du auf Jessie bist?

Das ganze System habe ich schon als Jessie installiert. So alt ist es nicht. Auch in den sources war alles aus den Jessie Quellen.
Der Kernel ist in jessie-backports drin. Und die waren auch in der sources.list drin.
Aus irgendeinem Grund wurde der bei dem upgrade installiert. Aufgefallen ist das auch nur als IPv6 auf einmal nicht mehr ging.
Ich finde das schon sehr seltsam.

Was das betrifft empfehle ich das Paket etckeeper. Das verwandelt das komplette etc-Verzeichnis in ein Git-Repo, oder wahlweise auch svn, bzr, oder ein anderes Versionsverwaltungstool. Es stattet das ganze aber mit ein paar Zusatz-Funktionen aus. Zum einen werden Hooks eingerichtet, die automatisch einen Commit erzeugen, wenn z.B. die Paketverwaltung etwas am etc-Verzeichnis ändern möchte. Und es wird eine Liste aller Unterverzeichnisse und Dateien angelegt, mitsamt ihrer Zugriffsrechte.
Damit lässt sich dann im Falle eines Falles eine alte Version des etc-Verzeichnisses wiederherstellen.
Quasi ein lokales Instant-Backup.

Ein richtiges Backup ersetzt das natürlich nicht.

Das wäre vielleicht keine schlechte Idee. Ich werde mich mal da umsehen.

Das erklärt zumindest die Fehlermeldung. Die Shell kann den Stern nicht auflösen, weil er auf keine Datei passt (es ist ja keine da) und reicht ihn dann gemäß den üblichen Erweiterungsregeln als Literal an 'cp' weiter. Welches natürlich Probleme hat, die Datei '*' zu finden.

$ mkdir empty
$ cp empty/* /tmp/
cp: cannot stat 'empty/*': No such file or directory

Eine einfache Lösung dürfte sein, irgendeine leere Datei in das Verzeichnis zu werfen. Dann hat die Shell was zum Auflösen.

$ echo '# This file contains no config on purpose' > empty/empty.conf
$ cp empty/* /tmp/

Ob das Verzeichnis in deinem Fall aber leer sein sollte, oder ob du Dateien verloren hast, die in deinem Fall für eine funktionierende Initrd gebraucht werden, kann ich dir nicht sagen. Musst du ausprobieren. Bei Ubuntu stellt das Paket 'kmod' diese Dateien bereit. Bei Debian scheint das etwas anders zu sein.

Gelöschte Konfigurationsdateien (in /etc) werden normalerweise nicht wieder angelegt, wenn man ein Paket neu installiert. Das muss man erzwingen:

apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall <paketname>

Ah, natürlich. Danke für die Hilfe.

Ich habe jetzt auch einfach eine config eingefügt die auf einer anderen Jessie-installation ist. Nachdem ich dann das initramfs neu generiert, den ungewollten Kernel entfernt und die grub.conf neu generiert habe klappt alles wieder. Vielen Dank euch für die super Hilfe.

[Blue Force]

Schade, für das Projekt Limux in München ist jetzt endgültig der Ofen aus, obwohl bereits 15000!!! Arbeitsplätze in der Stadtverwaltung seit einigen Jahren auf Linux laufen. Jetzt soll wieder auf Microsoft umgestellt werden

Auch wenn einige Gründe der haarsträubenden Unkenntnis der Politiker zugrunde liegen: Einmal war der städtische Email-Server abgeschmiert - da hat ein Politiker die Linux-Umstellung der PCs dafür verantwortlich gemacht (ich glaube es war sogar der heutige OB) also trifft da einer Entscheidungen der nicht mal weiß daß ein Linux-Server mit Linux-Desktop-PCs überhaupt nix zu tun hat. Hauptsache bei Linux ist irgendwo irgendwas abgestürzt

Ein wichtiger Grund war natürlich die mangelnde Kompatibilität zwischen LibreOffice und MS Office, was zu vielen unproduktiven Arbeitsstunden geführt hat, nur um zerschossenen Formate wiederherzustellen.

[Roscoe]

Der neue OB hat offenbar auch eine besondere Affinität zu MS, afaik wurde da eine neue MS-Zentrale in München gebaut, das Gutachten erstellte auch ein MS-Geschäftspartner, ...

LiMuX an sich war aber anscheinend auch nicht das Gelbe vom Ei. Anstatt eine eigene Distribution zu erstellen, hätte man auf die gängigen Business-Lösungen wie das gerade hier in Deutschland weit verbreitete SUSE Enterprise, Red Hat oder zur Not auch Canonical setzen können. Dann müsste man auch keine LiMuX-Spezialisten ausbilden, sondern könnte auf so viel mehr Supportquellen zurückgreifen.

Dazu kommt, dass die Abgeordneten sich beschwert haben, nicht selbständig Programme wie MS Office und Skype auf ihren Rechnern installieren zu dürfen. Offenbar hat ihnen niemand mitgeteilt, dass das keine Schikane, sondern Teil der Sicherheitspolitik einer Behörde ist.

Und von den Standards eines Quasi-Monopolisten abhängig zu sein, überwindet man nicht, indem man sie weiter benutzt, da gehört auch eine mglw. schwierige Übergangsphase dazu. Die niederländische Regierung setzt seit diesem Jahr bspw. auf die offenen Standards, wäre schön, wenn sich diese Einstellung mal grundsätzlich in Behörden durchsetzen würde. Zudem gibt es einen Trend zu Web-Apps, dann reicht ein Browser am Ende aus, wenn es unbedingt MS Office sein soll - dumm nur, dass diese Programme dann halt mit einem Abomodell daherkommen.

Naja, letzten Endes war es wohl mehr eine politische und keine inhaltliche Frage.

[Lookbehind]

Naja, immerhin war LiMuX gute 10 Jahre im Einsatz. Das kann man schon auch als Erfolg sehen. Die erneute Umstellung wird sicher auch die eine oder andere Schwierigkeit mit sich bringen. Aber das sind technische Details die insgesamt kaum jemanden interessieren.
Ob das eine rein politische Entscheidung war? Hm, weiß nicht, würd eher sagen Wirtschafts-Politisch. Ob nun zum besseren oder schlechteren, können wir wohl wenig beurteilen. Wir arbeiten ja nicht damit.

@Roscoe:
Ich hab mir die vertikalen Panels von Cinnamon die letzten 2-3 Tage mal angeschaut und für Mist befunden. Ich werd heute Abend wieder n XFCE-Panel einrichten.

[Roscoe]

Ich bin momentan von Cinnamon, das seit kurzer Zeit (auf Arch) ziemlich perfekt lief (gab davor lange Zeit Probleme mit der Bildschirmsperre, weil Clem bei Mint den cinnamon-screensaver komplett umgestaltet hat), auf XFCE umgestiegen, weil es einfach um einiges schneller ist und der Eyecandy auf Cinnamon zwar oft schön ist, aber das Design - insbesondere des Cinnamon-Menüs - überfrachtet wirkt. Hab auf XFCE gestern auch mal ein vertikales Panel ausprobiert, aber die Uhr ließ sich nicht in eine waagrechte Position bringen, außer ich stelle die Anzeige auf das hässliche LCD-Design um. Bei der Wetteranzeige hab ich das gleiche Problem, muss ich mich nochmal dransetzen.

[Blue Force]

Es kam wohl alles zusammen, der OB ziemlich tief bei MS hinten drin und die Verwaltungsmitarbeiter gefrustet von den Kompatibilitätsproblemen. Und das extra entwickelte Formularsystem Wollmux macht auch nicht den Eindruck als ob es besonders nutzerfreundlich ist, von dem bescheuerten Namen mal ganz abgesehen

[Lookbehind]

Ich bin momentan von Cinnamon, das seit kurzer Zeit (auf Arch) ziemlich perfekt lief (gab davor lange Zeit Probleme mit der Bildschirmsperre, weil Clem bei Mint den cinnamon-screensaver komplett umgestaltet hat), auf XFCE umgestiegen, weil es einfach um einiges schneller ist und der Eyecandy auf Cinnamon zwar oft schön ist, aber das Design - insbesondere des Cinnamon-Menüs - überfrachtet wirkt. Hab auf XFCE gestern auch mal ein vertikales Panel ausprobiert, aber die Uhr ließ sich nicht in eine waagrechte Position bringen, außer ich stelle die Anzeige auf das hässliche LCD-Design um. Bei der Wetteranzeige hab ich das gleiche Problem, muss ich mich nochmal dransetzen.

Funfact: Ausgerechnet die Uhr ist einer der Punkte, die ich am Cinnamon-Pannel zu bemängeln habe.
Außerdem sind die Spacer blöd, weil die nur mit festen Pixel-Werten arbeiten können und das Menü lässt sich bei einer Senkrechten Leiste auch nur sehr umständlich bedienen.
Ansonsten gefällt mir Cinnamon recht gut. Der Eyecandy is mir recht egal, aber das Fenster und Arbeitsflächen-Management funktioniert sehr gut, Nemo gefällt mir auch. Kritikpunkt für mich ist wirklich nur das Panel ... und das hab ich jetzt eben wieder durch ein XFCE-Panel ausgetauscht. No big deal.

Tipp für die Uhr bei XFCE: Stell sie auf Analog

[foobar]

Das ist ein grundsätzliches Problem in größeren Institutionen und speziell Verwaltungen. Die Entscheider haben keine Ahnung von der Materie und begreifen IT nicht als Prozess, sondern als einmalige Investition.

Als ich meinen Betrieb komplett auf Linux umgestellt habe, bin ich den umgekehrten Weg gegangen: Zuerst nach und nach die vorhandenen Programme durch plattformunabhängige Alternativen ersetzt, sobald sich eine Gelegenheit ergab. Wenn auslaufender Support oder geänderte gesetzliche Vorschriften sowieso eine Neuanschaffung verlangen, kann man ja auch ruhig mal schauen, ob es nicht auch Alternativen gibt, die sich später unter Linux weiter nutzen lassen. Und als am Ende kein Windows-Programm mehr übrig war, war es dann auch egal, als ich die darunter liegende Plattform austauscht und tatsächlich auf Linux umgestiegen bin. Das ist ein schonender Wechsel, kein mit brachialer Gewalt erzwungener Umstieg.

Das setzt nur voraus, dass man seine IT halt strategisch plant. Oft ist es eher so, dass man IT-Investitionen als Einmal-Anschaffung sieht. Wie anderes Büro-Equipment (Stühle, Tische, Lampen, Schreibmaschinen etc.) halt auch. Man kauft einmal Computer, Betriebssysteme und Programme und dann soll möglichst lange nichts mehr daran zu machen sein. Schon Support ist was, das in viele Köpfe nicht richtig rein will. Soll alles nix mehr kosten. Bis dann irgendwann, idealerweise in 20+ Jahren, alles neu angeschafft wird. Und Politiker wollen natürlich sowieso alles innerhalb der Legislaturperiode erledigt haben. Danach kommen ja wieder die anderen dran und machen alles kaputt, also muss man vollendete Tatsachen schaffen.

Wenn man da bis auf den letzten Drücker wartet, ist es natürlich schwierig, einen langsamen, schonenden Umstieg durchzuziehen. Wird das alte Windows nicht mehr supportet, muss es halt jetzt gewechselt werden. Nicht in 2 Jahren, wenn man von allen Windows-Anwendungen weg ist. Da bleibt dann nur der Brachialumstieg oder halt wieder Windows kaufen und 10 Jahre schlafen gehen.

[Roscoe]

Funfact: Ausgerechnet die Uhr ist einer der Punkte, die ich am Cinnamon-Pannel zu bemängeln habe.
Außerdem sind die Spacer blöd, weil die nur mit festen Pixel-Werten arbeiten können und das Menü lässt sich bei einer Senkrechten Leiste auch nur sehr umständlich bedienen.
Ansonsten gefällt mir Cinnamon recht gut. Der Eyecandy is mir recht egal, aber das Fenster und Arbeitsflächen-Management funktioniert sehr gut, Nemo gefällt mir auch. Kritikpunkt für mich ist wirklich nur das Panel ... und das hab ich jetzt eben wieder durch ein XFCE-Panel ausgetauscht. No big deal.

Tipp für die Uhr bei XFCE: Stell sie auf Analog

Nemo ist unangefochten klasse, erst recht, wenn man ihn mal neben Nautilus stellt. Cinnamon ist für mich das modernere XFCE, immer noch ziemlich modular, aber etwas schicker und dazu sehr einsteigerfreundlich. Vorschläge werden, so habe ich das Gefühl, auch schnell entgegengenommen und umgesetzt. Eigentlich perfekt, aber man ist ja nie zufrieden.

Danke! Hm, gefällt mir nicht so, aber ist vielleicht auch einfach nur ungewohnt.

Das ist ein grundsätzliches Problem in größeren Institutionen und speziell Verwaltungen. Die Entscheider haben keine Ahnung von der Materie und begreifen IT nicht als Prozess, sondern als einmalige Investition.

Das glaube ich allerdings auch. Bevor man die Personen befragt, die tatsächlich damit zu tun haben, beschäftigt man oft eher eine externe Unternehmensberatung und das Ergebnis schießt dann teilweise extrem an den eigentlichen Bedürfnissen vorbei.

Als ich meinen Betrieb komplett auf Linux umgestellt habe, bin ich den umgekehrten Weg gegangen: Zuerst nach und nach die vorhandenen Programme durch plattformunabhängige Alternativen ersetzt, sobald sich eine Gelegenheit ergab. Wenn auslaufender Support oder geänderte gesetzliche Vorschriften sowieso eine Neuanschaffung verlangen, kann man ja auch ruhig mal schauen, ob es nicht auch Alternativen gibt, die sich später unter Linux weiter nutzen lassen. Und als am Ende kein Windows-Programm mehr übrig war, war es dann auch egal, als ich die darunter liegende Plattform austauscht und tatsächlich auf Linux umgestiegen bin. Das ist ein schonender Wechsel, kein mit brachialer Gewalt erzwungener Umstieg.

Das setzt nur voraus, dass man seine IT halt strategisch plant. Oft ist es eher so, dass man IT-Investitionen als Einmal-Anschaffung sieht. Wie anderes Büro-Equipment (Stühle, Tische, Lampen, Schreibmaschinen etc.) halt auch. Man kauft einmal Computer, Betriebssysteme und Programme und dann soll möglichst lange nichts mehr daran zu machen sein. Schon Support ist was, das in viele Köpfe nicht richtig rein will. Soll alles nix mehr kosten. Bis dann irgendwann, idealerweise in 20+ Jahren, alles neu angeschafft wird. Und Politiker wollen natürlich sowieso alles innerhalb der Legislaturperiode erledigt haben. Danach kommen ja wieder die anderen dran und machen alles kaputt, also muss man vollendete Tatsachen schaffen.

Wenn man da bis auf den letzten Drücker wartet, ist es natürlich schwierig, einen langsamen, schonenden Umstieg durchzuziehen. Wird das alte Windows nicht mehr supportet, muss es halt jetzt gewechselt werden. Nicht in 2 Jahren, wenn man von allen Windows-Anwendungen weg ist. Da bleibt dann nur der Brachialumstieg oder halt wieder Windows kaufen und 10 Jahre schlafen gehen.

Genau so, langfristig und dabei die Benutzer im Blick, den Umstieg möglichst fließend gestalten.

Hab vor ein paar Tagen einen sehr guten Post hierzu gelesen.

Ich finde es einfach höchst problematisch, sich bereits von staatlicher Seite (ja, hier kommunal, aber läuft ja kaum wo anders) einem riesigen Unternehmen, egal, ob MS, Google, ..., auszuliefern, geschlagen zu geben. Das schließt ja nicht nur wirtschaftliche Aspekte, sondern bewiesenermaßen auch Spionage mit ein - und das in einem Umfeld, in dem man mit allen möglichen, privaten Bürgerdaten hantiert. Gut, jetzt könnte man wieder auf die Hardwareebene gehen und sagen, um das auszuschließen, müsste man gleich auch eigene Prozessoren herstellen, ...

[Lookbehind]

Ich bin dumm.
Das muss so sein, denn sonst würd mir auffallen, was alle an systemd so toll finden.
Mal ernsthaft. Der einzige Vorteil, den ich sehe, ist, dass es Dienste parallel starten kann und damit einen schnelleren System-Boot ermöglicht. Ansonsten macht der Mist eigentlich nur Probleme.

Aktueller Stein des Anstoßes: Script soll ab einem bestimmten Punkt nur weiter machen wenn die Dienste A, B und C auch laufen, weil wegen, sonst ist die Sache witzlos. Well ... easy enough. Die Info bekommt man ja über systemctl status Dienst-A, output parsen und weiter gehts ... Denkste! Der Mist macht noch nichtmal nen sauberen Exit. Was soll der Mist? Wer kann denn mit sowas vernünftig arbeiten?

Kann mir bitte mal einer das Konzept von Systemd so erklären, dass ich verstehe, was daran so toll ist?

[foobar]

Naja, warum der alte SysVInit mit seinen sequentiellen, statischen Skripten heutzutage nicht mehr unbedingt das Gelbe vom Ei ist, muss ich dir wohl nicht erklären. Im Gegensatz zu Upstart, das auch Dienste parallel und ereignisgesteuert starten kann, wenn alle Abhängigkeiten erfüllt sind, kann SystemD sogar Dienste starten, deren Abhängigkeiten noch gar nicht erfüllt sind. Es erzeugt die Sockets, die benötigt werden einfach selbst und puffert deren Daten solange, bis der eigentliche Dienst gestartet ist. Es lässt sich also mehr parallelisieren, weil man nicht mehr auf einzelne zentrale Dienste warten muss.

Beispiel: Syslog. Viele Dienste (z.B. D-Bus) verbinden sich beim Start mit /dev/log, welches von Syslog erzeugt wird. Upstart kann also D-Bus erst starten, wenn der Syslog-Daemon läuft. SystemD erzeugt /dev/log einfach selbst und kann beide Dienste parallel starten. Wenn D-Bus schon ins Socket schreibt, wird der Kram einfach gepuffert, bis Syslog auch läuft und die Daten abholt. Ist ja eigentlich keine doofe Idee. Viele Abhängigkeiten spielen auf einmal keine Rolle mehr.

Da der Socket von SystemD gehalten wird, kann der zuständige Dienst auch abstürzen oder im Zuge von Updates neu gestartet werden, ohne dass die von ihm abhängenden Dienste Probleme kriegen. Damit gehen auch keine Meldungen mehr verloren. Selbst die ganzen frühen Kernel-Nachrichten (bevor das Root-FS gemountet ist) werden gepuffert und landen dann später zur Auswertung im Log.


Aus deiner recht abstrakten Problembeschreibung kann ich nicht so ganz ableiten, was genau du eigentlich machen willst. Wenn du nur auf einen Prozess warten willst, kannst du den natürlich auch mit 'ps' & Co. abfragen. Aber je nachdem, worin die Abhängigkeit von den Diensten bei deinem Skript genau besteht, kann es sein, dass du es nur "richtig" machen musst, um eben gerade überhaupt nicht mehr auf sie warten zu müssen.

[Lookbehind]

Naja, warum der alte SysVInit mit seinen sequentiellen, statischen Skripten heutzutage nicht mehr unbedingt das Gelbe vom Ei ist, muss ich dir wohl nicht erklären.

Sicherlich. Da ist durchaus mal was moderneres und besseres fällig. Besser heißt aber für mich, dass man die "guten" Elemente übernimmt und das ersetzt, was nicht so doll ist.
Und bei Systemd hab ich das Gefühl, als hätte man die guten Elemente gleich mit über Bord geschmissen. KISS ist jedenfalls anders.

Im Gegensatz zu Upstart, das auch Dienste parallel und ereignisgesteuert starten kann, wenn alle Abhängigkeiten erfüllt sind, kann SystemD sogar Dienste starten, deren Abhängigkeiten noch gar nicht erfüllt sind. Es erzeugt die Sockets, die benötigt werden einfach selbst und puffert deren Daten solange, bis der eigentliche Dienst gestartet ist. Es lässt sich also mehr parallelisieren, weil man nicht mehr auf einzelne zentrale Dienste warten muss.

Mal abgesehen davon, dass ich allein aus diesem Konzept heraus schon sehen kann, dass, wenn etwas schief geht, es auf jeden Fall so richtig krachen wird, würde ich das eben als "Paralellisierung" abstempeln.
Das nutzt mir vor allem während des Boot-Vorgangs. Sicher auch noch an ein zwei anderen Stellen, aber da merk ich es am ehesten. Natürlich nehme ich diese Verbesserung gerne an. Wie bereits erwähnt, das sehe ich ja wirklich auch als Vorteil von Systemd. Aber der "Vorteil" sind bestenfalls 2-3 Sekunden. Setze ich das ins Verhältnis, wie oft so ein Linux überhaupt mal neu gestartet wird ... Hm ...
Dennoch, wenns sonst nix kostet, nehm ich das natürlich gerne an. Kleine Verbesserungen sind besser als keine.

Beispiel: Syslog. Viele Dienste (z.B. D-Bus) verbinden sich beim Start mit /dev/log, welches von Syslog erzeugt wird. Upstart kann also D-Bus erst starten, wenn der Syslog-Daemon läuft. SystemD erzeugt /dev/log einfach selbst und kann beide Dienste parallel starten. Wenn D-Bus schon ins Socket schreibt, wird der Kram einfach gepuffert, bis Syslog auch läuft und die Daten abholt. Ist ja eigentlich keine doofe Idee. Viele Abhängigkeiten spielen auf einmal keine Rolle mehr.

Da der Socket von SystemD gehalten wird, kann der zuständige Dienst auch abstürzen oder im Zuge von Updates neu gestartet werden, ohne dass die von ihm abhängenden Dienste Probleme kriegen. Damit gehen auch keine Meldungen mehr verloren. Selbst die ganzen frühen Kernel-Nachrichten (bevor das Root-FS gemountet ist) werden gepuffert und landen dann später zur Auswertung im Log.

Ob mehr Log-Einträge auch immer "besser" sind, darüber kann man sicher diskutieren. Die Option zu haben ist an sich natürlich nicht verkehrt. Ausgerechnet bei Systemd und Logs fällt mir blöderweise immer der Satz ein "Every feature that you can't turn off is a bug.".

Ob das jetzt Stabilität oder ein Risiko für einen fatalen Absturz bringt, darüber kann man sicher auch noch diskutieren. Aber wir gehen ja erstmal davon aus, dass das System funktioniert, wie es soll, und verbuchen das mal als "Aufschub vor einem totalen Absturz".
Damit wären wir bei bisher 2 mir bekannten Vorteilen von Systemd, gegenüber anderen Systemen. (Parallelität und Stabilität)

Aus deiner recht abstrakten Problembeschreibung kann ich nicht so ganz ableiten, was genau du eigentlich machen willst. Wenn du nur auf einen Prozess warten willst, kannst du den natürlich auch mit 'ps' & Co. abfragen. Aber je nachdem, worin die Abhängigkeit von den Diensten bei deinem Skript genau besteht, kann es sein, dass du es nur "richtig" machen musst, um eben gerade überhaupt nicht mehr auf sie warten zu müssen.

Zum prüfen ob ein Dienst läuft, ist 'ps' nur dann zuverlässig, wenn man die PID dazu kennt. Da beißt sich die Katze aber gegebenenfalls selbst in den Schwanz. => Nicht empfehlenswert.
Warum auch soll ich mich damit abmühen? Es gibt doch extra einen Dienst, der sich um das Starten und Beenden der Dienste kümmert. Der weiß gegebenenfalls auch am besten ob der Dienst gerade läuft, oder nicht. Also warum nicht den fragen? Dafür is der ja schließlich da. Mach ich doch mit der Paketverwaltung auch so. Natürlich kann ich auch händisch nachschauen ob ein Programm installiert ist, und in welcher Version. Aber mit Paketverwaltung wird die Sache eben nochmal bedeutend einfacher. Wofür hab ich die schließlich?

Jetzt stell dir vor, du hast ein Script, das ein paar Aufgaben durchführen soll. Dazu müssen aber ein paar Dienste auch aktiv sein, weil die Sache sonst einfach witzlos ist. Also möchtest du, ab einem bestimmten Punkt im Script nur weiter machen, wenn die Dienste auch laufen. Dazu möchtest du wissen, ob diese Dienste laufen. Also befragt man Google und die Man-Pages, wie das bei systemd geht. Siehe da, ist ganz einfach: systemctl status DIENSTNAME
Für einen Menschen ist das sicherlich auch OK so. Aber automatisiert aus dieser Ausgabe die Information heraus kitzeln, ob der Dienst läuft oder nicht? Viel Spaß! Geht schon damit los, dass dieser "Befehl" überhaupt kein Ende hat. Exit? Scheint man bei den Systemd-Entwicklern nicht zu kennen. Einheitliche Formatierungen auch nicht.
Wenn ich das falsch mache, dann sag mir wie es richtig geht. So is das jedenfalls Mist.

Und derartige Dinge in der Handhabung fallen mir eben ständig auf. KISS haben die Entwickler scheinbar noch nie gehört.

[foobar]

Ob das jetzt Stabilität oder ein Risiko für einen fatalen Absturz bringt, darüber kann man sicher auch noch diskutieren.

Naja, wenn dein Init-Prozess abstürzt, bleibt das System eh mit einer Kernel Panic stehen. Da spielt es dann auch keine Rolle mehr, ob das Ding die Sockets mit ins Grab nimmt.

Jetzt stell dir vor, du hast ein Script, das ein paar Aufgaben durchführen soll. Dazu müssen aber ein paar Dienste auch aktiv sein, weil die Sache sonst einfach witzlos ist. Also möchtest du, ab einem bestimmten Punkt im Script nur weiter machen, wenn die Dienste auch laufen. Also befragt man Google und die Man-Pages, wie das bei systemd geht. Siehe da, ist ganz einfach: systemctl status DIENSTNAME

'status' ist aber nur für Menschen gedacht. Steht auch in der Manpage:

status [PATTERN...|PID...]]
[...]
This function is intended to generate human-readable output. If you
are looking for computer-parsable output, use show instead.
[...]

# systemctl show syslog | grep running
SubState=running

# systemctl show --property SubState syslog
SubState=running

[Lookbehind]

Naja, wenn dein Init-Prozess abstürzt, bleibt das System eh mit einer Kernel Panic stehen. Da spielt es dann auch keine Rolle mehr, ob das Ding die Sockets mit ins Grab nimmt.

Ich meine das auch eher anders rum. Ich sehe da eine super Möglichkeit den Init-Prozess ab zu schießen.
Weniger als Sicherheitslücke, weil ich dafür ja erst mal einen entsprechenden Dienst auf dem System hinterlegen und in systemd einbinden muss. Dazu bräuchte ich eh schon root-Rechte, da brauch ich mir dann den Aufwand auch nicht mehr machen.
Aber durch ein paar schlecht programmierte Dienste, die sich im falschen Moment untereinander verhaken, könnte man da vielleicht was lustiges zaubern.

Auf der anderen Seite kann es halt auch die Stabilität verbessern, wenn einzelne Dienste abstürzen können, ohne alles, was von ihnen abhängt mit in den Tod zu reißen.
Darum sprach ich von "Diskussion", nicht von "Das is Mist!".

Allerdings muss ich auch klar sagen: Es ist nicht so, als hätten SystemV oder Upstart mit Stabilitätsproblemen zu kämpfen.
Der "Gewinn" ist also ähnlich wie beim Boot-Vorgang nicht so SUPER groß.

'status' ist aber nur für Menschen gedacht. Steht auch in der Manpage:

status [PATTERN...|PID...]]
[...]
This function is intended to generate human-readable output. If you
are looking for computer-parsable output, use show instead.
[...]

# systemctl show syslog | grep running
SubState=running

# systemctl show --property SubState syslog
SubState=running

Ok, und wo ist der Sinn, bei einem derartigen CLI-Tool einen nicht parsbaren Output zu generieren? Warum muss ich den Befehl anpassen, je nachdem wofür ich die Information benutzen möchte? ... oder Platt: Was ist an KISS so schwer?

Mal abgesehen davon, dass die erste Ausgabe auch nicht sauber beendet. Fürs automatisierte Parsing also auch schon wieder Mist.
Die Leute die den Kram entwickeln müssen doch auch halbwegs firm mit der Kommandozeile sein. Nervt die das nicht selber? Mir kommt das jedenfalls wie n Hammer mit zwei Stielen vor.

[foobar]

Aber durch ein paar schlecht programmierte Dienste, die sich im falschen Moment untereinander verhaken, könnte man da vielleicht was lustiges zaubern.

Derzeit ist mir diesbezüglich nichts bekannt. Ich kann auch, zumindest so aus dem Stegreif, kein konzeptionelles Problem erkennen. Entweder das benötigte Socket ist da oder eben nicht.

Ok, und wo ist der Sinn, bei einem derartigen CLI-Tool einen nicht parsbaren Output zu generieren?

Die Frage kannst du dann aber auch bei mutt, alpine, mc, nano und einem Dutzend anderer Programme für den Textmodus stellen. Ich für meinen Teil sehe jedenfalls nichts verwerfliches daran, dass SystemD auch eine "Text-GUI" bereit stellt, die sich darum bemüht, die Informationen für den Menschen leserlich aufzubereiten. Und zum Parsen nimmt man halt andere Befehle.

Mal abgesehen davon, dass die erste Ausgabe auch nicht sauber beendet. Fürs automatisierte Parsing also auch schon wieder Mist.

Wie meinen? 'systemctl show ...' terminiert bei mir einwandfrei. Selbst 'systemctl status ...' kann man in Skripten benutzen, wenn man es durch eine Pipe leitet. Macht nur wenig Sinn.

[Roscoe]

Okay, das kam dann doch etwas unerwartet:

Growing Ubuntu for Cloud and IoT, rather than Phone and convergence

[Lookbehind]

Okay, das kam dann doch etwas unerwartet:

Growing Ubuntu for Cloud and IoT, rather than Phone and convergence

Hm, Teilweise. Dass Ubuntu Phone wieder in der Versenkung verschwindet war zu erwarten. Schade find ichs trotzdem. Das Unity eingestellt wird, und man sich wieder auf Gnome konzentriert hab ich wiederum nicht erwartet. Und dass sich Canonical danach ausrichtet, was der Markt vorgibt, ist auch nicht SO verwunderlich. Man darf eben nicht den Fehler machen und freie Software mit einem Wohltätigkeitsverein zu verwechseln.

[jabu]

Okay, das kam dann doch etwas unerwartet:

Growing Ubuntu for Cloud and IoT, rather than Phone and convergence

Zitat aus o.g. Quelle:

We will shift our default Ubuntu desktop back to GNOME for Ubuntu 18.04 LTS.

Gute Nachrichten (wenngleich aus ganz falschen Motiven heraus, was mich bei seiner Vita nicht verwundert (teure Zertifikate sind für mich wie Schutzgelderpressung)). Diese voranschreitende Fragmentierung von Entwicklercommunities ist nicht gut gewesen und schon gar nicht, wenn dysfunktionaler Crap, welcher von Anfang an als Feigenblatt für Monetarisierung konzipiert war, dabei herauskommt.

[Lookbehind]

Zitat aus o.g. Quelle:

Gute Nachrichten (wenngleich aus ganz falschen Motiven heraus, was mich bei seiner Vita nicht verwundert (teure Zertifikate sind für mich wie Schutzgelderpressung)). Diese voranschreitende Fragmentierung von Entwicklercommunities ist nicht gut gewesen und schon gar nicht, wenn dysfunktionaler Crap, welcher von Anfang an als Feigenblatt für Monetarisierung konzipiert war, dabei herauskommt.

Hm, gute Nachrichten? Ich weiß nicht unbedingt. Ich war nie ein Fan von Unity, ich mag allerdings auch Gnome 3 nicht. Da find ich Unity tatsächlich benutzbarer. Aus Benutzer-Sicht würde ich dennoch keinem von beiden nachtrauern. Allerdings geht so eben auch ein Stück Vielfalt verloren. Das finde ich wiederum etwas schade. Aber ich habe einfach mal die Hoffnung, dass Unity als Comunity-Projekt weiter leben wird. Is ja schließlich freie Software. Gnome 2 wird ja auch noch weiter entwickelt, nur unter anderem Namen.

[foobar]

In gewisser Weise geht der Blogpost allerdings am eigentlichen Problem vorbei. Nämlich dem, dass Canonical wiederholt nachträglich Eigenlösungen backt, anstatt sich hinter bereits etablierte Technologien zu stellen.

Unity sehe ich hier nicht mal so sehr als Problem an. Ja, ich persönlich bin nie mit dem Ding warm geworden. Und ich halte bereits die Prämisse, man könne eine Einheitsoberfläche für jeden Gerätetyp bauen, für falsch. Nicht mal Apple hat sich daran versucht und pflegt für iOS und MacOS verschiedene Oberflächen. Weil das eben Sinn macht. Nur Microsoft mit ihrer "tollen" Metro-Oberfläche für Win8 und Canonical mit Unity haben den Versuch gewagt. Und sind beide gescheitert. Ein Lenkrad ist nun mal eben kein gutes Interface für eine Lokomotive, nur weil es im Auto aber so wunderbar funktioniert. Das Interface muss zum Gerät passen. Ist halt so.

Aber Unity ist ein Aufsatz und nicht besonders tief ins System eingegraben. Da lässt sich schnell und mit wenig Aufwand eine Alternative finden, also meinetwegen soll Canonical da ruhig rumexperimentieren bis der Arzt kommt. Ist nicht mein Geld und nicht meine Zeit, die sie verschwenden. Ist ja nicht so, als gäbe es nicht genug andere Desktops.

Nerviger sind Dinge, die tief ins System eingegraben sind und sich nur schwer bis gar nicht auswechseln lassen. Ich habe mich z.B. schon oft darüber geärgert, dass viele Pakete unnötige Abhängigkeiten zu PulseAudio mitbringen. Weil ich den nämlich nicht einsetze. Und was bitte soll dieser Blödsinn mit Mir? Wozu braucht man einen zweiten Display-Server, der konzeptionell nicht mal großartig anders als Wayland ist und deshalb auch keine nennenswerte Innovation darstellt?

Flatpak vs. Snap ist eine weitere solche Baustelle, wo Canonical irgendwie komisch ist. Tolle Idee bei Snap, die Anwendungsisolation von AppArmor-Erweiterungen abhängig zu machen, die man dann nicht in den offiziellen Kernel einbringt. Damit funktionieren Snaps auf anderen Distris dann natürlich nicht richtig. Auch Ubuntu-Nutzer, die aus welchen Gründen auch immer einen eigenen Kernel einsetzen, fliegen damit auf die Fresse. Und selbst, wenn der Patch doch noch kommt (oder schon gekommen ist, mein letzter Stand ist von 08/16), bleibt trotzdem eine AppArmor-Abhängigkeit bestehen. Das beißt sich natürlich mit dem bei Fedora & Co. standardmäßig eingesetztem SELinux. Flatpak arbeitet dagegen mit Chroot und Namespaces und ist so deutlich allgemeiner.

Wenn sich Canonical einen Ruf als innovationsfreudiges Unternehmen verdienen und damit auch einen Marktvorteil ergattern will, wären sie meiner Ansicht nach besser bedient, Probleme anzugehen, für die es bisher noch keine brauchbare Lösung gibt. Anstatt immer zu warten, bis jemand anderes die Idee hat und dann nachträglich mit einer inkompatiblen Alternative dazwischen zu grätschen.