Error StartServiceByName for org.freedesktop.secrets result in GUI testsuite failure in CI

[amrita-shrestha]

Pre-submission Checks

• I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
• I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.

Describe the QA issue

This could be the reason for lookup error

13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ warning sync.credentials.http.legacy ]:	Migrating old keychain entries failed "Error calling StartServiceByName for org.freedesktop.secrets: Failed to execute program org.freedesktop.secrets: Operation not permitted"
13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ info gui.account.state ]:	Fetched credentials for "http://owncloud/" attempting to connect
13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ warning gui.account.state ]:	checkConnectivity blocking: false

Steps to reproduce the issue

  Scenario: remove an account connection
    Given user "Alice" has been created on the server with default attributes and without skeleton files
    And user "Brian" has been created on the server with default attributes and without skeleton files
    And user "Alice" has set up a client with default settings
    And the user has added another account with
      | server   | %local_server% |
      | user     | Brian          |
      | password | AaBb2Cc3Dd4    |
    When the user removes the connection for user "Brian" and host %local_server_hostname%
    Then an account should be displayed with the displayname Alice Hansen and host %local_server_hostname%

Screenshots

GUI Logs:

Server Logs: https://cache.owncloud.com/public/owncloud/client/12592/guiReportUpload/serverlog.log

[sushmita56]

The following two scenarios failed with the same error message
Syncing a folder to the server serverlog.log
simple sharing of a file by public link with default expiration date serverlog.log

[TheOneRing]

We depend on the system password store to be available.

13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ warning sync.credentials.http.legacy ]: Migrating old keychain entries failed >"Error calling StartServiceByName for org.freedesktop.secrets: Failed to execute program org.freedesktop.secrets: Operation not >permitted"
13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ info gui.account.state ]: Fetched credentials for "http://owncloud/" attempting >to connect
13:55:03:574 AUT stdout: 07-22 13:55:02:763 [ warning gui.account.state ]: checkConnectivity blocking: false

You appear to use a legacy ownCloud.cfg format which is then migrated to the new credentials format and this seems to fail with the password store.

[TheOneRing]

Failed to execute program org.freedesktop.secrets: Operation not
Any chance we can ensure the credentials store service is running?

[saw-jan]

You appear to use a legacy ownCloud.cfg format which is then migrated to the new credentials format and this seems to fail with the password store.

@TheOneRing Can we make use of that new credentials format instead of ownCloud.cfg so that there won't be any migration process?

[TheOneRing]

Yes but we still would require the credentials store to be started.

[saw-jan]

Yes but we still would require the credentials store to be started.

No idea what the Credentials Store server is. Is there any way we can check the server status (running command or something)?

[TheOneRing]

@fmoc what is used on xfce?

[fmoc]

It is gnome-keyring-daemon.

[amrita-shrestha]

I think this issue is behind failure at the wait-until-sync steps too
i.e
And the user has waited for folder "Folder1" to be synced

GUI Log Screenshot

Server Logs: https://cache.owncloud.com/public/owncloud/client/12713/guiReportUpload/serverlog.log
serverlog.log

Screenshot

[TheOneRing]

Really hard to say what's going on here but it appears that gnome-keyring-daemon dies during the tests?

[TheOneRing]

Hmmm https://unix.stackexchange.com/questions/473528/how-do-you-enable-the-secret-tool-command-backed-by-gnome-keyring-libsecret-an

On the other hand that does not explain why it sometimes works and sometimes not.
@fmoc

[saw-jan]

The possible fix PR has been merged but could not test this behavior due to the new issue.
Blocked until owncloud-ci/squish#34
GUI tests are now enabled in #10046

[saw-jan]

Haven't seen these types of failures recently. Should be fixed by new squish image and disabling screen lock