Ausführungsreihenfolge für systemd ändern

[Andreas Kohlbach]

Wie ich die Ausführungsreihenfolge, wie systemd Programme startet,
ändere, weiß ich vom technischen Standpunkt aus ("Before" oder "After"
benutzen). Für den konkreten Fall weiß ich aber auch nach Lesen des
Boot-Log nicht, wo genau ich ansetzen soll. Vielleicht muss ich aber auch
ganz wo anders ansetzen?

Das Problem ist, dass nur manchmal ein Setup für die Konsole (TTY)
beachtet wird; es scheint wirklich vom Zufall (race condition) abhängig
zu sein. Ich habe beim Booten beobachtet, dass er eigentlich immer wie
gewünscht umschaltet. Sobald aber auf Framebuffer umgeschaltet wird,
werden die Einstellungen für die Konsole zunichte gemacht. Außer eben das
Setup für die TTY geschieht zufällig danach.

Nach was muss ich in /lib/systemd/system suchen, um das Einstellen für
die TTY zu verzögern? Oder muss man das ganz anders machen?
--
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[Sven Hartge]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:

> Wie ich die Ausführungsreihenfolge, wie systemd Programme startet,
> ändere, weiß ich vom technischen Standpunkt aus ("Before" oder "After"
> benutzen). Für den konkreten Fall weiß ich aber auch nach Lesen des
> Boot-Log nicht, wo genau ich ansetzen soll. Vielleicht muss ich aber
> auch ganz wo anders ansetzen?

> Das Problem ist, dass nur manchmal ein Setup für die Konsole (TTY)
> beachtet wird; es scheint wirklich vom Zufall (race condition)
> abhängig zu sein. Ich habe beim Booten beobachtet, dass er eigentlich
> immer wie gewünscht umschaltet. Sobald aber auf Framebuffer
> umgeschaltet wird, werden die Einstellungen für die Konsole zunichte
> gemacht. Außer eben das Setup für die TTY geschieht zufällig danach.

> Nach was muss ich in /lib/systemd/system suchen, um das Einstellen für
> die TTY zu verzögern? Oder muss man das ganz anders machen?

Eine genauere Beschreibung des Problems wäre gut.

Ich habe dein Posting jetzt drei Mal gelesen und nicht wirklich
verstanden, wo genau jetzt eigentlich welcher Fehler/welches Problem in
welcher Form auftritt.

S°

--
Sigmentation fault. Core dumped.

[Andreas Kohlbach]

Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
es aber nicht besser zu beschreiben. :-/

Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
eines bestimmten anderen - starten.

Erst mal ein Beispiel, wie es im SysV-Style ging: man hatte im passenden
Runlevel, etwa /etc/rcS.d/ die Ziffer hoch gesetzt. Z.B.

/etc/rcS.d/S18console-setup

in

/etc/rcS.d/S20console-setup

umbenannt, um diesen Vorgang später auszuführen.

Nun aber länger, und damit zu systemd:

Wenn ich die Bootmeldungen beobachte, sehe ich, dass auf der TTY auf den
von mir vorgegebenen Font umgeschaltet wird. Dann wird das Display - wie
immer - kurz dunkel, und es ist stattdessen wieder der Default-Font
da. So soll es *nicht* sein.

Manchmal aber funktioniert es, dass es erst dunkel wird und auf
Framebuffer umgeschaltet, und dann erst die Einstellungen für den
Konsolen-Font etc. gemacht werden. So soll es *immer* sein.

Es kam auch schon ein Mal vor, dass es für ein paar Konsolen der TTY (mit
den höheren Nummern, wie tty6) umgesetzt wurde, für andere aber
nicht. Was eben auf eine race condition hin deutet.

Also müsste ich systemd sagen, dass er die Einstellungen für die Konsole
*nach* dem Umschalten auf den Framebuffer vornehmen soll, falls es
überhaupt der Framebuffer ist, der die Einstellungen zunichte macht.

Nun weiß ich nur nicht, welcher Datei in /lib/systemd/system/ ich sagen
soll, dass dieser Prozess vor (Before) oder nach (After) eines anderen
Boot-Prozesses ausgeführt zu werden.

Man soll wohl auch noch "Idle" nutzen können, sollte aber "Before"
und/oder "After" vorziehen laut einer Source im Internet, die ich eben
las.

Kandidaten könnten console-getty.service oder console-getty.service sein,
um dort z.B. "Before" ein zu tragen. Aber welche? Ich finde in
/lib/systemd/system/ außerdem nichts, was auf "*framebuffer*" bzw. "*fb*"
hört.

[Juergen P. Meier]

Andreas Kohlbach <sept15....@spamgourmet.net>:

> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
> es aber nicht besser zu beschreiben. :-/
>
> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
> eines bestimmten anderen - starten.

Ersetze systemd durch einen sysv-init.

Das war jetzt einfach.

[Marc Haber]

Und nicht sinnvoll.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:
> "Juergen P. Meier" <nospa...@jors.net> wrote:
>>Andreas Kohlbach <sept15....@spamgourmet.net>:
>>> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
>>> es aber nicht besser zu beschreiben. :-/
>>> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
>>> eines bestimmten anderen - starten.
>>Ersetze systemd durch einen sysv-init.
>>Das war jetzt einfach.
> Und nicht sinnvoll.

Es koennte (so es denn moeglich waere) durchaus sinnvoll sein. Das man bei
systemd keine "Serialisierung der Systeminitialisierung" inclusive einer
dedizierten Reihenfolge des Startups erzwingen kann, mag manchen (Stichwort
"Geschwindigkeit des Startups") durchaus irrelevant erscheinen, ich per-
soenlich halte das fuer eine inakzeptable Design-Schwaeche und bedauere
daher den Trend "hin zu systemd", der bei den meisten Distributionen zu
finden ist. Eine optionale Parallelisierung des Boot-Vorgangs waere etwas.
mit dem ich durchaus noch leben koennte, was die systemd-Entwickler da
zusammengenagelt haben, ist fuer das debuggen des Bootvorgangs (wenn
Probleme nur ab und zu einmal auftreten) mit "Katastrophe ohne workaround"
noch nicht einmal annaehernd zutreffend beschrieben ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Christoph Kliemt]

Juergen Ilse <jue...@usenet-verwaltung.de> writes:

[...]

> Eine optionale Parallelisierung des Boot-Vorgangs waere etwas.
> mit dem ich durchaus noch leben koennte, was die systemd-Entwickler da
> zusammengenagelt haben, ist fuer das debuggen des Bootvorgangs (wenn
> Probleme nur ab und zu einmal auftreten) mit "Katastrophe ohne workaround"
> noch nicht einmal annaehernd zutreffend beschrieben ...

Lennart weiss, was gut für dich ist. Und jetzt sei brav.

Christoph

[Juergen P. Meier]

Christoph Kliemt <ne...@pgxml.net>:

> Lennart weiss, was gut für dich ist. Und jetzt sei brav.

Nein, das weis nur Mr. Jobs^WCook!

[Marc Haber]

Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> "Juergen P. Meier" <nospa...@jors.net> wrote:
>>>Andreas Kohlbach <sept15....@spamgourmet.net>:
>>>> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
>>>> es aber nicht besser zu beschreiben. :-/
>>>> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
>>>> eines bestimmten anderen - starten.
>>>Ersetze systemd durch einen sysv-init.
>>>Das war jetzt einfach.
>> Und nicht sinnvoll.
>
>Es koennte (so es denn moeglich waere) durchaus sinnvoll sein. Das man bei
>systemd keine "Serialisierung der Systeminitialisierung" inclusive einer
>dedizierten Reihenfolge des Startups erzwingen kann, mag manchen (Stichwort
>"Geschwindigkeit des Startups") durchaus irrelevant erscheinen, ich per-
>soenlich halte das fuer eine inakzeptable Design-Schwaeche und bedauere
>daher den Trend "hin zu systemd", der bei den meisten Distributionen zu
>finden ist. Eine optionale Parallelisierung des Boot-Vorgangs waere etwas.

>mit dem ich durchaus noch leben koennte, was die systemd-Entwickler das

>zusammengenagelt haben, ist fuer das debuggen des Bootvorgangs (wenn
>Probleme nur ab und zu einmal auftreten) mit "Katastrophe ohne workaround"
>noch nicht einmal annaehernd zutreffend beschrieben ...

In den allermeisten Fällen funktioniert der parallele systemstart ohne
Probleme. Ich habe auch in bald 20 Jahren Linux bisher noch nie Bugs
in diesem Bereich suchen müssen.

Dass Leute wie ich, denen die Boot-Geschwindigkeit ihres Rechners
weitgehend wurst ist, den parallelen Boot nicht abschalten können, ist
zwar lästig, aber wir müssen den Tatsachen ins Auge sehen: Der große
init-Krieg ist verloren, systemd hat gewonnen, und wer was anderes
verwenden möchte wird sehen, dass die großen Distributionen eine nach
der anderen den Support für andere inits aufs Altenteil schicken
werden, und bei denen, die diesen Schritt nicht gehen, wird der
sysvinit-Code erschreckend schnell dem Bitrot anheimfallen.

systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
es einfach geschickter sich damit auszukennen und die Vorteile, die er
zweifellos mitbringt schon heute zu nutzen.

[Christoph Kliemt]

Marc Haber <mh+usene...@zugschl.us> writes:

[...]

> systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
> es einfach geschickter sich damit auszukennen und die Vorteile, die er
> zweifellos mitbringt schon heute zu nutzen.

Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was sind
denn dann so die Vorteile...?

Christoph

[Sven Hartge]

Christoph Kliemt <ne...@pgxml.net> wrote:

> Marc Haber <mh+usene...@zugschl.us> writes:

>> systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
>> es einfach geschickter sich damit auszukennen und die Vorteile, die
>> er zweifellos mitbringt schon heute zu nutzen.

> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was
> sind denn dann so die Vorteile...?

Ich finde das (wenn man es mal verstanden hat) einfach filterbare
Journal sehr praktisch. Außerdem schätze ich, mittels "systemctl
--failed" einfach sehen zu können, wenn irgendwann irgendeine Unit einen
Fehler geworfen hat.

[Paul Muster]

On 24.09.2015 21:16, Christoph Kliemt wrote:
> Marc Haber <mh+usene...@zugschl.us> writes:

>> systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
>> es einfach geschickter sich damit auszukennen und die Vorteile, die er
>> zweifellos mitbringt schon heute zu nutzen.
>
> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was sind
> denn dann so die Vorteile...?

Hauptsächlich Denksport. Z.B. zu solchen Fragestellungen, wie wie man
policy routing auf einem mit systemd verseuch^H^H^Hhenen System
implementiert.


;-) , *SCNR* & mfG Paul

[Andreas Kohlbach]

Das wäre fast wie "Eine *Kleinigkeit* geht in meinem OS nicht, ersetze es
mit einem anderem".

> Das war jetzt einfach.

Nicht wirklich. systemd sieht vor, die Reihenfolge von Bootprozessen zu
ändern. Ich muss nur wissen, welcher genau für den Konsolen-Font, und
welcher für das Umschalten auf [vermutlich] den Framebuffer zuständig
ist.

[Andreas Kohlbach]

Juergen Ilse wrote on 24. September 2015:

[...]

> Es koennte (so es denn moeglich waere) durchaus sinnvoll sein. Das man bei
> systemd keine "Serialisierung der Systeminitialisierung" inclusive einer

> dedizierten Reihenfolge des Startups erzwingen kann [...]

Es wäre schwach, wenn man die Reihenfolge nicht festlegen könnte, während
das alte System es konnte. Und man kann es doch mit systemd, soweit ich
das verstehe. Als Beispiel mal einer der Kandidaten, die ich ändern
müsste /lib/systemd/system/console-shell.service:

| [Unit]
| Description=Console Shell
| Documentation=man:sulogin(8)
| After=systemd-user-sessions.service plymouth-quit-wait.service
| After=rc-local.service
| Before=getty.target
|
| [Service]

[...]

Über "After" und "Before" sollte man das festlegen können.

Um auf meine Eingangsfrage zurück zu kommen. Ich müsste wissen, ob
o.g. Datei eine derer ist, die ich ändern muss. Und welches die Zweite
sein würde. Ich möchte Trial & Error vermeiden, weshalb ich hier frage.

Weil es aber wohl keiner weiß, bzw. man rät, systemd wieder zu entfernen,
wird es am Wochenende wohl doch auf diesen Trial & Error hinaus laufen.

[Thomas 'PointedEars' Lahn]

Andreas Kohlbach wrote:

> Juergen P. Meier wrote on 23. September 2015:
>> Andreas Kohlbach <sept15....@spamgourmet.net>:
>>> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
>>> es aber nicht besser zu beschreiben. :-/
>>>
>>> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
>>> eines bestimmten anderen - starten.
>>
>> Ersetze systemd durch einen sysv-init.
>
> Das wäre fast wie "Eine *Kleinigkeit* geht in meinem OS nicht, ersetze es
> mit einem anderem".

Mit Deinem/unseren OS geht es schon, nur mit der von Dir gewählten Version
der von Dir gewählten Distribution nicht (mehr).

Ich benutze

| # lsb_release -ds
| Debian GNU/Linux unstable (sid)

ohne systemd (demnächst dann deshalb wohl Devuan), mit file-rc. Geht prima.

>> Das war jetzt einfach.
>
> Nicht wirklich. systemd sieht vor, die Reihenfolge von Bootprozessen zu
> ändern. Ich muss nur wissen, welcher genau für den Konsolen-Font, und
> welcher für das Umschalten auf [vermutlich] den Framebuffer zuständig
> ist.

Was denn, das verrät Dir das ach-so-tolle systemd-Journal nicht?

--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Andreas Kohlbach]

E. Braun wrote on 24. September 2015:
>
> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>
>> Es kam auch schon ein Mal vor, dass es für ein paar Konsolen der TTY (mit
>> den höheren Nummern, wie tty6) umgesetzt wurde, für andere aber
>> nicht. Was eben auf eine race condition hin deutet.
>

> Es ist keine race condition, sondern gewünschtes Verhalten und wenn
> was nicht klappt, dann die Schuld der Startskriptschreiber.

Wenn es mal zufällig funktioniert, dann wieder nicht; was anderes ist es
sonst wenn keine race condition?

> Willkommen bei systemd!

Ich bin nicht unbedingt positiv zu systemd eingestellt. Aber es
funktioniert sonst problemlos. Und da irgendwann die meisten Systeme von
systemd assimiliert sein werden, habe ich keine Lust, dagegen
anzukämpfen.

Das wäre so, als wenn man beim Webbrowsen Javascript verteufelt (nicht
unbedingt zu Unrecht) und sich dagegen wehrt. Das Web ist aber anderer
Ansicht, und alles Mögliche ist heute "verskriptet". Wer dagegen
ankämpft, macht sich nur das Leben schwer.

> Eine konsekutive Folge läßt sich m. W. mit den in systemd enthaltenen
> Mitteln nicht erzwingen, da Before… und After… nur auf den Startzeitpunkt
> bezogen werden.

Aber will ich nicht genau das? Den Startzeitpunkt des einen nach dem
eines anderen legen?

> Was man machen kann, ist zu umständlichen Tricks zu greifen. Wenn A→B
> gelten soll, könnte in Bs [Unit]
> ConditionPathExists=/tmp/temporaer
> stehen, wobei A diese Datei nach Beendigung seiner Aufgabe erzeugt.
>
> Wäre nett, wenn mir jemand sagt, daß ich mich einfach nur irre und daß
> es einen systemd-konformeren Weg gibt.

Ohne dass ich das jetzt verstanden habe: systemd kann natürlich bestimmen,
welcher Prozess vor einem anderen gestartet wird, und überlässt es nicht
dem Zufall. Es macht keinen Sinn, etwas erst zu starten, was von etwas
abhängig wäre, was noch gar nicht gestartet war.

Und das ist schon alles, was ich ändern möchte.

[Sven Hartge]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
> Juergen Ilse wrote on 24. September 2015:

> [...]

>> Es koennte (so es denn moeglich waere) durchaus sinnvoll sein. Das man bei
>> systemd keine "Serialisierung der Systeminitialisierung" inclusive einer
>> dedizierten Reihenfolge des Startups erzwingen kann [...]

> Es wäre schwach, wenn man die Reihenfolge nicht festlegen könnte, während
> das alte System es konnte. Und man kann es doch mit systemd, soweit ich
> das verstehe. Als Beispiel mal einer der Kandidaten, die ich ändern
> müsste /lib/systemd/system/console-shell.service:

Ich hoffe du weißt, wie man von der Distribution mitgelieferte Units
ändern oder erweitern kann?

Dies geschieht nicht durch das Verändern der Dateien an ihrem
eigentlichen Ort, sondern durch das Erzeugen eines Verzeichnisses unter
/etc/systemd/system. Im obigen Fall wäre das dann
"/etc/systemd/system/console-shell.service.d/" und dort legt man dann
eine oder mehrere "sonstwas.conf"-Dateien an, welche dann in
lexikalischer Reihenfolge nach dem Parsen der ursprünglichen Unit
geparst und interpretiert werden.

Beispiele z.B. hier:
https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets

[Andreas Kohlbach]

Sven Hartge wrote on 24. September 2015:

>
> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>
>> Es wäre schwach, wenn man die Reihenfolge nicht festlegen könnte, während
>> das alte System es konnte. Und man kann es doch mit systemd, soweit ich
>> das verstehe. Als Beispiel mal einer der Kandidaten, die ich ändern
>> müsste /lib/systemd/system/console-shell.service:
>
> Ich hoffe du weißt, wie man von der Distribution mitgelieferte Units
> ändern oder erweitern kann?

Bisher scheinbar nicht. Man soll also vorhandene Dateien selbst in
/lib/systemd/system/ nicht anfassen? Da Einträge wie "Before" und "After"
ja schon vorhanden sind, die man einfach anpassen könnte.

> Dies geschieht nicht durch das Verändern der Dateien an ihrem
> eigentlichen Ort, sondern durch das Erzeugen eines Verzeichnisses unter
> /etc/systemd/system. Im obigen Fall wäre das dann
> "/etc/systemd/system/console-shell.service.d/" und dort legt man dann
> eine oder mehrere "sonstwas.conf"-Dateien an, welche dann in
> lexikalischer Reihenfolge nach dem Parsen der ursprünglichen Unit
> geparst und interpretiert werden.
>
> Beispiele z.B. hier:
> https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets

Danke. Lesestoff für das Wochenende.

[Juergen P. Meier]

Andreas Kohlbach <sept15....@spamgourmet.net>:

> Juergen P. Meier wrote on 23. September 2015:
>>
>> Andreas Kohlbach <sept15....@spamgourmet.net>:
>>> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
>>> es aber nicht besser zu beschreiben. :-/
>>>
>>> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
>>> eines bestimmten anderen - starten.
>>
>> Ersetze systemd durch einen sysv-init.
>
> Das wäre fast wie "Eine *Kleinigkeit* geht in meinem OS nicht, ersetze es
> mit einem anderem".

BTDT.

>> Das war jetzt einfach.
>
> Nicht wirklich. systemd sieht vor, die Reihenfolge von Bootprozessen zu
> ändern. Ich muss nur wissen, welcher genau für den Konsolen-Font, und
> welcher für das Umschalten auf [vermutlich] den Framebuffer zuständig
> ist.

Es /ist/ so einfach. Man muss sich nur Trauen.

So wie damals der Schritt weg von Windows.

[Juergen P. Meier]

Sven Hartge <sh-...@svenhartge.de>:

Das erinnert mich spontan an den aktuellen XKCD.

[Juergen P. Meier]

Andreas Kohlbach <sept15....@spamgourmet.net>:
>
>> Was man machen kann, ist zu umständlichen Tricks zu greifen. Wenn A?B

>> gelten soll, könnte in Bs [Unit]
>> ConditionPathExists=/tmp/temporaer
>> stehen, wobei A diese Datei nach Beendigung seiner Aufgabe erzeugt.
>>
>> Wäre nett, wenn mir jemand sagt, daß ich mich einfach nur irre und daß
>> es einen systemd-konformeren Weg gibt.
>
> Ohne dass ich das jetzt verstanden habe: systemd kann natürlich bestimmen,
> welcher Prozess vor einem anderen gestartet wird, und überlässt es nicht
> dem Zufall. Es macht keinen Sinn, etwas erst zu starten, was von etwas
> abhängig wäre, was noch gar nicht gestartet war.
>
> Und das ist schon alles, was ich ändern möchte.

Es geht nicht um einzelne Prozesse, sondern um Initialisierungen von
Subsystemen.

Das Initialieren eines Subsystems kann schon mal ein paar Sekunden
lang dauern, bei klassischem System V Init laeuft das in der
sequentiellen Reihenfolge naechste Startscript erst dann los, wenn das
vorherige *abgeschlossen* ist.

Damit wird *GARANTIERT*, dass z.B. vor dem Startversuch des Mailservers
die Netzwerkverbindung und der lokale DNS-Resolver fertig gestartet
sind und auch die Home-Verzeichnisse fertig gemountet sind. etc.pp.

Das ist bei systemd so konzeptionell garnicht moeglich/vorgesehen,
was man so hoert, weil dieser Schrott alles parallelisiert startet.

Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines Subsystems
bevor es das naechste startet?

Kann ein Startscript systemd per vorgesehener API am Start weiterer
Subsysteme hindern, bis es fertig ist?

Das ist eine Fundamentale konzeptionelle Eigenschaft von System V Init.
Wenn systemd diese nicht mindestens Emulieren kann, dann ist es schlicht
und einfach NICHT ALS ERSTATZ GEEIGNET.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

begin 1 followup to Christoph Kliemt <ne...@pgxml.net>:

Es wird genau so ein Erfolg werden wie sein grosses Vorbild aus Redmont.

[Christoph Kliemt]

Andreas Kohlbach <sept15....@spamgourmet.net> writes:

[...]

> Ich bin nicht unbedingt positiv zu systemd eingestellt. Aber es
> funktioniert sonst problemlos. Und da irgendwann die meisten Systeme von
> systemd assimiliert sein werden, habe ich keine Lust, dagegen
> anzukämpfen.

Werden sie? Schaunmermal.

Christoph

--
> fortune
If our behavior is strict, we do not need fun!

[Stefan Froehlich]

On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines

> Subsystems bevor es das naechste startet?

Ich habe mich bis dato noch nicht mit systemd auseinandergesetzt,
weil noch keine Notwendigkeit dazu bestanden hat. Ich hätte aber
*jedenfalls* erwartet, dass Abhängigkeiten genauso aufgelöst werden:
die abhängige Unit startet, nachdem die bedingte Unit *fertig* ist.

Nun gibt es zum Glück man-Pages:

<http://www.freedesktop.org/software/systemd/man/systemd.unit.html>
| If a unit foo.service contains a setting Before=bar.service and both
| units are being started, bar.service's start-up is delayed until
| foo.service is started up.
| [...]
| After= is the inverse of Before=, i.e. while After= ensures that the
| configured unit is started after the listed unit finished starting
| up, Before= ensures the opposite, i.e. that the configured unit is
| fully started up before the listed unit is started.

> Das ist eine Fundamentale konzeptionelle Eigenschaft von System V Init.
> Wenn systemd diese nicht mindestens Emulieren kann, dann ist es schlicht
> und einfach NICHT ALS ERSTATZ GEEIGNET.

Ich nehme an, Du wusstest das ohnehin schon, mir war es bis gerade
eben neu. Gruselig ist es auf alle Fälle.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan! Da steckt mehr drin, als man denkt.
(Sloganizer)

[Juergen Ilse]

Hallo,

Einer der (zweifelhaften) Vorteile ist es, dass virtuelle Textconsolen erst
"bei Bedarf" neu erzeugt werden, statt sie in fester Zahl (12 Stueck?) be-
reits nach dem Start des Kernels zur Verfuegung zu haben. Das muss unheim-
lich viel Resourcen sparen, wenn es denn so wichtig ist ...

Weitere Vorteile sind "socket-aktivierte Services". Fuer manche Leute sicher-
lich ganz toll, aber ich habe eher nur bedingt Bedarf dafuer ...

Dann gibt es da noch "normalerweise keine scripte mehr sondern nur einfache
Konfigurationsdateien fuer Services". Dass damit nicht alles funktioniert,
was man frueher bei SYSV-init mit scripten gemacht hat, fuehrt dazu, dass
man alles was ohne diese scripte nicht geht als obsolet erklaert und die
Services, bei denen das scripting nachweislich sinnvoll waere, dann schlicht
in systemd integriert (ich frage mich immer noch, was denn ein sntpd oder
ein logger im init zu suchen haben, aber ich gehoere ja auch nicht zu den
erleuchteten, die die Weisheit der systemd-Entwickler in ihrer gesamten
Tragweite erfassen koennen ...).

Auf das aufzaehlen weiterer "Vorteile" verzichte ich lieberm, bevor der
Drang rueckwaerts zu fruehstuecken bei mir zu gross wird.

[Juergen Ilse]

Hallo,

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
> Juergen Ilse wrote on 24. September 2015:
> [...]
>> Es koennte (so es denn moeglich waere) durchaus sinnvoll sein. Das man bei
>> systemd keine "Serialisierung der Systeminitialisierung" inclusive einer
>> dedizierten Reihenfolge des Startups erzwingen kann [...]
> Es wäre schwach, wenn man die Reihenfolge nicht festlegen könnte, während
> das alte System es konnte. Und man kann es doch mit systemd, soweit ich
> das verstehe. Als Beispiel mal einer der Kandidaten, die ich ändern
> müsste /lib/systemd/system/console-shell.service:
> | [Unit]
> | Description=Console Shell
> | Documentation=man:sulogin(8)
> | After=systemd-user-sessions.service plymouth-quit-wait.service
> | After=rc-local.service
> | Before=getty.target
> |
> | [Service]
> [...]
> Über "After" und "Before" sollte man das festlegen können.

Nach allem, was ich bisher darueber gelesen habe, kann man damit festlegen,
dass ein Service spaeter gestartet wird, als ein anderer Service gestartet
wurde, nicht aber, dass ein Service erst nach der vollstaendigen Initiali-
sierung eiens andere Services gestartet wird. Damit sind Pin manchen Kon-
stellationen "timingabhaengige Probleme" fast vorprogrammiert.

[Juergen Ilse]

Hallo,

Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
>> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines
>> Subsystems bevor es das naechste startet?
> Ich habe mich bis dato noch nicht mit systemd auseinandergesetzt,
> weil noch keine Notwendigkeit dazu bestanden hat. Ich hätte aber
> *jedenfalls* erwartet, dass Abhängigkeiten genauso aufgelöst werden:
> die abhängige Unit startet, nachdem die bedingte Unit *fertig* ist.

Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem ist
bereits vollstaendig initialisiert" uebereinstimmen muss. Nachdem was ich
bisher gelesen habe, muss beides nicht in allen Faellen vollstaendig
uebereinstimmen ...

[Dietz Pröpper]

Juergen Ilse wrote:

> Hallo,
>
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
>>> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines
>>> Subsystems bevor es das naechste startet?
>> Ich habe mich bis dato noch nicht mit systemd auseinandergesetzt,
>> weil noch keine Notwendigkeit dazu bestanden hat. Ich hätte aber
>> *jedenfalls* erwartet, dass Abhängigkeiten genauso aufgelöst werden:
>> die abhängige Unit startet, nachdem die bedingte Unit *fertig* ist.
>
> Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem ist
> bereits vollstaendig initialisiert" uebereinstimmen muss. Nachdem was ich
> bisher gelesen habe, muss beides nicht in allen Faellen vollstaendig
> uebereinstimmen ...

Ohne jetzt für systemd argumentieren zu wollen, *das* Problem kannst Du Dir
auch mit sysvinit einfangen.

