我该如何为gconf制作一个虚假的“活动会话”？

Question

我已经自动化了我的Ubuntu安装——我有自动运行的Python代码（在一次干净的安装之后，但是在第一次用户登录之前——它在一个临时的/etc/in it.d/script中），它设置了从Apache&；它的配置到我的个人Gnome首选项的所有内容。是后者给了我麻烦。

这在Ubuntu8.04（Hardy）中运行得很好，但是当我在8.10（Intrepid）中使用它时，第一次尝试访问gconf时，我得到一个异常：

无法联系配置服务器；可能的原因是您需要为ORBit启用TCP/IP网络，或者由于系统崩溃而导致NFS锁定过时。有关信息，请参见http://www.gnome.org/projects/gconf/。（详细信息-1:未在活动会话中运行）

是的，是的，在运行时没有Gnome会话，因为用户还没有登录-但是，这之前已经成功了；这似乎是无畏的Gnome（2.24？）的新功能。

除了直接修改gconf的XML文件外，是否有方法生成某种代理Gnome会话？或者，还有其他建议吗？

（更多详细信息：这是以根用户身份运行的python代码，但在使用python gconf包中的“gconf”模块设置首选项之前，setuid和setgid必须是我自己。）

Answer 1

我可以通过在我的机器上安装GConf 2.24来复制这个。GConf 2.22运行良好，但2.24中断。

GConf无法启动，因为D-Bus未运行。手动生成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）。对于我的测试，我只是使用shell，并使用export DBUS_SESSION_BUS_ADDRESS=blahblah...等手动设置环境变量

接下来，需要使用从dbus-launch接收到的环境变量启动gconftool-2 --spawn。这将启动GConf守护进程。如果未设置D-Bus环境变量，守护进程将不会启动。

然后，运行GConf代码。如果您为自己的脚本设置了D-Bus会话总线环境变量，现在就可以与GConf守护进程通信。

我知道这很复杂。

gconftool-2提供了一个--direct选项，允许您设置GConf变量，而无需与服务器通信，但我还无法找到Python绑定的等效选项（缺少手动输出XML）。

编辑：供以后参考，如果有人想从普通的bash脚本中运行dbus-launch（与此线程正在讨论的Python脚本相反），那么检索会话总线地址以便在脚本中使用是相当容易的：

#!/bin/bash

eval `dbus-launch --sh-syntax`

export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

do_other_stuff_here

Answer 2

谢谢，阿里和杰里米-你的回答对我帮助很大。我还在做这个（虽然我已经停下来过夜了）。

首先，我从Ali那里得到了提示，并尝试了Jeremy的一部分建议：我使用dbus launch运行“gconftool-2--spawn”。它对我不起作用；我现在明白了为什么（thx，Jeremy）--我试图在启动dbus&gconftool的同一个python程序中使用gconf，但是它的环境没有环境变量-duh。

当我注意到gconftool-2的--direct选项时，我把这个策略放在一边；在内部，gconftool-2使用的是gconf python绑定没有公开的API。所以，我修改了python gconf以公开额外的方法，一旦构建（我遇到了一些不相关的问题，让它正常工作），我们将看看它是否修复了问题-如果它没有修复（或者如果它修复了，因为构建这些绑定似乎构建了所有的gnome！），我将在第一个策略中找到更好的方法来管理环境变量。

（不管怎样，我明天在这里再加一个答案）

第二天：我在修改python gconf时遇到了一个小问题，这启发了我尝试Jeremy的简单想法，这个想法很好——在执行第一个gconf操作之前，我只需运行“dbus launch”，解析得到的名称-值对，并将它们直接添加到python的环境中。完成后，我运行“gconftool-2--spawn”。问题解决了。

Answer 3

好吧，我想我理解这个问题。看起来您的脚本只需要启动dbus守护进程，或者确保它已启动。我认为这里的“session”指的是dbus会话。(here is some evidence)，不是Gnome会话。Dbus和gconf在没有Gnome的情况下运行良好。

不管怎样，假装一个“活跃的会议”听起来都是个很糟糕的主意。它只会在需要的时候寻找它。

也许我们可以在一个垃圾箱里看到剧本？在发表任何评论之前我真的应该看看。