systemd: dbus restart?

[Ulli Horlacher]

Auf Ubuntu 16.04 sollte ich nach einem update dbus neu starten, aber:

root@ptm4:~# service dbus restart
Failed to restart dbus.service: Operation refused, unit dbus.service may be requested by dependency only.
See system logs and 'systemctl status dbus.service' for details.

root@ptm4:~# systemctl status dbus.service
* dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
Active: active (running) since Fri 2016-05-20 08:42:48 CEST; 33min ago
Docs: man:dbus-daemon(1)
Main PID: 716 (dbus-daemon)
Tasks: 1 (limit: 512)
Memory: 2.0M
CPU: 61ms
CGroup: /system.slice/dbus.service
`-716 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation


Muss man da jetzt wirklich rebooten?!

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum IZUS/TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70550 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Sven Joachim]

Am 20.05.2016 um 07:19 schrieb Ulli Horlacher:

> Auf Ubuntu 16.04 sollte ich nach einem update dbus neu starten, aber:
>
> root@ptm4:~# service dbus restart
> Failed to restart dbus.service: Operation refused, unit dbus.service may be requested by dependency only.
> See system logs and 'systemctl status dbus.service' for details.
>
> root@ptm4:~# systemctl status dbus.service
> * dbus.service - D-Bus System Message Bus
> Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled)
> Active: active (running) since Fri 2016-05-20 08:42:48 CEST; 33min ago
> Docs: man:dbus-daemon(1)
> Main PID: 716 (dbus-daemon)
> Tasks: 1 (limit: 512)
> Memory: 2.0M
> CPU: 61ms
> CGroup: /system.slice/dbus.service
> `-716 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
>
>
> Muss man da jetzt wirklich rebooten?!

Sieht so aus. Aus dem Ubuntu-Changelog:

,----
| dbus (1.10.6-1ubuntu2) xenial; urgency=medium
|
| * dont-stop-dbus.patch: Disallow manual (re)starts, as we don't (want to)
| stop D-Bus on shutdown. (LP: #1540282)
|
| -- Martin Pitt <marti...@ubuntu.com> Thu, 11 Feb 2016 12:58:02 +0100
`----

Der darin erwähnte Bug:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1540282.

Auch lesenswert:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612
https://bugs.freedesktop.org/show_bug.cgi?id=89847

Sven

[Juergen P. Meier]

Sven Joachim <sven...@gmx.de>:

> Auch lesenswert:
> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612
> https://bugs.freedesktop.org/show_bug.cgi?id=89847

*Lach*.

There are reasons why we (the old sysv-init farts) do things in a lame
and boring old fashion way.
You Kids just found out what some of these reasons were.

(das sind meine Worte)

--
PS: There's more where that came from.

[Juergen P. Meier]

Sven Joachim <sven...@gmx.de>:

> Auch lesenswert:
> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612
> https://bugs.freedesktop.org/show_bug.cgi?id=89847

*Lach*.

There are reasons why we (the old sysv-init farts) do things in a lame
and boring old fashion way.

You Kids just found out what some of these reasons are.

(Das sind meine eigenen Worte)

[Tim Ritberg]

Am 20.05.2016 um 10:29 schrieb Juergen P. Meier:
> Sven Joachim <sven...@gmx.de>:
>> Auch lesenswert:
>> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612
>> https://bugs.freedesktop.org/show_bug.cgi?id=89847
>
> *Lach*.
>
> There are reasons why we (the old sysv-init farts) do things in a lame
> and boring old fashion way.
> You Kids just found out what some of these reasons are.
>
> (Das sind meine eigenen Worte)
>

Jaja, das Systemd. Ganz großes Tennis...

Tim

[Juergen P. Meier]

Marcus Jodorf <tr...@killfile.de>:
> Juergen P. Meier <nospa...@jors.net> schrieb:

>>
>> There are reasons why we (the old sysv-init farts) do things in a lame
>> and boring old fashion way.
>> You Kids just found out what some of these reasons are.
>>
>> (Das sind meine eigenen Worte)
>

> Wenn es nicht so traurig wäre...
>
> Ich hatte schon mal das Vergnügen vor einem Rechner mit beim Start
> gleich wieder abgeschmiertem dbus zu sitzen.

Cisco's neueste Appliances ($SOFTWARE die auf einem Redhat/Centos laeuft
das Cisco "ADEOS" nennt) sind auch schon systemd-verseucht.

Das laeuft so super toll zusammen mit dem Tomcat, Orakel, SQLiteDB,
PostgresQL, Java und anderen ineinander verzahnten Applicationservices.

Sporadisch klappt der service-restart nicht, weil systemd den
scheissdreck nicht in der richtigen Reihenfolge im richtigen zeitlichen
Abstand startet und der Tomcat haengt sich z.B. auf weil einer der DBs
nicht ganz fertig initialisiert war.

Workaround: Reboot. Schoene neue Welt.

Nein, da kann man diesen Dreck wirklich keinem seiner Kunden mehr
empfehlen. Sollen die sich lieber was von der Konkurrenz kaufen,
das unter Windows laeuft und vernuenftig virtualisierbar ist.

> Maus geht nicht mehr, Keyboard geht nicht mehr (weil evdev von X ohne
> dbus nicht mehr funktioniert).

KVM willst du an so einem Teil garnicht versuchen. Schon weil du dazu
ein Java mit SSLv3 (TLS >1.0 abschalten!) brauchst, mit allen
Sicherheitseinstellungen abgeschaltet. (Cisco halt, deren Welt ist nach
Erfindung der Seriellen Konsole mit 9600bps stehen gebliebe, immerhin
laeuft das mit Java 7).

> Remote kommt man nicht mehr rein, weil ohne dbus keine Netzwerkkartentreiber
> geladen werden (falls man sie nicht ausdrücklich manuell konfiguriert hat,
> was ich deshalb seitdem wieder überall mache.).

Ich will garnicht erleben was passiert, wenn systemd auf so einem
kritischen System die serielle Konsone zerschiesst.

"Kritische Infrasturktur und Systemd" ist heute so wie vor Jahren noch
"Kritische Infrastruktur und Windows".

> Kurz: Man sitzt in so einem Fall dann vor einem eigentlich laufendem
> System aber ohne jedwede Zugriffsmöglichkeit und kann nur noch Reset
> drücken und dem Filesystem die Daumen drücken.

Reset-taster haben diese Teile doch schon lange keine mehr.
Powercycling ist angesagt. Solange die remote schaltbaren PSU nicht
auch unter Linux laeuft...

> Das Ding dann wegen single-point-of-failure als Lösung unstoppbar zu
> machen und einfach zu hoffen, daß es nie abschmiert... tja...

Es ist als single-point-of-everything konzipiert. Failure inklusive.

[Manuel Reimer]

On 05/20/2016 09:19 AM, Ulli Horlacher wrote:
> root@ptm4:~# service dbus restart
> Failed to restart dbus.service: Operation refused, unit dbus.service may be requested by dependency only.
> See system logs and 'systemctl status dbus.service' for details.
>

> [...]

>
> Muss man da jetzt wirklich rebooten?!

Ja. Aktuell ist dbus leider die modernste Lösung für
Zwischenprozess-Kommunikation unter Linux und so ziemlich alles sitzt da
drauf.

Das ist mit einer der Gründe warum man dbus wieder loswerden will und
nun schon länger an einer kernelseitigen Lösung gearbeitet wird.

Gruß

Manuel

[Dietz Pröpper]

Manuel Reimer wrote:

> On 05/20/2016 09:19 AM, Ulli Horlacher wrote:
>> root@ptm4:~# service dbus restart
>> Failed to restart dbus.service: Operation refused, unit dbus.service may be
>> requested by dependency only. See system logs and 'systemctl status
>> dbus.service' for details.
>>
>> [...]
>>
>> Muss man da jetzt wirklich rebooten?!
>
> Ja. Aktuell ist dbus leider die modernste Lösung für
> Zwischenprozess-Kommunikation unter Linux und so ziemlich alles sitzt da
> drauf.

Dbus ist ein schlechter Witz.

> Das ist mit einer der Gründe warum man dbus wieder loswerden will und
> nun schon länger an einer kernelseitigen Lösung gearbeitet wird.

Nee. Der Grund hierfür ist, dass der schlechte Witz von oben "zu langsam" ist
und deswegen von Poetty & Gemeinde in den Kernel gewünscht wird.

Zumindest die ersten Versuche haben diversen Lachtests nicht standgehalten.
Weiter habe ich's dann nicht mehr verfolgt.

[Dietz Pröpper]

Edmund H. Ramm wrote:

> In <nhnf7v$mat$1...@tota-refugium.de> Tim Ritberg <t...@server.invalid> writes:
>
>> [...]

>> Jaja, das Systemd. Ganz großes Tennis...
>

> Gibt es eine Möglichkeit, systemd sequentiell booten zu lassen, z.B.
> zur Vermeidung von Race-Conditions?

Ja. Nennt sich sysvinit <d,r&h>.

[Manuel Reimer]

On 05/22/2016 11:04 AM, Dietz Pröpper wrote:
> Nee. Der Grund hierfür ist, dass der schlechte Witz von oben "zu langsam" ist

Ja, das ist auch ein Grund.

Eine annähernd gleichwertige Alternative für Interprozess-Kommunikation
existiert bisher nicht.

> Zumindest die ersten Versuche haben diversen Lachtests nicht standgehalten.

Weshalb der erste Entwurf von Linus auch verworfen wurde.

Gruß

Manuel

[Martin Vaeth]

Manuel Reimer <Manuel.N...@nurfuerspam.de> wrote:
>
> Eine annähernd gleichwertige Alternative für Interprozess-Kommunikation
> existiert bisher nicht.

Falcsh. Um nur zwei zu nennen: Corba, dcop.
Von diesen dreien ist dbus mit Abstand die langsamste Variante:
http://eleceng.dit.ie/frank/rpc/CORBAGnomeDBUSPerformanceAnalysis.pdf

Kernel-seitig gibt es schon lange TIPC, was ein viel besserer
(und standardisierter) Aufsatzpunkt wäre.

[Juergen P. Meier]

Martin Vaeth <mar...@mvath.de>:

Du uebersiehst ein wichtiges Argument der systemd/dbus-FanBois: NIH!

[Markus Grob]

Juergen P. Meier schrieb:
> Martin Vaeth <mar...@mvath.de>:

>> Kernel-seitig gibt es schon lange TIPC, was ein viel besserer
>> (und standardisierter) Aufsatzpunkt wäre.
>
> Du uebersiehst ein wichtiges Argument der systemd/dbus-FanBois: NIH!

National Institut of Health, NickelMetallHybrid Akku, Nicht Im Haus?

?, Markus

[Frank Beythien]

http://www.acronymfinder.com

Not Invented Here

CU/2
Frank

[Helmut Hullen]

Hallo, Frank,

Du meintest am 28.05.16:

>>> Du uebersiehst ein wichtiges Argument der systemd/dbus-FanBois:
>>> NIH!
>>
>> National Institut of Health, NickelMetallHybrid Akku, Nicht Im Haus?
>>
>> ?, Markus

> http://www.acronymfinder.com

> Not Invented Here

Ein Witz, der erklärt werden muss, taugt nicht.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Ralph Aichinger]

Juergen P. Meier <nospa...@jors.net> wrote:

> Du uebersiehst ein wichtiges Argument der systemd/dbus-FanBois: NIH!

Unsinn. Im Gnome-Umfeld war man durch 2 Generationen von Corba-Brokern
durch, bis man entschieden hat, daß das nicht gut funktioniert und
eher eine Lösung aus dem KDE-Umfeld abkupfert, die erwiesenermaßen
funktioniert hat. dbus ist der Abkömmling davon.

/ralph

[Sieghard Schicktanz]

Hallo Markus,

Du schriebst am Sat, 28 May 2016 12:09:11 +0200:

> National Institut of Health, NickelMetallHybrid Akku, Nicht Im Haus?

^^^^^^^^^^^^^^^^^^^^^^
Was soll'n _das_ sein? Und wie könnte man für sowas (auch wenn damit die
existierenden Nickel-Metall-Hy_d_rid-Akkus gemeint sein sollten) auf eine
Abkürzung "NIH" kommen? (Hybris?)

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Juergen P. Meier]

Markus Grob <sno...@ilnet.ch>:

Not Invented Here

Diese ganze Bande um Poettering koennen als "Ritter die NIH sagen"
auftreten. Nur sind sie nicht so lustig wie die von Monty Python.

[Juergen P. Meier]

Ralph Aichinger <r...@pi.h5.or.at>:

Man nehme etwas besonders kaputtes, um damit ein nur gewoehnlich
kaputtes zu rechtfertigen - ignoriert dabei geflisstentlich alles
andere?

Man haette sich wenigstens ein paar funktionierende und vor allem:
Erprobte Konzepte von anderen abschauen koennen.

[Ralph Aichinger]

Die da wären? Was die Micirosoft-Welt da zu bieten hat überzeugt
ja auch nicht. Wie schaut es bei Apple aus, was verwenden die?

/ralph

[Marc Haber]

Und die wären für diese Aufgabe gewesen?

--
-------------------------------------- !! 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 P. Meier]

Ralph Aichinger <r...@pi.h5.or.at>:

> Juergen P. Meier <nospa...@jors.net> wrote:
>> Man nehme etwas besonders kaputtes, um damit ein nur gewoehnlich
>> kaputtes zu rechtfertigen - ignoriert dabei geflisstentlich alles
>> andere?
>>
>> Man haette sich wenigstens ein paar funktionierende und vor allem:
>> Erprobte Konzepte von anderen abschauen koennen.
>
> Die da wären? Was die Micirosoft-Welt da zu bieten hat überzeugt

Wenn man bei der Microsoftwelt Abkupfert, sollte man auch die
Lektionen nicht uebersehen, die Microsoft in den letzten 20 Jahren
gelernt hat...

> ja auch nicht. Wie schaut es bei Apple aus, was verwenden die?

XPC.

[Martin Vaeth]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>
> Unsinn. Im Gnome-Umfeld war man durch 2 Generationen von Corba-Brokern
> durch, bis man entschieden hat, daß das nicht gut funktioniert

Eher bis man entschieden hat, dass xml so "hipp" ist, dass
man unbedingt das statt des schnellen Binary-Protokolls haben will,
auch wenn es naturgemäß extrem verlangsamt.
Und kaum nach Einführung hat man gemerkt, dass es zu langsam und
für Binärdaten ungeeignet ist.
Hier sind Könner am Werk!

[Martin Vaeth]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
> Juergen P. Meier <nospa...@jors.net> wrote:
>>
>> Man haette sich wenigstens ein paar funktionierende und vor allem:
>> Erprobte Konzepte von anderen abschauen koennen.
>
> Die da wären?

Wieso wird schon wieder TIPC kommentarlos ignoriert?

[Dietz Pröpper]

Weil die Frage "die da wären?" lautete?

[Volker Kohaupt]

Ist es überhaupt für die Zielsetzung geeignet? Wenn ich mir die Berichte
dazu anschaue ist TIPC was für Cluster und ersetzt dort TCP/IP.

Viele grüße Volker

[Juergen P. Meier]

Martin Vaeth <mar...@mvath.de>:

Not Invented Here!!1elf.

[Martin Vaeth]

Volker Kohaupt <xyvkoh...@freenet.de> wrote:
> Martin Vaeth schrieb am 29.05.2016 um 10:39:
>> Ralph Aichinger <r...@pi.h5.or.at> wrote:
>>> Juergen P. Meier <nospa...@jors.net> wrote:
>>>>
>>>> Man haette sich wenigstens ein paar funktionierende und vor allem:
>>>> Erprobte Konzepte von anderen abschauen koennen.
>>>
>>> Die da wären?
>>
>> Wieso wird schon wieder TIPC kommentarlos ignoriert?
>
> Ist es überhaupt für die Zielsetzung geeignet?

Ich habe mich nicht damit beschäftigt, bin also kein
Experte. Aber viele Kernel-Entwickler und andere
Protokoll-Experten sind wohl dieser Meinung.
Es wurde im Zusammenhang mit dem kdbus-Push in den
Kernel immer wieder erwähnt, dass die gewünschten
Features i.W. alle bereits in TIPC enthalten seien,
und zumindest an den paar Stellen, an denen ich die
Diskussion seinerzeit verfolgt habe, wurden diese
Kommentare der entsprechenden Experten zu meinem
Erstaunen stets unbeantwortet ignoriert.

> Wenn ich mir die Berichte dazu anschaue ist TIPC

> was für Cluster [...]

Es scheint mir ein sehr allgemeines Protokoll zur
Interprozesskommunikation zu sein, das für alles,
was damit zu tun hat, geeignet ist. Egal, ob in
einem Cluster (groß oder klein) oder auf einem
einzelnen isolierten Rechner:

http://tipc.sourceforge.net/features.shtml

"[...] ranging from a single node to a simple cluster
to sets of clusters grouped into distinct zones."

"[...] communicate using byte streams,
connection-based datagrams, and connectionless
datagrams."

Was ich gehört habe, ist es wohl auch für Geschwindigkeit
auf dem lokalen Rechner für große Datenmengen ziemlich
optimiert - also ganz das, was für kdbus so wichtig war -
zumindest in der Linux-Implementation.

> und ersetzt dort TCP/IP.

Multicast, Orsttranzparenz (was den Kommentaren auf
der Kernel-Liste nach anscheinend auch die "sichere"
Feststellung des Absenderprozesses bedeutet -
eines der Hauptprobleme bei dbus in Bezug auf
Sicherheit und auch bei dbus heftig kritisiert),
Abonnieren von Ereignissen, ...
Wie gesagt, ich bin kein Experte dafür, aber mir
scheint das doch, anders als TCP/IP, die Features
zu haben, die die Motivation für kdbus waren,
zumal wohl die Geschwindigkeit auf einem lokalen
Rechner nochmals ein wesentlicher Unterschied ist.

[Martin Vaeth]

Martin Vaeth <mar...@mvath.de> wrote:
>
> Multicast, Orsttranzparenz (was den Kommentaren auf
> der Kernel-Liste nach anscheinend auch die "sichere"
> Feststellung des Absenderprozesses bedeutet -
> eines der Hauptprobleme bei dbus in Bezug auf
> Sicherheit und auch bei dbus heftig kritisiert),

s/Orsttransparenz/Ortstransparenz/
s/bei dbus heftig/bei kdbus heftig/