--
"Requirements are 100% complete!" Consultant Three-of-Four repeated. After
an uncomfortable pause, he continued, "But they are not yet documented."
(http://thedailywtf.com/Articles/Invasion-of-the-Consultants.aspx)

[Juergen Ilse]

Hallo,

Dietz Pröpper <dietz...@rotfl.franken.de> wrote:

> Juergen Ilse wrote:
>> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>>> On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
>>>> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines
>>>> Subsystems bevor es das naechste startet?
>>> Ich habe mich bis dato noch nicht mit systemd auseinandergesetzt,
>>> weil noch keine Notwendigkeit dazu bestanden hat. Ich hätte aber
>>> *jedenfalls* erwartet, dass Abhängigkeiten genauso aufgelöst werden:
>>> die abhängige Unit startet, nachdem die bedingte Unit *fertig* ist.
>> Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem ist
>> bereits vollstaendig initialisiert" uebereinstimmen muss. Nachdem was ich
>> bisher gelesen habe, muss beides nicht in allen Faellen vollstaendig
>> uebereinstimmen ...
> Ohne jetzt für systemd argumentieren zu wollen, *das* Problem kannst Du Dir
> auch mit sysvinit einfangen.

Stimmt, Und bei SYSV-init habe ich i.d.R. die Moeglichkeit, mittels scripten
doch noch eine Loesung dafuer zusammenzubauen, aber scripting wurde ja von
den systemd-Entwicklern in ihrer unerschoepflichen Weisheit verteufelt und
*eigentlich* nicht mehr vorgesehen ...

[Stefan Froehlich]

On Fri, 25 Sep 2015 09:39:06 Juergen Ilse wrote:
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> > On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
> >> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS*
> >> eines Subsystems bevor es das naechste startet?

> > Ich habe mich bis dato noch nicht mit systemd
> > auseinandergesetzt, weil noch keine Notwendigkeit dazu bestanden
> > hat. Ich hätte aber *jedenfalls* erwartet, dass Abhängigkeiten
> > genauso aufgelöst werden: die abhängige Unit startet, nachdem
> > die bedingte Unit *fertig* ist.

> Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem
> ist bereits vollstaendig initialisiert" uebereinstimmen muss.

Die Diskussion, wann ein Subsystem "vollständig initialisiert" ist,
hatten wir hier ja schon ausführlich - mit der Quintessenz, dass man
das nicht generisch feststellen kann.

> Nachdem was ich bisher gelesen habe, muss beides nicht in allen
> Faellen vollstaendig uebereinstimmen ...

Stimmt schon, aber es könnte doch z.B. wenigstens Vorkehrungen dafür
geben, dass Units, die *wissen*, wann sie fertig initialisiert sind,
das dem systemd auch mitteilen können. So, wie das gelöst ist, sehe
ich nicht sehr viel Sinn hinter Before= und After=; der
Startzeitpunkt bringt für sich alleine doch genau gar nichts.

Btw. teilen die Autoren von systemd diese Meinung, da sie
schreiben:

| Note that while systemd offers a flexible dependency system between
| units it is recommended to use this functionality only sparingly and
| instead rely on techniques such as bus-based or socket-based
| activation which make dependencies implicit, resulting in a both
| simpler and more flexible system.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Für die Sekunden der Einsamkeit: Stefan - rudern, zum Relaxen der Hacksen!
(Sloganizer)

[Edzard Egberts]

E. Braun wrote:

> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>> Und da irgendwann die meisten Systeme von systemd assimiliert sein
>> werden, habe ich keine Lust, dagegen anzukämpfen.
>

> Schon klar, ich sehe das auch ganz pragmatisch. Leider beheben weder
> guter Wille noch Fatalismus die tatsächlich auftretenden Probleme…

Einfach etwas abwarten könnte auch helfen. Ich habe die Leute dieser
Gruppe eigentlich als etwas konservativer eingeschätzt, aber scheinbar
muss hier jeder unbedingt schon systemd verwenden. Wartet doch mal, bis
das fertig ist!

Ich beobachte zunehmend amüsiert die Entwicklung von CentOS 7 -
vorgestern dachte ich noch bei den neuen Features von GNOME3 (auch aus
dem Poettering-Team), dass das tatsächlich langsam benutzbar werden
könnte, aber die vollmundige Botschaft "Thunderbird is back" war dann
doch der Brüller: Die haben es erst jetzt geschafft, eine derart
verbreitete Software auf ihr neues System umzustellen? Weia, CentOS 6
läuft November 2020 aus, da müssen die langsam mal einen Zahl zulegen! :o(

[Juergen Ilse]

Hallo,

Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:

> Stimmt schon, aber es könnte doch z.B. wenigstens Vorkehrungen dafür
> geben, dass Units, die *wissen*, wann sie fertig initialisiert sind,
> das dem systemd auch mitteilen können. So, wie das gelöst ist, sehe
> ich nicht sehr viel Sinn hinter Before= und After=; der
> Startzeitpunkt bringt für sich alleine doch genau gar nichts.
> Btw. teilen die Autoren von systemd diese Meinung, da sie
> schreiben:
> | Note that while systemd offers a flexible dependency system between
> | units it is recommended to use this functionality only sparingly and
> | instead rely on techniques such as bus-based or socket-based
> | activation which make dependencies implicit, resulting in a both
> | simpler and more flexible system.

Mit anderen Worten: Baut Software gefaelligst so um, dass sie mit systemd
ordentlich und mit anderen inits gar nicht mehr laeuft, auf das ihr uns
helft, die unliebsame Konkurrenz auszurotten ...

[Christoph Kliemt]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:

[...]

> Stimmt schon, aber es könnte doch z.B. wenigstens Vorkehrungen dafür
> geben, dass Units, die *wissen*, wann sie fertig initialisiert sind,
> das dem systemd auch mitteilen können. So, wie das gelöst ist, sehe
> ich nicht sehr viel Sinn hinter Before= und After=; der
> Startzeitpunkt bringt für sich alleine doch genau gar nichts.

Eine klassische "wird schon gutgehen"-Konstruktion.

>
> Btw. teilen die Autoren von systemd diese Meinung, da sie
> schreiben:
>
> | Note that while systemd offers a flexible dependency system between
> | units it is recommended to use this functionality only sparingly and
> | instead rely on techniques such as bus-based or socket-based
> | activation which make dependencies implicit, resulting in a both
> | simpler and more flexible system.

Hast Du dazu eine Quellenangabe? Das liest sich ja wie "unsere
Abhängigkeitsauflösung war dann doch nix..."

Christoph

[Sven Hartge]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
> Sven Hartge wrote on 24. September 2015:
>> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:

>>> Es wäre schwach, wenn man die Reihenfolge nicht festlegen könnte,
>>> während das alte System es konnte. Und man kann es doch mit systemd,
>>> soweit ich das verstehe. Als Beispiel mal einer der Kandidaten, die
>>> ich ändern müsste /lib/systemd/system/console-shell.service:
>>
>> Ich hoffe du weißt, wie man von der Distribution mitgelieferte Units
>> ändern oder erweitern kann?

> Bisher scheinbar nicht. Man soll also vorhandene Dateien selbst in
> /lib/systemd/system/ nicht anfassen? Da Einträge wie "Before" und
> "After" ja schon vorhanden sind, die man einfach anpassen könnte.

Ja, weil diese Änderungen vom Paket-System beim nächsten Update einfach
wieder überschrieben würden. Wie bei allen Dateien, die nicht explizit
als Config-Dateien markiert sind.

[Sven Hartge]

Edzard Egberts <ed...@tantec.de> wrote:
> E. Braun wrote:
>> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:

>>> Und da irgendwann die meisten Systeme von systemd assimiliert sein
>>> werden, habe ich keine Lust, dagegen anzukämpfen.
>>
>> Schon klar, ich sehe das auch ganz pragmatisch. Leider beheben weder
>> guter Wille noch Fatalismus die tatsächlich auftretenden Probleme…

> Einfach etwas abwarten könnte auch helfen. Ich habe die Leute dieser
> Gruppe eigentlich als etwas konservativer eingeschätzt, aber scheinbar
> muss hier jeder unbedingt schon systemd verwenden. Wartet doch mal,
> bis das fertig ist!

Wenn du ein aktuelles SLES oder RHEL einsetzen willst oder musst, dann
hast du systemd. Und dort kannst du das auch nicht mal eben einfach (wie
bei Debian 8) durch ein anderes Init ersetzen, wenn du noch in
irgendeiner Form Support für dein System haben willst.

Bevor einen also der Zug überrollt, ist es nicht verkehrt, wenn man sich
_rechtzeitig_ mit den Dingen befasst.

Es ist ja schön, wenn du für dich sagen kannst "ich bleibe bis 2020 bei
RHEL6", aber die Realität sieht dann doch anders aus. Eher früher wie
später wird der Zwang zu den neueren Enterprise-Linux-Versionen, dann
mit systemd, kommen und dann hast du keinen Weg mehr daran vorbei.

[Stefan Froehlich]

On Fri, 25 Sep 2015 11:12:06 Christoph Kliemt wrote:
> > So, wie das gelöst ist, sehe ich nicht sehr viel Sinn hinter Before=
> > und After=; der Startzeitpunkt bringt für sich alleine doch genau gar
> > nichts.

> Eine klassische "wird schon gutgehen"-Konstruktion.

So in etwa, ja.

> > | Note that while systemd offers a flexible dependency system between
> > | units it is recommended to use this functionality only sparingly and
> > | instead rely on techniques such as bus-based or socket-based
> > | activation which make dependencies implicit, resulting in a both
> > | simpler and more flexible system.

> Hast Du dazu eine Quellenangabe?

Das stammt direkt aus systemd.unit(5), nachlesbar unter
<http://www.freedesktop.org/software/systemd/man/systemd.unit.html>.

> Das liest sich ja wie "unsere Abhängigkeitsauflösung war dann doch
> nix..."

Vor allem liest es sich für mich wie "lieber User, Du hast leider
Pech gehabt, wende Dich doch bitte an Deinen Softwarehersteller".
Und das finde ich deutlich weniger als mäßig erfreulich.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Selten so gelacht - Stefan: rudern, welch braunes Verlangen!
(Sloganizer)

[Edzard Egberts]

Sven Hartge wrote:

> Edzard Egberts <ed...@tantec.de> wrote:
>> Einfach etwas abwarten könnte auch helfen. Ich habe die Leute dieser
>> Gruppe eigentlich als etwas konservativer eingeschätzt, aber scheinbar
>> muss hier jeder unbedingt schon systemd verwenden. Wartet doch mal,
>> bis das fertig ist!
>
> Wenn du ein aktuelles SLES oder RHEL einsetzen willst oder musst, dann
> hast du systemd.

Das ist aber nur ein Grund zur Beschwerde, wenn man das einsetzen
*muss*, denn wenn man das einsetzen *will* hat man systemd doch
freiwillig akzeptiert. Ich würde CentOS 7 gerne einsetzen, stelle aber
immer wieder von neuem fest, dass ich das nicht will, weil mir dann zu
viel Software fehlt und die Oberfläche nicht grau genug ist.

> Es ist ja schön, wenn du für dich sagen kannst "ich bleibe bis 2020 bei
> RHEL6", aber die Realität sieht dann doch anders aus. Eher früher wie
> später wird der Zwang zu den neueren Enterprise-Linux-Versionen, dann
> mit systemd, kommen und dann hast du keinen Weg mehr daran vorbei.

Logisch, wenn außer mir jeder die neuesten Baustellen einsetzen muss
oder will, kann das ja auch nichts werden. Da muss man von MS-Windows
lernen, das wurde von den Usern so lange downgegraded bzw. verweigert,
bis sie ihr Startmenü zurück hatten! Nur die Linux-User übernehmen
kritiklos (na gut *fast* kritiklos ;o) alle sinnlosen Neuerungen! So
schlimm kann das mit systemd wohl doch nicht sein...

[Michael Baeuerle]

Juergen Ilse wrote:
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> >
> > Stimmt schon, aber es könnte doch z.B. wenigstens Vorkehrungen dafür
> > geben, dass Units, die *wissen*, wann sie fertig initialisiert sind,
> > das dem systemd auch mitteilen können. So, wie das gelöst ist, sehe
> > ich nicht sehr viel Sinn hinter Before= und After=; der
> > Startzeitpunkt bringt für sich alleine doch genau gar nichts.
> > Btw. teilen die Autoren von systemd diese Meinung, da sie
> > schreiben:
> > | Note that while systemd offers a flexible dependency system between
> > | units it is recommended to use this functionality only sparingly and
> > | instead rely on techniques such as bus-based or socket-based
> > | activation which make dependencies implicit, resulting in a both
> > | simpler and more flexible system.
>
> Mit anderen Worten: Baut Software gefaelligst so um, dass sie mit systemd
> ordentlich und mit anderen inits gar nicht mehr laeuft, auf das ihr uns
> helft, die unliebsame Konkurrenz auszurotten ...

... und nebenbei die Portierbarkeit auf andere OS (für die es per
Definition keinen systemd gibt) kaputt macht. Das rundet den Vendor
Lock-in für Linux und systemd dann ab.

[Christian Schweingruber]

Ohne auf die kontroverse Diskussion eingehen zu wollen, hier
eine Referenz, die das Verhalten und mögliche Lösungen recht gut beschreibt:
https://bbs.archlinux.org/viewtopic.php?id=194792

Kurz der ExecStart sollte vom Type oneshot oder forking sein und erst nach vollständiger
Initialisierung exiten (die Kontrolle zurückgeben)

Auf http://www.freedesktop.org/software/systemd/man/systemd.service.html
ist das Ganze unter Options auch genau beschrieben.

viele Grüsse
chrigu

[Juergen P. Meier]

begin 1 followup to Stefan Froehlich <Stefan...@Froehlich.Priv.at>:

> On Fri, 25 Sep 2015 09:39:06 Juergen Ilse wrote:
>> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> > On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
>> >> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS*
>> >> eines Subsystems bevor es das naechste startet?
>
>> > Ich habe mich bis dato noch nicht mit systemd
>> > auseinandergesetzt, weil noch keine Notwendigkeit dazu bestanden
>> > hat. Ich hätte aber *jedenfalls* erwartet, dass Abhängigkeiten
>> > genauso aufgelöst werden: die abhängige Unit startet, nachdem
>> > die bedingte Unit *fertig* ist.
>
>> Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem
>> ist bereits vollstaendig initialisiert" uebereinstimmen muss.
>
> Die Diskussion, wann ein Subsystem "vollständig initialisiert" ist,
> hatten wir hier ja schon ausführlich - mit der Quintessenz, dass man

Hatten wir? Da war ich nicht dabei.

> das nicht generisch feststellen kann.

Ist das so? Das bezweifel ich: Denn das ist ganz einfach:

Genau dann, wenn das Start-script endet.

Zu Dumm, wenn man keine scripte vorsieht.

> Btw. teilen die Autoren von systemd diese Meinung, da sie
> schreiben:
>
>| Note that while systemd offers a flexible dependency system between
>| units it is recommended to use this functionality only sparingly and
>| instead rely on techniques such as bus-based or socket-based
>| activation which make dependencies implicit, resulting in a both
>| simpler and more flexible system.

Ja klar. Erklaer mal wie du socket- oder bus-basiert einen VPN-tunnel
aktivierst, oder Crypto-Volumes aktivierst, deren Schluessel /nicht/
lokal als Datei herumliegen.

[Juergen P. Meier]

Juergen Ilse <jue...@usenet-verwaltung.de>:

> Hallo,
>
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> Stimmt schon, aber es könnte doch z.B. wenigstens Vorkehrungen dafür
>> geben, dass Units, die *wissen*, wann sie fertig initialisiert sind,
>> das dem systemd auch mitteilen können. So, wie das gelöst ist, sehe
>> ich nicht sehr viel Sinn hinter Before= und After=; der
>> Startzeitpunkt bringt für sich alleine doch genau gar nichts.
>> Btw. teilen die Autoren von systemd diese Meinung, da sie
>> schreiben:
>> | Note that while systemd offers a flexible dependency system between
>> | units it is recommended to use this functionality only sparingly and
>> | instead rely on techniques such as bus-based or socket-based
>> | activation which make dependencies implicit, resulting in a both
>> | simpler and more flexible system.
>
> Mit anderen Worten: Baut Software gefaelligst so um, dass sie mit systemd
> ordentlich und mit anderen inits gar nicht mehr laeuft, auf das ihr uns
> helft, die unliebsame Konkurrenz auszurotten ...

Steve Jobs haette es nicht besser machen koennen.

[Marc Haber]

Christoph Kliemt <ne...@pgxml.net> wrote:
>Marc Haber <mh+usene...@zugschl.us> writes:
>> systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
>> es einfach geschickter sich damit auszukennen und die Vorteile, die er
>> zweifellos mitbringt schon heute zu nutzen.
>
>Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was sind
>denn dann so die Vorteile...?

Ich finde es zum Beispiel sexy, dass man nicht mehr raten muss,
welchen Prozess man töten muss, wenn man einen Dienst herunterfahren
möchte. Dann freue ich mich darüber, keine Initscripts mehr schreiben
zu müssen, wobei ich es traurig finde, dass ich auch bald keine
Initscripts mehr schreiben _kann_, wenn ich es für richtig halte. Und
systemd-networkd ist für den durchschnittlichen Server genau das, was
man als Serverjockey haben möchte, wobei ich es hier traurig finde,
dass es so überhaupt keine Unterstützung für Dinge gibt, die der
Meister[tm] nicht für notwendig hält und dass man deswegen Klimmzüge
machen muss, die in ihrer Ekligkeit jedes Initscript der letzten 20
Jahre lockerst überbieten.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Juergen P. Meier" <nospa...@jors.net> wrote:
>Das ist bei systemd so konzeptionell garnicht moeglich/vorgesehen,
>was man so hoert, weil dieser Schrott alles parallelisiert startet.

Es geht halt nichts über ein gut gepflegtes Vorurteil. Das ist aber
auch nichts, was mich an dir überrascht. Auch das ist ein gut
gepflegtes Vorurteil, womit sich die Argumentationskette schließt.

SNCF

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Fri, 25 Sep 2015 09:39:06 Juergen Ilse wrote:
>> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>> > On Fri, 25 Sep 2015 04:19:38 Juergen P. Meier wrote:
>> >> [...] Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS*
>> >> eines Subsystems bevor es das naechste startet?
>
>> > Ich habe mich bis dato noch nicht mit systemd
>> > auseinandergesetzt, weil noch keine Notwendigkeit dazu bestanden
>> > hat. Ich hätte aber *jedenfalls* erwartet, dass Abhängigkeiten
>> > genauso aufgelöst werden: die abhängige Unit startet, nachdem
>> > die bedingte Unit *fertig* ist.
>
>> Die Frage ist, ob "Unit ist beendet" wirklich immer mit "Subsystem
>> ist bereits vollstaendig initialisiert" uebereinstimmen muss.
>
>Die Diskussion, wann ein Subsystem "vollständig initialisiert" ist,
>hatten wir hier ja schon ausführlich - mit der Quintessenz, dass man
>das nicht generisch feststellen kann.

Insbesondere nicht, wenn das Netz, insbesondere IPv6 im Spiel ist.
Schon zu sysvinit-Zeiten war die Reaktion mancher Maintainer "mei, fix
halt Deine Software"; das ist gestern wie heute unrealistisch.

Grüße

[Marc Haber]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>Man soll also vorhandene Dateien selbst in
>/lib/systemd/system/ nicht anfassen?

Nein, solle man nicht, die Änderungen dort überlebmen das nächste
Update nicht.

[Marc Haber]

Paul Muster <exp-3...@news.muster.net> wrote:

>On 24.09.2015 21:16, Christoph Kliemt wrote:
>> Marc Haber <mh+usene...@zugschl.us> writes:
>
>>> systemd _wird_ kommen, man kann es höchstens verzögern, und dann ist
>>> es einfach geschickter sich damit auszukennen und die Vorteile, die er
>>> zweifellos mitbringt schon heute zu nutzen.
>>
>> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was sind
>> denn dann so die Vorteile...?
>

>Hauptsächlich Denksport. Z.B. zu solchen Fragestellungen, wie wie man
>policy routing auf einem mit systemd verseuch^H^H^Hhenen System
>implementiert.

Du bist mir ja schon aus anderen Fachgebieten als sachkompetenter und
sich durch Fakten beeinflussen lassender, ausgesprochen angenehmer
Gesprächspartner bekannt.

Trotzdem bin ich mal so lieb, Dich darauf hinzuweisen, dass systemd
auch für mich noch verhältnismäßig neu ist und ich trotz der in großen
Mengen vorhandenen, durchaus zielführenden Dokumentation Lücken sehe,
die entweder in meinem Wissen oder doch in der Software vorhanden sind
und mir doch tatsächlich die Freiheit nehme, auch ohne Dich zu fragen
in meiner Filterblase Erkundungen nach "best practices" vornehme.

[Marc Haber]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>Juergen P. Meier wrote on 23. September 2015:
>>
>> Andreas Kohlbach <sept15....@spamgourmet.net>:
>>> Ich gebe zu, Folgendes mag sich immer noch verwirrend anhören. Ich weiß
>>> es aber nicht besser zu beschreiben. :-/
>>>
>>> Kurz: ich möchte einen der Bootprozesse verzögert - nach der Ausführung
>>> eines bestimmten anderen - starten.
>>
>> Ersetze systemd durch einen sysv-init.
>
>Das wäre fast wie "Eine *Kleinigkeit* geht in meinem OS nicht, ersetze es
>mit einem anderem".

Das machen doch viele User und landen dann bei Dingen wie Gentoo oder
Mint.

[Andreas Kohlbach]

Juergen P. Meier wrote on 24. September 2015:
>
> Andreas Kohlbach <sept15....@spamgourmet.net>:
>>

>> Nicht wirklich. systemd sieht vor, die Reihenfolge von Bootprozessen zu
>> ändern. Ich muss nur wissen, welcher genau für den Konsolen-Font, und
>> welcher für das Umschalten auf [vermutlich] den Framebuffer zuständig
>> ist.
>
> Es /ist/ so einfach. Man muss sich nur Trauen.
>
> So wie damals der Schritt weg von Windows.

Windows? Ich hatte immer vermutet, gerade du wärst direkt von
DOS - *ehem* - CP/M auf Linux umgestiegen. ;-)

Btw. auch wenn ich Win95 und Win98 auch installiert hatte, war ich doch
meist mit OS/2 unterwegs.

Man musste Windows nur genug hassen, dann war der Umstieg tatsächlich leicht.
--
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[Andreas Kohlbach]

Juergen P. Meier wrote on 24. September 2015:
>
> Andreas Kohlbach <sept15....@spamgourmet.net>:
>>

>> Ohne dass ich das jetzt verstanden habe: systemd kann natürlich bestimmen,
>> welcher Prozess vor einem anderen gestartet wird, und überlässt es nicht
>> dem Zufall. Es macht keinen Sinn, etwas erst zu starten, was von etwas
>> abhängig wäre, was noch gar nicht gestartet war.
>>
>> Und das ist schon alles, was ich ändern möchte.
>
> Es geht nicht um einzelne Prozesse, sondern um Initialisierungen von
> Subsystemen.

Ähm, so kann man es auch nennen.

> Das Initialieren eines Subsystems kann schon mal ein paar Sekunden
> lang dauern, bei klassischem System V Init laeuft das in der
> sequentiellen Reihenfolge naechste Startscript erst dann los, wenn das
> vorherige *abgeschlossen* ist.
>
> Damit wird *GARANTIERT*, dass z.B. vor dem Startversuch des Mailservers
> die Netzwerkverbindung und der lokale DNS-Resolver fertig gestartet
> sind und auch die Home-Verzeichnisse fertig gemountet sind. etc.pp.

>
> Das ist bei systemd so konzeptionell garnicht moeglich/vorgesehen,
> was man so hoert, weil dieser Schrott alles parallelisiert startet.

AFAIK nicht alles. Es wird schon drauf geachtet, dass z.B. Treiber für
Netzwerk-Device geladen sind, bevor sie initialisiert werden. Oder den
der Soundkarte, bevor sie dem Soundsystem (ALSA meist) bekannt gemacht
wird.

> Oder wartet Systemd beim "Before/After" auf *ABSCHLUSS* eines Subsystems
> bevor es das naechste startet?
>

> Kann ein Startscript systemd per vorgesehener API am Start weiterer
> Subsysteme hindern, bis es fertig ist?

Z.B. hat /lib/systemd/system/network-online.target die Zeile

After=network.target

drin, was es halt erst online bringt, nachdem alles in
/lib/systemd/system/network.target abgearbeitet wird. Was
wiederum... Eine lange Kette von Abhängigkeiten.

> Das ist eine Fundamentale konzeptionelle Eigenschaft von System V Init.
> Wenn systemd diese nicht mindestens Emulieren kann, dann ist es schlicht
> und einfach NICHT ALS ERSTATZ GEEIGNET.

Wenn systemd alles parallelisieren würden, würde es keinen erfolgreichen
Boot geben. Folge, keine Distribution würde systemd verwenden.

[Andreas Kohlbach]

Edzard Egberts wrote on 25. September 2015:
>
> Sven Hartge wrote:
>> Edzard Egberts <ed...@tantec.de> wrote:
>>> Einfach etwas abwarten könnte auch helfen. Ich habe die Leute dieser
>>> Gruppe eigentlich als etwas konservativer eingeschätzt, aber scheinbar
>>> muss hier jeder unbedingt schon systemd verwenden. Wartet doch mal,
>>> bis das fertig ist!
>>
>> Wenn du ein aktuelles SLES oder RHEL einsetzen willst oder musst, dann
>> hast du systemd.
>
> Das ist aber nur ein Grund zur Beschwerde, wenn man das einsetzen
> *muss*, denn wenn man das einsetzen *will* hat man systemd doch
> freiwillig akzeptiert.

Es wurde einem "aufgezwungen". Z.B. wenn man, wie ich, Debian
einsetzt. Man wurde nicht gefragt, es wurde einfach umgestellt.

Natürlich ist mir klar, dass man das selbst auch wieder zurückstellen
kann.

Ich würde anderseits vermuten (gibt es darüber Erhebungen? Ich finde
nichts), dass der Großteil der Debian-User bei systemd geblieben ist. Und
es gibt keine Probleme damit, die so groß sind, als dass es nicht
benutzbar wäre. Wäre es so, hätte Debian das schon wieder raus genommen.

Ich bin *kein* systemd-Befürworter. Mag es nicht, wenn etwas etwas
anderes in sich aufsaugt. Andererseits habe zumindest ich, bis auf
Kleinigkeiten, die ggf. auch bei anderen "Boot Prozessoren" auftreten
könnten, keine Probleme.

[Juergen P. Meier]

Marcus Jodorf <tr...@killfile.de>:
> Christoph Kliemt <ne...@pgxml.net> schrieb:

>
>> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was
>> sind denn dann so die Vorteile...?
>

> Du wirst schon mal für den späteren Umstieg zu Windows abgehärtet.
> Mittlerweile darf man ja auch schon bei Updates von systemd oder udev
> öfter mal neu booten und das macht den Umstieg auf Windows Server auf

Zumal man aktuelle Windows Server garnicht mehr so oft booten muss,
und das Booten mittlerweile echt schnell geht. Deutlich schneller
schon als die meisten ueberfrachteten Linux-Server-Distributionen.

Das mit dem BLOAT hat sich mittlerweile ja umgekehrt, Windows-Server
sind schlank und auf das notwendigste Abgespeckt (die naechste Generation
wird dies ueber Modularitaet weiter ins Extrem treiben), waeherend
Linux zum ueberfetteten Bloatmonster mutiert ist.

Die Zeiten, wo ein Linux-Server in einer VM nur ein Bruchteil der
Ressourcen eines windows-Servers benoetigte, sind Vorbei.

Auch Dank solcher Idioten wie Poettering uns seinen Juengern.

> jeden Fall schon mal mental einfacher. Der Voodoo-Faktor gleicht sich
> auch mittlerweile an.

Wartbarkeit, Betriebssicherheit (Stabilitaet), Debug-Moeglichkeiten -
all das haben Linux einst hervorragend ausgezeichnet.

Die Zeiten aendern sich.

> Ist doch nett, wenn man sanft vorbereitet wird, oder?!

So sanft wie ein Zugunglueck?

Darauf kann ich verzichten.

[Juergen P. Meier]

Marcus Jodorf <tr...@killfile.de>:
> Mein persönlicher Schenkelklopfer ist immer noch das Argument mit dem
> schneller Booten.

Komisch. Ein aktuelles CentOS mit systemd und einem Apachen (und
sonst nix) braucht deutlich laenger zu booten als ein Windows 2012 R2
mit einem IIS (dito) bis zum wichtigen "Service geht".

Auf der selben Plattform mit den selben Ressourcen.

> Dafür ist Debuggen wieder richtig schön mühsam geworden.

Dass das wichtig ist, hat man sogar in Villia Redmond verstanden, und
baut auch das in ihrem Spuelmittel deutlich aus...

Viel wichtiger als "bootet 30 Sekunden schneller !!1elf."

[Peter Köhlmann]

Juergen P. Meier wrote:

> Marcus Jodorf <tr...@killfile.de>:
>> Christoph Kliemt <ne...@pgxml.net> schrieb:
>>
>>> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was
>>> sind denn dann so die Vorteile...?
>>
>> Du wirst schon mal für den späteren Umstieg zu Windows abgehärtet.
>> Mittlerweile darf man ja auch schon bei Updates von systemd oder udev
>> öfter mal neu booten und das macht den Umstieg auf Windows Server auf
>
> Zumal man aktuelle Windows Server garnicht mehr so oft booten muss,
> und das Booten mittlerweile echt schnell geht. Deutlich schneller
> schon als die meisten ueberfrachteten Linux-Server-Distributionen.
>
> Das mit dem BLOAT hat sich mittlerweile ja umgekehrt, Windows-Server
> sind schlank und auf das notwendigste Abgespeckt (die naechste Generation
> wird dies ueber Modularitaet weiter ins Extrem treiben), waeherend
> Linux zum ueberfetteten Bloatmonster mutiert ist.

Und du glaubst diesen Blödsinn tatsächlich?

Hast du schon mal einen Windows-Server installiert? Offensichtlich nicht,
denn sonst würdest du dich für diesen Müll schämen

[Stefan Reuther]

Am 25.09.2015 um 23:14 schrieb Marcus Jodorf:
> Juergen Ilse <jue...@usenet-verwaltung.de> schrieb:
>> Auf das aufzaehlen weiterer "Vorteile" verzichte ich lieberm, bevor
>> der Drang rueckwaerts zu fruehstuecken bei mir zu gross wird.

>
> Mein persönlicher Schenkelklopfer ist immer noch das Argument mit dem
> schneller Booten.

> Interessiert auf kleinen Rechnern, die heute sowieso alle SSDs haben und
> so oder so in wenigen Sekunden durch sind kein Schwein mehr.

Für die gefühlte Geschwindigkeit macht "10s" vs. "15s" schon einen
Unterschied, auch, wenn das zu den "60s" eines Rechners mit Magnetplatte
beides deutliche Fortschritte sind. 10s sind "einschalten, hinsetzen,
Schreibtischlampe an, loslegen", bei 15s setzt schon die erste
Langeweile ein.

Letztlich wird Linux immer öfter auch embedded eingesetzt, wo es
eigentlich nur Flashspeicher ("SSD") gibt. Ich habe für ein solches
System, ohne systemd zu kennen, einen init entwickelt, der am Ende einen
ähnlichen Featureset wie systemd hat: Logging, Kommunikations- Bus,
paralleler Dienstestart mit Abhängigkeiten. Und ich habe eine
nichttriviale Menge Zeit damit zugebracht, Dependencies zu optimieren,
weil dem Kunden eben 10s vs 8s nicht egal war.


Stefan

[Dietz Pröpper]

Stefan Reuther wrote:

> Am 25.09.2015 um 23:14 schrieb Marcus Jodorf:
>> Juergen Ilse <jue...@usenet-verwaltung.de> schrieb:
>>> Auf das aufzaehlen weiterer "Vorteile" verzichte ich lieberm, bevor
>>> der Drang rueckwaerts zu fruehstuecken bei mir zu gross wird.
>>
>> Mein persönlicher Schenkelklopfer ist immer noch das Argument mit dem
>> schneller Booten.
>> Interessiert auf kleinen Rechnern, die heute sowieso alle SSDs haben und
>> so oder so in wenigen Sekunden durch sind kein Schwein mehr.
>
> Für die gefühlte Geschwindigkeit macht "10s" vs. "15s" schon einen
> Unterschied, auch, wenn das zu den "60s" eines Rechners mit Magnetplatte
> beides deutliche Fortschritte sind. 10s sind "einschalten, hinsetzen,
> Schreibtischlampe an, loslegen", bei 15s setzt schon die erste
> Langeweile ein.

Wenn man seine Box am Tag 10x neustarten muss, dann sollte man vielleicht
seinen Workflow anders gestalten.

$aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca. 30s.
Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca. 1x die
Woche statt.

In der Situation ist die Startup-Zeit genau eines - uninteressant.

--
"Requirements are 100% complete!" Consultant Three-of-Four repeated. After
an uncomfortable pause, he continued, "But they are not yet documented."
(http://thedailywtf.com/Articles/Invasion-of-the-Consultants.aspx)

[Sven Hartge]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:

> Ich würde anderseits vermuten (gibt es darüber Erhebungen? Ich finde
> nichts), dass der Großteil der Debian-User bei systemd geblieben ist.
> Und es gibt keine Probleme damit, die so groß sind, als dass es nicht
> benutzbar wäre. Wäre es so, hätte Debian das schon wieder raus
> genommen.

Für den Großteil der Benutzer ist es vollkommen egal, was für ein
Init-System im System steckt, solange es den Rechner gebootet bekommt.

Und das schaffen alle Init-Systeme.

Auch für den großteil der Server-Admins und deren Systeme ist es egal,
solange der Server nur bootet.

Es sind die Leute mit Spezial-Schneeflocken-Sonder-Systemen, die an
Dinge stoßen, die bei systemd anders sind oder gar nicht direkt
funktionieren. (Und natürlich Leute, die ein gesundes Cargo-Cult-Syndrom
pflegen.)

Bei Dingen, die anders sind, muss man sich dann halt umgewöhnen. Bei
Dingen, die nicht funktionieren, muss man einen Bug-Report aufmachen.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Bei Dingen, die anders sind, muss man sich dann halt umgewöhnen.

Was schwierig ist, weil große Teile der Community noch nicht richtig
firm mit der Technik sind und spezielle Sonderlocken, zu denen z.B.
bereits sinnvolle IPv6-Konfiguration oder gar Policy-Routing gehören,
nur mit größtem Ekel zu machen sind weil systemd halt keine Hooks hat,
weil da ja jemand ein Skript anklöppeln könnte.

> Bei
>Dingen, die nicht funktionieren, muss man einen Bug-Report aufmachen.

Da unterhält man sich besser mit der Wand. Du darfst Dir gerne meine
Bugreports gegen systemd in git anschauen. Waren größtenteils
Zeitverschwendung.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Bei Dingen, die nicht funktionieren, muss man einen Bug-Report
>> aufmachen.

> Da unterhält man sich besser mit der Wand. Du darfst Dir gerne meine
> Bugreports gegen systemd in git anschauen. Waren größtenteils
> Zeitverschwendung.

Ich weiss. Ich habe nirgends behauptet, dass durch den Bug-Report sich
die Situation ändern wird. Aber zumindest war man selbst nicht untätig,
so dass einem später keinen vorwerfen kann, Feature X oder Bug Y wäre
nicht bekannt, weil es keiner gesagt hat.

CYA, wenn du so willst.

Grüße,
Sven.

[Stefan Reuther]

Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
> Stefan Reuther wrote:
>> Am 25.09.2015 um 23:14 schrieb Marcus Jodorf:
>>> Mein persönlicher Schenkelklopfer ist immer noch das Argument mit dem
>>> schneller Booten.
>>> Interessiert auf kleinen Rechnern, die heute sowieso alle SSDs haben und
>>> so oder so in wenigen Sekunden durch sind kein Schwein mehr.
>>
>> Für die gefühlte Geschwindigkeit macht "10s" vs. "15s" schon einen
>> Unterschied, auch, wenn das zu den "60s" eines Rechners mit Magnetplatte
>> beides deutliche Fortschritte sind. 10s sind "einschalten, hinsetzen,
>> Schreibtischlampe an, loslegen", bei 15s setzt schon die erste
>> Langeweile ein.
>
> Wenn man seine Box am Tag 10x neustarten muss, dann sollte man vielleicht
> seinen Workflow anders gestalten.

Pauschalaussagen sind immer falsch.

> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca. 30s.
> Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca. 1x die
> Woche statt.

Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
ein Grund, auf Suspend-to-RAM zu verzichten. Dadurch gewinne ich
Sicherheit (komplette Trennung vom Stromnetz bei Abwesenheit, alle
Filesysteme in einem sauberen Zustand). Reboots verwende ich für den
Betriebssystemwechsel, denn auch hier besthet kein Leidensdruck, dem man
mit VMs oder anderen sperrigen Vehikeln entgegenwirken müsste (bisher
hatte noch jede VM irgendwelche Usability-Nachteile gegenüber einem
nativen OS).


Stefan

[Markus Grob]

Juergen Ilse schrieb:

> Nach allem, was ich bisher darueber gelesen habe, kann man damit festlegen,
> dass ein Service spaeter gestartet wird, als ein anderer Service gestartet
> wurde, nicht aber, dass ein Service erst nach der vollstaendigen Initiali-
> sierung eiens andere Services gestartet wird. Damit sind Pin manchen Kon-
> stellationen "timingabhaengige Probleme" fast vorprogrammiert.

Was ich bisher gelesen habe, kann man dies festlegen:

Ist eine Unit von einer anderen abhängig, so wird dies mit dem
Schlüsselwort Wants bekundet. Will man, dass eine Unit nur ausgeführt
wird, wenn die abhängige korrekt läuft, so wird Requires eingesetzt.
Wird After verwendet, so muss die gewünschte Unit korrekt fertig
gestartet sein, bevor die neue Unit aufgerufen wird. Dies ist etwa bei
einem Webserver der Fall, welcher bei seinem Start auf das Netzwerk
zurückgreifen können muss.

Gruss, Markus

[Dietz Pröpper]

Stefan Reuther wrote:

> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>> Stefan Reuther wrote:
>>> Für die gefühlte Geschwindigkeit macht "10s" vs. "15s" schon einen
>>> Unterschied, auch, wenn das zu den "60s" eines Rechners mit Magnetplatte
>>> beides deutliche Fortschritte sind. 10s sind "einschalten, hinsetzen,
>>> Schreibtischlampe an, loslegen", bei 15s setzt schon die erste
>>> Langeweile ein.
>>
>> Wenn man seine Box am Tag 10x neustarten muss, dann sollte man vielleicht
>> seinen Workflow anders gestalten.
>
> Pauschalaussagen sind immer falsch.

Daher "vielleicht".

>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca. 30s.
>> Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca. 1x die
>> Woche statt.
>
> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
> ein Grund, auf Suspend-to-RAM zu verzichten.

Du musst während des Bootens nie ein Passwort eingeben?

> Dadurch gewinne ich
> Sicherheit (komplette Trennung vom Stromnetz bei Abwesenheit, alle
> Filesysteme in einem sauberen Zustand).

Iirc war auf den Linuces, die ich bisher in den Fingern hatte einer der
letzten Schritte vor "enter S3" ein "sync". Sauber genug. Welchen
Sicherheitsgewinn versprichst Du Dir von der Stromnetztrennung? (Die bei einem
Laptop ggf. (eingebauter Akku) ohnehin schwierig wird.)

[Thomas Hochstein]

Juergen P. Meier schrieb:

> Das Initialieren eines Subsystems kann schon mal ein paar Sekunden
> lang dauern, bei klassischem System V Init laeuft das in der
> sequentiellen Reihenfolge naechste Startscript erst dann los, wenn das
> vorherige *abgeschlossen* ist.

Und u.a. das versucht man seit längerem zum Zwecke der Beschleunigung
des Systemstarts zu ändern.

> Das ist bei systemd so konzeptionell garnicht moeglich/vorgesehen,
> was man so hoert, weil dieser Schrott alles parallelisiert startet.

Natürlich. Das ist ja ein Ziel dieses und anderer - eigentlich aller
modernen - Init-Systeme: möglichst (!) paralleler Start aller Dienste
pp.

-thh

[Thomas Hochstein]

Andreas Kohlbach schrieb:

> Man soll also vorhandene Dateien selbst in
> /lib/systemd/system/ nicht anfassen?

Genau. Das macht man ganz gerne so, weil auf diese Weise bei Updates
einfach die Standardkonfiguration durch die aktualisierte Fassung
ersetzt werden kann und die gesonderten lokalen Änderungen erhalten
bleiben. Die Alternative wäre ein Prompt der Form "Alte Fassung
beibehalten oder neue Version einspielen?" mit einer
(Sicherheits-)Kopie (entweder der alten Fassung oder der dann nicht
eingespielten neuen Version), die man dann von Hand zusammenführen
"darf". Das ist nicht so wirklich spaßig.

[Thomas 'PointedEars' Lahn]

Dietz Pröpper wrote:

> Stefan Reuther wrote:
>> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca.
>>> 30s. Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca.
>>> 1x die Woche statt.
>>
>> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
>> ein Grund, auf Suspend-to-RAM zu verzichten.
>
> Du musst während des Bootens nie ein Passwort eingeben?

Ja. Du etwa?

Das Passwort gebe ich ein, nachdem das Booten abgeschlossen ist, nämlich auf
der Textkonsole oder im Anmeldedialog des Desktops (hier: KDE, daher kdm).

Trotzdem finde ich Suspend-to-RAM/Disk praktisch und nutze es regelmässig.
Stefans Argument „[durch Verzicht auf Suspend-to-RAM] gewinne ich Sicherheit

(komplette Trennung vom Stromnetz bei Abwesenheit, alle Filesysteme in einem

sauberen Zustand)“ ist auch nur scheinbar stichhaltig.

Es ignoriert erstens die Tatsache, dass ein abgeschalteter Computer ohne
weitere Massnahmen weiterhin mit dem Stromnetz verbunden ist¹, und zweitens
die Möglichkeit für Suspend-to-RAM-or-Disk (s2both(8)). Mit letzterem wird
es möglich, ein Linux-System so herunterzufahren, dass es sowohl nach dem
Einschalten schnell wieder verfügbar ist, als auch saubere Dateisysteme
hinterlässt, sollte die Spannungsquelle in der Zwischenzeit ausfallen oder
unzureichend werden. [2]

_________
¹ Blosses Abschalten schützt also zum Beispiel nicht gegen zerstörerische
statische Aufladung bei nahegelegenem Erdblitzschlag; man muss im
einfachsten Fall *den Stecker ziehen*, also eine *physische* Trennung
vollziehen. [1]

[1] <http://www.t-online.de/computer/hardware/id_19795496/blitzeinschlag-computer-und-fernseher-vor-blitzschaeden-schuetzen.html>
[2] <https://wiki.archlinux.org/index.php/Uswsusp>
<http://manpages.ubuntu.com/manpages/trusty/man8/s2disk.8.html>
<http://suspend.sourceforge.net/intro.shtml>
--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Holger Marzen]

* On Sat, 26 Sep 2015 11:12:24 +0200, Thomas Hochstein wrote:

> Juergen P. Meier schrieb:
>
>> Das Initialieren eines Subsystems kann schon mal ein paar Sekunden
>> lang dauern, bei klassischem System V Init laeuft das in der
>> sequentiellen Reihenfolge naechste Startscript erst dann los, wenn das
>> vorherige *abgeschlossen* ist.
>
> Und u.a. das versucht man seit längerem zum Zwecke der Beschleunigung
> des Systemstarts zu ändern.

Bei meinem Ubuntu (12.04 LTS, zugegeben nicht ganz taufrisch) haben sie
sich dabei so verdaddelt, dass NFS-Mounts mal gehen und mal nicht. Das
Mounten erfolgt offenbar genau dann, wenn am Netz herumkonfiguriert
wird.

Das hat mich dann zu autofs gebracht, schade ist es also nicht.

[Andreas Kohlbach]

Juergen P. Meier wrote on 26. September 2015:
>
> Marcus Jodorf <tr...@killfile.de>:
>> Christoph Kliemt <ne...@pgxml.net> schrieb:
>>
>>> Erfolg durch sich selbst erfüllende Prophezeiung? Na dann. Und was
>>> sind denn dann so die Vorteile...?
>>
>> Du wirst schon mal für den späteren Umstieg zu Windows abgehärtet.
>> Mittlerweile darf man ja auch schon bei Updates von systemd oder udev
>> öfter mal neu booten und das macht den Umstieg auf Windows Server auf
>
> Zumal man aktuelle Windows Server garnicht mehr so oft booten muss,
> und das Booten mittlerweile echt schnell geht. Deutlich schneller
> schon als die meisten ueberfrachteten Linux-Server-Distributionen.

Ist bei dir X dabei?

Während man bei Windows eine GUI als Muss (muss man das heute noch; ich
bin da gar nicht informiert?) annimmt, braucht man bei Linux nicht für
ein reines Server System. Ist Windows dann immer noch schneller?

[Andreas Kohlbach]

Markus Grob wrote on 26. September 2015:
>
> Ist eine Unit von einer anderen abhängig, so wird dies mit dem
> Schlüsselwort Wants bekundet. Will man, dass eine Unit nur ausgeführt
> wird, wenn die abhängige korrekt läuft, so wird Requires
> eingesetzt. Wird After verwendet, so muss die gewünschte Unit korrekt
> fertig gestartet sein, bevor die neue Unit aufgerufen wird. Dies ist
> etwa bei einem Webserver der Fall, welcher bei seinem Start auf das
> Netzwerk zurückgreifen können muss.

Mit "fertig gestartet sein" meinst du "beendet"? Also im Beispiel startet
der Webserver erst, wenn das Netzwerk verfügbar ist - also das Teil von
systemd, was das Netzwerk hoch bringt, *beendet* (fertig) ist?

[Andreas Kohlbach]

Das ist dann auch neu bei systemd? Bei anderen Dingen werde ich beim
Update noch darauf hingewiesen, dass diese und jene Konfigurationsdatei
von mir oder einem Skript geändert wurde. Und ob ich die Version vom
Maintainer einspielen, oder die Vorhandene behalten möchte.

[Andreas Kohlbach]

Holger Marzen wrote on 26. September 2015:
>
> Bei meinem Ubuntu (12.04 LTS, zugegeben nicht ganz taufrisch) haben sie
> sich dabei so verdaddelt, dass NFS-Mounts mal gehen und mal nicht. Das
> Mounten erfolgt offenbar genau dann, wenn am Netz herumkonfiguriert
> wird.

Das hört sich genau an meine race condition an, mit der ich zu kämpfen
habe.

Um aber nochmal auf meinen Ausgangspunkt zurück zu kommen. Hat denn
niemand systemd und dazu persönliche Einstellungen des TTY Fonts
vorgenommen? Und dann ggf. das Problem, dass diese -oft, aber eben nicht
immer - ignoriert werden, weil eine andere Umschaltung (Framebuffer?) die
wieder zunichte macht?

Einer der Log Einträge dazu ist:

| Sep 26 12:12:27 andreas systemd[1]: Starting LSB: Set console font and keymap...

was vor dem anderen, den ich im Log nicht lokalisieren kann, wieder
zunichte gemacht wird. Ich müsste halt die Reihenfolge tauschen. Wenn ich
denn wüsste, was der andere ist. Denn ich habe keine Zeile, die sowohl
"systemd" als auch "rame" (was in Framebuffer enthalten sein sollte)
im Log.

[Holger Marzen]

* On Sat, 26 Sep 2015 16:12:11 -0400, Andreas Kohlbach wrote:

> Thomas Hochstein wrote on 26. September 2015:
>>
>> Andreas Kohlbach schrieb:
>>
>>> Man soll also vorhandene Dateien selbst in
>>> /lib/systemd/system/ nicht anfassen?
>>
>> Genau. Das macht man ganz gerne so, weil auf diese Weise bei Updates
>> einfach die Standardkonfiguration durch die aktualisierte Fassung
>> ersetzt werden kann und die gesonderten lokalen Änderungen erhalten
>> bleiben. Die Alternative wäre ein Prompt der Form "Alte Fassung
>> beibehalten oder neue Version einspielen?" mit einer
>> (Sicherheits-)Kopie (entweder der alten Fassung oder der dann nicht
>> eingespielten neuen Version), die man dann von Hand zusammenführen
>> "darf". Das ist nicht so wirklich spaßig.
>
> Das ist dann auch neu bei systemd? Bei anderen Dingen werde ich beim
> Update noch darauf hingewiesen, dass diese und jene Konfigurationsdatei
> von mir oder einem Skript geändert wurde. Und ob ich die Version vom
> Maintainer einspielen, oder die Vorhandene behalten möchte.

Und ob ich mir die Änderungen anzeigen lassen will (diff). Nicht gerade
unwichtig, wenn man gefragt wird, ob man die alte oder die neue Version
haben will.

[Andreas Kohlbach]

Ja, "yes", "no" und anderes. Aber das scheint systemd eben neu zu sein:
"Fasse meine Dateien nicht an. Sie werden sonst ohne Warnung überschrieben".

[Marc Haber]

Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>Thomas Hochstein wrote on 26. September 2015:
>>
>> Andreas Kohlbach schrieb:
>>
>>> Man soll also vorhandene Dateien selbst in
>>> /lib/systemd/system/ nicht anfassen?
>>
>> Genau. Das macht man ganz gerne so, weil auf diese Weise bei Updates
>> einfach die Standardkonfiguration durch die aktualisierte Fassung
>> ersetzt werden kann und die gesonderten lokalen Änderungen erhalten
>> bleiben. Die Alternative wäre ein Prompt der Form "Alte Fassung
>> beibehalten oder neue Version einspielen?" mit einer
>> (Sicherheits-)Kopie (entweder der alten Fassung oder der dann nicht
>> eingespielten neuen Version), die man dann von Hand zusammenführen
>> "darf". Das ist nicht so wirklich spaßig.
>
>Das ist dann auch neu bei systemd? Bei anderen Dingen werde ich beim
>Update noch darauf hingewiesen, dass diese und jene Konfigurationsdatei
>von mir oder einem Skript geändert wurde. Und ob ich die Version vom
>Maintainer einspielen, oder die Vorhandene behalten möchte.

Das alles gilt nur in /etc. Die systemd-Methode verträgt sich
sozusagen überhaupt ganz gar nicht mit dem, was Debian-Anwender
gewöhnt sind.

Nichtsdestotrotz wurde systemd in Debian nach dem systemd-Weg
paketiert, nicht nach dem Debian-Weg, vermutlich wissend, dass man es
sich als Maintainer eines _so_ wichtigen Pakets besser mit seinen
Usern verscherzt als mit seinem Upstream.

[Juergen Ilse]

Hallo,

Thomas Hochstein <t...@inter.net> wrote:
> Juergen P. Meier schrieb:
>> Das Initialieren eines Subsystems kann schon mal ein paar Sekunden
>> lang dauern, bei klassischem System V Init laeuft das in der
>> sequentiellen Reihenfolge naechste Startscript erst dann los, wenn das
>> vorherige *abgeschlossen* ist.
> Und u.a. das versucht man seit längerem zum Zwecke der Beschleunigung
> des Systemstarts zu ändern.

Du kannst dir gar nicht vorstellen, wie egal mir die Geschwindigkeit
des Bootvorgangs sein kann, wenn diese Innovattion durch den Wegfall
von Debugging-Moeglichkeiten bei Bootproblemen erkauft werden ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Dietz Pröpper]

