Can confirm.

Downgrading to previous version (for us that was 1.21.5) didn't resolve issue.
Removing lockfiles manually resolved the issue.

fwiw i experienced this on forgejo too. a workaround that worked for me was to specify a different $GNUPGHOME, i.e.:

services:
  gitea:
    image: gitea/gitea:latest
    environment:
      GNUPGHOME: /.gnupg
# ...
    volumes:
      - ./data/gitea/gnupg:/.gnupg

Maybe we can have a check to delete these lock files when Gitea startup.

I run into this sporadically as well, despite not having an unclean shutdown (from my perspective). The Gitea server is stopped every night for backup using docker compose stop. So maybe it's unclean there, but that would be an issue in itself.

A check for stale lock files would be very useful

I also have this issue when I do docker compose stop to shutdown the container. I am using the image gitea/gitea:1.22.3.

My current setup is based on the docker-compose.yml file from the Installation with Docker page. I solved the issue by deleting the lock file at the startup of the container. I added this to the service definition:

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.22.3
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
+   command: sh -c "rm /data/gitea/home/.gnupg/public-keys.d/pubring.db.lock; /bin/s6-svscan /etc/s6"

The path /data/gitea/home/.gnupg/public-keys.d/pubring.db.lock is my problematic lock file. Then it runs the command that starts the container: /bin/s6-svscan /etc/s6.

When the lock file does not exist, it just logs a message and continues.