Re: [RFR] man://manpages-de/systemd.unit.5.po (Teil 5/13)
Hallo Helge,
#. type: Plain text
#: archlinux debian-unstable
msgid ""
"Note that this dependency type does not imply that the other unit always has "
"to be in active state when this unit is running\\&. Specifically: failing "
"condition checks (such as I<ConditionPathExists=>, "
"I<ConditionPathIsSymbolicLink=>, \\&... \\(em see below) do not cause the "
"start job of a unit with a I<Requires=> dependency on it to fail\\&. Also, "
"some unit types may deactivate on their own (for example, a service process "
"may decide to exit cleanly, or a device may be unplugged by the user), which "
"is not propagated to units having a I<Requires=> dependency\\&. Use the "
"I<BindsTo=> dependency type together with I<After=> to ensure that a unit "
"may never be in active state without a specific other unit also in active "
"state (see below)\\&."
msgstr ""
"Beachten Sie, dass dieser Abhängigkeitstyp nicht impliziert, dass andere "
"Units immer im aktiven Zustand sein müssen, wenn diese Unit läuft\\&. "
"Insbesondere: Fehlschlagende Bedingungsüberprüfungen (wie "
"I<ConditionPathExists=>, I<ConditionPathIsSymbolicLink=>, … \\(em siehe "
"unten) führen nicht dazu, dass der Start einer Unit mit einer I<Requires=>-"
"Abhängigkeit darauf fehlschlägt\\&. Auch können sich einige Unit-Typen von "
"selbst deaktivieren (beispielsweise kann sich ein Diensteprozess "
"entscheiden, sich sauber zu beenden, oder ein Gerät könnten von einem "
"Benutzer ausgesteckt werden), was nicht an die Units mit einer I<Requires=>-"
"Abhängigkeit übertragen wird\\&. Verwenden Sie den Abhängigkeitstyp "
"I<BindsTo=> zusammen mit I<After=>, um sicherzustellen, dass sich eine Unit "
"niemals im aktiven Zustand befindet, ohne dass eine andere Unit sich auch in "
"einem aktiven Zustand befindet (siehe unten)\\&."
ein Gerät könnten → ein Gerät könnte
#. type: Plain text
#: archlinux debian-unstable
msgid ""
"A weaker version of I<Requires=>\\&. Units listed in this option will be "
"started if the configuring unit is\\&. However, if the listed units fail to "
"start or cannot be added to the transaction, this has no impact on the "
"validity of the transaction as a whole\\&. This is the recommended way to "
"hook start-up of one unit to the start-up of another unit\\&."
msgstr ""
"Eine schwächere Version von I<Requires=>\\&. In dieser Option aufgeführte "
"Units werden gestartet, wenn die konfigurierende Unit es wird\\&. Falls "
"allerdings die aufgeführte Unit nicht startet oder der Transaktion nicht "
"hinzugefügt werden kann, hat dies keine Auswirkungen auf die Gültigkeit der "
"Transaktion als ganzes\\&. Dies ist die empfohlene Art, das Starten einer "
"Unit beim Starten einer anderen Unit einzuhängen\\&."
als ganzes → als Ganzes
Unit beim Starten einer anderen → Unit in den Start einer anderen
#. type: Plain text
#: archlinux debian-unstable
msgid ""
"When used in conjunction with I<After=> on the same unit the behaviour of "
"I<BindsTo=> is even stronger\\&. In this case, the unit bound to strictly "
"has to be in active state for this unit to also be in active state\\&. This "
"not only means a unit bound to another unit that suddenly enters inactive "
"state, but also one that is bound to another unit that gets skipped due to a "
"failed condition check (such as I<ConditionPathExists=>, "
"I<ConditionPathIsSymbolicLink=>, \\&... \\(em see below) will be stopped, "
"should it be running\\&. Hence, in many cases it is best to combine "
"I<BindsTo=> with I<After=>\\&."
msgstr ""
"Bei der Verwendung in Verbindung mit I<After=> auf die gleiche Unit ist das "
"Verhalten von I<BindsTo=> sogar noch stärker\\&. In diesem Falle muss die "
"angebundene Unit sogar in einem aktiven Zustand sein, damit diese Unit auch "
"in einem aktiven Zustand ist\\&. Dies bedeutet nicht nur, dass eine Unit, "
"die an eine andere Unit angebunden ist, die plötzlich in einen inaktiven "
"Zustand eintritt, sondern auch, die an eine andere Unit angebunden ist, die "
"aufgrund einer fehlenden Bedingungsprüfung (wie I<ConditionPathExists=>, "
"I<ConditionPathIsSymbolicLink=>, … \\em siehe unten) übersprungen wird, "
"gestopppt wird, sollte sie laufen\\&. Daher ist es in vielen Fällen am "
"besten, I<BindsTo=> mit I<After=> zu kombinieren\\&."
gestopppt → gestoppt
#. type: Plain text
#: archlinux debian-unstable
msgid ""
"If a unit A that conflicts with a unit B is scheduled to be started at the "
"same time as B, the transaction will either fail (in case both are required "
"parts of the transaction) or be modified to be fixed (in case one or both "
"jobs are not a required part of the transaction)\\&. In the latter case, the "
"job that is not required will be removed, or in case both are not required, "
"the unit that conflicts will be started and the unit that is conflicted is "
"stopped\\&."
msgstr ""
"Falls eine Unit A, die in Konflikt zu Unit B steht, gleichzeitig zum Starten "
"wie B eingeplant ist, wird die Transaktion entweder fehlschlagen (falls "
"beide benötigte Teile der Transaktion sind) oder so verändert, dass dies "
"behoben wird (falls eine oder beide Aufträge ein nicht benötigter Teil der "
"Transaktion sind)\\&. In letzterem Fall wird der Auftrag, der nicht benötigt "
"ist, entfernt, oder falls beide nicht benötigt werden, wird die den Konflikt "
"auslösende Unit gestartet und die in Konflikt stehende gestoppt\\&."
gleichzeitig zum Starten wie B → zum gleichzeitigen Start mit B
# FIXME: i.e. → I.e.
#. type: Plain text
#: archlinux debian-unstable
msgid ""
"These two settings expect a space-separated list of unit names\\&. They "
"configure ordering dependencies between units\\&. If a unit foo\\&.service "
"contains a setting B<Before=bar\\&.service> and both units are being "
"started, bar\\&.service\\*(Aqs start-up is delayed until foo\\&.service has "
"finished starting up\\&. Note that this setting is independent of and "
"orthogonal to the requirement dependencies as configured by I<Requires=>, "
"I<Wants=> or I<BindsTo=>\\&. It is a common pattern to include a unit name "
"in both the I<After=> and I<Requires=> options, in which case the unit "
"listed will be started before the unit that is configured with these options"
"\\&. This option may be specified more than once, in which case ordering "
"dependencies for all listed names are created\\&. I<After=> is the inverse "
"of I<Before=>, i\\&.e\\&. while I<After=> ensures that the configured unit "
"is started after the listed unit finished starting up, I<Before=> ensures "
"the opposite, that the configured unit is fully started up before the listed "
"unit is started\\&. Note that when two units with an ordering dependency "
"between them are shut down, the inverse of the start-up order is applied\\&. "
"i\\&.e\\&. if a unit is configured with I<After=> on another unit, the "
"former is stopped before the latter if both are shut down\\&. Given two "
"units with any ordering dependency between them, if one unit is shut down "
"and the other is started up, the shutdown is ordered before the start-up\\&. "
"It doesn\\*(Aqt matter if the ordering dependency is I<After=> or "
"I<Before=>, in this case\\&. It also doesn\\*(Aqt matter which of the two is "
"shut down, as long as one is shut down and the other is started up\\&. The "
"shutdown is ordered before the start-up in all cases\\&. If two units have "
"no ordering dependencies between them, they are shut down or started up "
"simultaneously, and no ordering takes place\\&. It depends on the unit type "
"when precisely a unit has finished starting up\\&. Most importantly, for "
"service units start-up is considered completed for the purpose of I<Before=>/"
"I<After=> when all its configured start-up commands have been invoked and "
"they either failed or reported start-up success\\&."
msgstr ""
"Diese zwei Einstellungen erwarten eine Leeraum-getrennte Liste von Unit-Namen"
"\\&. Sie konfigurieren Ordnungsabhängigkeiten zwischen Units\\&. Falls eine "
"Unit foo\\&.service eine Einstellung B<Before=bar\\&.service> enthält und "
"beide Units gestartet werden, wird das Starten von bar\\&.service verzögert, "
"bis foo\\&.service mit dem Starten abgeschlossen hat\\&. Beachten Sie, dass "
"diese Einstellung unabhängig von und orthogonal zu der mit I<Requires=>, "
"I<Wants=> oder I<BindsTo=> konfigurierten Anforderungsabhängigkeit ist\\&. "
"Es ist ein häufiges Muster, einen Unit-Namen sowohl in die Optionen "
"I<After=> als auch in I<Requires=> aufzunehmen; in diesem Fall wird die "
"aufgeführte Unit vor der Unit, die mit diesen Optionen konfiguriert ist, "
"gestartet\\&. Diese Option kann mehr als einmal festgelegt werden, dann "
"werden Ordnungsabhängigkeiten für alle aufgeführten Namen erstellt\\&. "
"I<After=> ist das Inverse von I<Before=>, d\\&.h\\&. während I<After=> "
"sicherstellt, dass die konfigurierte Unit gestartet wird, nachdem die "
"aufgeführte Unit das Starten abgeschlossen hat, stellt I<Before=> das "
"Gegenteil dar, dass die konfigurierte Unit vollständig gestartet ist, bevor "
"die aufgeführte Unit gestartet wird\\&. Beachten Sie, dass beim "
"Herunterfahren von zwei Units, zwischen denen eine Ordunngsabhängigkeit "
"besteht, das Inverse der Start-Reihenfolge angewandt wird\\&. Dies bedeutet, "
"falls eine Unit mit I<After=> auf eine andere Unit konfiguriert ist, wird "
"die erstere vor letzterer gestoppt, falls beide heruntergefahren werden\\&. "
"Existiert zwischen zwei Units eine Ordnungsabhängigkeit und wird eine Unit "
"gestoppt und die andere gestartet, dann wird das Herunterfahren vor dem "
"Hochfahren einsortiert\\&. Dabei spielt es in diesem Fall keine Rolle, ob "
"die Ordnungsabhängigkeit I<After=> oder I<Before=> ist\\&. Es spielt auch "
"keine Rolle, welcher der beiden Heruntergefahren wird, solange eine "
"heruntergefahren und die andere gestartet wird\\&. Das Herunterfahren wird "
"in allen Fällen vor dem Starten geordnet\\&. Falls zwischen zwei Units keine "
"Ordnungsabhängigkeit besteht, dann werden sie gleichzeitig heruntergefahren "
"und gestartet und es findet keine Ordnung statt\\&. Es hängt vom Unit-Typ "
"ab, wann genau eine Unit das Starten abgeschlossen hat\\&. Am wichtigsten "
"ist, dass für Dienste-Units das Starten für die Zwecke von I<Before=>/"
"I<After=> als abgeschlossen betrachtet wird, wenn alle ihre konfigurierten "
"Startbefehle aufgerufen wurden und entweder fehlschlugen oder Erfolg "
"berichteten\\&."
bis foo\\&.service mit dem Starten abgeschlossen hat\\&.
→
bis der Start von foo\\&.service abgeschlossen ist\\&.
die aufgeführte Unit das Starten abgeschlossen hat
→
der Start der aufgeführten Unit abgeschlossen ist
beiden Heruntergefahren → beiden heruntergefahren
vor dem Starten geordnet → vor dem Starten eingeordnet
eine Unit das Starten abgeschlossen hat\\&.
→
der Start einer Unit abgeschlossen ist\\&.
berichteten → meldeten
Gruß Mario
Reply to: