Nextcloud.log file in race condition - NextCloud

Nextcloud version:
OS: Slackware 14.2

php -v

PHP 7.2.4 (cli) (built: Apr 13 2018 10:52:37) ( ZTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright © 1998-2018 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured) v10.2.0, Copyright © 2002-2018, by ionCube Ltd.
with Zend OPcache v7.2.4, Copyright © 1999-2018, by Zend Technologies

apachectl -v

Server version: Apache/2.4.33 (Unix)
Server built: Apr 13 2018 10:36:48

mysql --version

mysql Ver 15.1 Distrib 10.2.14-MariaDB, for Linux (x86_64) using readline 5.1

uname -a

Linux hammer 4.4.0 #1 SMP Mon Jan 11 22:25:06 CST 2016 x86_64 Intel® Xeon® CPU E5-1620 v3 @ 3.50GHz GenuineIntel GNU/Linux

The issue you are facing:

I’ve got some kind of race condition whereby I even had to set up a cronjob to empty the ownlcoud.log file in order to keep the /var/partition from filling up. Here’s what every single entry looks like, from within Nextcloud:

hash_hmac(): Unknown hashing algorithm: sha1 at /var/www/htdocs/3rdparty/phpseclib/phpseclib/phpseclib/Crypt/Hash.php#308

When tailing the logfile it just races by at lightning speed, non-stop, until the partition eventually fills up.

Is this the first time you’ve seen this error? (Y/N): Yes.

Steps to replicate it:

./etc/rc.d/rc.mysqld start

/etc/rc.d/rc.httpd start

And in a couple of seconds the logfile begins to fill.

The output of your Nextcloud log in Admin > Logging:

    hash_hmac(): Unknown hashing algorithm: sha1 at /var/www/htdocs/3rdparty/phpseclib/phpseclib/phpseclib/Crypt/Hash.php#308

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

# cat config.php
$CONFIG = array (
  'instanceid' => 'santaclaus',
  'passwordsalt' => 'pepper',
  'secret' => 'secret',
  'trusted_domains' =>
  array (
    0 => 'host.sld.tld',
  'datadirectory' => '/var/www/htdocs/data',
  'overwrite.cli.url' => 'https://host.sld.tld',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'owncloud666',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'satan',
  'dbpassword' => 'password',
  'logtimezone' => 'UTC',
  'installed' => true,
  'mail_from_address' => 'satan',
  'mail_smtpmode' => 'smtp',
  'mail_domain' => 'sld.tld',
  'maintenance' => false,
  'loglevel' => 0,
  'theme' => '',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => '',
  'mail_smtpport' => '587',
  'mail_smtpname' => 'SMTP_Injection',
  'mail_smtppassword' => 'password',
  'mail_smtpsecure' => 'tls',


Any changes to PHP recently or any modifications to the php.ini?

Just pasting this error message in Google I found

What it boiled down to for me was that due to a forgotten comment in configs I was using mod_php with mpm_event apache. So non-thread-safe php7 in a threaded environment, hence shared memory corruption and a number of problems, one of them being sha1 was unavailable after some random uptime.

reboot resolved this issue

Actually @Schmu , I had upgraded from PHP5 to 7.2 just a few days earlier. I ran through the diff and made the adjustments for RAM, Timezone, timeouts, max file upload, and a couple of other insignificant allocations that I had customized in the previous php.ini, but nothing else had changed.

The logfile was filling so fast that I set the cronjob to every 10 minutes. In that amount of time the logfile grew several Gigs. There has been no reboot with uptime of over a year and I would like to avoid rebooting. I can restart any services at all that might alleviate this if you have suggestions besides a full reboot.

The behavior was exactly as exhibited in the first example you posted - everything is fine… for a while, and then all of a sudden cpu spikes and it goes haywire. I did nothing except letting it go and clearing the logfile repeatedly via the cronjob I wrote, and eventually it settled down to normal.

I think, for the moment, I’m going to try to monitor CPU and logfile with Zabbix and Observium or Nagios to alert me as soon as this happens again (It’s the second time afaik), and then perhaps be able to isolate whatever event triggers this. I can’t imagine that this is as random as the example you quoted is saying, so watching for it to happen again will identify what makes this occur.

In the meantime, I’m going to parse the old /etc/php.ini with the stock new one that was installed along with PHP7, to see if anything there matches or looks off. Reboots are bandaids, and I’d like to identify the issue and get to the bottom of it if a reboot can be avoided.

The string I searched for with google was longer, instead of the shorter string you searched on, which is why my search yielded nothing before I came here. I want to thank you for taking the time to point me in what appears to be the right direction and I’ll comment back as soon as I have more intelligence gathered from my box.

I’m just glad that it doesn’t appear as if this had anything to do with latent kruft left over from when I upgraded from ownCloud 8 or 9 or whatever it was during the migration to Nextcloud and up through 11, 12, and now 13, which was my immediate thought.

If there’s anything else in the meantime you can suggest I look at that would be great, and since SHA1 is in there I’m wondering if I missed something else, perhaps an update to OpenSSL or some other part of the system that was part of the update process?