我怎样才能制作一个假的“活动会话”？对于 gconf？

发布于 2024-07-09 06:37:15 字数 743 浏览 6 评论 0原文

我已经自动化了我的 Ubuntu 安装 - 我有自动运行的 Python 代码（在全新安装之后，但在第一个用户登录之前 - 它位于临时 /etc/init.d/ 脚本中），它设置了 Apache 的所有内容; 它的配置符合我个人的 Gnome 偏好。正是后者给我带来了麻烦。

这在 Ubuntu 8.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 是我的。）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

花开半夏魅人心 2024-07-16 06:37:15

我可以通过在我的机器上安装 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）。对于我的测试，我只使用了 shell，并使用 export DBUS_SESSION_BUS_ADDRESS=blahblah... 等手动设置环境变量。

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

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

我知道这很复杂。

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

编辑：供将来参考，如果有人想从普通的 bash 脚本（而不是 Python 脚本，如该线程正在讨论），检索会话总线地址以在脚本中使用非常容易：

#!/bin/bash

eval `dbus-launch --sh-syntax`

export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

do_other_stuff_here

I can reproduce this by installing GConf 2.24 on my machine. GConf 2.22 works fine, but 2.24 breaks it.

GConf is failing to launch because D-Bus is not running. Manually spawning D-Bus and the GConf daemon makes this work again.

I tried to spawn the D-Bus session bus by doing the following:

import dbus
dummy_bus = dbus.SessionBus()

...but got this:

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

Weird. Looks like it doesn't like to come up if X isn't running. To work around that, start dbus-launch manually (IIRC use the os.system() call):

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

You'll need to parse the output somehow and inject them into environment variables (you'll probably want to use os.putenv). For my testing, I just used the shell, and set the environment vars manually with export DBUS_SESSION_BUS_ADDRESS=blahblah..., etc.

Next, you need to launch gconftool-2 --spawn with those environment variables you received from dbus-launch. This will launch the GConf daemon. If the D-Bus environment vars are not set, the daemon will not launch.

Then, run your GConf code. Provided you set the D-Bus session bus environment variables for your own script, you will now be able to communicate with the GConf daemon.

I know it's complicated.

gconftool-2 provides a --direct option that enables you to set GConf variables without needing to communicate with the server, but I haven't been able to find an equivalent option for the Python bindings (short of outputting XML manually).

Edit: For future reference, if anybody wants to run dbus-launch from within a normal bash script (as opposed to a Python script, as this thread is discussing), it is quite easy to retrieve the session bus address for use within the script:

#!/bin/bash

eval `dbus-launch --sh-syntax`

export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID

do_other_stuff_here

回复收藏 0 原文

同尘 2024-07-16 06:37:15

嗯，我想我明白这个问题了。看起来你的脚本只需要启动 dbus 守护进程，或者确保它已启动。我相信这里的“会话”指的是 dbus 会话。（这里有一些证据），不是Gnome 会话。 Dbus 和 gconf 在没有 Gnome 的情况下都可以正常运行。

无论哪种方式，伪造“活动会话”听起来都是一个非常糟糕的主意。它只会在需要时寻找它。

也许我们可以在 Pastebin 中看到脚本？在发表任何评论之前我应该真正看到它。

回复收藏 0 原文

红焚 2024-07-16 06:37:15

谢谢，阿里和杰里米 - 你的回答都给了我很大的帮助。我仍在研究这个（尽管我晚上已经停下来了）。

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

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

（无论如何，明天我都会在这里添加另一个答案）

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

回复收藏 0 原文

~没有更多了~