redis_running returns null even when Redis instance is running

Bug reports
1

Issue Report: redis_running returns null even when Redis instance is running

Environment

  • apiscp version: 3.2.0-dd42bbbfc (revision: dd42bbbfc6b78229069f0ab93e6b9aea6e44efa7)
  • OS version: Linux 6.12.0-124.31.1.el10_1.x86_64
  • Redis/Valkey: Valkey 8.0.6 (Redis compatibility 7.2.4)
  • Debug mode: enabled

Can you reproduce this bug reliably?

Yes, consistently reproducible.

Steps to Reproduce

# 1. Create Redis instance
cpcmd -d test.com redis_create "test"
# Returns: 1 (success)

# 2. List instances - shows instance exists
cpcmd -d test.com redis_list
# Returns:
# test:
#   port: 40011
#   bind: 127.0.0.1
#   unixsocket: null
#   type: tcp

# 3. Check if running - returns empty (null)
cpcmd -d test.com redis_running "test"
# Returns: (empty)

# 4. Verify process is actually running
ss -tlnp | grep :40011
# Returns: LISTEN 0 511 127.0.0.1:40011 0.0.0.0:* users:(("redis-server",pid=872036,fd=8))

The Problem

The Redis instance is running (verified via ss -tlnp), but redis_running returns null.

Root Cause

The PID file contains a different PID than the actual running process:

# PID file contains:
cat /home/virtual/site1/fst/home/testuser/.redis/test/redis.pid
# Returns: 872104

# Actual running process:
ps aux | grep redis-server
# Returns: testuser 872036 ... redis-server 127.0.0.1:40011

The redis_running function reads PID 872104 from the file, but pidMatches(872104, 'redis-server') returns false because process 872104 doesn’t exist. The actual Redis process is running with PID 872036.

Additional Observations

  1. redis_stop also fails because it relies on the same PID file:
cpcmd -d test.com redis_stop "test"
# Returns: WARNING: Instance `test' not running
  1. redis_start reports success but may silently fail if the port is already in use by the orphaned process.
  2. redis_version throws an exception:
strtok(): Argument #1 ($string) must be of type string, null given
[/usr/local/apnscp/lib/modules/redis.php:360]

This appears to be because getFullVersionFromPackage('redis') returns null when Valkey is installed instead of Redis.

Expected Behavior

  • redis_running should return the correct PID when the instance is running
  • redis_stop should be able to stop the running instance
  • redis_version should handle Valkey installations

Suggested Investigation

The issue may be related to how the PID is captured when Redis daemonizes. The daemonize: yes option causes Redis to fork, and it appears the wrong PID (parent instead of child) is being written to the pidfile.

Thank you for looking into this.

2

Thanks for the bug report. This is fixed in edge. If you’re not already on edge, you may switch to it temporarily:

cpcmd scope:set cp.update-policy edge-major

Panel code may be updated by running upcp.

1 Like
3

Thanks it fixes the issue @msaladna

4

@msaladna PTAL

i am calling redis_running soap apis in my node backend, i can see it now returns pid in server but the soap api is still returning nil true… here are the details

redis_running SOAP API returns null even when Redis instance is running

Summary

The redis_running SOAP method returns xsi:nil="true" (null) even when the Redis instance is actively running with a valid PID. The same call via cpcmd correctly returns the PID.

Environment

  • apiscp panel
  • SOAP API via WSDL

Steps to Reproduce

  1. Create a Redis instance named “test2”
  2. Start the Redis instance
  3. Verify it’s running via CLI:
cpcmd -d example.com redis:running "test2"
# Returns: 998070 (PID)
  1. Make the same call via SOAP API:

SOAP Request:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
               xmlns:tns="urn:net.apnscp.api" 
               xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/">
  <soap:Body>
    <tns:redis_running>
      <name>test2</name>
    </tns:redis_running>
  </soap:Body>
</soap:Envelope>

SOAP Response:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:ns1="http://xml.apache.org/xml-soap" 
                   xmlns:ns2="redis_running_Response" 
                   xmlns:ns3="urn:net.apnscp.api" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
                   xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
                   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Header>
    <ns2:Messages>
      <ns1:Map>
        <item><key>message</key><value>Key `save' already present, overwriting</value></item>
        <item><key>errno</key><value>1</value></item>
        <item><key>severity</key><value>DEBUG</value></item>
      </ns1:Map>
      <!-- ... more debug messages ... -->
    </ns2:Messages>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <ns3:redis_runningResponse>
      <return xsi:nil="true"/>
    </ns3:redis_runningResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Expected Behavior

The SOAP response should return the PID (integer) when the Redis instance is running:

<return xsi:type="xsd:int">998070</return>

Actual Behavior

The SOAP response returns null (xsi:nil="true") even though the instance is confirmed running.

WSDL Definition

According to the WSDL, redis_running should return an integer:

<message name="redis_running_request">
    <part name="name" nillable="false" type="xsd:string" />
</message>
<message name="redis_running_response">
    <part name="return" type="xsd:int" />
</message>

Additional Context

  • The SOAP call is made using a valid session ID obtained via admin_hijack
  • Other Redis SOAP methods like redis_list work correctly and return data
  • The debug messages in the SOAP header (Key 'save' already present, overwriting) are identical to those shown in cpcmd, suggesting the method is being invoked correctly
  • This might be a permissions issue where the SOAP session context cannot read the PID file that cpcmd (running as root) can access