Import failing when DBUS_SESSION_BUS_ADDRESS not available about wakepy HOT 6 CLOSED

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?

from wakepy.

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.

from wakepy.

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

from wakepy.

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*
$

from wakepy.

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.

from wakepy.

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.

from wakepy.