Locking errors on Linux

After upgrading from Nextcloud 12 to version 13, I started to get mails with partially cryptic errors:

PHP Fatal error:  Uncaught Error: Call to a member function getLogger() on null in /path/to/lib/public/Util.php:158
Stack trace:
#0 /path/to/cron.php(158): OCP\Util::writeLog('cron', 'Could not acqui...', 4)
#1 {main}
thrown in /path/to/lib/public/Util.php on line 158

While collecting information for the bug report, I saw the full error message:

An unhandled exception has been thrown:
Exception: Could not acquire a shared lock on the config file
/path/to/config/config.php in /path/to/lib/private/Config.php:210

In the server's syslog, I saw more errors related to locking:

postfix/trivial-rewrite[10510]: fatal: /etc/postfix/transport.db: lock dictionary: Cannot allocate memory
postfix/smtpd[7048]: fatal: select lock: Cannot allocate memory
postfix/cleanup[9561]: fatal: select lock: Cannot allocate memory

Then I looked in the virtual server's management interface and saw:

Resource numflock red alert on environment lvps5-35-241-22.dedicated.hosteurope.de

current value: 1000
soft limit: 1000
hard limit: 1100

Red zone

The help said:

The number of file locks created by all virtual environment processes.

So, let's check who locks so much files:

$ lslocks --output COMMAND|sort |uniq -c
  1 atd
  1 cleanup
  5 courierlogger
  2 couriertcpd
  1 cron
 16 java
  2 master
  3 multilog
958 mysqld
  2 pipe
  1 postgrey --pidf
  2 proftpd
  1 smtpd
  6 supervise

I have no idea why MySQL started locking so much, but after restarting the service all was back to normal. (with MySQL using ~40 locks)

Written by Christian Weiske.

Comments? Please send an e-mail.