Import failing when DBUS_SESSION_BUS_ADDRESS not available

[rileyyy]

Hej,

The issue originally stems from another project where I am importing wakepy and it is causing all sorts of issues in readthedocs generation. I was able to reproduce the issue locally though with just wakepy.

Presently running an Ubuntu 20.04.4 LTS VM on WSL.
While I did get dbus-x11 installed and running, it seems $DBUS_SESSION_BUS_ADDRESS isn't set and that is causing problems.
I'm not sure what else is missing but maybe it could be caught by expanding the except after the import dbus

$ sudo apt-get install dbus-x11
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus-x11 is already the newest version (1.12.16-2ubuntu2.3).
0 upgraded, 0 newly installed, 0 to remove and 136 not upgraded.
$ service dbus status
 * dbus is running
$ pip install dbus-python pydbus
Requirement already satisfied: dbus-python in /usr/lib/python3/dist-packages (1.2.16)
Requirement already satisfied: pydbus in /home/riley/.local/lib/python3.8/site-packages (0.6.0)
riley@OHENP-PW012RVH0:/mnt/c/SourceCode/PythonDriver$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wakepy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/riley/.local/lib/python3.8/site-packages/wakepy/__init__.py", line 35, in <module>
    from ._linux import set_keepawake, unset_keepawake
  File "/home/riley/.local/lib/python3.8/site-packages/wakepy/_linux/__init__.py", line 17, in <module>
    my_module = import_module(f".{module}", f"wakepy._linux")
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/home/riley/.local/lib/python3.8/site-packages/wakepy/_linux/_jeepney_dbus.py", line 26, in <module>
    connection = open_dbus_connection(bus="SESSION")
  File "/home/riley/.local/lib/python3.8/site-packages/jeepney/io/blocking.py", line 341, in open_dbus_connection
    bus_addr = get_bus(bus)
  File "/home/riley/.local/lib/python3.8/site-packages/jeepney/bus.py", line 53, in get_bus
    return find_session_bus()
  File "/home/riley/.local/lib/python3.8/site-packages/jeepney/bus.py", line 42, in find_session_bus
    addr = os.environ['DBUS_SESSION_BUS_ADDRESS']
  File "/usr/lib/python3.8/os.py", line 675, in __getitem__
    raise KeyError(key) from None
KeyError: 'DBUS_SESSION_BUS_ADDRESS'

[fohrloop]

Hi @rileyyy and thanks for the information! If I understood correctly, there are two problems: import time exceptions and failure of detecting dbus.

Problem 1: import time exceptions

I am kind of aware of this problem, and working on a fix. I opened #26 when I found out that importing wakepy will fail in any tox tests if DBUS_SESSION_BUS_ADDRESS is not set. I then opened #29 to create support for syntax like

from wakepy import keepawake

with keepawake(on_failure='warn'):
    # do something

After this is ready import wakepy should not ever cause an exception, and even while using, user can make setting keepawake optional with e.g. on_failure='warn'. I will include this in the next release.

Problem 2: not detecting dbus

If I have understood correctly, dbus works like this:

1. Start a dbus-daemon for the session bus
2. Advertise the address of the session bus. Usually this is set to environment variable DBUS_SESSION_BUS_ADDRESS.
3. When wanting to talk with services connected to the session bus, get the address of the bus, and send messages.

I am no means yet an expert of the subject, though. There are also some other ways the session bus address can be advertised. From DBus Specification:

• X Window System root window property _DBUS_SESSION_BUS_ADDRESS
• File located in the current user's home directory, in subdirectory .dbus/session-bus/

Currently, I am using jeepney to get the dbus session address. The implementation in jeepney for getting the session bus address is:

def find_session_bus():
    addr = os.environ['DBUS_SESSION_BUS_ADDRESS']
    return next(get_connectable_addresses(addr))
    # TODO: fallbacks to X, filesystem

So it only checks the best guess, environment variable DBUS_SESSION_BUS_ADDRESS and does not check the other two (X Window System properties or possible files in ~/.dbus/session-bus/).

Possible solutions for problem 2

Option A

• Try to expand the bus address search to X Window System properties and files under ~/.dbus/session-bus
• Maybe there is already some python implementation doing this?

Option B

• Try to get the session bus address with system tools. Something like:

niko@niko-ubuntu-home:~$ ps -x | grep dbus
   1107 ?        Ss     0:04 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
   1246 ?        S      0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/1000/at-spi/bus
  20247 pts/3    S+     0:00 grep --color=auto dbus

