ubuntuusers.de

Hi.

Ich habe gerade NetworkManager/Dispatcher entdeckt und wollte damit jetzt ein kleines Problem mit pidgin lösen (verbindet sich nicht automatisch, wenn Internet nicht beim Start verfügbar ist).

#!/bin/bash

case "$2" in
        up)
                killall pidgin
                gksu -u stfischr nohup pidgin &
                ;;
esac

Das killall macht er noch brav aber pidgin wird nicht gestartet, wenn ich

gksu -u stfischr nohup pidgin &

in ein Rootterminal eingebe funktioniert das bestens, wo ist denn da der Knoten in meinem Kopf?

Fehlt ihm vielleicht das DISPLAY?

Jetzt nicht auf das Skript bezogen, aber ist der Parameter "-f" für Pidgin eventuell etwas dass dein Problem löst?

-f, --force-online Try to be online even if the network is reported (by Windows, or NetworkManager on Linux) to be unavailable.

grumpy grizzly schrieb:

Jetzt nicht auf das Skript bezogen, aber ist der Parameter "-f" für Pidgin eventuell etwas dass dein Problem löst?

-f, --force-online Try to be online even if the network is reported (by Windows, or NetworkManager on Linux) to be unavailable.

Leider keine Veränderung.

dAnjou schrieb:

Fehlt ihm vielleicht das DISPLAY?

Guter Tipp, aber:

DISPLAY=":0.0" gksu -u stfischr nohup pidgin &

bringt keine Veränderung. ☹

Noch jemand Ideen?

Nach dem 'killall' etwas warten? Bei Firefox, wenn ich den beende, und direkt neu starte, dann bekomme ich oft eine Beschwerde, dass er schon oder noch läuft.

Allerdings hat er oft eine Menge an Tabs zu speichern - keine Ahnung, ob das bei Pidgin in Frage kommt, und ob Pidgin überhaupt was dagegen hat, und sich wenn, dann nicht entsprechend melden würde, also eher 3 Gründe die dagegen sprechen.

Ja Pidgin verhindert auch mehrere Instanzen, außer man verwendet die Option -m.

Ich hab ihn mal 3 Sekunden warten lassen ... nix 😢

Aber es kommen auf jeden Fall immer wieder neue Ideen, an die ich garnicht gedacht habe. Dafür danke und weiter so. ☺

Edit: Wenn man statt stdin mal stderr anschaut 😬 komt übrigens folgende Meldung:

No protocol specified

(gksu:19440): Gtk-WARNING **: cannot open display: :0.0

Okay, anderer Ansatz! Ich fand das von Beginn an etwas umständlich Pidgin neu zu starten. Und wie ich es mir schon dachte gibt es eine schönere Möglichkeit: purple-remote - Send remote commands to Pidgin/Finch. Das ist im Paket libpurple-bin.

purple-remote setstatus?status=available 

Weitere Anwendungsmöglichkeiten ▶ man purple-remote

Falls du weshalb auch immer pidgin doch lieber neu starten willst, probier mal

DISPLAY=:0.0 sudo -u stfischr pidgin &

gksu - GTK+ frontend for su and sudo. Das benutzt man aus einer laufenden X-Sitzung heraus, nicht in einem Skript nehme ich mal an.

grumpy grizzly schrieb:

purple-remote setstatus?status=available 

Den Status zu ändern bringt nix und available ist es schon beim Start. Er sagt nur "warte auf Verbindung."

Weitere Anwendungsmöglichkeiten ▶ man purple-remote

Hm, da steht ja so gut wie nix drin. Im entsprechenden Pythonscript sind auch keine relevanten Befehle zu finden um einen reconncet durchzuführen.

Falls du weshalb auch immer pidgin doch lieber neu starten willst, probier mal

DISPLAY=:0.0 sudo -u stfischr pidgin &

gksu - GTK+ frontend for su and sudo. Das benutzt man aus einer laufenden X-Sitzung heraus, nicht in einem Skript nehme ich mal an.

Tatsächlich, es war das gksu. Ich hab aber schon viele Scripte gesehen, die das benutzt haben.

Fürdie Nachwelt, so sieht mein dispatcherscript jetzt aus:

1
2
3
4
5
6
7
8

#!/bin/bash

case "$2" in
        up)
                killall pidgin
                DISPLAY=:0.0 sudo -u stfischr nohup pidgin &
                ;;
esac

Edit: Achso, ein dickes Dankeschön an euch und vor allem an dich grumpy grizzly. ☺

stfischr schrieb:

Den Status zu ändern bringt nix und available ist es schon beim Start. Er sagt nur "warte auf Verbindung."

Hmm.. wie wäre es mit

purple-remote setstatus?status=offline
purple-remote setstatus?status=available

Oder du startest pidgin mit der Option "-n" wenn du eh schon weißt dass er sich direkt beim Start nicht verbinden kann.

stfischr schrieb:

grumpy grizzly schrieb:

Weitere Anwendungsmöglichkeiten ▶ man purple-remote

Hm, da steht ja so gut wie nix drin.

Ja gut, vorbildlich ist es nicht gerade. Aber ein paar Beispiele sind immerhin aufgeführt. 😉 Kann natürlich sein dass du eine andere manpage hast, ich hab hier Debian.

P.S.: Das nohup brauchst du wahrscheinlich gar nicht.

EDIT: purple-remote funktioniert scheinbar nicht wenn man es nicht aus der laufenden Sitzung startet. Von daher ist der Neustart von Pidgin wahrscheinlich doch einfacher.

grumpy grizzly schrieb:

purple-remote setstatus?status=offline
purple-remote setstatus?status=available

Das bringt zumindest nix, wenn ich es über pidgins Schaltfläche mache, von daher hab ich es über remote garnicht erst probiert.

Oder du startest pidgin mit der Option "-n" wenn du eh schon weißt dass er sich direkt beim Start nicht verbinden kann.

Ich möchte ja, dass pidgin (so wie es früher immer ging 👿 ) einfach beim Start sich mit dem ICQ/Jabber-Server verbindet. Mit -n müsste ich dann manuell immer noch die Verbindung herstellen.

Ja gut, vorbildlich ist es nicht gerade. Aber ein paar Beispiele sind immerhin aufgeführt. 😉 Kann natürlich sein dass du eine andere manpage hast, ich hab hier Debian.

Liegt glaube daran, dass in dem zugehörigen Pythonscript auch nicht viel mehr Optionen verfügbar sind.

P.S.: Das nohup brauchst du wahrscheinlich gar nicht.

Stimmt, alte angewonheit, weil beim Terminalschließen die Programme immer mit flöten gehen.

stfischr schrieb:

Mit -n müsste ich dann manuell immer noch die Verbindung herstellen.

Ich meinte ja auch mit "-n" starten und dann, nachdem das Netzwerk verfügbar ist, mit purple-remote verbinden. Aber wie gesagt scheint das in diesem Fall auch nicht so richtig zu funktionieren. Von daher ist es mit dem killall und dann wieder starten wohl doch zuverlässiger.