Could not boot workflowengine: Redis server went away

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 31.0.7
  • Operating system and version (e.g., Ubuntu 24.04):
    • Arch Linux 6.15.9
  • Web server and version (e.g, Apache 2.4.25):
    • apache 2.4.63
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • privoxy 4.0.0
  • PHP version (e.g, 8.3):
    • php 8.2.29
  • Is this the first time you’ve seen this error? (Yes / No):
    • yes
  • When did this problem seem to first start?
    • on installation
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • manual from arch packages
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • 'no`

Summary of the issue you are facing:

I’ve installed nextcloud manually on a new server with everything built-in (no external servers or services). Everything went fine and before installing and configuring valkey (redis replacement), I had not issue getting to main set-up page to this new nextcloud install.

After installing and configuring valkey, as I would redis and as described in arch wiki, I start getting Internal Server Errors when trying to go to the main nextcloud page.

NOTE:

  • I installed the valkey package (this wasn’t part of the instructions)
  • Installed php-legacy-redis (as per arch wiki nextcloud instructions)
  • Configured valkey as per arch wiki page’s instructions
  • Set /run/valkey/ under valkey ownership
  • Added http and nextcloud users to valkey group
  • Successfully started valkey systemd service with no errors

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

{
  "reqId": "pHQ3HW1eVb7LWbjhKhCO",
  "level": 4,
  "time": "2025-08-04T14:32:23+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "no app in context",
  "method": "",
  "url": "--",
  "message": "Could not boot workflowengine: Redis server went away",
  "userAgent": "--",
  "version": "31.0.7.1",
  "exception": {
    "Exception": "RedisException",
    "Message": "Redis server went away",
    "Code": 0,
    "Trace": [
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/Memcache/Redis.php",
        "line": 59,
        "function": "get",
        "class": "Redis",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/apps/workflowengine/lib/Manager.php",
        "line": 89,
        "function": "get",
        "class": "OC\\Memcache\\Redis",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/apps/workflowengine/lib/AppInfo/Application.php",
        "line": 50,
        "function": "getAllConfiguredEvents",
        "class": "OCA\\WorkflowEngine\\Manager",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/AppFramework/Bootstrap/FunctionInjector.php",
        "line": 28,
        "function": "registerRuleListeners",
        "class": "OCA\\WorkflowEngine\\AppInfo\\Application",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/AppFramework/Bootstrap/BootContext.php",
        "line": 32,
        "function": "injectFn",
        "class": "OC\\AppFramework\\Bootstrap\\FunctionInjector",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/apps/workflowengine/lib/AppInfo/Application.php",
        "line": 42,
        "function": "injectFn",
        "class": "OC\\AppFramework\\Bootstrap\\BootContext",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/AppFramework/Bootstrap/Coordinator.php",
        "line": 157,
        "function": "boot",
        "class": "OCA\\WorkflowEngine\\AppInfo\\Application",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/App/AppManager.php",
        "line": 479,
        "function": "bootApp",
        "class": "OC\\AppFramework\\Bootstrap\\Coordinator",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/App/AppManager.php",
        "line": 248,
        "function": "loadApp",
        "class": "OC\\App\\AppManager",
        "type": "->"
      },
      {
        "file": "/usr/share/webapps/nextcloud/cron.php",
        "line": 61,
        "function": "loadApps",
        "class": "OC\\App\\AppManager",
        "type": "->"
      }
    ],
    "File": "/usr/share/webapps/nextcloud/lib/private/Memcache/Redis.php",
    "Line": 59,
    "message": "Could not boot workflowengine: Redis server went away",
    "exception": {},
    "CustomMessage": "Could not boot workflowengine: Redis server went away"
  }

Configuration

Nextcloud

{
    "system": {
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "apps_paths": [
            {
                "path": "\/usr\/share\/webapps\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/lib\/nextcloud\/apps",
                "url": "\/wapps",
                "writable": true
            }
        ],
        "trusted_domains": [
            "localhost",
            "cloud"
        ],
        "overwrite.cli.url": "https:\/\/cloud\/",
        "htaccess.RewriteBase": "\/",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "31.0.7.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 1.5
        }
    }
}

First thing that comes to mind: Restart the app server (i.e. FPM) so that the group changes take effect

@jtr I just did that again. Even restarted the whole machine several times. Still an issue.

I also stopped the valkey service (it immediately removed the /run/valkey/valkey.sock dir and file). Tried running everything without, thinking maybe php-legacy-redis (which is php-redis on other distros) would add the files themselves, but no luck. It would just throw a ‘File not found’ in the log.

I’ve re-enabled valkey service and get the old error. Heres another snippet:

{
  "reqId": "UJQZ1MiEdC3urwpB5RdA",
  "level": 4,
  "time": "2025-08-04T15:26:55+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "app_api",
  "method": "",
  "url": "--",
  "message": "Error during app service registration: Permission denied",
  "userAgent": "--",
  "version": "31.0.7.1",
  "exception": {
    "Exception": "RedisException",
    "Message": "Permission denied",
    "Code": 0,
    "Trace": [
      {
        "file": "/usr/share/webapps/nextcloud/lib/private/RedisFactory.php",
        "line": 104,
        "function": "pconnect",
        "class": "Redis",
        "type": "->"

I’ll try almost anything to fix this. Seems like the only thing in my way on this install.

What happens when you do something like the following from the command-line?

valkey-cli -s /run/valkey/valkey.sock PING

I get PONG returned.

When I disable the Redis lines in config.php and restart everything, everything is fine. APCu runs for local memcache, no problems - I left that in there. There’s something up with my redis/valkey configs, likely. It’s baffling. Everything else works great.

Just a wild guess, and I haven’t used Valkey myself, so I’m not sure if there are differences. But with Redis, I also needed to set unixsocketperm to 770 in /etc/redis/redis.conf.

Although since you’re running it on Arch, things might be different there. Also the Wiki doesn’t seem to mention anything about changing unixsocketperm or adding the nextcloud user to the valkey group.

Did you specify the open_basedir option? If so maybe this could be the culprint…

https://wiki.archlinux.org/title/Nextcloud#Valkey_(Redis)

In case you have specified the open_basedir option in the above configuration files and use Valkey locally with a local Unix socket, you have to extend the list of directories where PHP is allowed to read and write files. Locate the relevant lines in the files specified above and add the directory containing the local Unix socket created by Valkey, e.g. /run/valkey.

Note: The sample configuration files nextcloud.ini and nextcloud.conf mentionend in the #Application server section already have open_basedir enabled. So in case you use a copy of one of these files you have to adapt it.

Maybe also search the Wiki for open_basedir. Besides the section I posted above, I found relevant sections under Configuration, Application server, and Troubleshooting.

Thanks for looking into it.

Yes, I already followed all of the above. The problem shows up with the config.php redis entries put in.

Just to make sure I was on the right page, I looked into another NC node (v22, I believe), which has a functioning redis implementation. Everything is exactly the same. The exception being that instead of a ‘redis’ user and group, Valkey has a ‘valkey’ user and group. Both are tuned to work on port 0 in both config.php, as well as in valkey.conf.

valkey.conf and redis.conf are also identical.

unixsockperm is set to 770, as well.

Now, what’s interesting is thathttpd error log shows this:

PHP message: PHP Fatal error:  Uncaught OCP\\HintException: [0]: Memcache OC\\Memcache\\Redis not available for distributed cache (Is the matching PHP module installed and enabled?)\n\n  thrown in /usr/share/webapps/nextcloud/lib/private/Memcache/Factory.php

This is a great hint, but leaves me even more baffled, as I’ve installed and enabled the modules: php-legacy-igbinary; and php-legacy-redis. How do I investigate this further? I’m not too well-versed in php to know where to look if these modules are being loaded and accessed properly.

EDIT: I just checked modules loaded with php-legacy -m. Indeed, these two modules are NOT loaded. Now, where am I going wrong?

In fact, NONE of the optional php-legacy modules are loaded! sodium, sysvsem, etc. Clearly, something’s up in either a config, or something’s not working or running to make sure these are up.

While I do use Arch, btw :wink:, I only run it on my desktop, so unfortunately, I don’t have any experience using PHP or other server-related stuff on Arch.

However, according to the Arch Wiki, the igbinary and redis modules need to be manually enabled in at least two places, the second one depending on whether you’re using PHP-FPM or uWSGI: Nextcloud - ArchWiki

Enable the required extensions igbinary and redis in the relevant configuration files. These are:

  • /etc/webapps/nextcloud/php.ini used by the occ command and the background jobs and
  • depending on the application server you use either
    • /etc/uwsgi/nextcloud.ini in case of uWSGI or
    • /etc/php-legacy/php-fpm.d/nextcloud.conf in case of FPM.

Locate the existing sections where other extensions are enabled and add two additional lines corresponding to igbinary and redis.

Note: It is important to load extension=igbinary before extension=redis. Otherwise occ will report an error (/usr/lib/php-legacy/modules/redis.so: undefined symbol: igbinary_serialize).

Not something I ever had to do on Debian, btw :wink:

See, that’s the thing: I HAVE enabled them in those files and I’ve restarted the app service, as well as the web server. This is why I’m baffled. I mean, the config files are fine. It’s something in the BG that’s not activating them. Clearly, there’s a missing link. I’m just waiting for that ‘A-HA!’ moment to come as I investigate this… with the community’s help.

So, I found the solution on my own, after doing a lot of digging and re-digging of old graves.

In the folder /etc/php-legacy/conf.d, there are the *.ini files for each of the individually installed modules. Inside, there are contents that are commented out by default. In the case of redis, to be loaded correctly as configured in NC (under Arch Linux, anyway), it must be uncommented, for example, from this:

/etc/php-legacy/conf.d/redis.ini

; this extension requires igbinary to be activated as well
; extension=redis

to this:

; this extension requires igbinary to be activated as well
extension=redis

After saving those changes, make sure they’re picked up with a restart of both php-fpm-legacy.service, as well as your web server (in my case, Apache), httpd.service.

Like so:

sudo systemctl restart php-fpm-legacy.service

# reload can be replaced by restart, but reload
# seems more appropriate for Apache.
sudo systemctl reload httpd.service 

With any luck, the problem goes away, as it did for me. I hope it sticks.

It should be mentioned that the other modules, though commented out in their respective *.ini files, load correctly by php-legacy-fpm, as needed. My best guess: the fault appears to be with the php-legacy-redis module.

It should also be noted that by uncommenting extension-redis in redis.ini, the module is loading from the start, whether it’s being initialized by php-legacy-fpm, or not. So, this isn’t quite ideal to NC’s standards. Nonetheless, it works. I’ll report this to the package maintainers and hope for a solution soon.

Hope this helps somebody else.