Error 500 in nextcloud polls

Today we found the poll application on one of our nextcloud instance to be completely broken. Attempting to create a new poll or add date options to an existing one resulted in HTTP 500 errors. In nextcloud logs, there were errors like:

duplicate key value violates unique constraint "oc_polls_polls_pkey"
DETAIL: Key (id)=(9) already exists.

or when adding options to an existing poll:

OCP\AppFramework\Db\DoesNotExistException: Did expect one result but found none

As a clue, this happened after a migration of the nextcloud DB from MySQL to PostgreSQL. My guess is that the PostgreSQL sequences were not updated correctly during the migration. So it was not possible to create either new rows for options in a poll or even a poll itself after a certain point, when the auto generated ID conflicted with an existing ID in the tables, which is the unique constraint violation you see in the error.

So the behavior was, we could add some options and some polls, but as soon as the sequence catches up to an existing ID, any INSERT fails with a primary key conflict. In our case only the polls tables seemed to be affected, but this could happen on other tables too because of the migration.

The fix was to reset the sequences to the current maximum ID for each table of the polls application:

SELECT setval('oc_polls_polls_id_seq',    (SELECT MAX(id) FROM oc_polls_polls));
SELECT setval('oc_polls_options_id_seq',  (SELECT MAX(id) FROM oc_polls_options));
SELECT setval('oc_polls_votes_id_seq',    (SELECT MAX(id) FROM oc_polls_votes));
SELECT setval('oc_polls_share_id_seq',    (SELECT MAX(id) FROM oc_polls_share));
SELECT setval('oc_polls_comments_id_seq', (SELECT MAX(id) FROM oc_polls_comments));
SELECT setval('oc_polls_log_id_seq',      (SELECT MAX(id) FROM oc_polls_log));

Where did my PGP keys go?

Today I noticed that one of my PGP private key just disappeared of GPG. The key did not appear when I did gpg --list-secret-keys. After a bit of investigation I discovered that the problem did not affect Linux hosts but only FreeBSD hosts. Weird…

The source of the problem was a migration from GnuPG v2.0 to v2.1. According to this page, GPG does not handle the private keys anymore and delegates all private keys operations to the gpg-agent. Therefore GPG v2.1 migrates the legacy secret keyring, secring.gpg, to the gpg-agent key store, private-keys-v1.d and then forgets about it.

Though, you see, my GPG keyrings were synchronized across all hosts. But the GnuPG package on Debian is still v2.0, while FreeBSD is v2.1. Get the picture?

I synced my keyring on FreeBSD hosts where GPG migrated my private keys to the gpg-agent key store. Then I generated a new key pair on a Debian host, which was added to the legacy keyring. Resynced, but the newer version of GPG didn’t care, they already migrated to the new key store.

Fortunately it was easy to fix, all you have to do is re-import your legacy keyring with one of the newer versions of GPG. The private keys are now also present in the new key store so you can sync to all other hosts.

gpg --import $HOME/.gnupg/secring.gpg
gpg --list-secret-keys