Mageia Forum

Hi,
wie von ML2010.2 bis ML2011.0 gewohnt, schalte ich hier in der mageia2 beta1 mit Hilfe des rfkill-Befehls im Autostartverzeichnis von KDE das Bluetooth bei Systemstart aus.
Genau seitdem entschuldigt sich der KDE-Dienst für "seine unerwartete Beendigung" und, dass die gesammelten Absturzinformationen wahrscheinlich nutzlos seien. Diese sehen so aus:

Code: Alles auswählen

Application: KDE-Dienst (kdeinit4), signal: Segmentation fault
Using host libthread_db library "/lib/i686/libthread_db.so.1".
[Current thread is 1 (Thread 0xb54506e0 (LWP 2189))]

Thread 2 (Thread 0xb0511b70 (LWP 2198)):
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb6cd317b in read () from /lib/i686/libpthread.so.0
#2  0xb5a7831e in ?? () from /lib/libglib-2.0.so.0
#3  0xb5a39940 in g_main_context_check () from /lib/libglib-2.0.so.0
#4  0xb5a39e52 in ?? () from /lib/libglib-2.0.so.0
#5  0xb5a3a011 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#6  0xb6e8eaf7 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0xb6e5accd in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#8  0xb6e5af69 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#9  0xb6d456dc in QThread::exec() () from /usr/lib/libQtCore.so.4
#10 0xb6e381dd in ?? () from /usr/lib/libQtCore.so.4
#11 0xb6d48bc0 in ?? () from /usr/lib/libQtCore.so.4
#12 0xb6ccca37 in start_thread () from /lib/i686/libpthread.so.0
#13 0xb606b98e in clone () from /lib/i686/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further

Thread 1 (Thread 0xb54506e0 (LWP 2189)):
[KCrash Handler]
#7  0xb6e70c62 in QObject::property(char const*) const () from /usr/lib/libQtCore.so.4
#8  0xb5be7700 in ?? () from /usr/lib/libQtDBus.so.4
#9  0xb5be83cb in ?? () from /usr/lib/libQtDBus.so.4
#10 0xb5be8778 in ?? () from /usr/lib/libQtDBus.so.4
#11 0xb6e76e3b in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
#12 0xb6333b04 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#13 0xb6338f13 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#14 0xb74d5741 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#15 0xb6e5c15e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#16 0xb6e5fd88 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4
#17 0xb6e600bc in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQtCore.so.4
#18 0xb6e8e6a4 in ?? () from /usr/lib/libQtCore.so.4
#19 0xb5a39b2a in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#20 0xb5a39f35 in ?? () from /lib/libglib-2.0.so.0
#21 0xb5a3a011 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#22 0xb6e8ea97 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#23 0xb63e72aa in ?? () from /usr/lib/libQtGui.so.4
#24 0xb6e5accd in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#25 0xb6e5af69 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#26 0xb6e6016a in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#27 0xb6331974 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#28 0xb4e95c70 in kdemain () from /usr/lib/libkdeinit4_kded4.so
#29 0x0804f944 in _start ()

Vielleicht kann mir der dok sagen, in welcher Datei es auch möglich ist, das Bluetooth mit Systemstart auszuschalten, damit die KDE-Meldung zu Beginn verschwindet.

Code: Alles auswählen

/etc/rc.local

liege ich da richtig?

Allerdings sollte ein komfortables Einschalten während des Betriebes gleichfalls möglich sein.

Danke!

unklar hat geschrieben:Vielleicht kann mir der dok sagen, in welcher Datei es auch möglich ist, das Bluetooth mit Systemstart auszuschalten, damit die KDE-Meldung zu Beginn verschwindet.

Code: Alles auswählen

/etc/rc.local

liege ich da richtig?

Wäre eine Möglichkeit, das ist allerdings nur ein Symlink auf /etc/rc.d/rc.local

unklar hat geschrieben:Allerdings sollte ein komfortaples Einschalten während des Betriebes gleichfalls möglich sein.

Normalerweise löst/setzt rfkill nur den Soft-Block, ein etwaiger Hard-Block (durch Hardware-Schalter etwa) bleibt davon unberührt.
Sollte also möglich sein.

