Bug 1712490

Summary: after update no longer works with threads
Product: [Fedora] Fedora Reporter: Michal Hlavinka <mhlavink>
Component: python-SecretStorageAssignee: Charalampos Stratakis <cstratak>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: cstratak, jkonecny, mdomonko, otaylor, projects.rg, pviktori, williamjmorenor
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-11 13:26:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1571015    
Bug Blocks:    
Attachments:
Description Flags
reproducer part 1/2
none
reproducer part 2/2 none

Description Michal Hlavinka 2019-05-21 15:38:41 UTC
Created attachment 1571695 [details]
reproducer part 1/2

Description of problem:
On Fedora 30 with new version of python-secretstorage it breaks software that uses threads. We have a tool called D Dashboard that has backend part that stores some passwords in gnome keyring. It communicates with webui frontend through web rest api. That is handled by python http simple server that creates threads for incoming requests. If required, some request may need to query gnome keyring and this is where it breaks because updated python-SecretStorage no longer works when used in a thread.

Version-Release number of selected component (if applicable):
python3-secretstorage-3.1.1-1.fc30.noarch

How reproducible:
always

Steps to Reproduce:
1.run attached ./threadwrap.py
2.
3.

Actual results:
  File "/usr/lib/python3.7/site-packages/keyring/backends/SecretService.py", line 79, in set_password
    collection = self.get_preferred_collection()
  File "/usr/lib/python3.7/site-packages/keyring/backends/SecretService.py", line 50, in get_preferred_collection
    bus = secretstorage.dbus_init()
  File "/usr/lib/python3.7/site-packages/secretstorage/__init__.py", line 37, in dbus_init
    connection = connect_and_authenticate()
  File "/usr/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 82, in connect_and_authenticate
    conn = DBusConnection(sock)
  File "/usr/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 20, in __init__
    hello_reply = self.bus_proxy.Hello()
  File "/usr/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 64, in inner
    return self._connection.send_and_get_reply(msg)
  File "/usr/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 45, in send_and_get_reply
    future = self.send_message(message)
  File "/usr/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 24, in send_message
    future = self.router.outgoing(message)
  File "/usr/lib/python3.7/site-packages/jeepney/routing.py", line 26, in outgoing
    self.awaiting_reply[msg.header.serial] = handle = self.handle_factory()
  File "/usr/lib64/python3.7/asyncio/events.py", line 644, in get_event_loop
    % threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'Thread-1'.


Expected results:
wokrs, no exceptions

Additional info:
if you run it directly, without thread it will work. Same if you downgrade to 
python3-SecretStorage-2.3.1-10.fc29.noarch.rpm (yes, fc29 on F30 machine, no typo)

Comment 1 Michal Hlavinka 2019-05-21 15:39:30 UTC
Created attachment 1571696 [details]
reproducer part 2/2

Comment 2 Owen Taylor 2019-08-02 21:23:33 UTC
Maybe use libsecret  (https://developer.gnome.org/libsecret/) via GObject introspection instead to talk to GNOME Keyring? There are even Python examples in the documentation.

Comment 3 Raphael Groner 2019-08-03 07:28:11 UTC
Well, this issue should get reported to upstream. Fedora as downstream just follows to new releases.

Comment 4 Raphael Groner 2019-08-03 07:42:48 UTC
The update to v3.1 was requested with bug #1571015.

Comment 5 Raphael Groner 2019-08-03 07:53:24 UTC
Maybe you're missing the asynchronous API that's removed with v3.1 compared to 3.0 (latter never seen in Fedora)?
https://github.com/mitya57/secretstorage/blob/master/changelog#L36
https://github.com/mitya57/secretstorage/commit/709517904ea953a67c28e276b072f78c7abfb9ab

Comment 6 Miro HronĨok 2019-08-03 08:16:23 UTC
I don't how to fix this (you'd need to talk to upstream), but I know how to workaround it.

jeepney uses asyncio Future internaly. it needs **an** event loop set for the thread:


    import asyncio
    
    def worker():
        asyncio.set_event_loop(asyncio.new_event_loop())
        ....

Comment 7 Petr Viktorin (pviktori) 2019-08-06 13:23:42 UTC
Quick comment, as I don't have time to dig deeper:
Should jeepney use concurrent.futures.Future rather than asyncio.Future? The latter is tied to an event loop.

Comment 8 Charalampos Stratakis 2019-09-10 15:59:45 UTC
Any updates here? Did you manage to workaround the problem?

Comment 9 Michal Hlavinka 2019-09-11 13:24:25 UTC
Yes, I've used a workaround based on comment #6

Comment 10 Charalampos Stratakis 2019-09-11 13:26:39 UTC
Closing this then.

Comment 11 Michal Hlavinka 2019-09-11 13:50:54 UTC
closed-upstream - do you have a link for upstream bug report?

Comment 12 Charalampos Stratakis 2019-09-11 13:53:05 UTC
(In reply to Michal Hlavinka from comment #11)
> closed-upstream - do you have a link for upstream bug report?

It's an intended change upstream as mentioned beforehand: https://github.com/mitya57/secretstorage/blob/master/changelog#L36