Bug 1476329

Thanks for a bug report. If I understand that `ps` command properly, then it reports that you have that many evolution-addressbook-factory-subprocess processes running, which is rather odd, because evolution-addressbook-factory runs one for each factory type (the --factory argument in the `ps` output), without "duplicates", and uses it until each client connecting to it is closed/freed.

Could the suspend/resume caused any misbehaviour here? I'll try to reproduce and will return back to you when I know more.

It might be a suspend/resume issue.. so over the weekend I have this again now:

ps aux | grep /usr/libexec/evolution-addressbook-factory-subprocess | grep -v grep

ohaessle   561  1.1  1.3 1674348 221592 ?      Sl   11:30   0:09 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx537x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/537/2
ohaessle 18506  0.0  1.3 1674348 221584 ?      Sl   Jul28   0:10 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx18493x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/18493/2
ohaessle 18997  0.0  1.3 1674348 221588 ?      Sl   Jul28   0:18 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx18973x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/18973/2
ohaessle 22163  0.0  1.3 1674344 221592 ?      Sl   Jul28   0:17 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx22145x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/22145/2
ohaessle 23460  0.0  1.3 1674348 221548 ?      Sl   Jul28   0:16 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx23435x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/23435/2
ohaessle 28155  0.1  1.3 1674352 221512 ?      Sl   10:19   0:08 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx28133x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/28133/2
ohaessle 28748  0.2  1.3 1674352 221676 ?      Sl   10:28   0:09 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx28737x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/28737/2
ohaessle 28993  0.2  1.3 1674384 221616 ?      Sl   10:29   0:10 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx28984x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/28984/2
ohaessle 29335  0.2  1.3 1674344 221552 ?      Sl   10:33   0:09 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx29321x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/29321/2
ohaessle 29801  0.4  1.3 1674388 221648 ?      Sl   10:37   0:19 /usr/libexec/evolution-addressbook-factory-subprocess --factory google --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx29782x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/29782/2

I tried it here, by installing suspend-button extension in the GNOME Shell in my virtual machine (VM) with RHEL, thus I did suspend it and when I woke the machine up there was no duplicated addressbook subprocess for the Google book. I didn't change networking or anything like that, it was the VM.

Could you grab a backtrace of any of the two running subprocesses, please? I'd like to see what they are doing. Ideally to pick the latest and the oldest, but it can be tricky to do due to the PID number not increasing monotonically. Getting a backtrace of evolution-addressbook-factory would be also interesting. Please install debuginfo package for evolution-data-server (and only for it), to get better backtrace. Make sure the debuginfo package version will match the version of the main package.

You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt
where the PID is replaced with the actual process ID. Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). You might want to rename the bt.txt based on the process you capture the backtrace for.

Created attachment 1306998 [details]
29801.txt

Created attachment 1307000 [details]
29335.txt

added to backlogs for the 2 newest PIDs

Thanks for the update. It shows that the process is stuck, when saving categories on exit. I do not know why it doesn't strike here, but it is a valid issue also in the upstream code.

I fixed it upstream with this commit:
https://git.gnome.org/browse/evolution-data-server/commit/?id=35ae7bc
which landed for 3.25.90+ and 3.24.5+.

Here is a test build with it included for RHEL 7.4:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13746532
It requires restart after being installed, thus the background process will use the new bits.

I believe a workaround would be to run evolution in the Contacts view and select all of the Google address books you might see there, thus for example from a terminal:

   $ evolution -c contacts

and then select the books with a mouse. After it wait until the books are fully populated. Then the categories changes will be saved to the disk, and you might see them in the Show: combo box as well (above the list with the contacts), but I'd like to test the fix first, thus the workaround is mentioned here just in case it won't work.

After testing a while, I can confirm that the patch is working.

Do we know when we can expect the patch to be in RHEL 7.4, so I can start deploying it on workstations?

(In reply to Oliver Haessler from comment #9)
> After testing a while, I can confirm that the patch is working.

Thanks for testing and confirmation.

> Do we know when we can expect the patch to be in RHEL 7.4, so I can start
> deploying it on workstations?

It missed 7.4, but it's approved for 7.5.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0912