Ich denke es ist am Einfachsten über die KDE-eigene Diensteverwaltung zu machen, einfach das Häkchen bei BlueDevil rausnehmen. Bei bedarf lässt er sich darüber auch wieder starten.

Hmmm, damit verhindert man aber nicht die Aktivierung des Bluetooth-Adapters, sondern nur des Frontends. Ist die Frage, was genau gewünscht ist (und warum).

unklar hat geschrieben:wie von ML2010.2 bis ML2011.0 gewohnt, schalte ich hier in der mageia2 beta1 mit Hilfe des rfkill-Befehls im Autostartverzeichnis von KDE das Bluetooth bei Systemstart aus.

Wenn unklar das aus dem KDE-Austostart raus haben will, sollte meine Vorgehensweise ausreichen.

Ich hab es so verstanden, dass er Bluetooth abschalten will, was rfkill macht.

@unklar: Was genau und mit welcher Zielstellung?

Ja, das ist richtig, ein physikalisches abschalten des BT-Adapters wird dadurch nicht erreicht, nur das Abschalten des BT-Dienstes. Das Abschalten des Dienstes könnte dann aber auch dazu führen, dass es bei ihm dann beim KDE-Start keinen Abbruch mehr gibt.

Ähhm, der Abbruch wird durch den Autostart-Aufruf von rfkill ausgelöst, da ist m.E. relativ wurscht ob der BT-Dienst startet oder nicht.
Falls doch, sollte das bei KDE als Bug gemeldet werden.

Oh, ja da hast du natürlich recht, ich hab' da wohl Tomaten auf den Augen gehabt, es ist ja nicht der Bluetooth-Dienst der abbricht sonder kdeinit.

Danke für die Zeit, die Ihr für mich aufwendet.

Es ist so, der vorhandene Hardwareschalter schaltet BT und Wlan.
Die Tasten Fn+F5 schalten nur Wlan.

Im Verhältnis BT zu Wlan benötige ich BT selten, was aber bei Systemstart immer aktiviert wird. Deshalb war das mit rfkill die für mich praktikable Lösung.

Lange Rede ...
ich habe jetzt die Idee von @alf ausprobiert. Die Lösung passt.
Eine KDE Absturzmeldung kommt nicht mehr, nachdem ich das Häkchen, "Bluetooth-Integration in KDE" herausgenommen habe.
Ich gestehe, mich in diesem Systemeinstellungsbereich bisher gar nicht umgeschaut zu haben.

Gelöst!

Was ist denn aber die Zielstellung dahinter? Strom sparen? Der Bluetooth-Adapter ist doch immer noch aktiv ...

Ja, Strom sparen z.B.

Den Adapter schalte ich ja dennoch mit rfkill aus.

Code: Alles auswählen

[unklar@localhost ~]$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: yes
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
[unklar@localhost ~]$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
3: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

Diese Absturzproblematik scheint es aber offensichtlicht nur bei festinstallierten BT-Adaptern zu geben. Ich mühe mich seit Stunden mit einem USB-Adapter diesen Fehler nachzustellen, vergeblich.

Hmmm, also meiner ist festinstalliert, und wird nicht beim Start aktiviert. Hängt definitiv mit der Implementation im BIOS sowie des Hardware-Schalters
zusammen, manchmal gibt es keinen, manchmal nur als Tastatur-Shortcut, und oft auch kombinierte Schalter für WLAN/Bluetooth/UMTS.

@unklar: Wenn es um Strom sparen geht, ist das der falsche Weg, weder rfkill mit dem soft-Block noch das
Abschalten des KDE-Bluetooth-Dienstes führen zu einer Stromersparnis. Du müsstest das jeweilige Kernelmodul entladen,
sowie den bluez-Systemdienst stoppen und dann schauen ob der Adapter dann stromlos ist.
Und das natürlich auf umgekehrtem Weg wenn du Bluetooth mal nutzen willst. Eine Sysiphus-Arbeit.

Schau dir doch lieber powertop an, oder pass das Energiemanagement entsprechend an, ist bestimmt effizienter, m.E.

Danke Dok, ich schaue mir das an!