Thomas 'PointedEars' Lahn wrote:

> Dietz Pröpper wrote:
>
>> Stefan Reuther wrote:
>>> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>>>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca.
>>>> 30s. Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca.
>>>> 1x die Woche statt.
>>>
>>> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
>>> ein Grund, auf Suspend-to-RAM zu verzichten.
>>
>> Du musst während des Bootens nie ein Passwort eingeben?
>
> Ja. Du etwa?

Ja. Luks mag ohne nicht so recht.

> Das Passwort gebe ich ein, nachdem das Booten abgeschlossen ist, nämlich auf
> der Textkonsole oder im Anmeldedialog des Desktops (hier: KDE, daher kdm).

"Zum Desktop" von oben hörte sich für mich nicht nach "DM da" an.

> Trotzdem finde ich Suspend-to-RAM/Disk praktisch und nutze es regelmässig.
> Stefans Argument „[durch Verzicht auf Suspend-to-RAM] gewinne ich Sicherheit
> (komplette Trennung vom Stromnetz bei Abwesenheit, alle Filesysteme in einem
> sauberen Zustand)“ ist auch nur scheinbar stichhaltig.

Eben.

[Martin Vaeth]

Markus Grob <sno...@ilnet.ch> wrote:
> Juergen Ilse schrieb:
>
>> Nach allem, was ich bisher darueber gelesen habe, kann man damit festlegen,
>> dass ein Service spaeter gestartet wird, als ein anderer Service gestartet
>> wurde, nicht aber, dass ein Service erst nach der vollstaendigen Initiali-
>> sierung eiens andere Services gestartet wird. Damit sind Pin manchen Kon-
>> stellationen "timingabhaengige Probleme" fast vorprogrammiert.
>
> Was ich bisher gelesen habe, kann man dies festlegen:

Nein, das ist *prinzipiell* nicht möglich, und das hat nichts
mit systemd zu tun, sondern ist die prinzipielle Schwäche des
Parallelstarts. systemd versucht, diese Schwäche zu umgehen,
indem es von Programmen fordert, dass diese mit der systemd-Bibliothek
gelinkt werden, und *gewisse* Rückmeldungen machen. (Dass diese
prinzipielle Fehlkonzeption ebenfalls unzureichend ist,
muss eigentlich nicht weiter erläutert werden.)

> Ist eine Unit von einer anderen abhängig, so wird dies mit dem
> Schlüsselwort Wants bekundet. Will man, dass eine Unit nur ausgeführt
> wird, wenn die abhängige korrekt läuft, so wird Requires eingesetzt.

Nein. Der Unterschied zwischen "Wants" und "Requires" ist nur,
dass bei "Requires" die Unit nicht gestartet wird, falls der
*Versuch*, die abhängige Unit zu starten, fehlschlägt.
Es gibt *keine* Garantie, dass beim abhängigen Service die
gewünschte *Funktionalität* bereits voll zur Verfügung steht.

> Wird After verwendet, so muss die gewünschte Unit korrekt fertig
> gestartet sein, bevor die neue Unit aufgerufen wird.

Schlimmer noch: Bei "After" wird nicht einmal *versucht*,
die abhängige Unit zu starten. Nur, falls "zufällig" beide
durch das selbe Kommando (etwa beim Booten) aktiviert würden,
wird der einen ein zeitlicher Vorzug gegeben.

