9

Ubuntuのインストールを自動化しました-自動的に実行されるPythonコードがあります（クリーンインストール後、最初のユーザーログインの前に-一時的な/etc/init.d/スクリプトにあります）。Apacheとすべてをセットアップします。私の個人的なGnomeの好みに合わせた構成。私に問題を与えているのは後者です。

これはUbuntu8.04（Hardy）で正常に機能しましたが、8.10（Intrepid）でこれを使用すると、初めてgconfにアクセスしようとすると、次の例外が発生します。

構成サーバーへの接続に失敗しました。考えられる原因としては、ORBitのTCP / IPネットワークを有効にする必要があるか、システムクラッシュが原因でNFSロックが古くなっていることが考えられます。詳細については、 http：//www.gnome.org/projects/gconf/を参照してください。（詳細-1：アクティブなセッション内で実行されていません）

はい、そうです。ユーザーがまだログインしていないため、これが実行されているときはGnomeセッションはありません。ただし、これは以前は機能していました。これは、IntrepidのGnome（2.24？）では新しいようです。

gconfのXMLファイルを直接変更する以外に、ある種のプロキシGnomeセッションを作成する方法はありますか？または、他の提案はありますか？

（詳細：これはrootとして実行されるPythonコードですが、python-gconfパッケージの「gconf」モジュールを使用してプリファレンスを設定する前にsetuidとsetgidを使用します。）

4

3 に答える 3

8

私のマシンに GConf 2.24 をインストールすることで、これを再現できます。GConf 2.22 は正常に動作しますが、2.24 では機能しません。

D-Bus が実行されていないため、GConf の起動に失敗しています。D-Bus と GConf デーモンを手動で生成すると、これが再び機能します。

次のようにして、D-Bus セッション バスを生成しようとしました。

import dbus
dummy_bus = dbus.SessionBus()

...しかし、これを得ました：

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.

変。X が実行されていないと起動しないようです。これを回避するには、dbus-launch を手動で開始します (IIRC はos.system()呼び出しを使用します)。

$ dbus-launch 
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-eAmT3q94u0,guid=c250f62d3c4739dcc9a12d48490fc268
DBUS_SESSION_BUS_PID=15836

何らかの方法で出力を解析し、それらを環境変数に挿入する必要があります (おそらくos.putenvを使用する必要があります)。私のテストでは、シェルを使用し、環境変数をexport DBUS_SESSION_BUS_ADDRESS=blahblah...などで手動で設定しました。

gconftool-2 --spawn次に、から受け取った環境変数を使用して起動する必要がありますdbus-launch。これにより、GConf デーモンが起動します。D-Bus 環境変数が設定されていない場合、デーモンは起動しません。

次に、GConf コードを実行します。独自のスクリプトに D-Bus セッション バス環境変数を設定すると、GConf デーモンと通信できるようになります。

私はそれが複雑であることを知っています。

gconftool-2--directサーバーとの通信を必要とせずに GConf 変数を設定できるオプションを提供しますが、Python バインディング用の同等のオプションを見つけることができませんでした (手動で XML を出力することはできません)。

編集：将来の参考のために、誰かがdbus-launch通常のbashスクリプト内から実行したい場合（このスレッドで議論されているPythonスクリプトとは対照的に）、スクリプト内で使用するセッションバスアドレスを取得するのは非常に簡単です：

#!/bin/bash

eval `dbus-launch --sh-syntax`

export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

do_other_stuff_here
于 2008-11-04T03:07:40.530 に答える
1

ありがとう、アリとジェレミー-あなたの答えは両方とも大きな助けになりました。私はまだこれに取り組んでいます（私は夕方に立ち止まりましたが）。

最初に、私はAliからヒントを得て、Jeremyの提案の一部を試していました。dbus-launchを使用して「gconftool-2-spawn」を実行していました。それは私にはうまくいきませんでした。理由がわかりました（thx、Jeremy）-dbusとgconftoolを起動していたのと同じPythonプログラム内からgconfを使用しようとしましたが、その環境には環境変数がありませんでした-当たり前です。

gconftool-2の--directオプションに気付いたとき、私はその戦略を脇に置きました。内部的には、gconftool-2はgconfpythonバインディングによって公開されていないAPIを使用しています。そこで、python-gconfを変更して追加のメソッドを公開し、それがビルドされると（これを機能させるためにいくつかの無関係な問題が発生しました）、それが問題を解決するかどうかを確認します。これらのバインディングを構築すると、すべてのgnomeが構築されるように見えるためです！）、その最初の戦略で環境変数を管理するためのより良い方法を見つけます。

（明日、どちらの方法でもここに別の回答を追加します）

そして次の日です。変更したpython-gconfで少し問題が発生したため、Jeremyのより単純なアイデアを試してみました。これはうまく機能しました。最初のgconf操作を実行する前に、単に「dbus-launch」を実行して解析しました。結果として得られる名前と値のペア、およびそれらをPythonの環境に直接追加しました。それが終わったら、「gconftool-2-spawn」を実行しました。問題が解決しました。

于 2008-11-04T07:39:34.617 に答える
1

さて、私は質問を理解していると思います。スクリプトで dbus デーモンを開始するか、開始されていることを確認するだけでよいようです。ここでの「セッション」は dbus セッションを指していると思います。（ここにいくつかの証拠があります）、Gnomeセッションではありません。Dbus と gconf はどちらも Gnome がなくても問題なく動作します。

いずれにせよ、「アクティブなセッション」を偽装するのはかなり悪い考えのように思えます。必要な場合にのみ検索します。

おそらく、ペーストビンでスクリプトを見ることができますか? コメントする前に実際に見るべきだった。

于 2008-11-03T02:52:42.030 に答える