SyncExternalUsers Issue

Install/Maintain/Configure
1

Hi

We are running Gitea v1.4.0+rc3 (we are upgrading soon). We run Gitea using Docker hosted on Rancher. The gitea container randomly restarted today, as in the container went down and Rancher rescheduled it. I’ve checked all the logs (also Rancher to make sure that it wasn’t the cause) and the only thing I can find that happened right before the crash was the following entries: -

2019/02/20 14:23:25 […gitea/models/user.go:1388 SyncExternalUsers()] [E] LDAP Search failed unexpectedly! (LDAP Result Code 4 “Size Limit Exceeded”: )
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user glew: database table is locked: user
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user FMac: database table is locked: user
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user lcar351: database table is locked: user
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user rkum071: database table is locked: user
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user mtho141: database table is locked: user
2019/02/20 14:23:26 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user afer141: database table is locked: user
2019/02/20 14:23:27 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user twin261: database table is locked: user
2019/02/20 14:23:27 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user rpla011: database table is locked: user
2019/02/20 14:23:27 […/gogits/cron/cron.go:92 Run()] [E] SyncExternalUsers[MINT AD]: Error deactivating user gwig351: database table is locked: user

Can anyone confirm if this could have brought down the container? It seems odd that sync job even ran because we setup LDAP over a year ago. Also, there are only a few admins and non of us have actioned anything to do with LDAP.

If this is not the cause of the issue, can anyone suggest why this job was triggered to run and only on the few users selected?

Many thanks
Jonny

2

Does anyone have any comments on the above?

3

Which database did you use?

4

At the moment we are using SQLlite (might look to migrate that to MySQL soon).

The SQLlite data is volume mounted on our NFS volume and thus is outside of the running container

5

Low version gitea with sqlite maybe lock table at some situations. We recommend you upgrade to latest stable version and with MySQL/Postgres/MSSQL

6

Ok, thanks Lunny. I thought that might be the case and we are in the process of upgrading.

Many thanks
Jonny