[Martin Vaeth]

Marc Haber <mh+usene...@zugschl.us> wrote:
> init-Krieg ist verloren, systemd hat gewonnen, und wer was anderes
> verwenden möchte wird sehen, dass die großen Distributionen eine nach
> der anderen den Support für andere inits aufs Altenteil schicken
> werden, und bei denen, die diesen Schritt nicht gehen, wird der
> sysvinit-Code erschreckend schnell dem Bitrot anheimfallen.

Ein realistischeres Szenario auf längere Sicht ist, dass
alle Distributionen, die törichterweise auf nur-systemd
eschwenkt sind, sich mit diesem Schritt überflüssig gemacht
haben. Sobald die Binärpaket-Verwaltung auf
systemd/Redhat-Art geschieht: Was kann dann Debian/Ubuntu/...
noch bieten, was vom Original Redhat/Fedora, das bereits jetzt
die ausschließliche Kontrolle über Aufnahe oder Ablehnung von
Features in das systemd-Betriebssystem hat, nicht wesentlich
besser geboten werden kann?

Bei source-basierten Distributionen ist derzeit nicht abzusehen,
dass sie sich in diese selbstgewählte Sackgasse begeben werden,
aber sie haben eben den Vorteil, nicht auf die Distribution
von Binärcode (außer auf lokalen Rechnern) angewisen zu sein.
Bei Gentoo ist derzeit nicht zu erwarten, dass der Support
für nicht-systemd entfernt wird.

Aber natürlich ist Gentoo nur ein kleines gallisches Dorf
mit dem Zaubertrank "source-basiert", der so unglaublich
stark macht.

[Martin Vaeth]

Juergen P. Meier <nospa...@jors.net> wrote:
>
> Ja klar. Erklaer mal wie du socket- oder bus-basiert einen VPN-tunnel
> aktivierst, oder Crypto-Volumes aktivierst, deren Schluessel /nicht/
> lokal als Datei herumliegen.

Mit dem systemd-Betriebsystem geht das schon:
*Irgendwo* muss der Schluessel ja sein, z.B. auf einem
USB-Stick. Der wird dann an udisks2 gemeldet, was dann
über dbus (oder - sobald die letzte Bastion eingenommen ist -
über kdbus) eine entsprechende Rückmeldung an systemd schickt,
die mit policykit durch eine enstprechende Regel entsprechend
authorisiert wird.

Von der Funktionalität her passt das schon alles zusammen.

Dass es mit Unix nichts mehr zu tun hat, und vom Sicherheitsaspekt
schon aufgrund der Komplexität eine wesentlich größere Katastrophe
ist, als es Windows jemals war, ist eine andere Geschichte.

[Thomas 'PointedEars' Lahn]

Dietz Pröpper wrote:

> Thomas 'PointedEars' Lahn wrote:
>>> Du musst während des Bootens nie ein Passwort eingeben?
>> Ja. Du etwa?
>
> Ja. Luks mag ohne nicht so recht.

Faszinierend.

[Thomas 'PointedEars' Lahn]

Marc Haber wrote:

> Andreas Kohlbach <sept15....@spamgourmet.net> wrote:
>>Thomas Hochstein wrote on 26. September 2015:
>>> Andreas Kohlbach schrieb:
>>>> Man soll also vorhandene Dateien selbst in
>>>> /lib/systemd/system/ nicht anfassen?
>>>
>>> Genau. Das macht man ganz gerne so, weil auf diese Weise bei Updates
>>> einfach die Standardkonfiguration durch die aktualisierte Fassung
>>> ersetzt werden kann und die gesonderten lokalen Änderungen erhalten
>>> bleiben. Die Alternative wäre ein Prompt der Form "Alte Fassung

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>> beibehalten oder neue Version einspielen?" mit einer

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>> (Sicherheits-)Kopie (entweder der alten Fassung oder der dann nicht
>>> eingespielten neuen Version), die man dann von Hand zusammenführen
>>> "darf". Das ist nicht so wirklich spaßig.
>>
>>Das ist dann auch neu bei systemd? Bei anderen Dingen werde ich beim
>>Update noch darauf hingewiesen, dass diese und jene Konfigurationsdatei
>>von mir oder einem Skript geändert wurde. Und ob ich die Version vom
>>Maintainer einspielen, oder die Vorhandene behalten möchte.

Das ist doch *genau* das, was Thomas beschrieben hat?

> Das alles gilt nur in /etc. Die systemd-Methode verträgt sich
> sozusagen überhaupt ganz gar nicht mit dem, was Debian-Anwender
> gewöhnt sind.

Inwiefern? Was ist der Unterschied zwischen

/etc/systemd/system/console-shell.service.d/

und

| # find /etc -type d -name '*.d'
| /etc/sane.d
| /etc/sane.d/dll.d
| /etc/init.d
| /etc/apache2/conf.d
| /etc/pam.d
| /etc/cron.d
| /etc/ConsoleKit/run-session.d
| /etc/ConsoleKit/seats.d
| /etc/ConsoleKit/run-seat.d
| /etc/auto.master.d
| /etc/dpkg/dpkg.cfg.d
| /etc/dbus-1/system.d
| /etc/dbus-1/session.d
| /etc/polkit-1/localauthority/10-vendor.d
| /etc/polkit-1/localauthority/50-local.d
| /etc/polkit-1/localauthority/90-mandatory.d
| /etc/polkit-1/localauthority/20-org.d
| /etc/polkit-1/localauthority/30-site.d
| /etc/polkit-1/nullbackend.conf.d
| /etc/polkit-1/localauthority.conf.d
| /etc/X11/xorg.conf.d
| /etc/X11/Xsession.d
| /etc/X11/Xreset.d
| /etc/java/security/security.d
| /etc/gss/mech.d
| /etc/mysql/conf.d
| /etc/mysql/mysql.conf.d
| /etc/udev/hwdb.d
| /etc/udev/rules.d
| /etc/fonts/conf.d
| /etc/tmpfiles.d
| /etc/apt/sources.list.d
| /etc/apt/trusted.gpg.d
| /etc/apt/apt.conf.d
| /etc/apt/preferences.d
| /etc/sudoers.d
| /etc/hibernate/scriptlets.d
| /etc/Muttrc.d
| /etc/sysctl.d
| /etc/ghostscript/cidfmap.d
| /etc/ghostscript/fontmap.d
| /etc/exim4/conf.d
| /etc/ca-certificates/update.d
| /etc/logrotate.d
| /etc/usb_modeswitch.d
| /etc/apparmor.d
| /etc/insserv.conf.d
| /etc/request-key.d
| /etc/security/namespace.d
| /etc/security/limits.d
| /etc/network/if-up.d
| /etc/network/if-down.d
| /etc/network/interfaces.d
| /etc/network/if-pre-up.d
| /etc/network/if-post-down.d
| /etc/apm/event.d
| /etc/php5/apache2/conf.d
| /etc/php5/cli/conf.d
| /etc/php5/conf.d
| /etc/ld.so.conf.d
| /etc/default/kdm.d
| /etc/rsyslog.d
| /etc/kernel/postrm.d
| /etc/kernel/postinst.d
| /etc/kernel/preinst.d
| /etc/bash_completion.d
| /etc/dhcp/dhclient-enter-hooks.d
| /etc/dhcp/dhclient-exit-hooks.d
| /etc/modprobe.d
| /etc/ufw/applications.d
| /etc/grub.d
| /etc/pm/config.d
| /etc/pm/power.d
| /etc/pm/sleep.d
| /etc/initramfs-tools/conf.d
| /etc/libpaper.d
| /etc/texmf/hyphen.d
| /etc/texmf/fmt.d
| /etc/texmf/texmf.d
| /etc/emacs/site-start.d
| /etc/ifplugd/action.d
| /etc/profile.d
| /etc/resolvconf/update-libc.d
| /etc/chromium.d
| /etc/phpmyadmin/conf.d
| /etc/NetworkManager/dispatcher.d
| /etc/sensors.d
| /etc/ppp/ipv6-up.d
| /etc/ppp/ip-down.d
| /etc/ppp/ip-up.d
| /etc/ppp/ipv6-down.d
| /etc/modules-load.d
| /etc/csh/login.d

?

[Marc Haber]

Martin Vaeth <mar...@mvath.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> init-Krieg ist verloren, systemd hat gewonnen, und wer was anderes
>> verwenden möchte wird sehen, dass die großen Distributionen eine nach
>> der anderen den Support für andere inits aufs Altenteil schicken
>> werden, und bei denen, die diesen Schritt nicht gehen, wird der
>> sysvinit-Code erschreckend schnell dem Bitrot anheimfallen.
>
>Ein realistischeres Szenario auf längere Sicht ist, dass
>alle Distributionen, die törichterweise auf nur-systemd
>eschwenkt sind, sich mit diesem Schritt überflüssig gemacht
>haben. Sobald die Binärpaket-Verwaltung auf
>systemd/Redhat-Art geschieht: Was kann dann Debian/Ubuntu/...
>noch bieten, was vom Original Redhat/Fedora, das bereits jetzt
>die ausschließliche Kontrolle über Aufnahe oder Ablehnung von
>Features in das systemd-Betriebssystem hat, nicht wesentlich
>besser geboten werden kann?

Ex false quodlibet. Lennart hat bezüglich systemd Narrenfreiheit, da
regiert ihm keiner rein.

>Bei source-basierten Distributionen ist derzeit nicht abzusehen,
>dass sie sich in diese selbstgewählte Sackgasse begeben werden,
>aber sie haben eben den Vorteil, nicht auf die Distribution
>von Binärcode (außer auf lokalen Rechnern) angewisen zu sein.
>Bei Gentoo ist derzeit nicht zu erwarten, dass der Support
>für nicht-systemd entfernt wird.
>
>Aber natürlich ist Gentoo nur ein kleines gallisches Dorf
>mit dem Zaubertrank "source-basiert", der so unglaublich
>stark macht.

... und mit der lächerlichsten Bevölkerung.

[Marc Haber]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>und
>
>| # find /etc -type d -name '*.d'

Ich könnte es dir erklären, nach dieser lächerlichen Nummer habe ich
aber keine Lust mehr dazu.

[Thomas 'PointedEars' Lahn]

Marc Haber wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>und
>>
>>| # find /etc -type d -name '*.d'
>
> Ich könnte es dir erklären, nach dieser lächerlichen Nummer habe ich
> aber keine Lust mehr dazu.

Wie meinen?

[Stefan Reuther]

Am 26.09.2015 um 18:03 schrieb Dietz Pröpper:
> Stefan Reuther wrote:
>> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca. 30s.
>>> Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca. 1x die
>>> Woche statt.
>>
>> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
>> ein Grund, auf Suspend-to-RAM zu verzichten.
>
> Du musst während des Bootens nie ein Passwort eingeben?

Singleuser-Rechner. Ansonsten bin ich durchaus in der Lage, die Zeit zur
Passworteingabe aus der Zeitmessung rauszurechnen :)

>> Dadurch gewinne ich
>> Sicherheit (komplette Trennung vom Stromnetz bei Abwesenheit, alle
>> Filesysteme in einem sauberen Zustand).
>
> Iirc war auf den Linuces, die ich bisher in den Fingern hatte einer der
> letzten Schritte vor "enter S3" ein "sync". Sauber genug.

Ich erinnere mich zumindest an Berichte, dass die Redmonter nicht so
freundlich seien und es überhaupt nicht mögen, wenn nach dem
unvorhergesehenen Kaltstart erstmal Linux in den Filesystemen rumrührt.

> Welchen Sicherheitsgewinn versprichst Du Dir von der Stromnetztrennung?

Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
geringfügig. Es stehen halt weniger Teile unter Spannung.


Stefan

[Holger Marzen]

* On Sun, 27 Sep 2015 11:29:19 +0200, Marc Haber wrote:

> Martin Vaeth <mar...@mvath.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>> init-Krieg ist verloren, systemd hat gewonnen, und wer was anderes
>>> verwenden möchte wird sehen, dass die großen Distributionen eine nach
>>> der anderen den Support für andere inits aufs Altenteil schicken
>>> werden, und bei denen, die diesen Schritt nicht gehen, wird der
>>> sysvinit-Code erschreckend schnell dem Bitrot anheimfallen.
>>
>>Ein realistischeres Szenario auf längere Sicht ist, dass
>>alle Distributionen, die törichterweise auf nur-systemd
>>eschwenkt sind, sich mit diesem Schritt überflüssig gemacht
>>haben. Sobald die Binärpaket-Verwaltung auf
>>systemd/Redhat-Art geschieht: Was kann dann Debian/Ubuntu/...
>>noch bieten, was vom Original Redhat/Fedora, das bereits jetzt
>>die ausschließliche Kontrolle über Aufnahe oder Ablehnung von
>>Features in das systemd-Betriebssystem hat, nicht wesentlich
>>besser geboten werden kann?
>
> Ex false quodlibet. Lennart hat bezüglich systemd Narrenfreiheit, da
> regiert ihm keiner rein.

Und wieder fällt Redhat vor allem durch seine Kernkompetenz auf:
Inkompatibel zu sein. Dummerweise lief es dieses Mal nicht so, dass die
anderen gesagt haben "dann macht halt euren proprietären Kram", dafür
haben sie es viel zu geschickt angestellt und ihre Entwicklermacht am
Kerneln in die Waagschale geworfen, quasi den Kernel als Geisel
genommen.

Über ein modernes Init-System kann man reden, aber diese Entwicklung
gefällt mir ganz und gar nicht.

Ob wir dasselbe erleben wie mit Solaris? Nachdem sie ein xml-basiertes,
ressourcenfressendes Initsystem verbrochen hatten, war es auch bald
vorbei mit Solaris.

[Thomas 'PointedEars' Lahn]

Stefan Reuther wrote:

> Am 26.09.2015 um 18:03 schrieb Dietz Pröpper:
>> Stefan Reuther wrote:
>>> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>>>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca.
>>>> 30s. Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca.
>>>> 1x die Woche statt.
>>>
>>> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
>>> ein Grund, auf Suspend-to-RAM zu verzichten.
>>>

>>> Dadurch gewinne ich Sicherheit (komplette Trennung vom Stromnetz bei
>>> Abwesenheit, alle Filesysteme in einem sauberen Zustand).
>>
>> Iirc war auf den Linuces, die ich bisher in den Fingern hatte einer der
>> letzten Schritte vor "enter S3" ein "sync". Sauber genug.
>
> Ich erinnere mich zumindest an Berichte, dass die Redmonter

(Auch an alle anderen Falschschreiber: ) Die Stadt im US-Bundesstaat
Washington, wo sich der Hauptsitz der Microsoft Corporation befindet, heisst
_Redmond_.

> nicht so freundlich seien und es überhaupt nicht mögen, wenn nach dem
> unvorhergesehenen Kaltstart erstmal Linux in den Filesystemen rumrührt.

Wichtig ist nur, dass man gemountete Windows-Dateisysteme (z. B. NTFS) – vor
allem das auf der Windows-Systempartition – unter GNU/Linux unmountet, bevor
man s2*(8) verwendet, da es andernfalls zu Problemen (mindestens
Inkonsistenzen) kommen kann, wenn man nach der Hibernation zuerst Windows
bootet.

Ich habe mir dafür ein Shellskript geschrieben, welches ich nach
Konfiguration von KDE (Systemeinstellungen → Eigene Kurzbefehle) mit fn+F3
bzw. Fn+F4 (da ist bei meinen Notebooks jeweils die Sleep-Funktion
vorgesehen – die Tasten sind jeweils mit etwas ähnlich wie „☾“ bzw. „Zz…“
beschriftet) ausführe. Der relevante Teil sieht so aus:

