"email digest sender command" and locked>0

Installation Issues
1

All,

Have tried various recommended means to address a constantly recurring log item:

info: {“message”:“Email digest sender command”,“sent”:0,“failed”:0,“pending”:0,“locked”:4}

This was discovered when clicking “save” (via web browser accessing passbolt in it’s own browser tab) and it was taking an abnormally long time to actually save the entry and return to the list of password entries.

Here are some of the things that were tried (amongst others):

sudo su -s /bin/bash -c "/usr/share/php/passbolt/bin/cake sender" www-data

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake passbolt send_test_email --recipient=<recipient_emailaddress>"

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake cache clear_all"

sudo -H -u www-data bash -c "/usr/share/php/passbolt/bin/cake passbolt show_queued_emails"

All of the outputs, tests and actions work as expected. Have even checked the email queue table in mysql and there are no errors listed. At this point, at a loss as to where the “locked:4” is coming from. The error messages are occurring every time an item is opened and saved in the GUI (via web browser). Appears to be linked to the ‘save’ action of an object. The test emails (via CLI and GUI) work.

Anyone have any ideas as to where else one should look and/or how to address? Perhaps worth note: when clicking “save” it’s taking an abnormally long period of time before it actually ‘saves’ the updated entry.

Out of curiosity, tested with the app on IOS - the ‘save’ is almost instantaneous and doesn’t result in the above error.

Fine with purging any sort of email “queue” to get past this issue - it that is the simplest path forward.

Thanks!

Edit/Update: found the four items in the email_queue that had a “locked” value set. These were old (almost two years old). As they’re “far gone”, setting to zero removes the “locked” appearance (can put the “locked” flag back if appropriate). However, doesn’t change anything about the long delay when trying to save via browser. Those log messages might be a red herring? Did try modifying an entry via IOS app, then modifying that same entry via web browser - update was fast via IOS app and long delay via web browser. Then went back re-modified entry via IOS app - save was fast. While not timing, it appears to be a couple seconds on IOS app vs. 30+ seconds via web browser - to provide sense of differential.

2

Hello @doubts,

It’s safe to purge the email queue (e.g. truncate email queue table for example), if you want to rule out if it’s this table making the creation slow.

However by the description, fast creation of resources on iOS but not in the browser extension, it looks like it could be something else. If you can inspect the behavior of the browser extension and try to find out which step is slow (is it slow when the request is being sent to the server, is it when the resource is being encrypted, etc.) we can try to narrow it down.

Cheers,

3

Unfortunately, not as familiar with debugging browser extensions. The “spin” appears to run throughout. It’s about 1 minute 12 seconds that the “spin” runs. Not seeing any get/post actions during that time in the developer tools /network. Did use FF profiling and not quite sure what one should be looking for. If you wouldn’t mind pointing me in the ‘right’ direction for the information you are after - I could probably find it.

Thanks!

4

G’day doubts,

Good info from the developer tools. The fact that there’s no network activity during the spin confirms the delay is happening client-side in the browser extension, not on the server. This lines up with iOS being fast.

When you save a resource, the browser extension encrypts the secret using OpenPGP.js (JavaScript-based crypto). If the resource is shared with multiple users, it has to encrypt a separate copy for each user’s public key. The iOS app uses native crypto libraries which are significantly faster at this.

A couple of things to help narrow it down:

  • How many users does the slow resource have access to? (i.e. is it shared with a group or many individuals?)
  • If you create a brand new resource that isn’t shared with anyone, is the save fast?
  • How many total users are in your passbolt instance?
  • Which browser and browser extension version are you running?

If it turns out to be related to the number of users the resource is shared with, that gives us a clear direction. If a non-shared resource is also slow, it could be something else in the extension environment (browser version, hardware acceleration settings, etc.).

Cheers
Gareth

5

Have tried with ‘shared’ items and not shared items (user shares are normally user + 2 other users - sometimes rw, sometimes ro). 7 users total. A new object is fairly quick, would say it’s “what one would expect”. That’s an entry to URI/username/password. Going back and editing - adding a note and it’s also fairly quick. Editing an existing object (not shared) is slow. Given that the overwhelming majority of items were added multiple passbolt versions/upgrades ago…. Wondering if it has something to do with “older” entries and/or less frequently accessed entries?

To test that:

  • Site created 2+ years ago (use a couple times per week), not shared entry, has notes
    • Librewolf: not slow
    • FF: not slow
  • Another site created 2+ years ago (rarely used, maybe once a year?), not shared entry, has notes
    • Librewolf: slow, “spin”
    • FF: slow, “spin”
  • Entry from 2 months ago (shared by another user)
    • Librewolf: not slow (edited note, added note, saved, re-edited - removing test note)
  • Entry from 9 months ago (not shared, no notes)
    • Librewolf: slow, “spin” after adding a note. Same issue when removing the note (returning to “blank” for notes)
  • Using prior “slow” entry (notes, not shared)
    • generated a new password (storing existing in notes) and saved - slow
    • Re-edited, made no changes and saved - slow
  • Entry created 2+ years ago (notes, shared by another user)
    • Librewolf: slow, “spin” after adding a note. (same when undoing change in note)
    • FF: same as Librewolf (slow/spin)

Trying to figure out “what is different” from one item to another when slow (spin) happens. Apologies if list was getting long, was also using to try to determine any “differences”. Not seeing a trend as to when the ‘save’ is slow. Some with a note are fast and others are slow - same for when there’s no note and adding a value in the note field. Age of the entry doesn’t seem to make a difference, either.

I’ll work on digging up a few more instances to see if there’s any sort of ‘trend’ for what is/isn’t hitting the “spin” on the save.

Librewolf, accessing passbolt server is within a container tab - no issues. Using passbolt extension works for sites in any container tab. Firefox, accessing server cannot be in a container tab due to error: “Could not verify the server key. x-gpgauth-authenticated should be set to false during the verify stage”, but passbolt extension works for sites in any tab. Librewolf is the ‘daily driver’ for security.

Browser is Librewolf (148.0.2-2). Plugin is 5.9.0. It’s running on a Mac Pro (desktop). None of the acceleration settings have been disabled in Librewolf. Out of 128GB of RAM, OS reports 0 swap used (if that matters). Only default theme installed/enabled. Other plugins are usual ‘cast of characters’: uBlock Origin, auto tab discard, auto cookie delete, etc. (extensions for protective disposition - passbolt is the only exception and passbolt server is whitelisted with protective extensions). No DoT/DoH use.

Thanks!