niko@niko-ubuntu-home:~$ cat /proc/1107/environ |  tr '\0' '\n' | grep DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

worked for me. It should be pretty easy to do this in python, at least if it would simply use subprocess to call ps and read the /proc/<pid>/environ file. It's a bit fragile, but could still work.

Option C

• Add simple error message saying that DBUS_SESSION_BUS_ADDRESS must be set and instructions how to check that.
• This could be implemented in any case (if all methods getting dbus address fail)

Option D

• Simply try to launch a new dbus daemon and set wakelock on that. I'm not sure if this could work. Perhaps?
• For multiprocessing case, would be good that the address is set to something that could be used in all the the processes (only one new session bus launched)

---

Any thoughts on the options? Or do you have some other suggestions or comments? How did you start dbus without getting the DBUS_SESSION_BUS_ADDRESS environment variable? What does your ps -x | grep dbus look like?

[rileyyy]

Wow thanks for the comprehensive response! I must have skipped over #26 since it seems you're pretty aware of this. I'm afraid I'm not very familiar with dbus or I might have realized what was going on there better. Presently, I've wrapped the import with a try/except for the KeyError so we could get a release out. But after talking to another developer I work with, we aren't too concerned as Linux users are probably an incredibly small userbase. I'm afraid I'm out of the office until monday so I can't check the ps -x output until next week.

I can certainly fine with closing this as duplicate since you seem aware of the problem. But I can certainly try to help figure out a work around for what I may be able to provide haha.

[fohrloop]

For problem 1, this can be considered as duplicate, but if you think that dbus should be detected even when DBUS_SESSION_BUS_ADDRESS environment variable is not set (problem 2), then this issue can kept be open for that.

I somehow did not register that you were running wakepy on WSL. I have not even considered how it should work there. In particular, I'm not sure how we systemd and dbus are working on WSL, and/or if those still could be used to prevent suspend of Windows. I made separate issue for WSL support: #36

[rileyyy]

Just wanted to update with some results if that helps at all for the WSL related support.
Personally, I think that DBUS should fail if DBUS_SESSION_BUS_ADDRESS is missing, even if dbus is running

$ ps -x | grep dbus
   80 pts/0    S      0:00 dbus-launch --autolaunch 88bfe84765205e963cb101b362d05207 --binary-syntax --close-stderr
   81 ?        Ss     0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
 2594 pts/0    S+     0:00 grep --color=auto dbus
$ cat /proc/81/environ |  tr '\0' '\n' | grep DBUS_SESSION_BUS_ADDRESS
$
$ cat /proc/81/environ |  tr '\0' '\n' | grep -G *DBUS*
$

[fohrloop]

Hi @rileyyy and thanks for the update! I hope I'll have some spare in the coming weeks so I could work on the next release and get at least the import-time exception fixed or more helpful.

[fohrloop]

This one is fixed.

on_fail behaviour

The default behaviour in 0.8.0dev (unreleased, available in the dev branch) is to throw an exception on failure, but no exceptions during import time:

from wakepy import keep
import os
del os.environ['DBUS_SESSION_BUS_ADDRESS']
with keep.running():
    ...

This will show:

Method usage results, in order (highest priority first):
[(FAIL @ACTIVATION, org.gnome.SessionManager, "DbusNotFoundError("The environment variable DBUS_SESSION_BUS_ADDRESS is not set! To use dbus-based methods with jeepney, a session (not system) bus (dbus-daemon process) must be running, and the address of the bus should be available at the DBUS_SESSION_BUS_ADDRESS environment variable. To check if you're running a session dbus-daemon, run `ps -x | grep dbus-daemon`")"), (FAIL @PLATFORM_SUPPORT, caffeinate, ""), (FAIL @PLATFORM_SUPPORT, SetThreadExecutionState, "")]

This can be also changed to a warning:

with keep.running(on_fail='warn'):
    ...

and it's possible to use any callable which takes in an ActivationResult:

def do_something(result: ActivationResult):
    ...

with keep.running(on_fail=do_something):
    ...

wakepy in tests -> WAKEPY_FAKE_SUCCESS

In tests and continuous integration, one can set WAKEPY_FAKE_SUCCESS to a truthy value, which will skip using any real methods (and io) and fake a success:

>>> os.environ['WAKEPY_FAKE_SUCCESS'] = '1'
>>> with keep.running() as m:
        print(m.active)
    
True
>>> m.activation_result.active_method
'WAKEPY_FAKE_SUCCESS'

WSL support

This one is under development and continuing in issue 36.