,----[ /home/****/bin/hibernate ]
| #!/bin/sh
| # […]
|
| unset win_was_mounted
| win_partition=/dev/sda2
| mount 2>/dev/null | grep -e "^$win_partition\\>" >/dev/null 2>&1
| [ $? -eq 0 ] && win_was_mounted=1
| if [ $win_was_mounted ]; then
| while ! sudo umount "$win_partition"
| do
| unset REPLY
| while [ ! $REPLY ]
| do
| read -n 1 -p "
| Could not umount Windows system partition ($win_partition).
| Hibernate anyway (if you say Yes, DO NOT boot Windows in the meantime)
| [y|N|l|?]? " \
| -s
| [ ! $REPLY ] && REPLY=N
| printf "$REPLY\n\n"
|
| case $REPLY in
| [Yy])
| break 2;;
| [Nn])
| exit 1;;
| [Ll])
| unset REPLY
|
| fuser -m "$win_partition"
| echo
| lsof "$win_partition"
|
| while [ ! $REPLY ]
| do
| read -n 1 -p "
| Terminate/kill these processes and try again [y|k|N]? " \
| -s
| [ ! $REPLY ] && REPLY=N
| printf "$REPLY\n\n"
|
| case $REPLY in
| [Yy])
| unset REPLY
| sudo fuser -k -15 "$win_partition"
| break;;
| [Kk])
| unset REPLY
| sudo fuser -k "$win_partition"
| break;;
| [Nn])
| unset REPLY
| break;;
| '?')
| unset REPLY
| printf "y) Yes, terminate processes
| k) Yes, KILL processes
| N) No, do not terminate/kill processes
| ?) Show this help\n\n";;
| *)
| unset REPLY
| printf "Invalid choice\n"
| esac
| done
| ;;
| '?')
| unset REPLY
| printf "y) Yes, hibernate anyway
| N) No, do not hibernate now (default)
| l) List processes using the partition
| ?) Show this help\n\n";;
| *)
| unset REPLY
| printf "Invalid choice\n"
| esac
| done
| done
|
| printf "Windows system partition (%s) safely umounted.\n"
| "$win_partition"
| fi
|
| # […]
| sudo /usr/sbin/hibernate
| exit_status=$?
|
| echo
|
| if [ $win_was_mounted ]; then
| if sudo mount "$win_partition"; then
| printf "\nWindows system partition (%s) re-mounted." "$win_partition"
| else
| echo
| printf >&2 "Windows system partition (%s) could not be re-mounted." \
| "$win_partition"
| fi
|
| echo
| fi
|
| […]
|
| exit $exit_status
`----

(Optimierungsvorschläge nehme ich gern entgegen.)

Das erlaubt es mir, schnell von Linux zu Windows und zurück zu wechseln, was
vor allem aufgrund meines älteren Scanners, für den es keine Linux-Treiber
gibt, sowie mangels Speicherplatz für eine VM, gelegentlich nötig ist.

>> Welchen Sicherheitsgewinn versprichst Du Dir von der Stromnetztrennung?
>
> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
> geringfügig. Es stehen halt weniger Teile unter Spannung.

Wie ich bereits in <news:1888253.F...@PointedEars.de> geschrieben
habe, stellt ein blosses Ausschalten des Computers eben *keine* Trennung vom
Stromnetz dar, schützt also _nicht_ gegen Überspannung/Blitzschlag. Um eine
effektive Trennung zu erreichen, müsstest Du mit dem Ausschalten weitere
Massnahmen koordinieren (auch eine Zeitschaltuhr an der Mehrfachsteckdose
reicht _nicht_ – das Kabel ist ja immer noch angeschlossen). Und selbst
dann hat Dein Computer keine Chance, wenn der Blitz ins Haus direkt
einschlägt (und nicht nur daneben).

Ausserdem ist die "Stromersparnis" (autsch!) von Stand-by gegenüber Save-to-
Disk/RAM mit Stand-by inzwischen erfreulicherweise minimal, so dass auch
dieses Argument nicht stichhaltig ist.

[Martin Vaeth]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Martin Vaeth <mar...@mvath.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>> init-Krieg ist verloren, systemd hat gewonnen, und wer was anderes
>>> verwenden möchte wird sehen, dass die großen Distributionen eine nach
>>> der anderen den Support für andere inits aufs Altenteil schicken
>>> werden, und bei denen, die diesen Schritt nicht gehen, wird der
>>> sysvinit-Code erschreckend schnell dem Bitrot anheimfallen.
>>
>>Ein realistischeres Szenario auf längere Sicht ist, dass
>>alle Distributionen, die törichterweise auf nur-systemd
>>eschwenkt sind, sich mit diesem Schritt überflüssig gemacht
>>haben. Sobald die Binärpaket-Verwaltung auf
>>systemd/Redhat-Art geschieht: Was kann dann Debian/Ubuntu/...
>>noch bieten, was vom Original Redhat/Fedora, das bereits jetzt
>>die ausschließliche Kontrolle über Aufnahe oder Ablehnung von
>>Features in das systemd-Betriebssystem hat, nicht wesentlich
>>besser geboten werden kann?
>
> Ex false quodlibet. Lennart hat bezüglich systemd Narrenfreiheit, da
> regiert ihm keiner rein.

Non sequitur. Fakt ist, dass bei der systemd-Entwicklung
das Ziel eines proprietären Vertriebs von Binärprogrammen
(also wesentlich mehr, als nur ein Paketmanager)
eines der erklärten Kernziele ist. Das ist auf etlichen
Blogs nachlesbar, und die Entwicklung von systemd,
insbesondere im Hinblick auf die dafür nötigen
Container-Funktionalitäten, lässt daran auch keinen Zweifel.

Da die Programme dann alle mit allen ihren Abhängigkeiten
kommen, haben sich die jetzigen Binärdistributionen und
ihre Paketmanager überflüssig gemacht.
Redhat hat dieses Ziel anscheinend als einzige Distribution
verstanden. Ob sie das gemeinsam mit Lennart ausgeheckt
haben oder nicht, weiß ich nicht, und es wird für die
fatalen Auswirkungen auch egal sein.

>>Aber natürlich ist Gentoo nur ein kleines gallisches Dorf
>>mit dem Zaubertrank "source-basiert", der so unglaublich
>>stark macht.
>
> ... und mit der lächerlichsten Bevölkerung.

Wenigstens hast Du inhaltliche Argumente.

[Peter Mc Donough]

Am 27.09.2015 um 13:07 schrieb Thomas 'PointedEars' Lahn:
> Stefan Reuther wrote:
>> ...

>> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
>> geringfügig. Es stehen halt weniger Teile unter Spannung.
>
> Wie ich bereits in <news:1888253.F...@PointedEars.de> geschrieben
> habe, stellt ein blosses Ausschalten des Computers eben *keine* Trennung vom

> Stromnetz dar, schützt also _nicht_ gegen Überspannung/Blitzschlag. ...
> ...

> Ausserdem ist die "Stromersparnis" (autsch!) von Stand-by gegenüber Save-to-
> Disk/RAM mit Stand-by inzwischen erfreulicherweise minimal, so dass auch
> dieses Argument nicht stichhaltig ist.
>

Bei einem Rechner nicht, Bei 100 Millionen schon. Wobei ich nicht
unterstelle, dass du 100 Mio. Rechner im Betrieb hast.

Es gehört heutzutage m.E. zu best practice nicht benötigte Verbraucher
vom Stromnetz zu trennen, wenn nicht gewichtige Gründe dagegen sprechen,
einfach weil jeder einzelne auf so simple Weise seinen Teil dazu
beitragen kann, die Umwelteinflüsse durch Energieerzeugung zu vermindern.

Es sind ja nicht nur Rechner, die im Standby minimal Strom brauchen,
sondern X-Millionen anderer Geräte, die in diesem Zusammenhang für viel
Mist verantwortlich sind.

Selbst wenn also der Schalter einer zentrale Steckdosenleiste nichts
gegen Folgen einen Blitzeinschlages schützt, schadet er der Umwelt
nicht, m.E. genügend Grund ihn zu benutzen.

Gruß
Peter

ps. Wer möchte, kann bei sich zu hause einmal nachsehen, wie viel
(Klein)geräte ständig unnötig eingeschaltet sind, die mWh für ein Jahr
ausrechnen und den Wert mit nur 20 Mio. BRD-Wohnungen malnehmen. Da
kommt eine ganze Menge Umweltwutzerei zusammen.

[Thomas 'PointedEars' Lahn]

Peter Mc Donough wrote:

> Am 27.09.2015 um 13:07 schrieb Thomas 'PointedEars' Lahn:
>> Stefan Reuther wrote:
>>> ...
>>> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
>>> geringfügig. Es stehen halt weniger Teile unter Spannung.
>>
>> Wie ich bereits in <news:1888253.F...@PointedEars.de> geschrieben
>> habe, stellt ein blosses Ausschalten des Computers eben *keine* Trennung
>> vom Stromnetz dar, schützt also _nicht_ gegen Überspannung/Blitzschlag.
>> ... ...
>> Ausserdem ist die "Stromersparnis" (autsch!) von Stand-by gegenüber
>> Save-to- Disk/RAM mit Stand-by inzwischen erfreulicherweise minimal, so
>> dass auch dieses Argument nicht stichhaltig ist.
>
> Bei einem Rechner nicht, Bei 100 Millionen schon. Wobei ich nicht
> unterstelle, dass du 100 Mio. Rechner im Betrieb hast.
>
> Es gehört heutzutage m.E. zu best practice nicht benötigte Verbraucher
> vom Stromnetz zu trennen, wenn nicht gewichtige Gründe dagegen sprechen,
> einfach weil jeder einzelne auf so simple Weise seinen Teil dazu
> beitragen kann, die Umwelteinflüsse durch Energieerzeugung zu vermindern.

Das ist *pseudowissenschaftliches*, *pseudogrünes* Gewäsch. Energie wird
nie erzeugt, sondern Energieformen werden ineinander umgewandelt (hatten wir
nicht bereits in <news:de.sci.physik> diskutiert?). *Negative*
Umwelteinflüsse (die Du wohl meinst) kann das nur haben, wenn die Umwandlung
nicht nachhaltig ist, also zum Beispiel überwiegend auf fossilen
Energieträgern beruht, oder zum Ausstoss von Schadstoffen führt. Hier muss
sich jeder bei der Wahl seines Energieversorgers an die eigene Nase fassen.

Ich bin der Erste, der die Monitore im Büro zum Feierabend abschaltet, und
ich ziehe zuhause den Stecker, wenn ich mein Notebook in der Nacht nicht
brauche. Aber wenn ich es vermeiden kann, werde ich sicher nicht mein
Notebook komplett *herunterfahren*, wenn ich nur kurz nicht brauche. Das
bringt nämlich genau gar nichts. Das ständige Ein- und Ausschalten und
Hoch- und Runterfahren verkürzt sogar die Lebensdauer der Hardware (vor
allem bei klassischen Festplatten), was wiederum *tatsächliche* negative
Auswirkungen auf die Umwelt haben kann (Müllproblematik).

> Es sind ja nicht nur Rechner, die im Standby minimal Strom brauchen,
> sondern X-Millionen anderer Geräte, die in diesem Zusammenhang für viel
> Mist verantwortlich sind.

Non sequitur. Das kleine Notebook macht dann den Kohl auch nicht mehr fett.

> Selbst wenn also der Schalter einer zentrale Steckdosenleiste nichts
> gegen Folgen einen Blitzeinschlages schützt, schadet er der Umwelt
> nicht, m.E. genügend Grund ihn zu benutzen.

Die Steckerleiste auszuschalten nützt bezogen auf den gesamten Energiebedarf
eines Haushalts nur dann etwas, wenn die daran angeschlossenen Geräte
andernfalls im Stand-by-Betrieb laufen. Mein Notebook ist aber nach
s2both(8) (getriggert von hibernate(8)) in der Regel ausgeschaltet, das
heisst ich ziehe abends den Stecker; es gibt allerdings die Ausnahme, dass
ich noch was vergessen habe, und dann ist das System in weniger als 1 s
wieder betriebsbereit *und* im alten Zustand, was selbst mit SSD anders
nicht machbar ist.

[Dietz Pröpper]

Thomas 'PointedEars' Lahn wrote:

> Dietz Pröpper wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>>> Du musst während des Bootens nie ein Passwort eingeben?
>>> Ja. Du etwa?
>>
>> Ja. Luks mag ohne nicht so recht.
>
> Faszinierend.

Tja.

Frage am Rand - willst Du darüber sprechen oder tun' wir so als habest Du
geschwiegen?

[Dietz Pröpper]

Stefan Reuther wrote:

> Am 26.09.2015 um 18:03 schrieb Dietz Pröpper:
>> Stefan Reuther wrote:
>>> Am 26.09.2015 um 10:30 schrieb Dietz Pröpper:
>>>> $aktueller Laptop benötigt von Kaltstart bis zu Login-Bildschirm ca. 30s.
>>>> Aufwachen aus Suspend-to-RAM ca. 0.5s. Ein Kaltstart findet so ca. 1x die
>>>> Woche statt.
>>>
>>> Mein neuer Rechner bootet in 10 Sekunden zum Desktop. Das ist für mich
>>> ein Grund, auf Suspend-to-RAM zu verzichten.
>>
>> Du musst während des Bootens nie ein Passwort eingeben?
>
> Singleuser-Rechner. Ansonsten bin ich durchaus in der Lage, die Zeit zur
> Passworteingabe aus der Zeitmessung rauszurechnen :)

;-).

>>> Dadurch gewinne ich
>>> Sicherheit (komplette Trennung vom Stromnetz bei Abwesenheit, alle
>>> Filesysteme in einem sauberen Zustand).
>>
>> Iirc war auf den Linuces, die ich bisher in den Fingern hatte einer der
>> letzten Schritte vor "enter S3" ein "sync". Sauber genug.
>
> Ich erinnere mich zumindest an Berichte, dass die Redmonter nicht so
> freundlich seien und es überhaupt nicht mögen, wenn nach dem
> unvorhergesehenen Kaltstart erstmal Linux in den Filesystemen rumrührt.

Eh, beziehst Du Dich jetzt auf NTFS? O-kay. Den use case habe ich auf Boxen,
die ich suspende zu selten.

>> Welchen Sicherheitsgewinn versprichst Du Dir von der Stromnetztrennung?
>
> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
> geringfügig. Es stehen halt weniger Teile unter Spannung.

Korrigier' mich bitte (Du hast von Elektronik ein wenig mehr Ahnung als meine
Wenigkeit), die "modernen" ("geswitchten") Netzteile sollten gegen
Überspannung recht resistent sein, oder?

[Dietz Pröpper]

Peter Mc Donough wrote:

> Am 27.09.2015 um 13:07 schrieb Thomas 'PointedEars' Lahn:
>> Stefan Reuther wrote:
>>> ...
>>> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
>>> geringfügig. Es stehen halt weniger Teile unter Spannung.
>>
>> Wie ich bereits in <news:1888253.F...@PointedEars.de> geschrieben
>> habe, stellt ein blosses Ausschalten des Computers eben *keine* Trennung
>> vom Stromnetz dar, schützt also _nicht_ gegen Überspannung/Blitzschlag. ...
>> ...
>> Ausserdem ist die "Stromersparnis" (autsch!) von Stand-by gegenüber
>> Save-to- Disk/RAM mit Stand-by inzwischen erfreulicherweise minimal, so
>> dass auch dieses Argument nicht stichhaltig ist.
>
> Bei einem Rechner nicht, Bei 100 Millionen schon. Wobei ich nicht
> unterstelle, dass du 100 Mio. Rechner im Betrieb hast.

Und? Deren Stromverbrauch ist das graue Rauschen in der Grundlast.

> Es gehört heutzutage m.E. zu best practice nicht benötigte Verbraucher
> vom Stromnetz zu trennen, wenn nicht gewichtige Gründe dagegen sprechen,
> einfach weil jeder einzelne auf so simple Weise seinen Teil dazu
> beitragen kann, die Umwelteinflüsse durch Energieerzeugung zu vermindern.

Das mit dem Nutzen des Energiesparens ist ein hoax. Durch ständige
Netztrennung läufst Du Gefahr, die Lebenserwartung der Hardware merklich zu
reduzieren. Und der Löwenanteil an Energie wird nachwievor bei der Produktion
eingesetzt.

> ps. Wer möchte, kann bei sich zu hause einmal nachsehen, wie viel
> (Klein)geräte ständig unnötig eingeschaltet sind, die mWh für ein Jahr
> ausrechnen und den Wert mit nur 20 Mio. BRD-Wohnungen malnehmen. Da
> kommt eine ganze Menge Umweltwutzerei zusammen.

Ich habe mir die Mühe vor einigen Jahren gemacht. Im Vergleich dazu, was ich
an normalem Verbrauch habe (Herd, Spül-/Waschmaschine, Rechner, drei davon
dauerlaufend) sind das ein paar kWh p.a..

[Holger Marzen]

* On Sun, 27 Sep 2015 15:42:01 +0200, Dietz Pröpper wrote:

> Thomas 'PointedEars' Lahn wrote:
>
>> Dietz Pröpper wrote:
>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Du musst während des Bootens nie ein Passwort eingeben?
>>>> Ja. Du etwa?
>>>
>>> Ja. Luks mag ohne nicht so recht.
>>
>> Faszinierend.
>
> Tja.
>
> Frage am Rand - willst Du darüber sprechen oder tun' wir so als habest Du
> geschwiegen?

Wenn er einen netten Schlüsselanhänger, passende Hardware im Rechner und
eine angepasste initrd hat, so dass sich der Schlüsselanhänger während des
Bootens des Rechners lediglich im Umkreis von 2 Metern befinden muss, …

[Marc Haber]

Martin Vaeth <mar...@mvath.de> wrote:
>Fakt ist, dass bei der systemd-Entwicklung
>das Ziel eines proprietären Vertriebs von Binärprogrammen
>(also wesentlich mehr, als nur ein Paketmanager)
>eines der erklärten Kernziele ist. Das ist auf etlichen
>Blogs nachlesbar, und die Entwicklung von systemd,
>insbesondere im Hinblick auf die dafür nötigen
>Container-Funktionalitäten, lässt daran auch keinen Zweifel.

Das ist eine interessante Verschwörungstheorie. Das klingt
unterhaltsam. Erklär mal für die ganz doofen.

[Peter Mc Donough]

Am 27.09.2015 um 15:19 schrieb Thomas 'PointedEars' Lahn:
> Peter Mc Donough wrote:
>> Am 27.09.2015 um 13:07 schrieb Thomas 'PointedEars' Lahn:
>>> Stefan Reuther wrote:
>>> ... ...
>>> Ausserdem ist die "Stromersparnis" (autsch!) von Stand-by gegenüber
>>> Save-to- Disk/RAM mit Stand-by inzwischen erfreulicherweise minimal, so
>>> dass auch dieses Argument nicht stichhaltig ist.

>> ...

>> Es gehört heutzutage m.E. zu best practice nicht benötigte Verbraucher
>> vom Stromnetz zu trennen, wenn nicht gewichtige Gründe dagegen sprechen,
>> einfach weil jeder einzelne auf so simple Weise seinen Teil dazu
>> beitragen kann, die Umwelteinflüsse durch Energieerzeugung zu vermindern.
>
> Das ist *pseudowissenschaftliches*, *pseudogrünes* Gewäsch. Energie wird
> nie erzeugt, sondern Energieformen werden ineinander umgewandelt (hatten wir
> nicht bereits in <news:de.sci.physik> diskutiert?). *Negative*
> Umwelteinflüsse (die Du wohl meinst) kann das nur haben, wenn die Umwandlung
> nicht nachhaltig ist, also zum Beispiel überwiegend auf fossilen
> Energieträgern beruht, oder zum Ausstoss von Schadstoffen führt. Hier muss
> sich jeder bei der Wahl seines Energieversorgers an die eigene Nase fassen.

Es ist bekannt, dass Energie nicht erzeugt, sondern nur umgewandelt
wird. Umgangssprachlich spricht man jedoch von Energieerzeugung.
Der Energieversorger (ist er das?) verkauft, was gekauft wird.
Der Verbraucher (da haben wir nach deiner Verwendung des Wortes
"Energie" ein Problem, den gibt es dann auch nicht) bestimmt mit seinem
Verhalten die Richtung, sofern er es bewusst einsetzt. Was du
nachfolgend beschreibst.

Mit der eigenen Nase ist das jedoch so eine Sache. Mache ich gerne und
überlege bei einem Hinweis, ob er berechtigt ist.

> Ich bin der Erste, der die Monitore im Büro zum Feierabend abschaltet, und
> ich ziehe zuhause den Stecker, wenn ich mein Notebook in der Nacht nicht
> brauche. Aber wenn ich es vermeiden kann, werde ich sicher nicht mein
> Notebook komplett *herunterfahren*, wenn ich nur kurz nicht brauche. Das
> bringt nämlich genau gar nichts. Das ständige Ein- und Ausschalten und
> Hoch- und Runterfahren verkürzt sogar die Lebensdauer der Hardware (vor
> allem bei klassischen Festplatten), was wiederum *tatsächliche* negative
> Auswirkungen auf die Umwelt haben kann (Müllproblematik).

Hervorragend. Genau so wie ich meinte, mit "wenn es nicht einen
triftigen Grund gibt" Allerdings müsstest du komplett auf die
Standby-Maßnahmen verzichten, da Änderungen der Betriebstempperatur die
Bauteile mechanisch belasten und deren Lebensdauer vermindern.

>> Es sind ja nicht nur Rechner, die im Standby minimal Strom brauchen,
>> sondern X-Millionen anderer Geräte, die in diesem Zusammenhang für viel
>> Mist verantwortlich sind.
>
> Non sequitur. Das kleine Notebook macht dann den Kohl auch nicht mehr fett.

Doch, macht es. Weil so wie du und ich handeln sehr viele. Wir sind
nicht die Individuen, die wir zu sein glauben.
Natürlich fallen die paar Watt für eingeschaltete aber nicht genutzte
Verbraucher in der Jahresstomrechnung beim Einzelnen nicht auf. Aber in
der Summe der vielen Nutzer ist das Energie, deren Umwandlung unsere
Umwelt belastet.
In dem Zusammenhang: Windkraftwerke z.B. entziehen dem Wind Energie
(klar), und haben Auswirkungen auf das Mikroklima. Wie sehr wird sich
noch zeigen.

>> Selbst wenn also der Schalter einer zentrale Steckdosenleiste nichts
>> gegen Folgen einen Blitzeinschlages schützt, schadet er der Umwelt
>> nicht, m.E. genügend Grund ihn zu benutzen.
>
> Die Steckerleiste auszuschalten nützt bezogen auf den gesamten Energiebedarf
> eines Haushalts nur dann etwas, wenn die daran angeschlossenen Geräte
> andernfalls im Stand-by-Betrieb laufen.

Es hat sich im Laufe der vergangene Jahre einiges geändert. Oder warum
glaubst du, gibt es seit einiger Zeit die Pflichtangaben für den
Standby-Betrieb.
Es ist bekannt, dass sogar einige Fabrikate im ausgeschalteten Zustand
Strom benötigen. Habe ich bei mir auch noch. Hier hilft wirklich nur
eine reale Netztrennung.
Ich erspare dir die Links zu den entsprechenden Seiten

> Mein Notebook ist aber nach
> s2both(8) (getriggert von hibernate(8)) in der Regel ausgeschaltet, das
> heisst ich ziehe abends den Stecker; es gibt allerdings die Ausnahme, dass
> ich noch was vergessen habe, und dann ist das System in weniger als 1 s
> wieder betriebsbereit *und* im alten Zustand, was selbst mit SSD anders
> nicht machbar ist.

Das ist eine bewusste Entscheidung, du weiß was du machst. Es geht nicht
ums Energiesparen, koste es was es wolle.

Gruß
Peter

[Peter Mc Donough]

Am 27.09.2015 um 15:53 schrieb Dietz Pröpper:
> Peter Mc Donough wrote:

> >...

>> ps. Wer möchte, kann bei sich zu hause einmal nachsehen, wie viel
>> (Klein)geräte ständig unnötig eingeschaltet sind, die mWh für ein Jahr
>> ausrechnen und den Wert mit nur 20 Mio. BRD-Wohnungen malnehmen. Da
>> kommt eine ganze Menge Umweltwutzerei zusammen.
>
> Ich habe mir die Mühe vor einigen Jahren gemacht. Im Vergleich dazu, was ich
> an normalem Verbrauch habe (Herd, Spül-/Waschmaschine, Rechner, drei davon
> dauerlaufend) sind das ein paar kWh p.a..

Ob ich eine eine Suppe kochen oder ein Programm laufen lasse, die
Energie wird gebraucht. Der Kühlschrank frisst übrigens am meisten.

An anderer Stelle habe ich schon geschrieben, dass ein paar kWh bei der
Rechnung nicht auffallen.

Es geht aber um die heimlichen Stromdiebe, die ohne Gegenleistung unsere
Umwelt belasten und mir das Geld aus der Tasche ziehen.
Das kann man ganz leicht ändern, man muss mit den eigenen Möglichkeiten
anfangen.
Meinen Laserdrucker z.B. brauche ich nur selten. Der hängt an einem
eigenen Schalter.

Gruß
Peter

[Peter Köhlmann]

Und nun wirst du sicherlich auch erklären, was ein Init-System mit Package-
Managern zu tun hat. Du darfst gerne auch die Mitschuld von SystemD an 9/11
mit dazupacken

[Stefan Reuther]

Am 27.09.2015 um 15:46 schrieb Dietz Pröpper:
> Stefan Reuther wrote:
>> Ich erinnere mich zumindest an Berichte, dass die Redmonter nicht so
>> freundlich seien und es überhaupt nicht mögen, wenn nach dem
>> unvorhergesehenen Kaltstart erstmal Linux in den Filesystemen rumrührt.
>
> Eh, beziehst Du Dich jetzt auf NTFS? O-kay. Den use case habe ich auf Boxen,
> die ich suspende zu selten.

Ein besseres Filesystem für den Datenaustausch zwischen beiden Systemen
scheint's nicht zu geben. FAT macht auf einer Terabyteplatte halt keinen
Spaß. Das Tuxera-Zeug unter Linux hat wenigstens einen gewissen Ruf.

>>> Welchen Sicherheitsgewinn versprichst Du Dir von der Stromnetztrennung?
>>
>> Überspannung/Blitzschlag und ggf. Stromersparnis, wenn auch nur
>> geringfügig. Es stehen halt weniger Teile unter Spannung.
>
> Korrigier' mich bitte (Du hast von Elektronik ein wenig mehr Ahnung als meine
> Wenigkeit), die "modernen" ("geswitchten") Netzteile sollten gegen
> Überspannung recht resistent sein, oder?

Neee, da verwechselst du mich mit jemandem, der sich auf einer anderen
Stelle der Leiterplatte rumtreibt. Mein Verständnis beginnt am
Analog-Digital-Wandler.

Allerdings habe ich durch Blitzschlag schon Geräte verloren (wenn auch
keine PCs). Ergo nutze ich den Fortschritt des schnellen Bootens für
eine elektrische Trennung (ja, Steckdosenleiste).


Stefan

[Stefan Reuther]

Am 27.09.2015 um 15:19 schrieb Thomas 'PointedEars' Lahn:

> Ich bin der Erste, der die Monitore im Büro zum Feierabend abschaltet, und
> ich ziehe zuhause den Stecker, wenn ich mein Notebook in der Nacht nicht
> brauche. Aber wenn ich es vermeiden kann, werde ich sicher nicht mein
> Notebook komplett *herunterfahren*, wenn ich nur kurz nicht brauche. Das
> bringt nämlich genau gar nichts. Das ständige Ein- und Ausschalten und
> Hoch- und Runterfahren verkürzt sogar die Lebensdauer der Hardware (vor
> allem bei klassischen Festplatten), was wiederum *tatsächliche* negative
> Auswirkungen auf die Umwelt haben kann (Müllproblematik).

Was den Verschleiß an mechanischen Komponenten (Lüftern, Festplatten)
angeht: den hast du beim Suspend-to-RAM genauso wie beim Herunterfahren.


Stefan

[Thomas 'PointedEars' Lahn]

Stefan Reuther wrote:

> Was den Verschleiß an mechanischen Komponenten (Lüftern, Festplatten)
> angeht: den hast du beim Suspend-to-RAM genauso wie beim Herunterfahren.

Nein.

[Martin Vaeth]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Martin Vaeth <mar...@mvath.de> wrote:
>>Fakt ist, dass bei der systemd-Entwicklung
>>das Ziel eines proprietären Vertriebs von Binärprogrammen
>>(also wesentlich mehr, als nur ein Paketmanager)
>>eines der erklärten Kernziele ist. Das ist auf etlichen
>>Blogs nachlesbar, und die Entwicklung von systemd,
>>insbesondere im Hinblick auf die dafür nötigen
>>Container-Funktionalitäten, lässt daran auch keinen Zweifel.
>
> Das ist eine interessante Verschwörungstheorie.

Interessant ist eher, dass Du die von Lennart seit Jahren
propagierten und diskutierten Ziele jetzt auf einmal
als Verschwörungstheorie betrachtest.

> Das klingt unterhaltsam. Erklär mal für die ganz doofen.

Ich dachte, hier ginge es um "news".
Die Suchmaschine Deiner Wahl wird zu
"Poettering systemd BTRFS" genügend Stichworte zum
Thema liefern. Hier eine Beschreibung einer bekanntermaßen
systemd-affine Seite mit einem Link zu Lennarts Blog:

http://www.golem.de/news/lennart-poettering-systemd-und-btrfs-statt-linux-distributionen-mit-paketen-1409-108941.html

Oder hier auch kritische Meinungen in den Kommentaren:

https://lwn.net/Articles/610067/

Etwas aktueller:
Nicht zufällig sind die erstgenannten Punkte bei
Lennarts Vortrag zur aktuellen systemd-Entwicklung
sowohl die Container/nspawn als auch die BTRFS-Integration,
die die notwendigen Schritte für die Vorbereitung
der o.G. Ziele sind:

https://gist.github.com/mika/7b13a6cd7ad99a7aba7f

Zur Wertung des Ganzen bedenke man, dass freie und
quelloffene Distributionen keinen Bedarf haben sollten,
den Vertrieb proprietärer Software voranzutreiben,
ja dies sogar möglichst schwer machen müssten, um
zur Quelloffenheit zu zwingen.